GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc8039

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc8039.txt · Last modified: 2016/12/08 16:37 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki