idnits 2.17.1 draft-ietf-tictoc-multi-path-synchronization-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 6, 2016) is 2751 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 6824 (ref. 'MPTCP') (Obsoleted by RFC 8684) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. Shpiner 2 Internet Draft Mellanox 3 Intended status: Experimental R. Tse 4 Expires: April 2017 PMC-Sierra 5 C. Schelp 6 Oracle 7 T. Mizrahi 8 Marvell 9 October 6, 2016 11 Multi-Path Time Synchronization 12 draft-ietf-tictoc-multi-path-synchronization-06.txt 14 Abstract 16 Clock synchronization protocols are very widely used in IP-based 17 networks. The Network Time Protocol (NTP) has been commonly deployed 18 for many years, and the last few years have seen an increasingly 19 rapid deployment of the Precision Time Protocol (PTP). As time- 20 sensitive applications evolve, clock accuracy requirements are 21 becoming increasingly stringent, requiring the time synchronization 22 protocols to provide high accuracy. This memo describes a multi-path 23 approach to PTP and NTP over IP networks, allowing the protocols to 24 run concurrently over multiple communication paths between the master 25 and slave clocks, without modifying these protocols. The multi-path 26 approach can significantly contribute to clock accuracy, security and 27 fault tolerance. The multi-path approach that is presented in this 28 document enables backward compatibility with nodes that do not 29 support the multi-path functionality. 31 Status of this Memo 33 This Internet-Draft is submitted to IETF in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF), its areas, and its working groups. Note that 38 other groups may also distribute working documents as Internet- 39 Drafts. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 The list of current Internet-Drafts can be accessed at 47 http://www.ietf.org/ietf/1id-abstracts.txt. 49 The list of Internet-Draft Shadow Directories can be accessed at 50 http://www.ietf.org/shadow.html. 52 This Internet-Draft will expire on April 6, 2017. 54 Copyright Notice 56 Copyright (c) 2016 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction...................................................3 72 2. Conventions Used in this Document..............................4 73 2.1. Abbreviations.............................................4 74 2.2. Terminology...............................................5 75 3. Multiple Paths in IP Networks..................................5 76 3.1. Load Balancing............................................5 77 3.2. Using Multiple Paths Concurrently.........................5 78 3.3. Two-Way Paths.............................................6 79 4. Solution Overview..............................................6 80 4.1. Path Configuration and Identification.....................6 81 4.2. Combining.................................................7 82 5. Multi-Path Time Synchronization over IP Networks...............7 83 5.1. Overview..................................................7 84 5.2. Single-Ended Multi-Path Synchronization...................8 85 5.2.1. Single-Ended MPPTP Synchronization Message Exchange..8 86 5.2.2. Single-Ended MPNTP Synchronization Message Exchange..9 87 5.3. Dual-Ended Multi-Path Synchronization....................10 88 5.3.1. Dual-Ended MPPTP Synchronization Message Exchange...10 89 5.3.2. Dual-Ended MPNTP Synchronization Message Exchange...11 90 5.4. Using Traceroute for Path Discovery......................12 91 5.5. Using Unicast Discovery for MPPTP........................13 92 6. Combining Algorithm...........................................13 93 7. Security Considerations.......................................14 94 8. IANA Considerations...........................................14 95 9. Acknowledgments...............................................14 96 10. References...................................................14 97 10.1. Normative References....................................14 98 10.2. Informative References..................................15 100 1. Introduction 102 The two most common time synchronization protocols in IP networks are 103 the Network Time Protocol [NTP], and the Precision Time Protocol 104 (PTP), defined in the IEEE 1588 standard [IEEE1588]. 105 The accuracy of the time synchronization protocols directly depends 106 on the stability and the symmetry of propagation delays on both 107 directions between the master and slave clocks. Depending on the 108 nature of the underlying network, time synchronization protocol 109 packets can be subject to variable network latency or path asymmetry 110 (e.g. [ASSYMETRY], [ASSYMETRY2]). As time sensitive applications 111 evolve, accuracy requirements are becoming increasingly stringent. 113 Using a single network path in a clock synchronization protocol 114 closely ties the slave clock accuracy to the behavior of the specific 115 path, which may suffer from temporal congestion, faults or malicious 116 attacks. Relying on multiple clock servers as in NTP solves these 117 problems, but requires active maintenance of multiple accurate 118 sources in the network, which is not always possible. The usage of 119 Transparent Clocks (TC) in PTP solves the congestion problem by 120 eliminating the queueing time from the delay calculations, but does 121 not address security or fault-tolerance aspects. 122 ____ 123 ______/ \_____ 124 ___/ \____ 125 ____/ \ 126 ____ / path 1 / ___ 127 / \ / ________________________ \ / \ 128 /Master\____\___/ \____\________/Slave\ 129 \Clock / / \________ _______________/ \ \Clock/ 130 \____/ \ / \__ / 131 \____ path 2 __/ 132 \_______ ______/ 133 \_________/ 135 Figure 1 Multi-Path Connection 137 Since master and slave clocks are often connected through more than 138 one path in the network, as shown in Figure 1, [SLAVEDIV] suggested 139 that a time synchronization protocol can be run over multiple paths, 140 providing several advantages. First, it can significantly increase 141 the clock accuracy as shown in [SLAVEDIV]. Second, this approach 142 provides additional security, allowing to mitigate man-in-the-middle 143 attacks against the time synchronization protocol [DELAY-ATT]. Third, 144 using multiple paths concurrently provides an inherent failure 145 protection mechanism. 147 This document introduces Multi-Path PTP (MPPTP) and Multi-Path NTP 148 (MPNTP). The functionality of the multi-path approach is defined at 149 the network layer and does not require any changes in the PTP or in 150 the NTP protocols. 152 MPPTP and MPNTP are defined over IP networks. As IP networks 153 typically combine ECMP routing, this property is leveraged for the 154 multiple paths used in MPPTP and MPNTP. The key property of the 155 multi-path approach is that clocks in the network can use more than 156 one IP address. Each {master IP, slave IP} address pair defines a 157 path. Depending on the network topology and configuration, the IP 158 combination pairs can form multiple diverse paths used by the multi- 159 path synchronization protocols. It has been shown [MULTI] that using 160 multiple IP addresses over the wide Internet indeed allows two end- 161 points to attain multiple diverse paths. 163 This document introduces two variants of the multi-path approach; a 164 variant that requires both master and slave nodes to support the 165 multi-path functionality, referred to as the dual-ended variant, and 166 a backward compatible variant that allows a multi-path clock to 167 connect to a conventional single-path clock, referred to as the 168 single-ended variant. 170 2. Conventions Used in this Document 172 2.1. Abbreviations 174 BMC Best Master Clock [IEEE1588] 176 ECMP Equal Cost Multiple Path 178 LAN Local Area Network 180 MPNTP Multi-Path Network Time Protocol 182 MPPTP Multi-Path Precision Time Protocol 183 NTP Network Time Protocol [NTP] 185 PTP Precision Time Protocol [IEEE1588] 187 2.2. Terminology 189 In the NTP terminology, a time synchronization protocol is run 190 between a client and a server, while PTP uses the terms master and 191 slave. Throughout this document, the sections that refer to both PTP 192 and NTP generically use the terms master and slave. 194 3. Multiple Paths in IP Networks 196 3.1. Load Balancing 198 Traffic sent across IP networks is often load balanced across 199 multiple paths. The load balancing decisions are typically based on 200 packet header fields: source and destination addresses, Layer 4 201 ports, the Flow Label field in IPv6, etc. 202 Three common load balancing criteria are per-destination, per-flow 203 and per-packet. The per-destination load balancers take a load 204 balancing decision based on the destination IP address. Per-flow load 205 balancers use various fields in the packet header, e.g., IP addresses 206 and Layer 4 ports, for the load balancing decision. Per-packet load 207 balancers use flow-blind techniques such as round-robin without 208 basing the choice on the packet content. 210 3.2. Using Multiple Paths Concurrently 212 To utilize the diverse paths that traverse per-destination load- 213 balancers or per-flow load-balancers, the packet transmitter can vary 214 the IP addresses in the packet header. The analysis in [PARIS2] shows 215 that a significant majority of the flows on the internet traverse 216 per-destination or per-flow load-balancing. It presents statistics 217 that 72% of the flows traverse per-destination load balancing and 39% 218 of the flows traverse per-flow load-balancing, while only a 219 negligible part of the flows traverse per-packet load balancing. 220 These statistics show that the vast majority of the traffic on the 221 internet is load balanced based on packet header fields. 223 The approaches in this draft are based on varying the source and 224 destination IP addresses in the packet header. Possible extensions 225 have been considered that also vary the UDP ports. However some of 226 the existing implementations of PTP and NTP use fixed UDP port values 227 in both the source and destination UDP port fields, and thus do not 228 allow this approach. 230 3.3. Two-Way Paths 232 A key property of IP networks is that packets forwarded from A to B 233 do not necessarily traverse the same path as packets from B to A. 234 Thus, we define a two-way path for a master-slave connection as a 235 pair of one-way paths: the first from master to slave and the second 236 from slave to master. 238 If possible, a traffic engineering approach can be used to verify 239 that time synchronization traffic is always forwarded through 240 bidirectional two-way paths, i.e., that each two-way path uses the 241 same route on the forward and reverse directions, thus allowing 242 propagation time symmetry. However, in the general case two-way paths 243 do not necessarily use the same path for the forward and reverse 244 directions. 246 4. Solution Overview 248 The multi-path time synchronization protocols we present are 249 comprised of two building blocks; one is the path configuration and 250 identification, and the other is the algorithm used by the slave to 251 combine the information received from the various paths. 253 4.1. Path Configuration and Identification 255 The master and slave clocks must be able to determine the path of 256 transmitted protocol packets, and to identify the path of incoming 257 protocol packets. A path is determined by a {master IP, slave IP} 258 address pair. The synchronization protocol message exchange is run 259 independently through each path. 261 Each IP address pair defines a two-way path, and thus allows the 262 clocks to bind a transmitted packet to a specific path, or to 263 identify the path of an incoming packet. 265 If possible, the routing tables across the network should be 266 configured with multiple traffic engineered paths between the pair of 267 clocks. By carefully configuring the routers in such networks it is 268 possible to create diverse paths for each of the IP address pairs 269 between two clocks in the network. However, in public and provider 270 networks the load balancing behavior is hidden from the end users. In 271 this case the actual number of paths may be less than the number of 272 IP address pairs, since some of the address pairs may share common 273 paths. 275 4.2. Combining 277 Various methods can be used for combining the time information 278 received from the different paths. The output of the combining 279 algorithm is the accurate time offset. Combining methods are further 280 discussed in Section 6. 282 5. Multi-Path Time Synchronization over IP Networks 284 5.1. Overview 286 This section presents two variants of MPPTP and MPNTP; single-ended 287 multi-path time synchronization and dual-ended multi-path time 288 synchronization. In the first variant, the multi-path approach is 289 only implemented by the slave and the master is not aware of its 290 usage. In the second variant, all clocks use multiple paths. 292 The dual-ended variant provides higher path diversity by using 293 multiple IP addresses at both ends, the master and slave, while the 294 single-ended variant only uses multiple addresses at the slave. 295 Consequently, the single-ended approach is can interoperate with 296 existing implementations, which do not use multiple paths. The dual- 297 ended and single-ended approaches can co-exist in the same network; 298 each slave selects the connection(s) it wants to make with the 299 available masters. A dual-ended slave could switch to single-ended 300 mode if it does not see any dual-ended masters available. A single- 301 ended slave could connect to a single IP address of a dual-ended 302 master. 304 Multi-path time synchronization, in both variants, requires clocks to 305 use multiple IP addresses. Using multiple IP addresses introduces a 306 tradeoff. A large number of IP addresses allows a large number of 307 diverse paths, providing the advantages of slave diversity discussed 308 in Section 1. On the other hand, a large number of IP addresses is 309 more costly, requires the network topology to be more redundant, and 310 exacts extra management overhead. 312 If possible, the set of IP addresses for each clock should be chosen 313 in a way that enables the establishment of paths that are the most 314 different. If the load balancing rules in the network are known, it 315 is possible to choose the IP addresses in a way that enforces path 316 diversity. However, even if the load balancing scheme is not known, a 317 careful choice of the IP addresses can increase the probability of 318 path diversity. For example, choosing multiple addresses with 319 different prefixes is likely to produce higher path diversity, as BGP 320 routers are more likely to route these different prefixes through 321 different routes. 323 The use of Network Address Translation (NAT) may significantly reduce 324 the effectiveness of multi-path synchronization in some cases. For 325 example, if a master uses multiple IP addresses that are translated 326 to a single IP address, the path diversity can be dramatically 327 reduced compared to a network that does not use NAT. Thus, path 328 discovery should be used to identify the possible paths between the 329 master and slave. Path discovery is further discussed in Section 5.4. 331 The concept of using multiple IP addresses or multiple interfaces is 332 a well-established concept that is being used today by various 333 applications and protocols, e.g., [MPTCP]. Using multiple interfaces 334 introduces some challenges and issues, which were presented and 335 discussed in [MIF]. 337 The descriptions in this section refer to the end-to-end scheme of 338 PTP, but are similarly applicable to the peer-to-peer scheme. MPNTP, 339 as described in this document, refers to the NTP client-server mode, 340 although the concepts described here can be extended to include the 341 symmetric variant as well. 343 Multi-path synchronization by nature requires protocol messages to be 344 sent as unicast. Specifically in PTP, the following messages must be 345 sent as unicast in MPPTP: Sync, Delay_Req, Delay_Resp, PDelay_Req, 346 PDelay_Resp, Follow_Up, and PDelay_Resp_Follow_Up. Note that 347 [IEEE1588] allows these messages to be sent either as multicast or as 348 unicast. 350 5.2. Single-Ended Multi-Path Synchronization 352 In the single-ended approach, only the slave is aware of the fact 353 that multiple paths are used, while the master is agnostic to the 354 usage of multiple paths. This approach allows a hybrid network, where 355 some of the clocks are multi-path clocks, and others are conventional 356 one-path clocks. A single-ended multi-path clock presents itself to 357 the network as N independent clocks, using N IP addresses, as well as 358 N clock identity values (in PTP). Thus, the usage of multiple slave 359 identities by a slave clock is transparent from the master's point of 360 view, such that it treats each of the identities as a separate slave 361 clock. 363 5.2.1. Single-Ended MPPTP Synchronization Message Exchange 365 The single-ended MPPTP message exchange procedure is as follows. 367 o Each single-ended MPPTP clock has a fixed set of N IP addresses 368 and N corresponding clockIdentities. Each clock arbitrarily 369 defines one of its IP addresses and clockIdentity values as the 370 clock primary identity. 372 o A single-ended MPPTP port sends Announce messages only from its 373 primary identity, according to the BMC algorithm. 375 o The BMC algorithm at each clock determines the master, based on 376 the received Announce messages. 378 o A single-ended MPPTP port that is in the 'slave' state uses 379 unicast negotiation to request the master to transmit unicast 380 messages to each of the N slave clock identities. The slave port 381 periodically sends N Signaling messages to the master, using each 382 of its N identities. The Signaling message includes the 383 REQUEST_UNICAST_TRANSMISSION_TLV. 385 o The master periodically sends unicast Sync messages from its 386 primary identity, identified by the sourcePortIdentity and IP 387 address, to each of the slave identities. 389 o The slave, upon receiving a Sync message, identifies its path 390 according to the destination IP address. The slave sends a 391 Delay_Req unicast message to the primary identity of the master. 392 The Delay_Req is sent using the slave identity corresponding to 393 the path the Sync was received through. Note that the rate of 394 Delay_Req messages may be lower than the Sync message rate, and 395 thus a Sync message is not necessarily followed by a Delay_Req. 397 o The master, in response to a Delay_Req message from the slave, 398 responds with a Delay_Resp message using the IP address and 399 sourcePortIdentity from the Delay_Req message. 401 o Upon receiving the Delay_Resp message, the slave identifies the 402 path using the destination IP address and the 403 requestingPortIdentity. The slave can then compute the 404 corresponding path delay and the offset from the master. 406 o The slave combines the information from all negotiated paths. 408 5.2.2. Single-Ended MPNTP Synchronization Message Exchange 410 The single-ended MPNTP message exchange procedure is as follows. 412 o A single-ended MPNTP client has N separate identities, i.e., N IP 413 addresses. The assumption is that the server information, 414 including its IP address is known to the NTP clients. This is a 415 fair assumption, as typically the address(es) of the NTP server(s) 416 are provided to the NTP client by configuration. 418 o A single-ended MPNTP client initiates the NTP protocol with an NTP 419 server N times, using each of its N identities. 421 o The NTP protocol is maintained between the server and each of the 422 N client identities. 424 o The client sends NTP messages to the master using each of its N 425 identities. 427 o The server responds to the client's NTP messages using the IP 428 address from the received NTP packet. 430 o The client, upon receiving an NTP packet, uses the IP destination 431 address to identify the path it came through, and uses the time 432 information accordingly. 434 o The client combines the information from all paths. 436 5.3. Dual-Ended Multi-Path Synchronization 438 In dual-ended multi-path synchronization each clock has N IP 439 addresses. Time synchronization messages are exchanged between some 440 of the combinations of {master IP, slave IP} addresses, allowing 441 multiple paths between the master and slave. Note that the actual 442 number of paths between the master and slave may be less than the 443 number of chosen {master, slave} IP address pairs. 445 Once the multiple two-way connections are established, a separate 446 synchronization protocol exchange instance is run through each of 447 them. 449 5.3.1. Dual-Ended MPPTP Synchronization Message Exchange 451 The dual-ended MPPTP message exchange procedure is as follows. 453 o Every clock has N IP addresses, but uses a single clockIdentity. 455 o The BMC algorithm at each clock determines the master. The master 456 is identified by its clockIdentity, allowing other clocks to know 457 the multiple IP addresses it uses. 459 o When a clock sends an Announce message, it sends it from each of 460 its IP addresses with its clockIdentity. 462 o A dual-ended MPPTP port that is in the 'slave' state uses unicast 463 negotiation to request the master to transmit unicast messages to 464 some or all of its N_s IP addresses. This negotiation is done 465 individually between a slave IP address and the corresponding 466 master IP address that the slave desires a connection with. The 467 slave port periodically sends Signaling messages to the master, 468 using some or all of its N_s IP addresses as source, to the 469 corresponding master's N_m IP addresses. The Signaling message 470 includes the REQUEST_UNICAST_TRANSMISSION_TLV. 472 o The master periodically sends unicast Sync messages from each of 473 its IP addresses to the corresponding slave IP addresses for which 474 a unicast connection was negotiated. 476 o The slave, upon receiving a Sync message, identifies its path 477 according to the {source, destination} IP addresses. The slave 478 sends a Delay_Req unicast message, swapping the source and 479 destination IP addresses from the Sync message. Note that the rate 480 of Delay_Req messages may be lower than the Sync message rate, and 481 thus a Sync message is not necessarily followed by a Delay_Req. 483 o The master, in response to a Delay_Req message from the slave, 484 responds with a Delay_Resp message using the sourcePortIdentity 485 from the Delay_Req message, and swapping the IP addresses from the 486 Delay_Req. 488 o Upon receiving the Delay_Resp message, the slave identifies the 489 path using the {source, destination} IP address pair. The slave 490 can then compute the corresponding path delay and the offset from 491 the master. 493 o The slave combines the information from all negotiated paths. 495 5.3.2. Dual-Ended MPNTP Synchronization Message Exchange 497 The MPNTP message exchange procedure is as follows. 499 o Each NTP clock has a set of N IP addresses. The assumption is that 500 the server information, including its multiple IP addresses is 501 known to the NTP clients. 503 o The MPNTP client chooses N_svr of the N server IP addresses and 504 N_c of the N client IP addresses and initiates the N_svr*N_c 505 instances of the protocol, one for each {server IP, client IP} 506 pair, allowing the client to combine the information from the 507 N_s*N_c paths. 508 (N_svr and N_c indicate the number of IP addresses of the server 509 and client, respectively, which a client chooses to connect with) 511 o The client sends NTP messages to the master using each of the 512 source-destination address combinations. 514 o The server responds to the client's NTP messages using the IP 515 address combination from the received NTP packet. 517 o Using the {source, destination} IP address pair in the received 518 packets, the client identifies the path, and performs its 519 computations for each of the paths accordingly. 521 o The client combines the information from all paths. 523 5.4. Using Traceroute for Path Discovery 525 The approach described thus far uses multiple IP addresses in a 526 single clock to create multiple paths. However, although each two-way 527 path is defined by a different {master, slave} address pair, some of 528 the IP address pairs may traverse exactly the same network path, 529 making them redundant. 531 Traceroute-based path discovery can be used for filtering only the IP 532 addresses that obtain diverse paths. 'Paris Traceroute' [PARIS] and 533 'TraceFlow' [TRACEFLOW] are examples of tools that discover the paths 534 between two points in the network. It should be noted that this 535 filtering approach is effective only if the Traceroute implementation 536 uses the same IP addresses and UDP ports as the synchronization 537 protocol packets. Since some Traceroute implementations vary the UDP 538 ports, they may not be effective in identifying and filtering 539 redundant paths in synchronization protocols. 541 The Traceroute-based filtering can be implemented by both master and 542 slave nodes, or it can be restricted to run only on slave nodes to 543 reduce the overhead on the master. For networks that guarantee that 544 the path of the timing packets in the forward and reverse direction 545 are the same, path discovery should only be performed at the slave. 547 Since network routes change over time, path discovery and redundant 548 path filtering should be performed periodically. Two {master,slave} 549 pairs that produce two diverse paths may be rerouted to use the same 550 paths. Thus, the set of addresses that are used by each clock should 551 be reassessed regularly. 553 5.5. Using Unicast Discovery for MPPTP 555 As presented above, MPPTP uses Announce messages and the BMC 556 algorithm to discover the master. The unicast discovery option of PTP 557 can be used as an alternative. 559 When using unicast discovery the MPPTP slave ports maintain a list of 560 the IP addresses of the master. The slave port uses unicast 561 negotiation to request unicast service from the master, as follows: 563 o In single-ended MPPTP, the slave uses unicast negotiation from 564 each of its identities to the master's (only) identity. 566 o In dual-ended MPPTP, the slave uses unicast negotiation from its 567 IP addresses, each to a corresponding master IP address to request 568 unicast synchronization messages. 570 Afterwards, the message exchange continues as described in sections 571 5.2.1. and 5.3.1. 573 The unicast discovery option can be used in networks that do not 574 support multicast or in networks in which the master clocks are known 575 in advance. In particular, unicast discovery avoids multicasting 576 Announce messages. 578 6. Combining Algorithm 580 Previous sections discussed the methods of creating the multiple 581 paths and obtaining the time information required by the slave 582 algorithm. Once the time information is received through each of the 583 paths, the slave should use a combining algorithm, which consolidates 584 the information from the different paths into a single clock. 585 Various methods have been suggested for combining information from 586 different paths or from different clocks, e.g., [NTP], [SLAVEDIV], 587 [HIGH-AVAI], [KALMAN]. The choice of the combining algorithm is local 588 to the slave, and does not affect interoperability. Hence, this 589 document does not define a specific method to be used by the slave. 590 The combining algorithm should be chosen carefully based on the 591 system properties, as different combining algorithms provide 592 different advantages. For example, some combining algorithms (e.g., 593 [NTP], [DELAY-ATT]) are intended to be robust in the face of security 594 attacks, while other combining algorithms (e.g., [KALMAN]) are more 595 resilient to random delay variation. 597 7. Security Considerations 599 The security aspects of time synchronization protocols are discussed 600 in detail in [TICTOCSEC]. The methods describe in this document 601 propose to run a time synchronization protocol through redundant 602 paths, and thus allow to detect and mitigate man-in-the-middle 603 attacks, as described in [DELAY-ATT]. It should be noted that when 604 using multiple paths, these paths may partially overlap, and thus an 605 attack that takes place in a common segment of these paths is not 606 mitigated by the redundancy. Moreover, an on-path attacker may in 607 some cases have access to more than one router, or may be able to 608 migrate from one router to another. Therefore, when using multiple 609 paths it is important for the paths to be as diverse and as 610 independent as possible, making the redundancy scheme more tolerant 611 to on-path attacks. 613 It should be noted that the multi-path approach requires the master 614 (or NTP server) to dedicate more resources to each slave (client) 615 than the conventional single-path approach. Hence, well-known 616 Distributed Denial-of-Service (DDoS) attacks may porentially be 617 amplified when the multi-path approach is enabled. 619 8. IANA Considerations 621 There are no IANA actions required by this document. 623 RFC Editor: please delete this section before publication. 625 9. Acknowledgments 627 The authors gratefully acknowledge the useful comments provided by 628 Peter Meyer, Doug Arnold, Joe Abley, Zhen Cao, Watson Ladd, and 629 Mirja Kuehlewind, as well as other comments received from the TICTOC 630 working group participants. 632 This document was prepared using 2-Word-v2.0.template.dot. 634 10. References 636 10.1. Normative References 638 [IEEE1588] IEEE Instrumentation and Measurement Society, "IEEE 639 Standard for a Precision Clock Synchronization 640 Protocol for Networked Measurement and Control 641 Systems", IEEE Std 1588, 2008. 643 [NTP] D. Mills, J. Martin, J. Burbank, W. Kasch, "Network 644 Time Protocol Version 4: Protocol and Algorithms 645 Specification", IETF, RFC 5905, 2010. 647 10.2. Informative References 649 [ASSYMETRY] Yihua He and Michalis Faloutsos and Srikanth 650 Krishnamurthy and Bradley Huffaker, "On routing 651 asymmetry in the internet", IEEE Globecom, 2005. 653 [ASSYMETRY2] Abhinav Pathak, Himabindu Pucha, Ying Zhang, Y. 654 Charlie Hu, and Z. Morley Mao, "A measurement study of 655 internet delay asymmetry", PAM'08, 2008. 657 [DELAY-ATT] T. Mizrahi, "A Game Theoretic Analysis of Delay 658 Attacks against Time Synchronization Protocols", 659 ISPCS, 2012. 661 [HIGH-AVAI] P. Ferrari, A. Flammini, S. Rinaldi, G. Prytz, "High 662 availability IEEE 1588 nodes over IEEE 802.1 aq 663 Shortest Path Bridging networks" ISPCS, 2013. 665 [KALMAN] G. Giorgi, C. Narduzzi, "Kalman filtering for multi- 666 path network synchronization" ISPCS, 2014. 668 [MIF] Blanchet, M. and P. Seite, "Multiple Interfaces and 669 Provisioning Domains Problem Statement", RFC 6418, DOI 670 10.17487/RFC6418, November 2011, . 673 [MPTCP] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 674 "TCP Extensions for Multipath Operation with Multiple 675 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 676 2013, . 678 [MULTI] A. Shpiner, Y. Revah, T. Mizrahi, "Multi-path Time 679 Protocols" ISPCS, 2013. 681 [PARIS] Brice Augustin, Timur Friedman and Renata Teixeira, 682 "Measuring Load-balanced Paths in the Internet", IMC, 683 2007. 685 [PARIS2] B. Augustin, T. Friedman, and R. Teixeira, "Measuring 686 Multipath Routing in the Internet", IEEE/ACM 687 Transactions on Networking, 19(3), p. 830 - 840, June 688 2011. 690 [SLAVEDIV] T. Mizrahi, "Slave Diversity: Using Multiple Paths to 691 Improve the Accuracy of Clock Synchronization 692 Protocols", ISPCS, 2012. 694 [TICTOCSEC] T. Mizrahi, "Security Requirements of Time Protocols 695 in Packet Switched Networks", IETF, RFC 7384, 2014. 697 [TRACEFLOW] J. Narasimhan, B. V. Venkataswami, R. Groves and P. 698 Hoose, "Traceflow", IETF, draft-janapath-intarea- 699 traceflow, work in progress, 2012. 701 Authors' Addresses 703 Alex Shpiner 704 Mellanox Technologies, Ltd. 705 Hakidma 26 706 Ofer Industrial Park 707 Yokneam, 2069200, Israel 709 Email: alexshp@mellanox.com 711 Richard Tse 712 PMC-Sierra 713 8555 Baxter Place 714 Burnaby, BC 715 Canada 716 V5A 4V7 718 Email: Richard.Tse@pmcs.com 720 Craig Schelp 721 Oracle 723 Email: craig.schelp@gmail.com 724 Tal Mizrahi 725 Marvell 726 6 Hamada St. 727 Yokneam, 20692, Israel 729 Email: talmi@marvell.com