draft-ietf-tictoc-ptp-enterprise-profile-10.txt   draft-ietf-tictoc-ptp-enterprise-profile-11.txt 
TICTOC Working Group Doug Arnold TICTOC Working Group Doug Arnold
Internet Draft Meinberg-USA Internet Draft Meinberg-USA
Intended status: Standards Track Heiko Gerstung Intended status: Standards Track Heiko Gerstung
Meinberg Meinberg
Expires: December 19, 2018 Expires: January 31, 2019
Enterprise Profile for the Precision Time Protocol Enterprise Profile for the Precision Time Protocol
With Mixed Multicast and Unicast Messages With Mixed Multicast and Unicast Messages
draft-ietf-tictoc-ptp-enterprise-profile-10.txt draft-ietf-tictoc-ptp-enterprise-profile-11.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be provisions of BCP 78 and BCP 79. This document may not be
modified, and derivative works of it may not be created, except to modified, and derivative works of it may not be created, except to
publish it as an RFC and to translate it into languages other than publish it as an RFC and to translate it into languages other than
English. English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
documents at any time. It is inappropriate to use Internet-Drafts documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." 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 December 19, 2018. This Internet-Draft will expire on January 31, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
skipping to change at page 4, line 5 skipping to change at page 4, line 5
3. Technical Terms 3. Technical Terms
Acceptable Master Table: A PTP Slave Clock may maintain a list of Acceptable Master Table: A PTP Slave Clock may maintain a list of
masters which it is willing to synchronize to. masters which it is willing to synchronize to.
Alternate Master: A PTP Master Clock, which is not the Best Alternate Master: A PTP Master Clock, which is not the Best
Master, may act as a master with the Alternate Master flag set on Master, may act as a master with the Alternate Master flag set on
the messages it sends. the messages it sends.
Announce message: Contains the master clock properties of a Master Announce message: Contains the Master Clock properties of a Master
clock. Used to determine the Best Master. Clock. Used to determine the Best Master.
Best Master: A clock with a port in the master state, operating Best Master: A clock with a port in the master state, operating
consistently with the Best Master Clock Algorithm. consistently with the Best Master Clock Algorithm.
Best Master Clock Algorithm: A method for determining which state Best Master Clock Algorithm: A method for determining which state
a port of a PTP clock should be in. The algorithm works by a port of a PTP clock should be in. The algorithm works by
identifying which of several PTP Master capable clocks is the best identifying which of several PTP Master capable clocks is the best
master. Clocks have priority to become the acting Grandmaster, master. Clocks have priority to become the acting Grandmaster,
based on the properties each Master Clock sends in its Announce based on the properties each Master Clock sends in its Announce
Message. Message.
Boundary Clock: A device with more than one PTP port. Generally Boundary Clock: A device with more than one PTP port. Generally
boundary clocks will have one port in slave state to receive boundary Clocks will have one port in slave state to receive
timing and then other ports in master state to re-distribute the timing and then other ports in master state to re-distribute the
timing. timing.
Clock Identity: In IEEE 1588-2008 this is a 64-bit number Clock Identity: In IEEE 1588-2008 this is a 64-bit number
assigned to each PTP clock which must be unique. Often the assigned to each PTP clock which must be unique. Often it is
Ethernet MAC address is used since there is already an derived from the Ethernet MAC address, since there is already an
international infrastructure for assigning unique numbers to each international infrastructure for assigning unique numbers to each
device manufactured. device manufactured.
Domain: Every PTP message contains a domain number. Domains are Domain: Every PTP message contains a domain number. Domains are
treated as separate PTP systems in the network. Clocks, however, treated as separate PTP systems in the network. Clocks, however,
can combine the timing information derived from multiple domains. can combine the timing information derived from multiple domains.
End to End Delay Measurement Mechanism: A network delay End to End Delay Measurement Mechanism: A network delay
measurement mechanism in PTP facilitated by an exchange of measurement mechanism in PTP facilitated by an exchange of
messages between a Master Clock and Slave Clock. messages between a Master Clock and Slave Clock.
Grandmaster: the primary master clock within a domain of a PTP Grandmaster: the primary Master Clock within a domain of a PTP
system system
IEEE 1588: The timing and synchronization standard which defines IEEE 1588: The timing and synchronization standard which defines
PTP, and describes the node, system, and communication properties PTP, and describes the node, system, and communication properties
necessary to support PTP. necessary to support PTP.
Master clock: a clock with at least one port in the master state. Master Clock: a clock with at least one port in the master state.
NTP: Network Time Protocol, defined by RFC 5905, see [NTP]. NTP: Network Time Protocol, defined by RFC 5905, see [NTP].
Ordinary Clock: A clock that has a single Precision Time Protocol Ordinary Clock: A clock that has a single Precision Time Protocol
(PTP) port in a domain and maintains the timescale used in the (PTP) port in a domain and maintains the timescale used in the
domain. It may serve as a master clock, or be a slave clock. domain. It may serve as a Master Clock, or be a slave clock.
Peer to Peer Delay Measurement Mechanism: A network delay Peer to Peer Delay Measurement Mechanism: A network delay
measurement mechanism in PTP facilitated by an exchange of measurement mechanism in PTP facilitated by an exchange of
messages between adjacent devices in a network. messages between adjacent devices in a network.
Preferred Master: A device intended to act primarily as the Preferred Master: A device intended to act primarily as the
Grandmaster of a PTP system, or as a back up to a Grandmaster. Grandmaster of a PTP system, or as a back up to a Grandmaster.
PTP: The Precision Time Protocol, the timing and synchronization PTP: The Precision Time Protocol, the timing and synchronization
protocol define by IEEE 1588. protocol defined by IEEE 1588.
PTP port: An interface of a PTP clock with the network. Note that PTP port: An interface of a PTP clock with the network. Note that
there may be multiple PTP ports running on one physical interface, there may be multiple PTP ports running on one physical interface,
for example, a unicast slave which talks to several Grandmaster for example, a unicast slave which talks to several Grandmaster
clocks in parallel. clocks in parallel.
PTPv2: Refers specifically to the second version of PTP defined by PTPv2: Refers specifically to the second version of PTP defined by
IEEE 1588-2008. IEEE 1588-2008.
Rogue Master: A clock with a port in the master state, even though Rogue Master: A clock with a port in the master state, even though
it should not be in the master state according to the Best Master it should not be in the master state according to the Best Master
Clock Algorithm, and does not set the alternate master flag. Clock Algorithm, and does not set the alternate master flag.
Slave clock: a clock with at least one port in the slave state, Slave clock: a clock with at least one port in the slave state,
and no ports in the master state. and no ports in the master state.
Slave Only Clock: An Ordinary clock which cannot become a Master Slave Only Clock: An Ordinary Clock which cannot become a Master
clock. Clock.
TLV: Type Length Value, a mechanism for extending messages in TLV: Type Length Value, a mechanism for extending messages in
networked communications. networked communications.
Transparent Clock. A device that measures the time taken for a Transparent Clock. A device that measures the time taken for a
PTP event message to transit the device and then updates the PTP event message to transit the device and then updates the
message with a correction for this transit time. message with a correction for this transit time.
Unicast Discovery: A mechanism for PTP slaves to establish a Unicast Discovery: A mechanism for PTP slaves to establish a
unicast communication with PTP masters using a configures table of unicast communication with PTP masters using a configures table of
skipping to change at page 6, line 24 skipping to change at page 6, line 24
multicast whenever the information going to many destinations is multicast whenever the information going to many destinations is
the same. It is also advantageous to send information which is the same. It is also advantageous to send information which is
unique to one device as a unicast message. The latter can be unique to one device as a unicast message. The latter can be
essential as the number of PTP slaves becomes hundreds or essential as the number of PTP slaves becomes hundreds or
thousands. thousands.
PTP devices operating in these networks need to be robust. This PTP devices operating in these networks need to be robust. This
includes the ability to ignore PTP messages which can be includes the ability to ignore PTP messages which can be
identified as improper, and to have redundant sources of time. identified as improper, and to have redundant sources of time.
Interoperability among independent implementations of this PTP
profile has been demonstrated at the ISPCS Plugfest [ISPCS].
5. Network Technology 5. Network Technology
This PTP profile SHALL operate only in networks characterized by This PTP profile SHALL operate only in networks characterized by
UDP [RFC768] over either IPv4 [RFC791] or IPv6 [RFC2460], as UDP [RFC768] over either IPv4 [RFC791] or IPv6 [RFC2460], as
described by Annexes D and E in [IEEE1588] respectively. If a described by Annexes D and E in [IEEE1588] respectively. If a
network contains both IPv4 and IPv6, then they SHALL be treated as network contains both IPv4 and IPv6, then they SHALL be treated as
separate communication paths. Clocks which communicate using IPv4 separate communication paths. Clocks which communicate using IPv4
can interact with clocks using IPv6 if there is an intermediary can interact with clocks using IPv6 if there is an intermediary
device which simultaneously communicates with both IP versions. A device which simultaneously communicates with both IP versions. A
boundary clock might perform this function, for example. A PTP Boundary Clock might perform this function, for example. A PTP
domain SHALL use either IPv4 or IPv6 over a communication path, domain SHALL use either IPv4 or IPv6 over a communication path,
but not both. The PTP system MAY include switches and routers. but not both. The PTP system MAY include switches and routers.
These devices MAY be transparent clocks, boundary clocks, or These devices MAY be Transparent Clocks, boundary Clocks, or
neither, in any combination. PTP Clocks MAY be Preferred Masters, neither, in any combination. PTP Clocks MAY be Preferred Masters,
Ordinary Clocks, or Boundary Clocks. The ordinary clocks may be Ordinary Clocks, or Boundary Clocks. The Ordinary Clocks may be
Slave Only Clocks, or be master capable. Slave Only Clocks, or be master capable.
Note that clocks SHOULD always be identified by their clock ID and Note that clocks SHOULD always be identified by their clock ID and
not the IP or Layer 2 address. This is important in IPv6 networks not the IP or Layer 2 address. This is important in IPv6 networks
since Transparent clocks are required to change the source address since Transparent Clocks are required to change the source address
of any packet which they alter. In IPv4 networks some clocks of any packet which they alter. In IPv4 networks some clocks
might be hidden behind a NAT, which hides their IP addresses from might be hidden behind a NAT, which hides their IP addresses from
the rest of the network. Note also that the use of NATs may place the rest of the network. Note also that the use of NATs may place
limitations on the topology of PTP networks, depending on the port limitations on the topology of PTP networks, depending on the port
forwarding scheme employed. Details of implementing PTP with NATs forwarding scheme employed. Details of implementing PTP with NATs
are out of scope of this document. are out of scope of this document.
PTP, like NTP, assumes that the one-way network delay for Sync PTP, like NTP, assumes that the one-way network delay for Sync
Messages and Delay Response Messages are the same. When this is Messages and Delay Response Messages are the same. When this is
not true it can cause errors in the transfer of time from the not true it can cause errors in the transfer of time from the
Master to the Slave. It is up to the system integrator to design Master to the Slave. It is up to the system integrator to design
the network so that such effects do not prevent the PTP system the network so that such effects do not prevent the PTP system
from meeting the timing requirements. The details of from meeting the timing requirements. The details of
network asymmetry are outside the scope of this document. See for network asymmetry are outside the scope of this document. See for
example, [G8271]. example, [G8271].
6. Time Transfer and Delay Measurement 6. Time Transfer and Delay Measurement
Master clocks, Transparent clocks and Boundary clocks MAY be Master Clocks, Transparent Clocks and Boundary Clocks MAY be
either one-step clocks or two-step clocks. Slave clocks MUST either one-step clocks or two-step clocks. Slave clocks MUST
support both behaviors. The End to End Delay Measurement Method support both behaviors. The End to End Delay Measurement Method
MUST be used. MUST be used.
Note that, in IP networks, Sync messages and Delay Request Note that, in IP networks, Sync messages and Delay Request
messages exchanged between a master and slave do not necessarily messages exchanged between a master and slave do not necessarily
traverse the same physical path. Thus, wherever possible, the traverse the same physical path. Thus, wherever possible, the
network SHOULD be traffic engineered so that the forward and network SHOULD be traffic engineered so that the forward and
reverse routes traverse the same physical path. Traffic reverse routes traverse the same physical path. Traffic
engineering techniques for path consistency are out of scope of engineering techniques for path consistency are out of scope of
skipping to change at page 7, line 32 skipping to change at page 7, line 32
Sync messages MUST be sent as PTP event multicast messages (UDP Sync messages MUST be sent as PTP event multicast messages (UDP
port 319) to the PTP primary IP address. Two step clocks SHALL port 319) to the PTP primary IP address. Two step clocks SHALL
send Follow-up messages as PTP general messages (UDP port 320). send Follow-up messages as PTP general messages (UDP port 320).
Announce messages MUST be sent as multicast messages (UDP port 320) Announce messages MUST be sent as multicast messages (UDP port 320)
to the PTP primary address. The PTP primary IP address is to the PTP primary address. The PTP primary IP address is
224.0.1.129 for IPv4 and FF0X:0:0:0:0:0:0:181 for Ipv6, where X can 224.0.1.129 for IPv4 and FF0X:0:0:0:0:0:0:181 for Ipv6, where X can
be a value between 0x0 and 0xF, see [IEEE1588] Annex E, Section be a value between 0x0 and 0xF, see [IEEE1588] Annex E, Section
E.3. E.3.
Delay Request Messages MAY be sent as either multicast or unicast Delay Request Messages MAY be sent as either multicast or unicast
PTP event messages. Master clocks SHALL respond to multicast Delay PTP event messages. Master Clocks SHALL respond to multicast Delay
Request messages with multicast Delay Response PTP general Request messages with multicast Delay Response PTP general
messages. Master clocks SHALL respond to unicast Delay Request PTP messages. Master Clocks SHALL respond to unicast Delay Request PTP
event messages with unicast Delay Response PTP general messages. event messages with unicast Delay Response PTP general messages.
This allow for the use of Ordinary clocks which do not support the This allow for the use of Ordinary Clocks which do not support the
Enterprise Profile, if they are slave Only Clocks. Enterprise Profile, if they are slave Only Clocks.
Clocks SHOULD include support for multiple domains. The purpose is Clocks SHOULD include support for multiple domains. The purpose is
to support multiple simultaneous masters for redundancy. Leaf to support multiple simultaneous masters for redundancy. Leaf
devices (non-forwarding devices) can use timing information from devices (non-forwarding devices) can use timing information from
multiple masters by combining information from multiple multiple masters by combining information from multiple
instantiations of a PTP stack, each operating in a different instantiations of a PTP stack, each operating in a different
domain. Redundant sources of timing can be ensembled, and/or domain. Redundant sources of timing can be ensembled, and/or
compared to check for faulty master clocks. The use of multiple compared to check for faulty Master Clocks. The use of multiple
simultaneous masters will help mitigate faulty masters reporting as simultaneous masters will help mitigate faulty masters reporting as
healthy, network delay asymmetry, and security problems. Security healthy, network delay asymmetry, and security problems. Security
problems include man-in-the-middle attacks such as delay attacks, problems include man-in-the-middle attacks such as delay attacks,
packet interception / manipulation attacks. Assuming the path to packet interception / manipulation attacks. Assuming the path to
each master is different, failures malicious or otherwise would each master is different, failures malicious or otherwise would
have to happen at more than one path simultaneously. Whenever have to happen at more than one path simultaneously. Whenever
feasible, the underlying network transport technology SHOULD be feasible, the underlying network transport technology SHOULD be
configured so that timing messages in different domains traverse configured so that timing messages in different domains traverse
different network paths. different network paths.
skipping to change at page 8, line 16 skipping to change at page 8, line 16
The Sync, Announce and Delay Request default message rates SHALL The Sync, Announce and Delay Request default message rates SHALL
each be once per second. The Sync and Delay Request message rates each be once per second. The Sync and Delay Request message rates
MAY be set to other values, but not less than once every 128 MAY be set to other values, but not less than once every 128
seconds, and not more than 128 messages per second. The Announce seconds, and not more than 128 messages per second. The Announce
message rate SHALL NOT be changed from the default value. The message rate SHALL NOT be changed from the default value. The
Announce Receipt Timeout Interval SHALL be three Announce Announce Receipt Timeout Interval SHALL be three Announce
Intervals for Preferred Masters, and four Announce Intervals for Intervals for Preferred Masters, and four Announce Intervals for
all other masters. all other masters.
Unicast Discovery and Unicast Message Negotiation options SHALL NOT The logMessageInterval carried in the unicast Delay Response
be utilized. message MAY be set to correspond to the master ports preferred
message period, rather than 7F, which indicates message periods
are to be negotiated. Note that negotiated message periods are not
allowed, see section 13.
8. Requirements for Master Clocks 8. Requirements for Master Clocks
Master clocks SHALL obey the standard Best Master Clock Algorithm Master Clocks SHALL obey the standard Best Master Clock Algorithm
from [IEEE1588]. PTP systems using this profile MAY support from [IEEE1588]. PTP systems using this profile MAY support
multiple simultaneous Grandmasters if each active Grandmaster is multiple simultaneous Grandmasters if each active Grandmaster is
operating in a different PTP domain. operating in a different PTP domain.
A port of a clock SHALL NOT be in the master state unless the A port of a clock SHALL NOT be in the master state unless the
clock has a current value for the number of UTC leap clock has a current value for the number of UTC leap
seconds. seconds.
If a unicast negotiation signaling message is received it SHALL If a unicast negotiation signaling message is received it SHALL
be ignored. be ignored.
skipping to change at page 9, line 8 skipping to change at page 9, line 8
continue to recognize a Best Master for the duration of the continue to recognize a Best Master for the duration of the
Announce Time Out Interval. Slaves MAY use an Acceptable Master Announce Time Out Interval. Slaves MAY use an Acceptable Master
Table. If a Master is not an Acceptable Master, then the Slave Table. If a Master is not an Acceptable Master, then the Slave
MUST NOT synchronize to it. Note that IEEE 1588-2008 requires MUST NOT synchronize to it. Note that IEEE 1588-2008 requires
slave clocks to support both two-step or one-step Master clocks. slave clocks to support both two-step or one-step Master clocks.
See [IEEE1588], subClause 11.2. See [IEEE1588], subClause 11.2.
Since Announce messages are sent as multicast messages slaves can Since Announce messages are sent as multicast messages slaves can
obtain the IP addresses of a master from the Announce messages. obtain the IP addresses of a master from the Announce messages.
Note that the IP source addresses of Sync and Follow-up messages Note that the IP source addresses of Sync and Follow-up messages
may have been replaced by the source addresses of a transparent may have been replaced by the source addresses of a Transparent
clock, so, slaves MUST send Delay Request messages to the IP Clock, so, slaves MUST send Delay Request messages to the IP
address in the Announce message. Sync and Follow-up messages can address in the Announce message. Sync and Follow-up messages can
be correlated with the Announce message using the clock ID, which be correlated with the Announce message using the clock ID, which
is never altered by Transparent clocks in this profile. is never altered by Transparent Clocks in this profile.
10. Requirements for Transparent Clocks 10. Requirements for Transparent Clocks
Transparent clocks SHALL NOT change the transmission mode of an Transparent Clocks SHALL NOT change the transmission mode of an
Enterprise Profile PTP message. For example, a Transparent clock Enterprise Profile PTP message. For example, a Transparent Clock
SHALL NOT change a unicast message to a multicast message. SHALL NOT change a unicast message to a multicast message.
Transparent Clocks SHOULD support multiple domains. Transparent Transparent Clocks SHOULD support multiple domains. Transparent
Clocks which syntonize to the master clock will need to maintain Clocks which syntonize to the master clock will need to maintain
separate clock rate offsets for each of the supported domains. separate clock rate offsets for each of the supported domains.
11. Requirements for Boundary Clocks 11. Requirements for Boundary Clocks
Boundary Clocks SHOULD support multiple simultaneous PTP domains. Boundary Clocks SHOULD support multiple simultaneous PTP domains.
This will require them to maintain servo loops for each of the This will require them to maintain servo loops for each of the
domains supported, at least in software. Boundary clocks MUST NOT domains supported, at least in software. Boundary Clocks MUST NOT
combine timing information from different domains. combine timing information from different domains.
12. Management and Signaling Messages 12. Management and Signaling Messages
PTP Management messages MAY be used. Management PTP Management messages MAY be used. Management
messages intended for a specific clock, i.e. the [IEEE1588] defined messages intended for a specific clock, i.e. the [IEEE1588] defined
attribute targetPortIdentity.clockIdentity is not set to All 1's, attribute targetPortIdentity.clockIdentity is not set to All 1's,
MUST be sent as a unicast message. Similarly, if any signaling MUST be sent as a unicast message. Similarly, if any signaling
messages are used they MUST also be sent as unicast messages messages are used they MUST also be sent as unicast messages
whenever the message is intended for a specific clock. whenever the message is intended for a specific clock.
13. Forbidden PTP Options 13. Forbidden PTP Options
Clocks operating in the Enterprise Profile SHALL NOT use peer to Clocks operating in the Enterprise Profile SHALL NOT use peer to
peer timing for delay measurement. Grandmaster Clusters are NOT peer timing for delay measurement. Grandmaster Clusters are NOT
ALLOWED. The Alternate Master option is also NOT ALLOWED. Clocks ALLOWED. The Alternate Master option is also NOT ALLOWED. Clocks
operating in the Enterprise Profile SHALL NOT use Alternate operating in the Enterprise Profile SHALL NOT use Alternate
Timescales. Timescales. Unicast discovery and unicast negotiation SHALL NOT be
used.
14. Interoperation with IEEE 1588 Default Profile 14. Interoperation with IEEE 1588 Default Profile
Clocks operating in the Enterprise Profile will interoperate with Clocks operating in the Enterprise Profile will interoperate with
clocks operating in the Default Profile described in [IEEE1588] clocks operating in the Default Profile described in [IEEE1588]
Annex J.3. This variant of the Default Profile uses the End to End Annex J.3. This variant of the Default Profile uses the End to End
Delay Measurement Mechanism. In addition, the Default Profile Delay Measurement Mechanism. In addition, the Default Profile
would have to operates over IPv4 or IPv6 networks, and use would have to operate over IPv4 or IPv6 networks, and use
management messages in unicast when those messages are directed at management messages in unicast when those messages are directed at
a specific clock. If either of these requirements are not met than a specific clock. If either of these requirements are not met than
Enterprise Profile clocks will not interoperate with Annex J.3 Enterprise Profile clocks will not interoperate with Annex J.3
Default Profile Clocks. The Enterprise Profile will not Default Profile Clocks. The Enterprise Profile will not
interoperate with the Annex J.4 variant of the Default Profile interoperate with the Annex J.4 variant of the Default Profile
which requires use of the Peer to Peer Delay Measurement Mechanism. which requires use of the Peer to Peer Delay Measurement Mechanism.
Enterprise Profile Clocks will interoperate with clocks operating Enterprise Profile Clocks will interoperate with clocks operating
in other profiles if the clocks in the other profiles obey the in other profiles if the clocks in the other profiles obey the
rules of the Enterprise Profile. These rules MUST NOT be changed rules of the Enterprise Profile. These rules MUST NOT be changed
skipping to change at page 10, line 50 skipping to change at page 10, line 50
Protocols used to transfer time, such as PTP and NTP can be Protocols used to transfer time, such as PTP and NTP can be
important to security mechanisms which use time windows for keys important to security mechanisms which use time windows for keys
and authorization. Passing time through the networks poses a and authorization. Passing time through the networks poses a
security risk since time can potentially be manipulated. security risk since time can potentially be manipulated.
The use of multiple simultaneous masters, using multiple PTP The use of multiple simultaneous masters, using multiple PTP
domains can mitigate problems from rogue masters and domains can mitigate problems from rogue masters and
man-in-the-middle attacks. See sections 9 and 10. Additional man-in-the-middle attacks. See sections 9 and 10. Additional
security mechanisms are outside the scope of this document. security mechanisms are outside the scope of this document.
PTP native management messages SHOULD not be used, due to the lack
of a security mechanism for this option. Secure management can be
obtained using standard management mechanisms which include
security, for example NETCONF [NETCONF].
General security considerations of time protocols are discussed in
[RFC7384].
17. IANA Considerations 17. IANA Considerations
There are no IANA requirements in this specification. There are no IANA requirements in this specification.
18. References 18. References
18.1. Normative References 18.1. Normative References
[IEEE1588] IEEE std. 1588-2008, "IEEE Standard for a [IEEE1588] IEEE std. 1588-2008, "IEEE Standard for a
Precision Clock Synchronization for Networked Precision Clock Synchronization for Networked
skipping to change at page 11, line 32 skipping to change at page 11, line 32
[RFC2460] Deering, S., Hinden, R., "Internet Protocol, [RFC2460] Deering, S., Hinden, R., "Internet Protocol,
Version 6 (IPv6) Specification," RFC 2460, Version 6 (IPv6) Specification," RFC 2460,
December, 1998. December, 1998.
18.2. Informative References 18.2. Informative References
[G8271] ITU-T G.8271/Y.1366, "Time and Phase [G8271] ITU-T G.8271/Y.1366, "Time and Phase
Synchronization Aspects of Packet Networks" Synchronization Aspects of Packet Networks"
February, 2012. February, 2012.
[ISPCS] Arnold, D., et. al. "Plugfest Report,"
International Symposium on Precision Clock
Synchronization for Measurement, Control and
Communications, Monterey, CA, October, 2017.
[NETCONF] Ens, R., et. al., "Network Configuration Protocol
(NETCONF)," RFC 6241, June, 2011.
[NTP] Mills, D., Martin, J., Burbank, J., Kasch, W., [NTP] Mills, D., Martin, J., Burbank, J., Kasch, W.,
"Network Time Protocol Version 4: Protocol and "Network Time Protocol Version 4: Protocol and
Algorithms Specification," RFC 5905, June 2010. Algorithms Specification," RFC 5905, June 2010.
[RFC7384] Mizrahi, T., "Security Requirements of Time
Protocols in Packet Switched Networks," RFC 7384,
October, 2014.
19. Acknowledgments 19. Acknowledgments
The authors would like to thank members of IETF for reviewing and The authors would like to thank members of IETF for reviewing and
providing feedback on this draft. providing feedback on this draft.
This document was initially prepared using This document was initially prepared using
2-Word-v2.0.template.dot. 2-Word-v2.0.template.dot.
20. Authors' Addresses 20. Authors' Addresses
 End of changes. 32 change blocks. 
34 lines changed or deleted 61 lines changed or added

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