draft-ietf-detnet-security-03.txt   draft-ietf-detnet-security-04.txt 
Internet Engineering Task Force T. Mizrahi Internet Engineering Task Force T. Mizrahi
Internet-Draft HUAWEI Internet-Draft HUAWEI
Intended status: Informational E. Grossman, Ed. Intended status: Informational E. Grossman, Ed.
Expires: April 19, 2019 DOLBY Expires: September 3, 2019 DOLBY
A. Hacker A. Hacker
MISTIQ MISTIQ
S. Das S. Das
Applied Communication Sciences Applied Communication Sciences
J. Dowdell J. Dowdell
Airbus Defence and Space Airbus Defence and Space
H. Austad H. Austad
Cisco Systems Cisco Systems
K. Stanton K. Stanton
INTEL INTEL
N. Finn N. Finn
HUAWEI HUAWEI
October 16, 2018 March 2, 2019
Deterministic Networking (DetNet) Security Considerations Deterministic Networking (DetNet) Security Considerations
draft-ietf-detnet-security-03 draft-ietf-detnet-security-04
Abstract Abstract
A deterministic network is one that can carry data flows for real- A deterministic network is one that can carry data flows for real-
time applications with extremely low data loss rates and bounded time applications with extremely low data loss rates and bounded
latency. Deterministic networks have been successfully deployed in latency. Deterministic networks have been successfully deployed in
real-time operational technology (OT) applications for some years real-time operational technology (OT) applications for some years
(for example [ARINC664P7]). However, such networks are typically (for example [ARINC664P7]). However, such networks are typically
isolated from external access, and thus the security threat from isolated from external access, and thus the security threat from
external attackers is low. IETF Deterministic Networking (DetNet) external attackers is low. IETF Deterministic Networking (DetNet)
skipping to change at page 2, line 20 skipping to change at page 2, line 20
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 April 19, 2019. This Internet-Draft will expire on September 3, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 27 skipping to change at page 3, line 27
4.2. Flow Modification and Spoofing . . . . . . . . . . . . . 14 4.2. Flow Modification and Spoofing . . . . . . . . . . . . . 14
4.2.1. Flow Modification . . . . . . . . . . . . . . . . . . 14 4.2.1. Flow Modification . . . . . . . . . . . . . . . . . . 14
4.2.2. Spoofing . . . . . . . . . . . . . . . . . . . . . . 14 4.2.2. Spoofing . . . . . . . . . . . . . . . . . . . . . . 14
4.2.2.1. Dataplane Spoofing . . . . . . . . . . . . . . . 14 4.2.2.1. Dataplane Spoofing . . . . . . . . . . . . . . . 14
4.2.2.2. Control Plane Spoofing . . . . . . . . . . . . . 14 4.2.2.2. Control Plane Spoofing . . . . . . . . . . . . . 14
4.3. Segmentation attacks (injection) . . . . . . . . . . . . 15 4.3. Segmentation attacks (injection) . . . . . . . . . . . . 15
4.3.1. Data Plane Segmentation . . . . . . . . . . . . . . . 15 4.3.1. Data Plane Segmentation . . . . . . . . . . . . . . . 15
4.3.2. Control Plane segmentation . . . . . . . . . . . . . 15 4.3.2. Control Plane segmentation . . . . . . . . . . . . . 15
4.4. Replication and Elimination . . . . . . . . . . . . . . . 15 4.4. Replication and Elimination . . . . . . . . . . . . . . . 15
4.4.1. Increased Attack Surface . . . . . . . . . . . . . . 15 4.4.1. Increased Attack Surface . . . . . . . . . . . . . . 15
4.4.2. Header Manipulation at Elimination Bridges . . . . . 15 4.4.2. Header Manipulation at Elimination Bridges . . . . . 16
4.5. Control or Signaling Packet Modification . . . . . . . . 16 4.5. Control or Signaling Packet Modification . . . . . . . . 16
4.6. Control or Signaling Packet Injection . . . . . . . . . . 16 4.6. Control or Signaling Packet Injection . . . . . . . . . . 16
4.7. Reconnaissance . . . . . . . . . . . . . . . . . . . . . 16 4.7. Reconnaissance . . . . . . . . . . . . . . . . . . . . . 16
4.8. Attacks on Time Sync Mechanisms . . . . . . . . . . . . . 16 4.8. Attacks on Time Sync Mechanisms . . . . . . . . . . . . . 16
4.9. Attacks on Path Choice . . . . . . . . . . . . . . . . . 16 4.9. Attacks on Path Choice . . . . . . . . . . . . . . . . . 16
5. Security Threat Mitigation . . . . . . . . . . . . . . . . . 16 5. Security Threat Mitigation . . . . . . . . . . . . . . . . . 16
5.1. Path Redundancy . . . . . . . . . . . . . . . . . . . . . 16 5.1. Path Redundancy . . . . . . . . . . . . . . . . . . . . . 17
5.2. Integrity Protection . . . . . . . . . . . . . . . . . . 17 5.2. Integrity Protection . . . . . . . . . . . . . . . . . . 17
5.3. DetNet Node Authentication . . . . . . . . . . . . . . . 17 5.3. DetNet Node Authentication . . . . . . . . . . . . . . . 17
5.4. Encryption . . . . . . . . . . . . . . . . . . . . . . . 17 5.4. Encryption . . . . . . . . . . . . . . . . . . . . . . . 18
5.5. Control and Signaling Message Protection . . . . . . . . 18 5.4.1. Encryption Considerations for DetNet . . . . . . . . 18
5.6. Dynamic Performance Analytics . . . . . . . . . . . . . . 18 5.5. Control and Signaling Message Protection . . . . . . . . 19
5.7. Mitigation Summary . . . . . . . . . . . . . . . . . . . 18 5.6. Dynamic Performance Analytics . . . . . . . . . . . . . . 19
6. Association of Attacks to Use Cases . . . . . . . . . . . . . 20 5.7. Mitigation Summary . . . . . . . . . . . . . . . . . . . 20
6.1. Use Cases by Common Themes . . . . . . . . . . . . . . . 20 6. Association of Attacks to Use Cases . . . . . . . . . . . . . 21
6.1.1. Network Layer - AVB/TSN Ethernet . . . . . . . . . . 20 6.1. Use Cases by Common Themes . . . . . . . . . . . . . . . 21
6.1.2. Central Administration . . . . . . . . . . . . . . . 21 6.1.1. Network Layer - AVB/TSN Ethernet . . . . . . . . . . 22
6.1.3. Hot Swap . . . . . . . . . . . . . . . . . . . . . . 21 6.1.2. Central Administration . . . . . . . . . . . . . . . 22
6.1.4. Data Flow Information Models . . . . . . . . . . . . 22 6.1.3. Hot Swap . . . . . . . . . . . . . . . . . . . . . . 22
6.1.5. L2 and L3 Integration . . . . . . . . . . . . . . . . 22 6.1.4. Data Flow Information Models . . . . . . . . . . . . 23
6.1.6. End-to-End Delivery . . . . . . . . . . . . . . . . . 22 6.1.5. L2 and L3 Integration . . . . . . . . . . . . . . . . 23
6.1.7. Proprietary Deterministic Ethernet Networks . . . . . 23 6.1.6. End-to-End Delivery . . . . . . . . . . . . . . . . . 23
6.1.8. Replacement for Proprietary Fieldbuses . . . . . . . 23 6.1.7. Proprietary Deterministic Ethernet Networks . . . . . 24
6.1.9. Deterministic vs Best-Effort Traffic . . . . . . . . 23 6.1.8. Replacement for Proprietary Fieldbuses . . . . . . . 24
6.1.10. Deterministic Flows . . . . . . . . . . . . . . . . . 24 6.1.9. Deterministic vs Best-Effort Traffic . . . . . . . . 25
6.1.11. Unused Reserved Bandwidth . . . . . . . . . . . . . . 24 6.1.10. Deterministic Flows . . . . . . . . . . . . . . . . . 25
6.1.12. Interoperability . . . . . . . . . . . . . . . . . . 24 6.1.11. Unused Reserved Bandwidth . . . . . . . . . . . . . . 25
6.1.13. Cost Reductions . . . . . . . . . . . . . . . . . . . 25 6.1.12. Interoperability . . . . . . . . . . . . . . . . . . 26
6.1.14. Insufficiently Secure Devices . . . . . . . . . . . . 25 6.1.13. Cost Reductions . . . . . . . . . . . . . . . . . . . 26
6.1.15. DetNet Network Size . . . . . . . . . . . . . . . . . 25 6.1.14. Insufficiently Secure Devices . . . . . . . . . . . . 26
6.1.16. Multiple Hops . . . . . . . . . . . . . . . . . . . . 26 6.1.15. DetNet Network Size . . . . . . . . . . . . . . . . . 27
6.1.17. Level of Service . . . . . . . . . . . . . . . . . . 26 6.1.16. Multiple Hops . . . . . . . . . . . . . . . . . . . . 27
6.1.18. Bounded Latency . . . . . . . . . . . . . . . . . . . 27 6.1.17. Level of Service . . . . . . . . . . . . . . . . . . 28
6.1.19. Low Latency . . . . . . . . . . . . . . . . . . . . . 27 6.1.18. Bounded Latency . . . . . . . . . . . . . . . . . . . 28
6.1.20. Bounded Jitter (Latency Variation) . . . . . . . . . 27 6.1.19. Low Latency . . . . . . . . . . . . . . . . . . . . . 28
6.1.21. Symmetrical Path Delays . . . . . . . . . . . . . . . 27 6.1.20. Bounded Jitter (Latency Variation) . . . . . . . . . 29
6.1.22. Reliability and Availability . . . . . . . . . . . . 28 6.1.21. Symmetrical Path Delays . . . . . . . . . . . . . . . 29
6.1.23. Redundant Paths . . . . . . . . . . . . . . . . . . . 28 6.1.22. Reliability and Availability . . . . . . . . . . . . 29
6.1.24. Security Measures . . . . . . . . . . . . . . . . . . 28 6.1.23. Redundant Paths . . . . . . . . . . . . . . . . . . . 29
6.2. Attack Types by Use Case Common Theme . . . . . . . . . . 28 6.1.24. Security Measures . . . . . . . . . . . . . . . . . . 30
6.3. Security Considerations for OAM Traffic . . . . . . . . . 31 6.2. Attack Types by Use Case Common Theme . . . . . . . . . . 30
7. Appendix A: DetNet Draft Security-Related Statements . . . . 31 6.3. Security Considerations for OAM Traffic . . . . . . . . . 32
7.1. Architecture (draft 8) . . . . . . . . . . . . . . . . . 31 7. Appendix A: DetNet Draft Security-Related Statements . . . . 32
7.1.1. Fault Mitigation (sec 4.5) . . . . . . . . . . . . . 31 7.1. Architecture (draft 8) . . . . . . . . . . . . . . . . . 33
7.1.2. Security Considerations (sec 7) . . . . . . . . . . . 32 7.1.1. Fault Mitigation (sec 4.5) . . . . . . . . . . . . . 33
7.2. Data Plane Alternatives (draft 4) . . . . . . . . . . . . 32 7.1.2. Security Considerations (sec 7) . . . . . . . . . . . 33
7.2.1. Security Considerations (sec 7) . . . . . . . . . . . 32 7.2. Data Plane Alternatives (draft 4) . . . . . . . . . . . . 34
7.3. Problem Statement (draft 5) . . . . . . . . . . . . . . . 33 7.2.1. Security Considerations (sec 7) . . . . . . . . . . . 34
7.3.1. Security Considerations (sec 5) . . . . . . . . . . . 33 7.3. Problem Statement (draft 5) . . . . . . . . . . . . . . . 34
7.4. Use Cases (draft 11) . . . . . . . . . . . . . . . . . . 33 7.3.1. Security Considerations (sec 5) . . . . . . . . . . . 34
7.4. Use Cases (draft 11) . . . . . . . . . . . . . . . . . . 35
7.4.1. (Utility Networks) Security Current Practices and 7.4.1. (Utility Networks) Security Current Practices and
Limitations (sec 3.2.1) . . . . . . . . . . . . . . . 33 Limitations (sec 3.2.1) . . . . . . . . . . . . . . . 35
7.4.2. (Utility Networks) Security Trends in Utility 7.4.2. (Utility Networks) Security Trends in Utility
Networks (sec 3.3.3) . . . . . . . . . . . . . . . . 35 Networks (sec 3.3.3) . . . . . . . . . . . . . . . . 36
7.4.3. (BAS) Security Considerations (sec 4.2.4) . . . . . . 36 7.4.3. (BAS) Security Considerations (sec 4.2.4) . . . . . . 38
7.4.4. (6TiSCH) Security Considerations (sec 5.3.3) . . . . 37 7.4.4. (6TiSCH) Security Considerations (sec 5.3.3) . . . . 38
7.4.5. (Cellular radio) Security Considerations (sec 6.1.5) 37 7.4.5. (Cellular radio) Security Considerations (sec 6.1.5) 39
7.4.6. (Industrial M2M) Communication Today (sec 7.2) . . . 37 7.4.6. (Industrial M2M) Communication Today (sec 7.2) . . . 39
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
9. Security Considerations . . . . . . . . . . . . . . . . . . . 38 9. Security Considerations . . . . . . . . . . . . . . . . . . . 39
10. Informative References . . . . . . . . . . . . . . . . . . . 38 10. Informative References . . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction 1. Introduction
Security is of particularly high importance in DetNet networks Security is of particularly high importance in DetNet networks
because many of the use cases which are enabled by DetNet because many of the use cases which are enabled by DetNet
[I-D.ietf-detnet-use-cases] include control of physical devices [I-D.ietf-detnet-use-cases] include control of physical devices
(power grid components, industrial controls, building controls) which (power grid components, industrial controls, building controls) which
can have high operational costs for failure, and present potentially can have high operational costs for failure, and present potentially
attractive targets for cyber-attackers. attractive targets for cyber-attackers.
skipping to change at page 13, line 39 skipping to change at page 13, line 39
Severely delayed messages in a DetNet link can result in the same Severely delayed messages in a DetNet link can result in the same
behavior as dropped messages in ordinary networks as the services behavior as dropped messages in ordinary networks as the services
attached to the stream has strict deterministic requirements. attached to the stream has strict deterministic requirements.
For a single path scenario, disruption is a real possibility, whereas For a single path scenario, disruption is a real possibility, whereas
in a multipath scenario, large delays or instabilities in one stream in a multipath scenario, large delays or instabilities in one stream
can lead to increased buffer and CPU resources on the elimination can lead to increased buffer and CPU resources on the elimination
bridge. bridge.
A data-plane delay attack on a system controlling substantial moving
devices, for example in industrial automation, can cause physical
damage. For example, if the network promises a bounded latency of
2ms for a flow, yet the machine receives it with 5ms latency, the
machine's control loop can become unstable.
4.1.2. Control Plane Delay Attacks 4.1.2. Control 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 streams finally giving rise to a result in failure to allocate new streams finally giving rise to a
denial of service attack. denial of service attack.
skipping to change at page 18, line 7 skipping to change at page 18, line 13
Section 3.2.4. Section 3.2.4.
5.4. Encryption 5.4. Encryption
Description Description
DetNet flows can be forwarded in encrypted form. DetNet flows can be forwarded in encrypted form.
Related attacks Related attacks
While confidentiality is not considered an important goal with Encryption can be used to mitigate recon attacks (Section 3.2.7).
respect to DetNet, encryption can be used to mitigate recon However, for a DetNet network to give differentiated quality of
attacks (Section 3.2.7). service on a flow-by-flow basis, the network must be able to
identify the flows individually. This implies that in a recon
attack the attacker may also be able to track individual flows to
learn more about the system.
Encryption can also provide traffic origin verification, i.e. to
verify that each packet in a DetNet flow is from a trusted source,
for example as part of ingress filtering.
5.4.1. Encryption Considerations for DetNet
Any compute time which is required for encryption and decryption
processing ('crypto') must be included in the flow latency
calculations. Thus, crypto algorithms used in a DetNet must have
bounded worst-case execution times, and these values must be used in
the latency calculations.
Some crypto algorithms are symmetric in encode/decode time (such as
AES) and others are asymmetric (such as public key algorithms).
There are advantages and disadvantages to the use of either type in a
given DetNet context.
Asymmetrical crypto is typically not used in networks on a packet-by-
packet basis due to its computational cost. For example, if only
endpoint checks or checks at a small number of intermediate points
are required, asymmetric crypto can be used to authenticate
distribution or exchange of a secret symmetric crypto key; a
successful check based on that key will provide traffic origin
verification, as long as the key is kept secret by the participants.
TLS and IKE (for IPsec) are examples of this for endpoint checks.
However, if secret symmetrical keys are used for this purpose the key
must be given to all relays, which increases the probability of a
secret key being leaked. Also, if any relay is compromised or
misbehaving it may inject traffic into the flow.
Alternatively, asymmetric crypto can provide traffic origin
verification at every intermediate node. For example, a DetNet flow
can be associated with an (asymmetric) keypair, such that the private
key is available to the source of the flow and the public key is
distributed with the flow information, allowing verification at every
node for every packet. However, this is more computationally
expensive.
In either case, origin verification also requires replay detection as
part of the security protocol to prevent an attacker from recording
and resending traffic, e.g., as a denial of service attack on flow
forwarding resources.
If crypto keys are to be regenerated over the duration of the flow
then the time required to accomplish this must be accounted for in
the latency calculations.
5.5. Control and Signaling Message Protection 5.5. Control and Signaling Message Protection
Description Description
Control and sigaling messages can be protected using Control and sigaling messages can be protected using
authentication and integrity protection mechanisms. authentication and integrity protection mechanisms.
Related attacks Related attacks
skipping to change at page 18, line 42 skipping to change at page 19, line 50
and monitoring of packet arrival times. Unusual behavior or and monitoring of packet arrival times. Unusual behavior or
potentially malicious nodes can be reported to a management potentially malicious nodes can be reported to a management
system, or can be used as a trigger for taking corrective actions. system, or can be used as a trigger for taking corrective actions.
The information can be tracked by DetNet end systems and transit The information can be tracked by DetNet end systems and transit
nodes, and exported to a management system, for example using nodes, and exported to a management system, for example using
NETCONF. NETCONF.
Related attacks Related attacks
Performance analytics can be used to mitigate various attacks, Performance analytics can be used to mitigate various attacks,
including the ones described in Section 3.2.1, Section 3.2.3, and including the ones described in Section 3.2.1 (Delay Attack),
Section 3.2.8. Section 3.2.3 (Resource Segmentation Attack), and Section 3.2.8
(Time Sync Attack).
For example, in the case of data plane delay attacks, one possible
mitigation is to timestamp the data at the source, and timestamp
it again at the destination, and if the resulting latency exceeds
the promised bound, discard that data and warn the operator (and/
or enter a fail-safe mode).
5.7. Mitigation Summary 5.7. Mitigation Summary
The following table maps the attacks of Section 3 to the impacts of The following table maps the attacks of Section 3 to the impacts of
Section 4, and to the mitigations of the current section. Each row Section 4, and to the mitigations of the current section. Each row
specifies an attack, the impact of this attack if it is successfully specifies an attack, the impact of this attack if it is successfully
implemented, and possible mitigation methods. implemented, and possible mitigation methods.
+----------------------+---------------------+---------------------+ +----------------------+---------------------+---------------------+
| Attack | Impact | Mitigations | | Attack | Impact | Mitigations |
skipping to change at page 36, line 47 skipping to change at page 38, line 13
associated with implementing security solutions in OT networks. associated with implementing security solutions in OT networks.
Securing OT (Operation technology) telecommunications over packet- Securing OT (Operation technology) telecommunications over packet-
switched IP networks follow the same principles that are foundational switched IP networks follow the same principles that are foundational
for securing the IT infrastructure, i.e., consideration must be given for securing the IT infrastructure, i.e., consideration must be given
to enforcing electronic access control for both person-to-machine and to enforcing electronic access control for both person-to-machine and
machine-to-machine communications, and providing the appropriate machine-to-machine communications, and providing the appropriate
levels of data privacy, device and platform integrity, and threat levels of data privacy, device and platform integrity, and threat
detection and mitigation. detection and mitigation.
Existing power automation security standards can inform network
security. For example the NERC CIP (North American Electric
Reliability Corporation Critical Infrastructure Protection) plan is a
set of requirements designed to secure the assets required for
operating North America's bulk electric system. Another standardized
security control technique is Segmentation (zones and conduits
including access control).
The requirements in Industrial Automation and Control Systems (IACS)
are quite similar, especially in new scenarios such as Industry 4.0/
Digital Factory where workflows and protocols cross zones, segments,
and entities. IEC 62443 (ISA99) defines security for IACS, typically
for installations in other critical infrastructure such as oil and
gas.
Availability and integrity are the most important security objectives
for the lower layers of such networks; confidentiality and privacy
are relevant if customer or market data is involved, typically
handled by higher layers.
7.4.3. (BAS) Security Considerations (sec 4.2.4) 7.4.3. (BAS) Security Considerations (sec 4.2.4)
When BAS field networks were developed it was assumed that the field When BAS field networks were developed it was assumed that the field
networks would always be physically isolated from external networks networks would always be physically isolated from external networks
and therefore security was not a concern. In today's world many BASs and therefore security was not a concern. In today's world many BASs
are managed remotely and are thus connected to shared IP networks and are managed remotely and are thus connected to shared IP networks and
so security is definitely a concern, yet security features are not so security is definitely a concern, yet security features are not
available in the majority of BAS field network deployments . available in the majority of BAS field network deployments .
The management network, being an IP-based network, has the protocols The management network, being an IP-based network, has the protocols
skipping to change at page 38, line 19 skipping to change at page 39, line 48
10. Informative References 10. 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-architecture] [I-D.ietf-detnet-architecture]
Finn, N., Thubert, P., Varga, B., and J. Farkas, Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", draft-ietf- "Deterministic Networking Architecture", draft-ietf-
detnet-architecture-08 (work in progress), September 2018. detnet-architecture-11 (work in progress), February 2019.
[I-D.ietf-detnet-use-cases] [I-D.ietf-detnet-use-cases]
Grossman, E., "Deterministic Networking Use Cases", draft- Grossman, E., "Deterministic Networking Use Cases", draft-
ietf-detnet-use-cases-18 (work in progress), September ietf-detnet-use-cases-20 (work in progress), December
2018. 2018.
[I-D.varga-detnet-service-model] [I-D.varga-detnet-service-model]
Varga, B. and J. Farkas, "DetNet Service Model", draft- Varga, B. and J. Farkas, "DetNet Service Model", draft-
varga-detnet-service-model-02 (work in progress), May varga-detnet-service-model-02 (work in progress), May
2017. 2017.
[IEEE1588] [IEEE1588]
IEEE, "IEEE 1588 Standard for a Precision Clock IEEE, "IEEE 1588 Standard for a Precision Clock
Synchronization Protocol for Networked Measurement and Synchronization Protocol for Networked Measurement and
 End of changes. 16 change blocks. 
65 lines changed or deleted 150 lines changed or added

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