diff options
Diffstat (limited to 'doc/rfc/rfc8039.txt')
| -rw-r--r-- | doc/rfc/rfc8039.txt | 955 |
1 files changed, 955 insertions, 0 deletions
diff --git a/doc/rfc/rfc8039.txt b/doc/rfc/rfc8039.txt new file mode 100644 index 0000000..537361e --- /dev/null +++ b/doc/rfc/rfc8039.txt @@ -0,0 +1,955 @@ + + + + + + +Internet Engineering Task Force (IETF) A. Shpiner +Request for Comments: 8039 Mellanox +Category: Experimental R. Tse +ISSN: 2070-1721 Microsemi + C. Schelp + Oracle + T. Mizrahi + Marvell + December 2016 + + + Multipath Time Synchronization + +Abstract + + Clock synchronization protocols are very widely used in IP-based + networks. The Network Time Protocol (NTP) has been commonly deployed + for many years, and the last few years have seen an increasingly + rapid deployment of the Precision Time Protocol (PTP). As time- + sensitive applications evolve, clock accuracy requirements are + becoming increasingly stringent, requiring the time synchronization + protocols to provide high accuracy. This memo describes a multipath + approach to PTP and NTP over IP networks, allowing the protocols to + run concurrently over multiple communication paths between the master + and slave clocks, without modifying these protocols. The multipath + approach can significantly contribute to clock accuracy, security, + and fault tolerance. The multipath approach that is presented in + this document enables backward compatibility with nodes that do not + support the multipath functionality. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for examination, experimental implementation, and + evaluation. + + This document defines an Experimental Protocol for the Internet + community. This document is a product of the Internet Engineering + Task Force (IETF). It represents the consensus of the IETF + community. It has received public review and has been approved for + publication by the Internet Engineering Steering Group (IESG). Not + all documents approved by the IESG are a candidate for any level of + Internet Standard; see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc8039. + + + + +Shpiner, et al. Experimental [Page 1] + +RFC 8039 Multipath Time Synchronization December 2016 + + +Copyright Notice + + Copyright (c) 2016 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction ....................................................3 + 2. Conventions Used in This Document ...............................4 + 2.1. Abbreviations ..............................................4 + 2.2. Terminology ................................................4 + 3. Multiple Paths in IP Networks ...................................5 + 3.1. Load Balancing .............................................5 + 3.2. Using Multiple Paths Concurrently ..........................5 + 3.3. Two-Way Paths ..............................................5 + 4. Solution Overview ...............................................6 + 4.1. Path Configuration and Identification ......................6 + 4.2. Combining ..................................................6 + 5. Multipath Time Synchronization over IP Networks .................7 + 5.1. Overview ...................................................7 + 5.2. Single-Ended Multipath Synchronization .....................8 + 5.2.1. Single-Ended MPPTP Synchronization Message + Exchange ............................................8 + 5.2.2. Single-Ended MPNTP Synchronization Message + Exchange ............................................9 + 5.3. Dual-Ended Multipath Synchronization ......................10 + 5.3.1. Dual-Ended MPPTP Synchronization Message Exchange ..10 + 5.3.2. Dual-Ended MPNTP Synchronization Message Exchange ..11 + 5.4. Using Traceroute for Path Discovery .......................12 + 5.5. Using Unicast Discovery for MPPTP .........................13 + 6. Combining Algorithm ............................................13 + 7. Security Considerations ........................................14 + 8. Scope of the Experiment ........................................14 + 9. References .....................................................15 + 9.1. Normative References ......................................15 + 9.2. Informative References ....................................15 + Acknowledgments ...................................................17 + Authors' Addresses ................................................17 + + + +Shpiner, et al. Experimental [Page 2] + +RFC 8039 Multipath Time Synchronization December 2016 + + +1. Introduction + + The two most common time synchronization protocols in IP networks are + (1) the Network Time Protocol [NTP] and (2) the Precision Time + Protocol (PTP) as defined in the IEEE 1588 standard [IEEE1588]. + + The accuracy of the time synchronization protocols directly depends + on the stability and the symmetry of propagation delays in both + directions between the master and slave clocks. Depending on the + nature of the underlying network, time synchronization protocol + packets can be subject to variable network latency or path asymmetry + (e.g., [ASYMMETRY] [ASYMMETRY2]). As time-sensitive applications + evolve, accuracy requirements are becoming increasingly stringent. + Using a single network path in a clock synchronization protocol + closely ties the slave clock accuracy to the behavior of the specific + path, which may suffer from temporal congestion, faults, or malicious + attacks. Relying on multiple clock servers, as in NTP, solves these + problems but requires active maintenance of multiple accurate sources + in the network, which is not always possible. The usage of + Transparent Clocks (TCs) in PTP solves the congestion problem by + eliminating the queuing time from the delay calculations but does not + address security or fault-tolerance aspects. + + ____ + ______/ \_____ + ___/ \____ + ____/ \ + ____ / path 1 / ___ + / \ / ________________________ \ / \ + /Master\____\___/ \____\________/Slave\ + \Clock / / \________ _______________/ \ \Clock/ + \____/ \ / \__ / + \____ path 2 __/ + \_______ ______/ + \_________/ + + Figure 1: Multipath Connection + + Since master and slave clocks are often connected through more than + one path in the network, as shown in Figure 1, [SLAVEDIV] suggested + that a time synchronization protocol can be run over multiple paths, + providing several advantages. First, it can significantly increase + the clock accuracy as shown in [SLAVEDIV]. Second, this approach + provides additional security, allowing the mitigation of + man-in-the-middle attacks against the time synchronization protocol + [DELAY-ATT]. Third, using multiple paths concurrently provides an + inherent failure protection mechanism. + + + + +Shpiner, et al. Experimental [Page 3] + +RFC 8039 Multipath Time Synchronization December 2016 + + + This document introduces Multipath PTP (MPPTP) and Multipath NTP + (MPNTP). The functionality of the multipath approach is defined at + the network layer and does not require any changes in PTP or NTP. + + MPPTP and MPNTP are defined over IP networks. As IP networks + typically combine ECMP routing, this property is leveraged for the + multiple paths used in MPPTP and MPNTP. The key property of the + multipath approach is that clocks in the network can use more than + one IP address. Each {master IP, slave IP} address pair defines a + path. Depending on the network topology and configuration, the IP + combination pairs can form multiple diverse paths used by the + multipath synchronization protocols. It has been shown [MULTI] that + using multiple IP addresses over the wide Internet indeed allows two + endpoints to attain multiple diverse paths. + + This document introduces two variants of the multipath approach: + (1) a variant that requires both master and slave nodes to support + the multipath functionality, referred to as the dual-ended variant, + and (2) a backward-compatible variant that allows a multipath clock + to connect to a conventional single-path clock, referred to as the + single-ended variant. + +2. Conventions Used in This Document + +2.1. Abbreviations + + BMC Best Master Clock [IEEE1588] + + ECMP Equal-Cost Multipath + + LAN Local Area Network + + MPNTP Multipath Network Time Protocol + + MPPTP Multipath Precision Time Protocol + + NTP Network Time Protocol [NTP] + + PTP Precision Time Protocol [IEEE1588] + +2.2. Terminology + + In the NTP terminology, a time synchronization protocol is run + between a client and a server, while PTP uses the terms 'master' and + 'slave'. Throughout this document, the sections that refer to both + PTP and NTP generically use the terms 'master' and 'slave'. + + + + + +Shpiner, et al. Experimental [Page 4] + +RFC 8039 Multipath Time Synchronization December 2016 + + +3. Multiple Paths in IP Networks + +3.1. Load Balancing + + Traffic sent across IP networks is often load-balanced across + multiple paths. The load-balancing decisions are typically based on + packet header fields: source and destination addresses, Layer 4 + ports, the Flow Label field in IPv6, etc. + + Three common load-balancing criteria are per-destination, per-flow, + and per-packet. The per-destination load balancers take a + load-balancing decision based on the destination IP address. + Per-flow load balancers use various fields in the packet header, + e.g., IP addresses and Layer 4 ports, for the load-balancing + decision. Per-packet load balancers use flow-blind techniques such + as round-robin without basing the choice on the packet content. + +3.2. Using Multiple Paths Concurrently + + To utilize the diverse paths that traverse per-destination + load balancers or per-flow load balancers, the packet transmitter can + vary the IP addresses in the packet header. The analysis in [PARIS2] + shows that a significant majority of the flows on the Internet + traverse per-destination or per-flow load balancing. It presents + statistics that 72% of the flows traverse per-destination + load balancing and 39% of the flows traverse per-flow load balancing, + while only a negligible part of the flows traverse per-packet + load balancing. These statistics show that the vast majority of the + traffic on the Internet is load-balanced based on packet header + fields. + + The approaches in this document are based on varying the source and + destination IP addresses in the packet header. Possible extensions + have been considered that also vary the UDP ports. However, some of + the existing implementations of PTP and NTP use fixed UDP port values + in both the source and destination UDP port fields and thus do not + allow this approach. + +3.3. Two-Way Paths + + A key property of IP networks is that packets forwarded from A to B + do not necessarily traverse the same path as packets from B to A. + Thus, we define a two-way path for a master-slave connection as a + pair of one-way paths: the first from master to slave and the second + from slave to master. + + + + + + +Shpiner, et al. Experimental [Page 5] + +RFC 8039 Multipath Time Synchronization December 2016 + + + If possible, a traffic engineering approach can be used to verify + that time synchronization traffic is always forwarded through + bidirectional two-way paths, i.e., that each two-way path uses the + same route in the forward and reverse directions, thus allowing + propagation time symmetry. However, in the general case, two-way + paths do not necessarily use the same path for the forward and + reverse directions. + +4. Solution Overview + + The multipath time synchronization protocols we present here are + comprised of two building blocks: one is the path configuration and + identification, and the other is the algorithm used by the slave to + combine the information received from the various paths. + +4.1. Path Configuration and Identification + + The master and slave clocks must be able to determine the path of + transmitted protocol packets and to identify the path of incoming + protocol packets. A path is determined by a {master IP, slave IP} + address pair. The synchronization protocol message exchange is run + independently through each path. + + Each IP address pair defines a two-way path and thus allows the + clocks to bind a transmitted packet to a specific path or to identify + the path of an incoming packet. + + If possible, the routing tables across the network should be + configured with multiple traffic-engineered paths between the pair of + clocks. By carefully configuring the routers in such networks, it is + possible to create diverse paths for each of the IP address pairs + between two clocks in the network. However, in public and provider + networks, the load-balancing behavior is hidden from the end users. + In this case, the actual number of paths may be less than the number + of IP address pairs, since some of the address pairs may share common + paths. + +4.2. Combining + + Various methods can be used for combining the time information + received from the different paths. The output of the combining + algorithm is the accurate time offset. Combining methods are further + discussed in Section 6. + + + + + + + + +Shpiner, et al. Experimental [Page 6] + +RFC 8039 Multipath Time Synchronization December 2016 + + +5. Multipath Time Synchronization over IP Networks + +5.1. Overview + + This section presents two variants of MPPTP and MPNTP: single-ended + multipath time synchronization and dual-ended multipath time + synchronization. In the first variant, the multipath approach is + only implemented by the slave, and the master is not aware of its + usage. In the second variant, all clocks use multiple paths. + + The dual-ended variant provides higher path diversity by using + multiple IP addresses at both ends, the master and slave, while the + single-ended variant only uses multiple addresses at the slave. + Consequently, the single-ended approach can interoperate with + existing implementations that do not use multiple paths. The + dual-ended and single-ended approaches can coexist in the same + network; each slave selects the connection(s) it wants to make with + the available masters. A dual-ended slave could switch to + single-ended mode if it does not see any dual-ended masters + available. A single-ended slave could connect to a single IP address + of a dual-ended master. + + Multipath time synchronization, in both variants, requires clocks to + use multiple IP addresses. Using multiple IP addresses introduces a + trade-off. A large number of IP addresses allows a large number of + diverse paths, providing the advantages of slave diversity discussed + in Section 1. On the other hand, a large number of IP addresses is + more costly, requires the network topology to be more redundant, and + exacts extra management overhead. + + If possible, the set of IP addresses for each clock should be chosen + in a way that enables the establishment of paths that are the most + different. If the load-balancing rules in the network are known, it + is possible to choose the IP addresses in a way that enforces path + diversity. However, even if the load-balancing scheme is not known, + a careful choice of the IP addresses can increase the probability of + path diversity. For example, choosing multiple addresses with + different prefixes is likely to produce higher path diversity, as BGP + routers are more likely to route these different prefixes through + different routes. + + The use of Network Address Translation (NAT) may significantly reduce + the effectiveness of multipath synchronization in some cases. For + example, if a master uses multiple IP addresses that are translated + to a single IP address, the path diversity can be dramatically + reduced compared to a network that does not use NAT. Thus, path + + + + + +Shpiner, et al. Experimental [Page 7] + +RFC 8039 Multipath Time Synchronization December 2016 + + + discovery should be used to identify the possible paths between the + master and slave. Path discovery is further discussed in + Section 5.4. + + The concept of using multiple IP addresses or multiple interfaces is + well established and is being used today by various applications and + protocols, e.g., [MPTCP]. Using multiple interfaces introduces some + challenges and issues, which were presented and discussed in [MIF]. + + The descriptions in this section refer to the end-to-end scheme of + PTP but are similarly applicable to the peer-to-peer scheme. MPNTP, + as described in this document, refers to the NTP client-server mode, + although the concepts described here can be extended to include the + symmetric variant as well. + + Multipath synchronization by nature requires protocol messages to be + sent as unicast. Specifically in PTP, the following messages must be + sent as unicast in MPPTP: Sync, Delay_Req, Delay_Resp, PDelay_Req, + PDelay_Resp, Follow_Up, and PDelay_Resp_Follow_Up. Note that + [IEEE1588] allows these messages to be sent either as multicast or as + unicast. + +5.2. Single-Ended Multipath Synchronization + + In the single-ended approach, only the slave is aware of the fact + that multiple paths are used, while the master is agnostic to the + usage of multiple paths. This approach allows a hybrid network, + where some of the clocks are multipath clocks and others are + conventional one-path clocks. A single-ended multipath clock + presents itself to the network as N independent clocks, using N IP + addresses, as well as N clockIdentity [IEEE1588] values (in PTP). + Thus, the usage of multiple slave identities by a slave clock is + transparent from the master's point of view, such that it treats each + of the identities as a separate slave clock. + +5.2.1. Single-Ended MPPTP Synchronization Message Exchange + + The single-ended MPPTP message exchange procedure is as follows. + + o Each single-ended MPPTP clock has a fixed set of N IP addresses + and N corresponding clockIdentities. Each clock arbitrarily + defines one of its IP addresses and clockIdentity values as the + clock primary identity. + + o A single-ended MPPTP port sends Announce messages only from its + primary identity, according to the BMC algorithm. + + + + + +Shpiner, et al. Experimental [Page 8] + +RFC 8039 Multipath Time Synchronization December 2016 + + + o The BMC algorithm at each clock determines the master, based on + the received Announce messages. + + o A single-ended MPPTP port that is in the 'slave' state uses + unicast negotiation to request the master to transmit unicast + messages to each of the N slave clockIdentity values. The slave + port periodically sends N Signaling messages to the master, using + each of its N identities. The Signaling message includes the + REQUEST_UNICAST_TRANSMISSION TLV [IEEE1588]. + + o The master periodically sends unicast Sync messages from its + primary identity, identified by the sourcePortIdentity [IEEE1588] + and IP address, to each of the slave identities. + + o The slave, upon receiving a Sync message, identifies its path + according to the destination IP address. The slave sends a + Delay_Req unicast message to the primary identity of the master. + The Delay_Req is sent using the slave identity corresponding to + the path through which the Sync was received. Note that the rate + of Delay_Req messages may be lower than the Sync message rate, and + thus a Sync message is not necessarily followed by a Delay_Req. + + o The master, in response to a Delay_Req message from the slave, + responds with a Delay_Resp message using the IP address and + sourcePortIdentity from the Delay_Req message. + + o Upon receiving the Delay_Resp message, the slave identifies the + path using the destination IP address and the + requestingPortIdentity [IEEE1588]. The slave can then compute the + corresponding path delay and the offset from the master. + + o The slave combines the information from all negotiated paths. + +5.2.2. Single-Ended MPNTP Synchronization Message Exchange + + The single-ended MPNTP message exchange procedure is as follows. + + o A single-ended MPNTP client has N separate identities, i.e., N IP + addresses. The assumption is that the server information, + including its IP address, is known to the NTP clients. This is a + fair assumption, as typically the address(es) of the NTP server(s) + is provided to the NTP client by configuration. + + o A single-ended MPNTP client initiates NTP with an NTP server + N times, using each of its N identities. + + o NTP is maintained between the server and each of the N client + identities. + + + +Shpiner, et al. Experimental [Page 9] + +RFC 8039 Multipath Time Synchronization December 2016 + + + o The client sends NTP messages to the master using each of its + N identities. + + o The server responds to the client's NTP messages using the IP + address from the received NTP packet. + + o The client, upon receiving an NTP packet, uses the IP destination + address to identify the path through which it came, and it uses + the time information accordingly. + + o The client combines the information from all paths. + +5.3. Dual-Ended Multipath Synchronization + + In dual-ended multipath synchronization, each clock has N IP + addresses. Time synchronization messages are exchanged between some + of the combinations of {master IP, slave IP} addresses, allowing + multiple paths between the master and slave. Note that the actual + number of paths between the master and slave may be less than the + number of chosen {master IP, slave IP} address pairs. + + Once the multiple two-way connections are established, a separate + synchronization protocol exchange instance is run through each + of them. + +5.3.1. Dual-Ended MPPTP Synchronization Message Exchange + + The dual-ended MPPTP message exchange procedure is as follows. + + o Every clock has N IP addresses but uses a single clockIdentity. + + o The BMC algorithm at each clock determines the master. The master + is identified by its clockIdentity, allowing other clocks to know + the multiple IP addresses it uses. + + o When a clock sends an Announce message, it sends it from each of + its IP addresses with its clockIdentity. + + o A dual-ended MPPTP port that is in the 'slave' state uses unicast + negotiation to request the master to transmit unicast messages to + some or all of its N_s IP addresses. This negotiation is done + individually between a slave IP address and the corresponding + master IP address with which the slave desires a connection. The + slave port periodically sends Signaling messages to the master, + using some or all of its N_s IP addresses as the source, to the + corresponding master's N_m IP addresses. The Signaling message + includes the REQUEST_UNICAST_TRANSMISSION TLV [IEEE1588]. + + + + +Shpiner, et al. Experimental [Page 10] + +RFC 8039 Multipath Time Synchronization December 2016 + + + ('N_s' and 'N_m' indicate the number of IP addresses of the slave + and master, respectively.) + + o The master periodically sends unicast Sync messages from each of + its IP addresses to the corresponding slave IP addresses for which + a unicast connection was negotiated. + + o The slave, upon receiving a Sync message, identifies its path + according to the {source IP, destination IP} addresses. The slave + sends a Delay_Req unicast message, swapping the source and + destination IP addresses from the Sync message. Note that the + rate of Delay_Req messages may be lower than the Sync message + rate, and thus a Sync message is not necessarily followed by a + Delay_Req. + + o The master, in response to a Delay_Req message from the slave, + responds with a Delay_Resp message using the sourcePortIdentity + from the Delay_Req message and swapping the IP addresses from the + Delay_Req. + + o Upon receiving the Delay_Resp message, the slave identifies the + path using the {source IP, destination IP} address pair. The + slave can then compute the corresponding path delay and the offset + from the master. + + o The slave combines the information from all negotiated paths. + +5.3.2. Dual-Ended MPNTP Synchronization Message Exchange + + The MPNTP message exchange procedure is as follows. + + o Each NTP clock has a set of N IP addresses. The assumption is + that the server information, including its multiple IP addresses, + is known to the NTP clients. + + o The MPNTP client chooses N_svr server IP addresses and N_c client + IP addresses and initiates the N_svr*N_c instances of the + protocol, one for each {server IP, client IP} address pair, + allowing the client to combine the information from the N_s*N_c + paths. + + ('N_svr' and 'N_c' indicate the number of IP addresses of the + server and client, respectively, with which a client chooses to + connect.) + + o The client sends NTP messages to the master using each of the + source-destination address combinations. + + + + +Shpiner, et al. Experimental [Page 11] + +RFC 8039 Multipath Time Synchronization December 2016 + + + o The server responds to the client's NTP messages using the IP + address combination from the received NTP packet. + + o Using the {source IP, destination IP} address pair in the received + packets, the client identifies the path and performs its + computations for each of the paths accordingly. + + o The client combines the information from all paths. + +5.4. Using Traceroute for Path Discovery + + The approach described thus far uses multiple IP addresses in a + single clock to create multiple paths. However, although each + two-way path is defined by a different {master IP, slave IP} address + pair, some of the IP address pairs may traverse exactly the same + network path, making them redundant. + + Traceroute-based path discovery can be used for filtering only the IP + addresses that obtain diverse paths. 'Paris traceroute' [PARIS] and + 'TraceFlow' [TRACEFLOW] are examples of tools that discover the paths + between two points in the network. It should be noted that this + filtering approach is effective only if the Traceroute implementation + uses the same IP addresses and UDP ports as the synchronization + protocol packets. Since some Traceroute implementations vary the UDP + ports, they may not be effective in identifying and filtering + redundant paths in synchronization protocols. + + Traceroute-based filtering can be implemented by both master and + slave nodes, or it can be restricted to run only on slave nodes to + reduce the overhead on the master. For networks that guarantee that + the path of the timing packets in the forward and reverse directions + are the same, path discovery should only be performed at the slave. + + Since network routes change over time, path discovery and redundant + path filtering should be performed periodically. Two {master IP, + slave IP} address pairs that produce two diverse paths may be + rerouted to use the same paths. Thus, the set of addresses that are + used by each clock should be reassessed regularly. + + + + + + + + + + + + + +Shpiner, et al. Experimental [Page 12] + +RFC 8039 Multipath Time Synchronization December 2016 + + +5.5. Using Unicast Discovery for MPPTP + + As presented above, MPPTP uses Announce messages and the BMC + algorithm to discover the master. The unicast discovery option of + PTP can be used as an alternative. + + When using unicast discovery, the MPPTP slave ports maintain a list + of the IP addresses of the master. The slave port uses unicast + negotiation to request unicast service from the master as follows: + + o In single-ended MPPTP, the slave uses unicast negotiation from + each of its identities to the master's (only) identity. + + o In dual-ended MPPTP, the slave uses unicast negotiation from its + IP addresses, each to a corresponding master IP address, to + request unicast synchronization messages. + + Afterwards, the message exchange continues as described in + Sections 5.2.1 and 5.3.1. + + The unicast discovery option can be used in networks that do not + support multicast or in networks in which the master clocks are known + in advance. In particular, unicast discovery avoids multicasting + Announce messages. + +6. Combining Algorithm + + Previous sections discussed the methods of creating the multiple + paths and obtaining the time information required by the slave + algorithm. Once the time information is received through each of the + paths, the slave should use a combining algorithm, which consolidates + the information from the different paths into a single clock. + Various methods have been suggested for combining information from + different paths or from different clocks, e.g., [NTP] [SLAVEDIV] + [HIGH-AVAI] [KALMAN]. The choice of the combining algorithm is local + to the slave and does not affect interoperability. Hence, this + document does not define a specific method to be used by the slave. + The combining algorithm should be chosen carefully based on the + system properties, as different combining algorithms provide + different advantages. For example, some combining algorithms (e.g., + [NTP] [DELAY-ATT]) are intended to be robust in the face of security + attacks, while other combining algorithms (e.g., [KALMAN]) are more + resilient to random delay variation. + + + + + + + + +Shpiner, et al. Experimental [Page 13] + +RFC 8039 Multipath Time Synchronization December 2016 + + +7. Security Considerations + + The security aspects of time synchronization protocols are discussed + in detail in [RFC7384]. The methods described in this document + propose to run a time synchronization protocol through redundant + paths and thus allow the detection and mitigation of + man-in-the-middle attacks, as described in [DELAY-ATT]. + Specifically, multipath synchronization can mitigate the following + threats (as per [RFC7384]): + + o Packet manipulation (Section 3.2.1 of [RFC7384]). + + o Packet interception and removal (Section 3.2.5 of [RFC7384]). + + o Packet delay manipulation (Section 3.2.6 of [RFC7384]). + + It should be noted that when using multiple paths, these paths may + partially overlap, and thus an attack that takes place in a common + segment of these paths is not mitigated by the redundancy. Moreover, + an on-path attacker may in some cases have access to more than one + router or may be able to migrate from one router to another. + Therefore, when using multiple paths, it is important for the paths + to be as diverse and as independent as possible, making the + redundancy scheme more tolerant to on-path attacks. + + It should be noted that the multipath approach requires the master + (or NTP server) to dedicate more resources to each slave (client) + than the conventional single-path approach. Hence, well-known + Distributed Denial-of-Service (DDoS) attacks may potentially be + amplified when the multipath approach is enabled. + +8. Scope of the Experiment + + This memo is published as an Experimental RFC. The purpose of the + experimental period is to allow the community to analyze and to + verify the methods defined in this document. An experimental + evaluation of some of these methods has been published in [MULTI]. + It is expected that the experimental period will allow the methods to + be further investigated and verified by the community. The duration + of the experiment is expected to be no less than two years from the + publication of this document. + + + + + + + + + + +Shpiner, et al. Experimental [Page 14] + +RFC 8039 Multipath Time Synchronization December 2016 + + +9. References + +9.1. Normative References + + [IEEE1588] IEEE Instrumentation and Measurement Society, "IEEE + Standard for a Precision Clock Synchronization Protocol + for Networked Measurement and Control Systems", IEEE + Std 1588-2008, DOI 10.1109/IEEESTD.2008.4579760. + + [NTP] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, + "Network Time Protocol Version 4: Protocol and Algorithms + Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, + <http://www.rfc-editor.org/info/rfc5905>. + +9.2. Informative References + + [ASYMMETRY] + He, Y., Faloutsos, M., Krishnamurthy, S., and B. Huffaker, + "On routing asymmetry in the Internet", IEEE GLOBECOM, + DOI 10.1109/GLOCOM.2005.1577769, December 2005. + + [ASYMMETRY2] + Pathak, A., Pucha, H., Zhang, Y., Hu, C., and Z. Mao, "A + measurement study of internet delay asymmetry", + International Conference on Passive and Active Network + Measurement 2008, DOI 10.1007/978-3-540-79232-1_19, + April 2008. + + [DELAY-ATT] + Mizrahi, T., "A Game Theoretic Analysis of Delay Attacks + against Time Synchronization Protocols", IEEE + International Symposium on Precision Clock Synchronization + for Measurement, Control and Communication (ISPCS), + DOI 10.1109/ISPCS.2012.6336612, September 2012. + + [HIGH-AVAI] + Ferrari, P., Flammini, A., Rinaldi, S., and G. Prytz, + "High availability IEEE 1588 nodes over IEEE 802.1 aq + Shortest Path Bridging networks", IEEE International + Symposium on Precision Clock Synchronization for + Measurement, Control and Communication (ISPCS), + DOI 10.1109/ISPCS.2013.6644760, September 2013. + + [KALMAN] Giorgi, G. and C. Narduzzi, "Kalman filtering for + multi-path network synchronization", IEEE International + Symposium on Precision Clock Synchronization for + Measurement, Control and Communication (ISPCS), + DOI 10.1109/ISPCS.2014.6948693, September 2014. + + + +Shpiner, et al. Experimental [Page 15] + +RFC 8039 Multipath Time Synchronization December 2016 + + + [MIF] Blanchet, M. and P. Seite, "Multiple Interfaces and + Provisioning Domains Problem Statement", RFC 6418, + DOI 10.17487/RFC6418, November 2011, + <http://www.rfc-editor.org/info/rfc6418>. + + [MPTCP] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, + "TCP Extensions for Multipath Operation with Multiple + Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, + <http://www.rfc-editor.org/info/rfc6824>. + + [MULTI] Shpiner, A., Revah, Y., and T. Mizrahi, "Multi-path Time + Protocols", IEEE International Symposium on Precision + Clock Synchronization for Measurement, Control and + Communication (ISPCS), DOI 10.1109/ISPCS.2013.6644754, + September 2013. + + [PARIS] Augustin, B., Friedman, T., and R. Teixeira, "Measuring + Load-balanced Paths in the Internet", 7th ACM SIGCOMM + conference on Internet measurement (IMC '07), + DOI 10.1145/1298306.1298329, October 2007. + + [PARIS2] Augustin, B., Friedman, T., and R. Teixeira, "Measuring + Multipath Routing in the Internet", IEEE/ACM Transactions + on Networking, 19(3), pp. 830-840, + DOI 10.1109/TNET.2010.2096232, June 2011. + + [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in + Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, + October 2014, <http://www.rfc-editor.org/info/rfc7384>. + + [SLAVEDIV] Mizrahi, T., "Slave Diversity: Using Multiple Paths to + Improve the Accuracy of Clock Synchronization Protocols", + IEEE International Symposium on Precision Clock + Synchronization for Measurement, Control and Communication + (ISPCS), DOI 10.1109/ISPCS.2012.6336621, September 2012. + + [TRACEFLOW] + Narasimhan, J., Venkataswami, B., Groves, R., and P. + Hoose, "Traceflow", Work in Progress, + draft-janapath-intarea-traceflow-00, January 2012. + + + + + + + + + + + +Shpiner, et al. Experimental [Page 16] + +RFC 8039 Multipath Time Synchronization December 2016 + + +Acknowledgments + + The authors would like to thank Yoram Revah for his contribution to + this work. The authors also gratefully acknowledge the useful + comments provided by Peter Meyer, Doug Arnold, Joe Abley, Zhen Cao, + Watson Ladd, and Mirja Kuehlewind, as well as other comments received + from the TICTOC working group participants. + +Authors' Addresses + + Alex Shpiner + Mellanox Technologies, Ltd. + Hakidma 26 + Ofer Industrial Park + Yokneam, 2069200 + Israel + + Email: alexshp@mellanox.com + + + Richard Tse + Microsemi + 8555 Baxter Place + Burnaby, BC V5A 4V7 + Canada + + Email: Richard.Tse@microsemi.com + + + Craig Schelp + Oracle + + Email: craig.schelp@oracle.com + + + Tal Mizrahi + Marvell + 6 Hamada St. + Yokneam, 2066721 + Israel + + Email: talmi@marvell.com + + + + + + + + + +Shpiner, et al. Experimental [Page 17] + |