draft-ietf-tictoc-multi-path-synchronization-06.txt   draft-ietf-tictoc-multi-path-synchronization-07.txt 
Network Working Group A. Shpiner Network Working Group A. Shpiner
Internet Draft Mellanox Internet Draft Mellanox
Intended status: Experimental R. Tse Intended status: Experimental R. Tse
Expires: April 2017 PMC-Sierra Expires: April 2017 PMC-Sierra
C. Schelp C. Schelp
Oracle Oracle
T. Mizrahi T. Mizrahi
Marvell Marvell
October 6, 2016 October 27, 2016
Multi-Path Time Synchronization Multi-Path Time Synchronization
draft-ietf-tictoc-multi-path-synchronization-06.txt draft-ietf-tictoc-multi-path-synchronization-07.txt
Abstract Abstract
Clock synchronization protocols are very widely used in IP-based Clock synchronization protocols are very widely used in IP-based
networks. The Network Time Protocol (NTP) has been commonly deployed networks. The Network Time Protocol (NTP) has been commonly deployed
for many years, and the last few years have seen an increasingly for many years, and the last few years have seen an increasingly
rapid deployment of the Precision Time Protocol (PTP). As time- rapid deployment of the Precision Time Protocol (PTP). As time-
sensitive applications evolve, clock accuracy requirements are sensitive applications evolve, clock accuracy requirements are
becoming increasingly stringent, requiring the time synchronization becoming increasingly stringent, requiring the time synchronization
protocols to provide high accuracy. This memo describes a multi-path protocols to provide high accuracy. This memo describes a multi-path
skipping to change at page 2, line 8 skipping to change at page 2, line 8
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 6, 2017. This Internet-Draft will expire on April 27, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 50 skipping to change at page 2, line 50
5.2. Single-Ended Multi-Path Synchronization...................8 5.2. Single-Ended Multi-Path Synchronization...................8
5.2.1. Single-Ended MPPTP Synchronization Message Exchange..8 5.2.1. Single-Ended MPPTP Synchronization Message Exchange..8
5.2.2. Single-Ended MPNTP Synchronization Message Exchange..9 5.2.2. Single-Ended MPNTP Synchronization Message Exchange..9
5.3. Dual-Ended Multi-Path Synchronization....................10 5.3. Dual-Ended Multi-Path Synchronization....................10
5.3.1. Dual-Ended MPPTP Synchronization Message Exchange...10 5.3.1. Dual-Ended MPPTP Synchronization Message Exchange...10
5.3.2. Dual-Ended MPNTP Synchronization Message Exchange...11 5.3.2. Dual-Ended MPNTP Synchronization Message Exchange...11
5.4. Using Traceroute for Path Discovery......................12 5.4. Using Traceroute for Path Discovery......................12
5.5. Using Unicast Discovery for MPPTP........................13 5.5. Using Unicast Discovery for MPPTP........................13
6. Combining Algorithm...........................................13 6. Combining Algorithm...........................................13
7. Security Considerations.......................................14 7. Security Considerations.......................................14
8. IANA Considerations...........................................14 8. Scope of the Experiment.......................................14
9. Acknowledgments...............................................14 9. IANA Considerations...........................................14
10. References...................................................14 10. Acknowledgments..............................................15
10.1. Normative References....................................14 11. References...................................................15
10.2. Informative References..................................15 11.1. Normative References....................................15
11.2. Informative References..................................15
1. Introduction 1. Introduction
The two most common time synchronization protocols in IP networks are The two most common time synchronization protocols in IP networks are
the Network Time Protocol [NTP], and the Precision Time Protocol the Network Time Protocol [NTP], and the Precision Time Protocol
(PTP), defined in the IEEE 1588 standard [IEEE1588]. (PTP), defined in the IEEE 1588 standard [IEEE1588].
The accuracy of the time synchronization protocols directly depends The accuracy of the time synchronization protocols directly depends
on the stability and the symmetry of propagation delays on both on the stability and the symmetry of propagation delays on both
directions between the master and slave clocks. Depending on the directions between the master and slave clocks. Depending on the
nature of the underlying network, time synchronization protocol nature of the underlying network, time synchronization protocol
skipping to change at page 14, line 8 skipping to change at page 14, line 8
The combining algorithm should be chosen carefully based on the The combining algorithm should be chosen carefully based on the
system properties, as different combining algorithms provide system properties, as different combining algorithms provide
different advantages. For example, some combining algorithms (e.g., different advantages. For example, some combining algorithms (e.g.,
[NTP], [DELAY-ATT]) are intended to be robust in the face of security [NTP], [DELAY-ATT]) are intended to be robust in the face of security
attacks, while other combining algorithms (e.g., [KALMAN]) are more attacks, while other combining algorithms (e.g., [KALMAN]) are more
resilient to random delay variation. resilient to random delay variation.
7. Security Considerations 7. Security Considerations
The security aspects of time synchronization protocols are discussed The security aspects of time synchronization protocols are discussed
in detail in [TICTOCSEC]. The methods describe in this document in detail in [RFC7384]. The methods described in this document
propose to run a time synchronization protocol through redundant propose to run a time synchronization protocol through redundant
paths, and thus allow to detect and mitigate man-in-the-middle paths, and thus allow to detect and mitigate man-in-the-middle
attacks, as described in [DELAY-ATT]. It should be noted that when attacks, as described in [DELAY-ATT]. Specifically, multi-path
using multiple paths, these paths may partially overlap, and thus an synchronization can mitigate the following threats (as per
attack that takes place in a common segment of these paths is not [RFC7384]):
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 o Packet manipulation (Section 3.2.1 of [RFC7384]).
migrate from one router to another. Therefore, when using multiple
paths it is important for the paths to be as diverse and as o Packet Interception and Removal (Section 3.2.5 of [RFC7384]).
independent as possible, making the redundancy scheme more tolerant
to on-path attacks. 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 multi-path approach requires the master It should be noted that the multi-path approach requires the master
(or NTP server) to dedicate more resources to each slave (client) (or NTP server) to dedicate more resources to each slave (client)
than the conventional single-path approach. Hence, well-known than the conventional single-path approach. Hence, well-known
Distributed Denial-of-Service (DDoS) attacks may porentially be Distributed Denial-of-Service (DDoS) attacks may porentially be
amplified when the multi-path approach is enabled. amplified when the multi-path approach is enabled.
8. IANA Considerations 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.
9. IANA Considerations
There are no IANA actions required by this document. There are no IANA actions required by this document.
RFC Editor: please delete this section before publication. RFC Editor: please delete this section before publication.
9. Acknowledgments 10. Acknowledgments
The authors gratefully acknowledge the useful comments provided by The authors gratefully acknowledge the useful comments provided by
Peter Meyer, Doug Arnold, Joe Abley, Zhen Cao, Watson Ladd, and Peter Meyer, Doug Arnold, Joe Abley, Zhen Cao, Watson Ladd, and
Mirja Kuehlewind, as well as other comments received from the TICTOC Mirja Kuehlewind, as well as other comments received from the TICTOC
working group participants. working group participants.
This document was prepared using 2-Word-v2.0.template.dot. This document was prepared using 2-Word-v2.0.template.dot.
10. References 11. References
10.1. Normative References 11.1. Normative References
[IEEE1588] IEEE Instrumentation and Measurement Society, "IEEE [IEEE1588] IEEE Instrumentation and Measurement Society, "IEEE
Standard for a Precision Clock Synchronization Standard for a Precision Clock Synchronization
Protocol for Networked Measurement and Control Protocol for Networked Measurement and Control
Systems", IEEE Std 1588, 2008. Systems", IEEE Std 1588, 2008.
[NTP] D. Mills, J. Martin, J. Burbank, W. Kasch, "Network [NTP] D. Mills, J. Martin, J. Burbank, W. Kasch, "Network
Time Protocol Version 4: Protocol and Algorithms Time Protocol Version 4: Protocol and Algorithms
Specification", IETF, RFC 5905, 2010. Specification", IETF, RFC 5905, 2010.
10.2. Informative References 11.2. Informative References
[ASSYMETRY] Yihua He and Michalis Faloutsos and Srikanth [ASSYMETRY] Yihua He and Michalis Faloutsos and Srikanth
Krishnamurthy and Bradley Huffaker, "On routing Krishnamurthy and Bradley Huffaker, "On routing
asymmetry in the internet", IEEE Globecom, 2005. asymmetry in the internet", IEEE Globecom, 2005.
[ASSYMETRY2] Abhinav Pathak, Himabindu Pucha, Ying Zhang, Y. [ASSYMETRY2] Abhinav Pathak, Himabindu Pucha, Ying Zhang, Y.
Charlie Hu, and Z. Morley Mao, "A measurement study of Charlie Hu, and Z. Morley Mao, "A measurement study of
internet delay asymmetry", PAM'08, 2008. internet delay asymmetry", PAM'08, 2008.
[DELAY-ATT] T. Mizrahi, "A Game Theoretic Analysis of Delay [DELAY-ATT] T. Mizrahi, "A Game Theoretic Analysis of Delay
skipping to change at page 16, line 5 skipping to change at page 16, line 22
[PARIS] Brice Augustin, Timur Friedman and Renata Teixeira, [PARIS] Brice Augustin, Timur Friedman and Renata Teixeira,
"Measuring Load-balanced Paths in the Internet", IMC, "Measuring Load-balanced Paths in the Internet", IMC,
2007. 2007.
[PARIS2] B. Augustin, T. Friedman, and R. Teixeira, "Measuring [PARIS2] B. Augustin, T. Friedman, and R. Teixeira, "Measuring
Multipath Routing in the Internet", IEEE/ACM Multipath Routing in the Internet", IEEE/ACM
Transactions on Networking, 19(3), p. 830 - 840, June Transactions on Networking, 19(3), p. 830 - 840, June
2011. 2011.
[RFC7384] T. Mizrahi, "Security Requirements of Time Protocols
in Packet Switched Networks", IETF, RFC 7384, 2014.
[SLAVEDIV] T. Mizrahi, "Slave Diversity: Using Multiple Paths to [SLAVEDIV] T. Mizrahi, "Slave Diversity: Using Multiple Paths to
Improve the Accuracy of Clock Synchronization Improve the Accuracy of Clock Synchronization
Protocols", ISPCS, 2012. Protocols", ISPCS, 2012.
[TICTOCSEC] T. Mizrahi, "Security Requirements of Time Protocols
in Packet Switched Networks", IETF, RFC 7384, 2014.
[TRACEFLOW] J. Narasimhan, B. V. Venkataswami, R. Groves and P. [TRACEFLOW] J. Narasimhan, B. V. Venkataswami, R. Groves and P.
Hoose, "Traceflow", IETF, draft-janapath-intarea- Hoose, "Traceflow", IETF, draft-janapath-intarea-
traceflow, work in progress, 2012. traceflow, work in progress, 2012.
Authors' Addresses Authors' Addresses
Alex Shpiner Alex Shpiner
Mellanox Technologies, Ltd. Mellanox Technologies, Ltd.
Hakidma 26 Hakidma 26
Ofer Industrial Park Ofer Industrial Park
 End of changes. 13 change blocks. 
26 lines changed or deleted 47 lines changed or added

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