draft-ietf-detnet-security-15.txt   draft-ietf-detnet-security-16.txt 
Internet Engineering Task Force E. Grossman, Ed. Internet Engineering Task Force E. Grossman, Ed.
Internet-Draft DOLBY Internet-Draft DOLBY
Intended status: Informational T. Mizrahi Intended status: Informational T. Mizrahi
Expires: August 26, 2021 HUAWEI Expires: September 3, 2021 HUAWEI
A. Hacker A. Hacker
MISTIQ MISTIQ
February 22, 2021 March 2, 2021
Deterministic Networking (DetNet) Security Considerations Deterministic Networking (DetNet) Security Considerations
draft-ietf-detnet-security-15 draft-ietf-detnet-security-16
Abstract Abstract
A DetNet (deterministic network) provides specific performance A DetNet (deterministic network) provides specific performance
guarantees to its data flows, such as extremely low data loss rates guarantees to its data flows, such as extremely low data loss rates
and bounded latency (including bounded latency variation, i.e. and bounded latency (including bounded latency variation, i.e.
"jitter"). As a result, securing a DetNet requires that in addition "jitter"). As a result, securing a DetNet requires that in addition
to the best practice security measures taken for any mission-critical to the best practice security measures taken for any mission-critical
network, additional security measures may be needed to secure the network, additional security measures may be needed to secure the
intended operation of these novel service properties. intended operation of these novel service properties.
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 26, 2021. This Internet-Draft will expire on September 3, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 15 skipping to change at page 4, line 15
8.1.15. Multiple Hops . . . . . . . . . . . . . . . . . . . . 44 8.1.15. Multiple Hops . . . . . . . . . . . . . . . . . . . . 44
8.1.16. Level of Service . . . . . . . . . . . . . . . . . . 44 8.1.16. Level of Service . . . . . . . . . . . . . . . . . . 44
8.1.17. Bounded Latency . . . . . . . . . . . . . . . . . . . 45 8.1.17. Bounded Latency . . . . . . . . . . . . . . . . . . . 45
8.1.18. Low Latency . . . . . . . . . . . . . . . . . . . . . 45 8.1.18. Low Latency . . . . . . . . . . . . . . . . . . . . . 45
8.1.19. Bounded Jitter (Latency Variation) . . . . . . . . . 45 8.1.19. Bounded Jitter (Latency Variation) . . . . . . . . . 45
8.1.20. Symmetrical Path Delays . . . . . . . . . . . . . . . 45 8.1.20. Symmetrical Path Delays . . . . . . . . . . . . . . . 45
8.1.21. Reliability and Availability . . . . . . . . . . . . 46 8.1.21. Reliability and Availability . . . . . . . . . . . . 46
8.1.22. Redundant Paths . . . . . . . . . . . . . . . . . . . 46 8.1.22. Redundant Paths . . . . . . . . . . . . . . . . . . . 46
8.1.23. Security Measures . . . . . . . . . . . . . . . . . . 46 8.1.23. Security Measures . . . . . . . . . . . . . . . . . . 46
8.2. Summary of Attack Types per Use Case Common Theme . . . . 47 8.2. Summary of Attack Types per Use Case Common Theme . . . . 47
8.3. Security Considerations for OAM Traffic . . . . . . . . . 49 9. Security Considerations for OAM Traffic . . . . . . . . . . . 49
9. DetNet Technology-Specific Threats . . . . . . . . . . . . . 49 10. DetNet Technology-Specific Threats . . . . . . . . . . . . . 49
9.1. IP . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 10.1. IP . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
9.2. MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . 51 10.2. MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . 51
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52
11. Security Considerations . . . . . . . . . . . . . . . . . . . 52 12. Security Considerations . . . . . . . . . . . . . . . . . . . 52
12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 52 13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 52
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 53 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 53
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 53
14.1. Normative References . . . . . . . . . . . . . . . . . . 53 15.1. Normative References . . . . . . . . . . . . . . . . . . 53
14.2. Informative References . . . . . . . . . . . . . . . . . 54 15.2. Informative References . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59
1. Introduction 1. Introduction
A deterministic IP network (IETF DetNet, [RFC8655]) can carry data A deterministic IP network (IETF DetNet, [RFC8655]) can carry data
flows for real-time applications with extremely low data loss rates flows for real-time applications with extremely low data loss rates
and bounded latency. The bounds on latency defined by DetNet (as and bounded latency. The bounds on latency defined by DetNet (as
described in [I-D.ietf-detnet-flow-information-model]) include both described in [I-D.ietf-detnet-flow-information-model]) include both
worst case latency (Maximum Latency, Section 5.9.2) and worst case worst case latency (Maximum Latency, Section 5.9.2) and worst case
jitter (Maximum Latency Variation, Section 5.9.3). Data flows with jitter (Maximum Latency Variation, Section 5.9.3). Data flows with
skipping to change at page 6, line 40 skipping to change at page 6, line 40
properties" might be that dropping of more than a specific number of properties" might be that dropping of more than a specific number of
packets in a row is not acceptable according to the service level packets in a row is not acceptable according to the service level
agreement. agreement.
The exact security requirements for any given DetNet are necessarily The exact security requirements for any given DetNet are necessarily
specific to the use cases handled by that network. Thus the reader specific to the use cases handled by that network. Thus the reader
is assumed to be familiar with the specific security requirements of is assumed to be familiar with the specific security requirements of
their use cases, for example those outlined in the DetNet Use Cases their use cases, for example those outlined in the DetNet Use Cases
[RFC8578] and the Security Considerations sections of the DetNet [RFC8578] and the Security Considerations sections of the DetNet
documents applicable to the network technologies in use, for example documents applicable to the network technologies in use, for example
[RFC8939]). Readers can find a general introduction to the DetNet [RFC8939] for an IP data plane and [RFC8964] for an MPLS data plane.
Architecture in [RFC8655], the DetNet Data Plane in [RFC8938], and Readers can find a general introduction to the DetNet Architecture in
the Flow Information Model in [RFC8655], the DetNet Data Plane in [RFC8938], and the Flow
[I-D.ietf-detnet-flow-information-model]. Information Model in [I-D.ietf-detnet-flow-information-model].
The DetNet technologies include ways to: The DetNet technologies include ways to:
o Assign data plane resources for DetNet flows in some or all of the o Assign data plane resources for DetNet flows in some or all of the
intermediate nodes (routers) along the path of the flow intermediate nodes (routers) along the path of the flow
o Provide explicit routes for DetNet flows that do not dynamically o Provide explicit routes for DetNet flows that do not dynamically
change with the network topology in ways that affect the quality change with the network topology in ways that affect the quality
of service received by the affected flow(s) of service received by the affected flow(s)
skipping to change at page 7, line 20 skipping to change at page 7, line 20
ensure delivery of the data in each packet in spite of the loss of ensure delivery of the data in each packet in spite of the loss of
a path. a path.
This document includes sections considering DetNet component design This document includes sections considering DetNet component design
as well as system design. The latter includes a taxonomy and as well as system design. The latter includes a taxonomy and
analysis of threats, threat impacts and mitigations, and an analysis of threats, threat impacts and mitigations, and an
association of attacks with use cases (based on the Use Case Common association of attacks with use cases (based on the Use Case Common
Themes section of the DetNet Use Cases [RFC8578]). Themes section of the DetNet Use Cases [RFC8578]).
This document is based on the premise that there will be a very broad This document is based on the premise that there will be a very broad
range of DetNet applications and use cases, ranging in size scope range of DetNet applications and use cases, ranging in size and scope
from individual industrial machines to networks that span an entire from individual industrial machines to networks that span an entire
country ([RFC8578]). Thus no single set of prescriptions (such as country ([RFC8578]). Thus no single set of prescriptions (such as
exactly which mitigation should be applied to which segment of a exactly which mitigation should be applied to which segment of a
DetNet) can be applicable to all of them, and indeed any single one DetNet) can be applicable to all of them, and indeed any single one
that we might prescribe would inevitably prove impractical for some that we might prescribe would inevitably prove impractical for some
use case, perhaps one that does not even exist at the time of this use case, perhaps one that does not even exist at the time of this
writing. Thus we are not prescriptive here - we are stating the writing. Thus we are not prescriptive here - we are stating the
desired end result, with the understanding that most DetNet use cases desired end result, with the understanding that most DetNet use cases
will necessarily differ from each other, and there is no "one size will necessarily differ from each other, and there is no "one size
fits all". fits all".
skipping to change at page 13, line 41 skipping to change at page 13, line 41
continued safe operation of the system. For example, the network continued safe operation of the system. For example, the network
(i.e. the controller plane and data plane working together) must (i.e. the controller plane and data plane working together) must
mitigate in a timely fashion any potential adverse effect on mitigate in a timely fashion any potential adverse effect on
mechanical devices controlled by the network. mechanical devices controlled by the network.
4. DetNet Security Considerations Compared With DiffServ Security 4. DetNet Security Considerations Compared With DiffServ Security
Considerations Considerations
DetNet is designed to be compatible with DiffServ [RFC2474] as DetNet is designed to be compatible with DiffServ [RFC2474] as
applied to IT traffic in the DetNet. DetNet also incorporates the applied to IT traffic in the DetNet. DetNet also incorporates the
use of the 6-bit value of the DSCP field of the Type of Service (ToS) use of the 6-bit value of the DCSP field of the Type of Service
byte of the IPv4 header (or the Traffic Class byte in IPv6) for flow (IPv4) and Traffic Class (IPv6) bytes for flow identification.
identification for OT traffic. However, the DetNet interpretation of However, the DetNet interpretation of the DSCP value for OT traffic
the DSCP value for OT traffic is not equivalent to the PHB selection is not equivalent to the PHB selection behavior as defined by
behavior as defined by DiffServ. DiffServ.
Thus security consideration for DetNet have some aspects in common Thus security consideration for DetNet have some aspects in common
with DiffServ, in fact overlapping 100% with respect to IP IT with DiffServ, in fact overlapping 100% with respect to IP IT
traffic. Security considerations for these aspects are part of the traffic. Security considerations for these aspects are part of the
existing literature on IP network security, specifically the Security existing literature on IP network security, specifically the Security
Considerations sections of [RFC2474] and [RFC2475]. However, DetNet Considerations sections of [RFC2474] and [RFC2475]. However, DetNet
also introduces timing and other considerations which are not present also introduces timing and other considerations which are not present
in DiffServ, so the DiffServ security considerations are a subset of in DiffServ, so the DiffServ security considerations are a subset of
the DetNet security considerations. the DetNet security considerations.
skipping to change at page 14, line 38 skipping to change at page 14, line 38
marking) of the DSCP values of packets destined for DetNet OT flows marking) of the DSCP values of packets destined for DetNet OT flows
is expected to occur at the ingress to the DetNet domain; once inside is expected to occur at the ingress to the DetNet domain; once inside
the domain, maintaining the integrity of the DSCP values is subject the domain, maintaining the integrity of the DSCP values is subject
to the same handling considerations as any other field in the packet. to the same handling considerations as any other field in the packet.
5. Security Threats 5. Security Threats
This section presents a taxonomy of threats, and analyzes the This section presents a taxonomy of threats, and analyzes the
possible threats in a DetNet-enabled network. The threats considered possible threats in a DetNet-enabled network. The threats considered
in this section are independent of any specific technologies used to in this section are independent of any specific technologies used to
implement the DetNet; Section 9 considers attacks that are associated implement the DetNet; Section 10 considers attacks that are
with the DetNet technologies encompassed by [RFC8938]. associated with the DetNet technologies encompassed by [RFC8938].
We distinguish controller plane threats from data plane threats. The We distinguish controller plane threats from data plane threats. The
attack surface may be the same, but the types of attacks as well as attack surface may be the same, but the types of attacks as well as
the motivation behind them, are different. For example, a delay the motivation behind them, are different. For example, a delay
attack is more relevant to data plane than to controller plane. attack is more relevant to data plane than to controller plane.
There is also a difference in terms of security solutions: the way There is also a difference in terms of security solutions: the way
you secure the data plane is often different than the way you secure you secure the data plane is often different than the way you secure
the controller plane. the controller plane.
5.1. Threat Taxonomy 5.1. Threat Taxonomy
skipping to change at page 16, line 48 skipping to change at page 16, line 48
may be part of DetNet flows or non-DetNet traffic. may be part of DetNet flows or non-DetNet traffic.
Another example of a resource segmentation attack is the case in Another example of a resource segmentation attack is the case in
which an attacker is able to overload the exception path queue on the which an attacker is able to overload the exception path queue on the
router, i.e. a "slow path" typically taken by control or OAM packets router, i.e. a "slow path" typically taken by control or OAM packets
which are diverted from the data plane because they require which are diverted from the data plane because they require
processing by a CPU. DetNet OT flows are typically configured to processing by a CPU. DetNet OT flows are typically configured to
take the "fast path" through the data plane, to minimize latency. take the "fast path" through the data plane, to minimize latency.
However if there is only one queue from the forwarding ASIC to the However if there is only one queue from the forwarding ASIC to the
exception path, and for some reason the system is configured such exception path, and for some reason the system is configured such
that DetNet packets must be handled on this exception path, then that any DetNet packets must be handled on this exception path, then
saturating the exception path could result in delaying or dropping of saturating the exception path could result in delaying or dropping of
DetNet packets. DetNet packets.
5.2.4. Packet Replication and Elimination 5.2.4. Packet Replication and Elimination
5.2.4.1. Replication: Increased Attack Surface 5.2.4.1. Replication: Increased Attack Surface
Redundancy is intended to increase the robustness and survivability Redundancy is intended to increase the robustness and survivability
of DetNet flows, and replication over multiple paths can potentially of DetNet flows, and replication over multiple paths can potentially
mitigate an attack that is limited to a single path. However, the mitigate an attack that is limited to a single path. However, the
skipping to change at page 23, line 25 skipping to change at page 23, line 25
the DetNet flow are likely to have strict delivery time requirements. the DetNet flow are likely to have strict delivery time requirements.
For a single path scenario, disruption within the single flow is a For a single path scenario, disruption within the single flow is a
real possibility. In a multipath scenario, large delays or real possibility. In a multipath scenario, large delays or
instabilities in one DetNet flow can also lead to increased buffer instabilities in one DetNet flow can also lead to increased buffer
and processor resource consumption at the eliminating router. and processor resource consumption at the eliminating router.
A data-plane delay attack on a system controlling substantial moving A data-plane delay attack on a system controlling substantial moving
devices, for example in industrial automation, can cause physical devices, for example in industrial automation, can cause physical
damage. For example, if the network promises a bounded latency of damage. For example, if the network promises a bounded latency of
2ms for a flow, yet the machine receives it with 5ms latency, control 2ms for a flow, yet the machine receives it with 5ms latency, the
loop of the machine can become unstable. control loop of the machine may become unstable.
6.1.2. Controller Plane Delay Attacks 6.1.2. Controller Plane Delay Attacks
In and of itself, this is not directly a threat to the DetNet In and of itself, this is not directly a threat to the DetNet
service, but the effects of delaying control messages can have quite service, but the effects of delaying control messages can have quite
adverse effects later. adverse effects later.
o Delayed tear-down can lead to resource leakage, which in turn can o Delayed tear-down can lead to resource leakage, which in turn can
result in failure to allocate new DetNet flows, finally giving result in failure to allocate new DetNet flows, finally giving
rise to a denial of service attack. rise to a denial of service attack.
skipping to change at page 27, line 30 skipping to change at page 27, line 30
This section describes a set of measures that can be taken to This section describes a set of measures that can be taken to
mitigate the attacks described in Section 5, Security Threats. These mitigate the attacks described in Section 5, Security Threats. These
mitigations should be viewed as a set of tools, any of which can be mitigations should be viewed as a set of tools, any of which can be
used individually or in concert. The DetNet component and/or system used individually or in concert. The DetNet component and/or system
and/or application designer can apply these tools, as necessary based and/or application designer can apply these tools, as necessary based
on a system-specific threat analysis. on a system-specific threat analysis.
Some of the technology-specific security considerations and Some of the technology-specific security considerations and
mitigation approaches are further discussed in the DetNet data plane mitigation approaches are further discussed in the DetNet data plane
solution documents, such as [RFC8939], [RFC8938], solution documents, such as [RFC8938], [RFC8939], [RFC8964],
[I-D.ietf-detnet-mpls-over-udp-ip], and [I-D.ietf-detnet-mpls-over-udp-ip], and
[I-D.ietf-detnet-ip-over-mpls]. [I-D.ietf-detnet-ip-over-mpls].
7.1. Path Redundancy 7.1. Path Redundancy
Description Description
A DetNet flow that can be forwarded simultaneously over multiple A DetNet flow that can be forwarded simultaneously over multiple
paths. Packet replication and elimination [RFC8655] provides paths. Packet replication and elimination [RFC8655] provides
resiliency to dropped or delayed packets. This redundancy resiliency to dropped or delayed packets. This redundancy
skipping to change at page 28, line 24 skipping to change at page 28, line 24
Integrity Protection in the scope of DetNet is the ability to Integrity Protection in the scope of DetNet is the ability to
detect if a packet header has been modified (maliciously or detect if a packet header has been modified (maliciously or
otherwise) and if so, take some appropriate action (as discussed otherwise) and if so, take some appropriate action (as discussed
in Section 7.7). The decision on where in the network to apply in Section 7.7). The decision on where in the network to apply
integrity protection is part of the DetNet system design, and the integrity protection is part of the DetNet system design, and the
implementation of the protection method itself is a part of a implementation of the protection method itself is a part of a
DetNet component design. DetNet component design.
The most common technique for detecting header modification is the The most common technique for detecting header modification is the
use of a Message Authentication Code (MAC) (for examples see use of a Message Authentication Code (MAC) (for examples see
Section 9). The MAC can be distributed either in-line (included Section 10). The MAC can be distributed either in-line (included
in the same packet) or via a side channel. Of these, the in-line in the same packet) or via a side channel. Of these, the in-line
method is generally preferred due to the low latency that may be method is generally preferred due to the low latency that may be
required on DetNet flows and the relative complexity and required on DetNet flows and the relative complexity and
computational overhead of a sideband approach. computational overhead of a sideband approach.
There are different levels of security available for integrity There are different levels of security available for integrity
protection, ranging from the basic ability to detect if a header protection, ranging from the basic ability to detect if a header
has been corrupted in transit (no malicious attack) to stopping a has been corrupted in transit (no malicious attack) to stopping a
skilled and determined attacker capable of both subtly modifying skilled and determined attacker capable of both subtly modifying
fields in the headers as well as updating an unsigned MAC. Common fields in the headers as well as updating an unkeyed checksum.
for all are the 2 steps that need to be performed in both ends. Common for all are the 2 steps that need to be performed in both
The first is computing the checksum or MAC. The corresponding ends. The first is computing the checksum or MAC. The
verification step must perform the same steps before comparing the corresponding verification step must perform the same steps before
provided with the computed value. Only then can the receiver be comparing the provided with the computed value. Only then can the
reasonably sure that the header is authentic. receiver be reasonably sure that the header is authentic.
The most basic protection mechanism consists of computing a simple The most basic protection mechanism consists of computing a simple
checksum of the header fields and provide it to the next entity in checksum of the header fields and provide it to the next entity in
the packets path for verification. Using a MAC combined with a the packets path for verification. Using a MAC combined with a
secret key provides the best protection against modification and secret key provides the best protection against modification and
replication attacks (see Section 5.2.2 and Section 5.2.4). This replication attacks (see Section 5.2.2 and Section 5.2.4). This
MAC usage needs to be part of a security association that is MAC usage needs to be part of a security association that is
established and managed by a security association protocol (such established and managed by a security association protocol (such
as IKEv2 for IPsec security associations). Integrity protection as IKEv2 for IPsec security associations). Integrity protection
in the controller plane is discussed in Section 7.6. The secret in the controller plane is discussed in Section 7.6. The secret
skipping to change at page 49, line 16 skipping to change at page 49, line 16
+----------------------------+--+--+--+--+--+--+--+--+--+--+--+ +----------------------------+--+--+--+--+--+--+--+--+--+--+--+
|Reliability and Availability| +| +| +| +| +| +| +| +| +| +| +| |Reliability and Availability| +| +| +| +| +| +| +| +| +| +| +|
+----------------------------+--+--+--+--+--+--+--+--+--+--+--+ +----------------------------+--+--+--+--+--+--+--+--+--+--+--+
|Redundant Paths | | | | +| +| | | +| +| | | |Redundant Paths | | | | +| +| | | +| +| | |
+----------------------------+--+--+--+--+--+--+--+--+--+--+--+ +----------------------------+--+--+--+--+--+--+--+--+--+--+--+
|Security Measures | | | | | | | | | | | | |Security Measures | | | | | | | | | | | |
+----------------------------+--+--+--+--+--+--+--+--+--+--+--+ +----------------------------+--+--+--+--+--+--+--+--+--+--+--+
Figure 5: Mapping Between Themes and Attacks Figure 5: Mapping Between Themes and Attacks
8.3. Security Considerations for OAM Traffic 9. Security Considerations for OAM Traffic
This section considers DetNet-specific security considerations for This section considers DetNet-specific security considerations for
packet traffic that is generated and transmitted over a DetNet as packet traffic that is generated and transmitted over a DetNet as
part of OAM (Operations, Administration, and Maintenance). For the part of OAM (Operations, Administration, and Maintenance). For the
purposes of this discussion, OAM traffic falls into one of two basic purposes of this discussion, OAM traffic falls into one of two basic
types: types:
o OAM traffic generated by the network itself. The additional o OAM traffic generated by the network itself. The additional
bandwidth required for such packets is added by the network bandwidth required for such packets is added by the network
administration, presumably transparent to the customer. Security administration, presumably transparent to the customer. Security
skipping to change at page 49, line 44 skipping to change at page 49, line 44
exactly the same as for any other customer data flows. exactly the same as for any other customer data flows.
From the perspective of an attack, OAM traffic is indistinguishable From the perspective of an attack, OAM traffic is indistinguishable
from DetNet traffic and the network needs to be secure against from DetNet traffic and the network needs to be secure against
injection, removal, or modification of traffic of any kind, including injection, removal, or modification of traffic of any kind, including
OAM traffic. A DetNet is sensitive to any form of packet injection, OAM traffic. A DetNet is sensitive to any form of packet injection,
removal or manipulation and in this respect DetNet OAM traffic is no removal or manipulation and in this respect DetNet OAM traffic is no
different. Techniques for securing a DetNet against these threats different. Techniques for securing a DetNet against these threats
have been discussed elsewhere in this document. have been discussed elsewhere in this document.
9. DetNet Technology-Specific Threats 10. DetNet Technology-Specific Threats
Section 5, Security Threats, described threats which are independent Section 5, Security Threats, described threats which are independent
of a DetNet implementation. This section considers threats of a DetNet implementation. This section considers threats
specifically related to the IP- and MPLS-specific aspects of DetNet specifically related to the IP- and MPLS-specific aspects of DetNet
implementations. implementations.
The primary security considerations for the data plane specifically The primary security considerations for the data plane specifically
are to maintain the integrity of the data and the delivery of the are to maintain the integrity of the data and the delivery of the
associated DetNet service traversing the DetNet network. associated DetNet service traversing the DetNet network.
The primary relevant differences between IP and MPLS implementations The primary relevant differences between IP and MPLS implementations
are in flow identification and OAM methodologies. are in flow identification and OAM methodologies.
As noted in [RFC8655], DetNet operates at the IP layer ( [RFC8939]) As noted in [RFC8655], DetNet operates at the IP layer ( [RFC8939])
and delivers service over sub-layer technologies such as MPLS and delivers service over sub-layer technologies such as MPLS
([RFC8938]) and IEEE 802.1 Time-Sensitive Networking (TSN) ([RFC8964]) and IEEE 802.1 Time-Sensitive Networking (TSN)
([I-D.ietf-detnet-ip-over-tsn]). Application flows can be protected ([I-D.ietf-detnet-ip-over-tsn]). Application flows can be protected
through whatever means are provided by the layer and sub-layer through whatever means are provided by the layer and sub-layer
technologies. For example, technology-specific encryption may be technologies. For example, technology-specific encryption may be
used, for example for IP flows, IPSec [RFC4301]. For IP over used, for example for IP flows, IPSec [RFC4301]. For IP over
Ethernet (Layer 2) flows using an underlying sub-net, MACSec Ethernet (Layer 2) flows using an underlying sub-net, MACSec
[IEEE802.1AE-2018] may be appropriate. For some use cases packet [IEEE802.1AE-2018] may be appropriate. For some use cases packet
integrity protection without encryption may be sufficient. integrity protection without encryption may be sufficient.
However, if the DetNet nodes cannot decrypt IPsec traffic, then However, if the DetNet nodes cannot decrypt IPsec traffic, then
DetNet flow identification for encrypted IP traffic flows must be DetNet flow identification for encrypted IP traffic flows must be
skipping to change at page 50, line 42 skipping to change at page 50, line 42
which are the two IP addresses and the DSCP. If the IPsec sessions which are the two IP addresses and the DSCP. If the IPsec sessions
are established by a controller, then this controller could also are established by a controller, then this controller could also
transmit (in the clear) the Security Parameter Index (SPI) and thus transmit (in the clear) the Security Parameter Index (SPI) and thus
the SPI could be used (in addition to the pair of IP addresses) for the SPI could be used (in addition to the pair of IP addresses) for
flow identification. Identification of DetNet flows over IPsec is flow identification. Identification of DetNet flows over IPsec is
further discussed in Section 5.1.2.3. of [RFC8939]. further discussed in Section 5.1.2.3. of [RFC8939].
Sections below discuss threats specific to IP and MPLS in more Sections below discuss threats specific to IP and MPLS in more
detail. detail.
9.1. IP 10.1. IP
The IP protocol has a long history of security considerations and The IP protocol has a long history of security considerations and
architectural protection mechanisms. From a data plane perspective architectural protection mechanisms. From a data plane perspective
DetNet does not add or modify any IP header information, so the DetNet does not add or modify any IP header information, so the
carriage of DetNet traffic over an IP data plane does not introduce carriage of DetNet traffic over an IP data plane does not introduce
any new security issues that were not there before, apart from those any new security issues that were not there before, apart from those
already described in the data-plane-independent threats section already described in the data-plane-independent threats section
Section 5, Security Threats. Section 5, Security Threats.
Thus the security considerations for a DetNet based on an IP data Thus the security considerations for a DetNet based on an IP data
skipping to change at page 51, line 35 skipping to change at page 51, line 35
isolation between flows, for example by protecting the forwarding isolation between flows, for example by protecting the forwarding
bandwidth and related resources so that they are available to detnet bandwidth and related resources so that they are available to detnet
traffic, by whatever means are appropriate for the data plane of that traffic, by whatever means are appropriate for the data plane of that
network, for example through the use of queueing mechanisms. network, for example through the use of queueing mechanisms.
In a VPN, bandwidth is generally guaranteed over a period of time, In a VPN, bandwidth is generally guaranteed over a period of time,
whereas in DetNet it is not aggregated over time. This implies that whereas in DetNet it is not aggregated over time. This implies that
any VPN-type protection mechanism must also maintain the DetNet any VPN-type protection mechanism must also maintain the DetNet
timing constraints. timing constraints.
9.2. MPLS 10.2. MPLS
An MPLS network carrying DetNet traffic is expected to be a "well- An MPLS network carrying DetNet traffic is expected to be a "well-
managed" network. Given that this is the case, it is difficult for managed" network. Given that this is the case, it is difficult for
an attacker to pass a raw MPLS encoded packet into a network because an attacker to pass a raw MPLS encoded packet into a network because
operators have considerable experience at excluding such packets at operators have considerable experience at excluding such packets at
the network boundaries, as well as excluding MPLS packets being the network boundaries, as well as excluding MPLS packets being
inserted through the use of a tunnel. inserted through the use of a tunnel.
MPLS security is discussed extensively in [RFC5920] ("Security MPLS security is discussed extensively in [RFC5920] ("Security
Framework for MPLS and GMPLS Networks") to which the reader is Framework for MPLS and GMPLS Networks") to which the reader is
skipping to change at page 52, line 10 skipping to change at page 52, line 10
[RFC6941] builds on [RFC5920] by providing additional security [RFC6941] builds on [RFC5920] by providing additional security
considerations that are applicable to the MPLS-TP extensions considerations that are applicable to the MPLS-TP extensions
appropriate to the MPLS Transport Profile [RFC5921], and thus to the appropriate to the MPLS Transport Profile [RFC5921], and thus to the
operation of DetNet over some types of MPLS network. operation of DetNet over some types of MPLS network.
[RFC5921] introduces to MPLS new Operations, Administration, and [RFC5921] introduces to MPLS new Operations, Administration, and
Maintenance (OAM) capabilities, a transport-oriented path protection Maintenance (OAM) capabilities, a transport-oriented path protection
mechanism, and strong emphasis on static provisioning supported by mechanism, and strong emphasis on static provisioning supported by
network management systems. network management systems.
The operation of DetNet over an MPLS network is modeled on the The operation of DetNet over an MPLS network builds on MPLS and
operation of multi-segment pseudowires (MS-PW). Thus for guidance on pseudowire encapsulation. Thus for guidance on securing the DetNet
securing the DetNet elements of DetNet over MPLS the reader is elements of DetNet over MPLS the reader is also referred to the
referred to the security considerations of [RFC8077], [RFC3931], security considerations of [RFC4385], [RFC5586], [RFC3985],
[RFC3985], [RFC6073], and [RFC6478]. [RFC6073], and [RFC6478].
Having attended to the conventional aspects of network security it is Having attended to the conventional aspects of network security it is
necessary to attend to the dynamic aspects. The closest experience necessary to attend to the dynamic aspects. The closest experience
that the IETF has with securing protocols that are sensitive to that the IETF has with securing protocols that are sensitive to
manipulation of delay are the two way time transfer protocols (TWTT), manipulation of delay are the two way time transfer protocols (TWTT),
which are NTP [RFC5905] and Precision Time Protocol [IEEE1588]. The which are NTP [RFC5905] and Precision Time Protocol [IEEE1588]. The
security requirements for these are described in [RFC7384]. security requirements for these are described in [RFC7384].
One particular problem that has been observed in operational tests of One particular problem that has been observed in operational tests of
TWTT protocols is the ability for two closely but not completely TWTT protocols is the ability for two closely but not completely
synchronized flows to beat and cause a sudden phase hit to one of the synchronized flows to beat and cause a sudden phase hit to one of the
flows. This can be mitigated by the careful use of a scheduling flows. This can be mitigated by the careful use of a scheduling
system in the underlying packet transport. system in the underlying packet transport.
Some investigations into protection of MPLS systems against dynamic Some investigations into protection of MPLS systems against dynamic
attacks exist, such as [I-D.ietf-mpls-opportunistic-encrypt]; perhaps attacks exist, such as [I-D.ietf-mpls-opportunistic-encrypt]; perhaps
deployment of DetNets will encourage additional such investigations. deployment of DetNets will encourage additional such investigations.
10. IANA Considerations 11. IANA Considerations
This document includes no requests from IANA. This document includes no requests from IANA.
11. Security Considerations 12. Security Considerations
The security considerations of DetNet networks are presented The security considerations of DetNet networks are presented
throughout this document. throughout this document.
12. Privacy Considerations 13. Privacy Considerations
Privacy in the context of DetNet is maintained by the base Privacy in the context of DetNet is maintained by the base
technologies specific to the DetNet and user traffic. For example technologies specific to the DetNet and user traffic. For example
TSN can use MACsec, IP can use IPsec, applications can use IP TSN can use MACsec, IP can use IPsec, applications can use IP
transport protocol-provided methods e.g. TLS and DTLS. MPLS transport protocol-provided methods e.g. TLS and DTLS. MPLS
typically uses L2/L3 VPNs combined with the previously mentioned typically uses L2/L3 VPNs combined with the previously mentioned
privacy methods. privacy methods.
However, note that reconnaissance threats such as traffic analysis However, note that reconnaissance threats such as traffic analysis
and monitoring of electrical side channels can still cause there to and monitoring of electrical side channels can still cause there to
be privacy considerations even when traffic is encrypted. be privacy considerations even when traffic is encrypted.
13. Contributors 14. Contributors
The Editor would like to recognize the contributions of the following The Editor would like to recognize the contributions of the following
individuals to this draft. individuals to this draft.
Subir Das (Applied Communication Sciences) Subir Das (Applied Communication Sciences)
150 Mount Airy Road, Basking Ridge, New Jersey, 07920, USA 150 Mount Airy Road, Basking Ridge, New Jersey, 07920, USA
email sdas@appcomsci.com email sdas@appcomsci.com
John Dowdell (Airbus Defence and Space) John Dowdell (Airbus Defence and Space)
Celtic Springs, Newport, NP10 8FZ, United Kingdom Celtic Springs, Newport, NP10 8FZ, United Kingdom
skipping to change at page 53, line 42 skipping to change at page 53, line 42
email: stewart.bryant@gmail.com email: stewart.bryant@gmail.com
David Black (Dell EMC) David Black (Dell EMC)
176 South Street, Hopkinton, MA 01748, USA 176 South Street, Hopkinton, MA 01748, USA
email: david.black@dell.com email: david.black@dell.com
Carsten Bormann (Universitat Bremen TZI) Carsten Bormann (Universitat Bremen TZI)
Postfach 330440, D-28359 Bremen, Germany Postfach 330440, D-28359 Bremen, Germany
email: cabo@tzi.org email: cabo@tzi.org
14. References 15. References
14.1. Normative References 15.1. Normative References
[RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", RFC 8655, "Deterministic Networking Architecture", RFC 8655,
DOI 10.17487/RFC8655, October 2019, DOI 10.17487/RFC8655, October 2019,
<https://www.rfc-editor.org/info/rfc8655>. <https://www.rfc-editor.org/info/rfc8655>.
[RFC8938] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S. [RFC8938] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S.
Bryant, "Deterministic Networking (DetNet) Data Plane Bryant, "Deterministic Networking (DetNet) Data Plane
Framework", RFC 8938, DOI 10.17487/RFC8938, November 2020, Framework", RFC 8938, DOI 10.17487/RFC8938, November 2020,
<https://www.rfc-editor.org/info/rfc8938>. <https://www.rfc-editor.org/info/rfc8938>.
[RFC8939] Varga, B., Ed., Farkas, J., Berger, L., Fedyk, D., and S. [RFC8939] Varga, B., Ed., Farkas, J., Berger, L., Fedyk, D., and S.
Bryant, "Deterministic Networking (DetNet) Data Plane: Bryant, "Deterministic Networking (DetNet) Data Plane:
IP", RFC 8939, DOI 10.17487/RFC8939, November 2020, IP", RFC 8939, DOI 10.17487/RFC8939, November 2020,
<https://www.rfc-editor.org/info/rfc8939>. <https://www.rfc-editor.org/info/rfc8939>.
14.2. Informative References [RFC8964] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., Bryant,
S., and J. Korhonen, "Deterministic Networking (DetNet)
Data Plane: MPLS", RFC 8964, DOI 10.17487/RFC8964, January
2021, <https://www.rfc-editor.org/info/rfc8964>.
15.2. Informative References
[ARINC664P7] [ARINC664P7]
ARINC, "ARINC 664 Aircraft Data Network, Part 7, Avionics ARINC, "ARINC 664 Aircraft Data Network, Part 7, Avionics
Full-Duplex Switched Ethernet Network", 2009. Full-Duplex Switched Ethernet Network", 2009.
[I-D.ietf-detnet-flow-information-model] [I-D.ietf-detnet-flow-information-model]
Varga, B., Farkas, J., Cummings, R., Jiang, Y., and D. Varga, B., Farkas, J., Cummings, R., Jiang, Y., and D.
Fedyk, "DetNet Flow and Service Information Model", draft- Fedyk, "DetNet Flow and Service Information Model", draft-
ietf-detnet-flow-information-model-14 (work in progress), ietf-detnet-flow-information-model-14 (work in progress),
January 2021. January 2021.
skipping to change at page 56, line 44 skipping to change at page 57, line 5
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
<https://www.rfc-editor.org/info/rfc2475>. <https://www.rfc-editor.org/info/rfc2475>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003, DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/info/rfc3552>. <https://www.rfc-editor.org/info/rfc3552>.
[RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed.,
"Layer Two Tunneling Protocol - Version 3 (L2TPv3)",
RFC 3931, DOI 10.17487/RFC3931, March 2005,
<https://www.rfc-editor.org/info/rfc3931>.
[RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation
Edge-to-Edge (PWE3) Architecture", RFC 3985, Edge-to-Edge (PWE3) Architecture", RFC 3985,
DOI 10.17487/RFC3985, March 2005, DOI 10.17487/RFC3985, March 2005,
<https://www.rfc-editor.org/info/rfc3985>. <https://www.rfc-editor.org/info/rfc3985>.
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic
Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107,
June 2005, <https://www.rfc-editor.org/info/rfc4107>. June 2005, <https://www.rfc-editor.org/info/rfc4107>.
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
skipping to change at page 57, line 21 skipping to change at page 57, line 26
January 2006, <https://www.rfc-editor.org/info/rfc4253>. January 2006, <https://www.rfc-editor.org/info/rfc4253>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>. December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005, DOI 10.17487/RFC4302, December 2005,
<https://www.rfc-editor.org/info/rfc4302>. <https://www.rfc-editor.org/info/rfc4302>.
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385,
February 2006, <https://www.rfc-editor.org/info/rfc4385>.
[RFC4432] Harris, B., "RSA Key Exchange for the Secure Shell (SSH) [RFC4432] Harris, B., "RSA Key Exchange for the Secure Shell (SSH)
Transport Layer Protocol", RFC 4432, DOI 10.17487/RFC4432, Transport Layer Protocol", RFC 4432, DOI 10.17487/RFC4432,
March 2006, <https://www.rfc-editor.org/info/rfc4432>. March 2006, <https://www.rfc-editor.org/info/rfc4432>.
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
"MPLS Generic Associated Channel", RFC 5586,
DOI 10.17487/RFC5586, June 2009,
<https://www.rfc-editor.org/info/rfc5586>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<https://www.rfc-editor.org/info/rfc5880>. <https://www.rfc-editor.org/info/rfc5880>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>. <https://www.rfc-editor.org/info/rfc5905>.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
skipping to change at page 59, line 5 skipping to change at page 59, line 19
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <https://www.rfc-editor.org/info/rfc7748>. 2016, <https://www.rfc-editor.org/info/rfc7748>.
[RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID [RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID
Separation Protocol (LISP) Threat Analysis", RFC 7835, Separation Protocol (LISP) Threat Analysis", RFC 7835,
DOI 10.17487/RFC7835, April 2016, DOI 10.17487/RFC7835, April 2016,
<https://www.rfc-editor.org/info/rfc7835>. <https://www.rfc-editor.org/info/rfc7835>.
[RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and
Maintenance Using the Label Distribution Protocol (LDP)",
STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017,
<https://www.rfc-editor.org/info/rfc8077>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases", [RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases",
RFC 8578, DOI 10.17487/RFC8578, May 2019, RFC 8578, DOI 10.17487/RFC8578, May 2019,
<https://www.rfc-editor.org/info/rfc8578>. <https://www.rfc-editor.org/info/rfc8578>.
[RS_DEF] Wikipedia, "RS Definition", 2020, [RS_DEF] Wikipedia, "RS Definition", 2020,
<https://en.wikipedia.org/wiki/Network_segmentation>. <https://en.wikipedia.org/wiki/Network_segmentation>.
 End of changes. 31 change blocks. 
65 lines changed or deleted 70 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/