The tictoc WG chairs have determined there is consensus to forward the document "Security Requirements of Time Protocols in Packet Switched Networks" (draft-ietf-tictoc-security-requirements-05.txt) to the IESG for approval. Regards, Karen and Yaakov
This message initiates a two week TICTOC Working Group Last Call on advancing: Title : Precision Time Protocol Version 2 (PTPv2) Management Information Base Author(s) : Vinay Shankarkumar, Laurent Montini, Tim Frost, Greg Dowd Filename : draft-ietf-tictoc-ptp-mib-05.txt Pages : 77 Date : 2013-02-25 http://datatracker.ietf.org/doc/draft-ietf-tictoc-ptp-mib/?include_text=1 as a Standards Track RFC. Substantive comments and statements of support for advancing this document should be directed to the mailing list. Editorial suggestions can be sent directly to the authors. This last call will end on 31 May 2013.
We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of(Continue reading)
Hi,
Following the comments received on the WGLC I updated the draft – mostly minor editorial updates.
The most notable changes compared to draft 04:
1. I added some text in the introduction about the target audience of the document.
2. I changed “time synchronization protocols” to “time protocols”, as this seems to be the common grounds of NTP and PTP, both of which end with a TP (Time Protocol). Seems like a fair compromise between Yaakov’s suggestion and Kevin’s (http://www.ietf.org/mail-archive/web/tictoc/current/msg01382.html).
The current draft can be found in:
http://tools.ietf.org/html/draft-ietf-tictoc-security-requirements-05
Thanks,
Tal.
_______________________________________________ TICTOC mailing list TICTOC <at> ietf.org https://www.ietf.org/mailman/listinfo/tictoc
The following is my review of the 04 version of this document.
(Actually I originally mistakenly reviewed 03 and only afterward went over this version.
I was pleased that almost all of my comments were obsoleted by 04!)
General I personally prefer “timing distribution protocols” to “time synchronization protocols”,
as I think the protocol distributes the timing (time and/or frequency)
while the specific sync algorithm performs the synchronization.
General nit : you have a lot of strange spaces near anchors that are probably due to some automatic mechanism
For example “Section 5 .” -> “Section 5.” (twice) “(Section 3.2.2 )” -> “(Section 3.2.2)”, etc. etc. etc.
(I guess this is a Microsoft Word artifact)
Section 2.1
requirements that every security mechanism should comply to -> requirements with which every security mechanism should comply
Section 2.4 I believe that “clock” means master clock OR intermediate clock OR slave clock.
Why only PTP intermediate clock. And why is the definition of clock separated from the other definitions.
I realize that it is more fundamental, but it makes it harder to find.
3.2.2 an attacker -> an injector
3.2.5 receiving the some or all -> receiving some or all
3.2.6 perhaps it is worthwhile calling out that the added delay may be constant, jittered, or slowly wandering (3 different attacks)
3.2.7 fake protocol packet -> fake protocol packets
3.2.8 shouldn’t this section be before 3.2.7 ? (as it is more general)
3.2.9 using -> by sending it 3 .2.4 -> 3.2.4
3.2.10 e.g. -> e.g.,
An attacker can spoof the GPS -> an attacker can transmit a signal similar to one from a GPS satellite
3.2.11 <NEW> an additional attack is jamming the reception of GPS signals !!!!
3.3 are the severity -> are the impact
provides an intuition -> provides an intuitive measure of
Table 1
I think we need a “+” in interception and removal DoS
I think we don’t need “+”s in Master Time source spoofing MITM (both internal and external)
Section 4 about the reason -> detailing the reason
I liked the version 3 text for “security requirements” (other than 2 typos) more than the present text.
Here you quote 2119, which is actually not directly relevant for requirements documents.
Suggestion – point to your own section 2.1.
Section 5.1 I have a problem here. You say that the security mechanism MUST provide a means for each clock to authenticate
the sender of protocol packets. But afterwards you say that a master MAY authenticate its slaves.
But slaves send protocol packets to the master!
5.1.2 I don’t believe that “inductive” is correct here. I suggest to continue using the term “recursive”, or to use “iteration”.
5.1.3 reduces -> induces (quite the opposite !)
It could be argued that the authentication of slaves could …
I suggest
The authentication of slaves might put a higher computational load on
the master than serving an unauthorized clock, and hence this
requirement is a SHOULD. <and note “than” not “then”>
5.1.4 suggested title Authentication and Authorization of PTP TCs by the Master
5.1.5 Agreed. So why not add this attack to the list above, rather than apologizing here ?
5.2 Data -> Protocol Packet a high impact -> high impact
5.2.1.1 please add reference to the appropriate 1588 section describing correctionField
Also, induction -> tracing back or something similar
5.2.1.2 validate -> directly validate
5.5.1 periodically -> frequently (as far as I see there is no real requirement for periodic updates,
Just for updates before wrap-around that may provide crackers with additional information)
5.5.2 Security Associations - Actually I have a problem with the reasoning here.
Isn’t the purpose of a non-ephemeral association to save time in generating symmetric keys ?
5.5.3 Unicast and Multicast timing protocols (?)
especially in -> especially for
strictly (I believe can be removed)
5.6 does not significantly degrade the quality, or does not degrade the quality to a noticeable degree …
5.7 are rather esoteric -> are, for now, rather esoteric
does not prevent -> does not completely prevent
5.8 Packet Interception and Removal and Packet Delay attacks
Note: one of my consistent comments on 03 was that the mechanisms were not consistently mapped to the threats.
This version is much better, but still not complete. Could you please directly map each mechanism to the threat it prevents/ameliorates ?
5.9 possibly add “or is too expensive to implement”
5.9.1 A protocol packet received from -> In this mode any protocol packet received from
You can remove “a bit”
explicitly defines -> refers to
A master in the hybrid mode SHOULD be - but there is a general requirement for ALL masters to be secure. No ?
and not -> which is not
Section 6
Authentication of sender – MUST : as I already commented above, this can not be true in general since it would
mean that all clocks must support security mechanisms.
Similarly for Integrity protection.
7.1 often require protocol packets to be -> often require that protocol packets be
with the time of transmission -> based on the time of transmission and/or reception
During transmission the security protocol must be applied after ->
During transmission encryption and authentication MUST be applied after
What happened to the second sentence from the 03 version ?
6.3 RFC 5905 uses the term “secondary server” . You can save a lot of writing about stratum 1 and 2 !
In the paragraph A common rule, I think the first must should be a MUST, while the second is correctly a “must”.
7.4 packets are sent over -> packets are necessarily transported over (it is not the sending that is important here, it is the transport)
Section 8 The key distribution -> Key distribution (can add that it is an “implementation issue”)
I am not sure that I understand the relationship between 7.5.1 and 7.5.2.
I believe that the “early time” in 7.5.2 is a case of the “mutual dependence” of 7.5.1.
Y(J)S
_______________________________________________ TICTOC mailing list TICTOC <at> ietf.org https://www.ietf.org/mailman/listinfo/tictoc
Dear all, Tal,
_______________________________________________ TICTOC mailing list TICTOC <at> ietf.org https://www.ietf.org/mailman/listinfo/tictoc
_______________________________________________ TICTOC mailing list TICTOC <at> ietf.org https://www.ietf.org/mailman/listinfo/tictoc
_______________________________________________ TICTOC mailing list TICTOC <at> ietf.org https://www.ietf.org/mailman/listinfo/tictoc
Hi Shahram, Manav,
Thanks for tolerating my exhausting comments. :)
I believe in draft 04 you addressed most of the major issues I raised.
I am quoting below some of my comments about draft 03 that I believe are still not addressed in draft 04.
I am sure most of them are just a slip, but if you disagree with some of them I will appreciate if you can respond.
Thanks,
Tal.
Quoting comments about draft 03 that were not fully addressed (quoting from http://www.ietf.org/mail-archive/web/tictoc/current/msg01326.html):
1. The IEEE 1588 uses the term “port”. Each PTP “port” has a state, which can be master, slave, or passive. The state is determined according to the BMC algorithm. The BMC algorithm determines whether a port is a slave or a master based on the announce messages received through this port.
In the current draft, I assume a “port” is in fact defined by a specific timing LSP (corresponding to a specific peer BC/OC), and the set of Announce messages received through it. This implies that Announce messages must either be sent through the timing LSP, or somehow be traceable to a specific timing LSP. This must be well defined in the document to allow consistent implementations.
2. Section 19 currently suggests a few possible solutions. It is important that this document will define a single solution.
3. Some terms in the document are used inconsistently, for example, the terms “time-stamping” and “timestamping” are used intermittently.
4. There is some inconsistency about capitalization, for example, the word “Timing” is sometimes capitalized and sometimes not. Since you are using the term “Timing messages” quite often, I would suggest to add it to the terminology section, and to be consistent about its capitalization, whereas if the word “timing” is used on its own lowercase letters would be more appropriate.
5. “…NTP messages for clock and time synchronization. The PTP…” --> “...NTP messages for clock and time synchronization. The NTP…”
6. It appears that some of the sections are only applicable to PTP (e.g., Section 4, Section 18, Section 19). That is reasonable, but it should be pointed out explicitly that these sections apply only to PTP.
Tal.
_______________________________________________ TICTOC mailing list TICTOC <at> ietf.org https://www.ietf.org/mailman/listinfo/tictoc
Here is a first cut at a draft of a PTP profile foe enterprise networks. Any feedback/suggestions would be much appreciated.
I enclose both a MS Word version and a pure text version, since I used the Joe Touch’s template.
//Doug
TICTOC Working Group D. Arnold
Internet Draft Symmetricom
Intended status: Stadards Track H. Gerstung
Expires: October 25, 2013 Meinberg
April 25, 2013
Enterprise Profile for the Precise Time Protocol
With Mixed Multicast and Unicast Messages
draft-ietf-tictoc-PTPenterpriseprofile-02.txt
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be 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 English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on October 25, 2013.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
Arnold and Gerstung Expires October 25, 2013 [Page 1]
Internet-Draft Enterprise Profile for PTP February 2013
This document is subject to BCP 78 and the IETF Trusts 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.
Abstract
This document describes a profile for the use of the Precise Time
Protocol in an IPV4 or IPv6 Enterprise information system environment.
The profile used the End to End Delay Measurement Mechanism, allows
both multicast and unicast Delay Request and Delay Response Messages.
Table of Contents
1. Introduction...................................................2
2. Conventions used in this document..............................4
3. Technical Terms................................................4
4. Problem Statement..............................................5
5. Network Technology.............................................6
6. Time Transfer and Delay Measurement............................6
6.1. Unicast Mode..............................................6
6.2. Multicast Mode............................................7
6.3. Hybrid Mode...............................................7
7. Default Message Rates..........................................7
8. Timing Domains.................................................7
9. Requirements for Master Clocks.................................7
10. Requirements for Slave Clocks.................................8
11. Management Messages...........................................8
12. Forbidden PTP Options.........................................8
13. Interoperation with Other PTP Profiles........................9
14. Security Considerations.......................................9
15. IANA Considerations...........................................9
16. References...................................................10
16.1. Normative References....................................10
16.2. Informative References..................................10
17. Acknowledgments..............................................10
1. Introduction
The Precision Time Protocol ("PTP"), standardized in IEEE 1588, has
been designed in its first version (IEEE 1588-2002) with the goal to
Arnold and Gerstung Expires October 25, 2013 [Page 2]
Internet-Draft Enterprise Profile for PTP February 2013
minimize configuration on the participating nodes. Network
communication was based solely on Multicast messages, which unlike
NTP did not require that a receiving node ("slave clock" in IEEE
1588) needs to know the identity of the time sources in the network
(the Master Clocks).
The so-called "Best Master Clock Algorithm" ([IEEE1588] Clause 9.3),
a mechanism that all participating PTP nodes must follow, set up
strict rules for all members of a PTP domain to determine which node
shall be the active sending time source (Grandmaster Clock).
Although the multicast communication model has advantages in smaller
networks, it complicated the application of PTP in larger networks,
for example in environments like IP based telecommunication networks
or financial data centers. It is considered inefficient that, even
if the content of a message applies only to one receiver, it is
forwarded by the underlying network (IP) to all nodes, requiring
them to spend network bandwidth and other resources like CPU cycles
to drop the message.
The second revision of the standard (IEEE 1588-2008) is the current
version (also known as PTPv2) and introduced the possibility to use
unicast communication between the PTP nodes in order to overcome the
limitation of using multicast messages for the bi-directional
information exchange between PTP nodes. The unicast approach avoided
that, in PTP domains with a lot of nodes, devices had to throw away
up to 99% of the received multicast messages because they carried
information for some other node. PTPv2 also introduced so-called
"PTP profiles" ([IEEE1588] Clause 19.3). This construct allows
organizations to specify selections of attribute values and optional
features, simplifying the configuration of PTP nodes for a specific
application. Instead of having to go through all possible parameters
and configuration options and individually set them up, selecting a
profile on a PTP node will set all the parameters that are specified
in the profile to a defined value. If a PTP profile definition
allows multiple values for a parameter, selection of the profile
will set the profile-specific default value for this parameter.
Parameters not allowing multiple values are set to the value defined
in the PTP profile. A number of PTP features and functions are
optional and a profile should also define which optional features of
PTP are required, permitted or prohibited. It is possible to extend
the PTP standard with a PTP profile by using the TLV mechanism of
PTP (see [IEEE1588] Clause 13.4), defining an optional Best Master
Clock Algorithm and a few other ways. PTP has its own management
protocol (defined in [IEEE1588] Clause 15.2) but allows a PTP
profile specify an alternative management mechanism, for example
SNMP.
Arnold and Gerstung Expires October 25, 2013 [Page 3]
Internet-Draft Enterprise Profile for PTP February 2013
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying RFC-2119 significance.
3. Technical Terms
Acceptable Master List: A PTP Slave Clock may maintain a list of
masters which it is willing to synchronize to.
Alternate Master: A PTP Master Clock, which is not the Best Master,
may act as a master with the Alternate Master flag set on the
messages it sends.
Best Master: The winner of Best Master Clock Algorithm Competition.
Best Master Clock Algorithm: A method for determining which of
several PTP Master
Clocks have priority to become the acting Grandmaster, based on the
properties each Master Capable Clock sends in its Announce Message.
Boundary Clock: A device with more than one PTP port. Generally
boundary clocks will have one port in slave state to receive timing
and then other ports in master state to re-distribute the timing.
End to End Delay Measurement Mechanism: A network delay measurement
mechanism in PTP facilitated by an exchange of messages between a
Master Clock and Slave Clock.
Grandmaster: the primary master clock within a domain of a PTP
system
IEEE 1588: The timing and synchronization standard which defines
PTP.
Master Clock: The source of 1588 timing to a set of slave clocks.
Ordinary Clocks: PTP Clocks capable of acting as either a master or
slave.
Arnold and Gerstung Expires October 25, 2013 [Page 4]
Internet-Draft Enterprise Profile for PTP February 2013
Peer to Peer Delay Measurement Mechanism: A network delay
measurement mechanism in PTP facilitated by an exchange of messages
between adjacent devices in a network.
Preferred Master: A device intended to act primarily as the
Grandmaster of a PTP system, or as a back up to a Grandmaster.
PTP: The timing and synchronization protocol define by IEEE 1588.
PTPv2: Refers specifically to the second version of PTP defined by
IEEE 1588-2008.
Rogue Master: A PTP clock operating as the Grandmaster, even though
it is not the best master according to the Best Master Clock
Algorithm, and does not have the alternate master flag set.
Slave Clock: A receiver of PTP timing from a master clock.
Slave Only Clock: A device which can only act as a slave in a PTP
network.
TLV: Type Length Value, a mechanism for extending messages in
networked communications.
Transparent Clock. A device that measures the time taken for a PTP
event message to transit the device and then updates the message
with a correction for this transit time.
Unicast Discovery: A mechanism in PTP for Slave Clocks to negotiate
unicast Sync, announce and Delay Request Message Rates from a Master
Clock.
4. Problem Statement
This document describes a version of PTP intended to work in large
enterprise networks. Such networks are deployed, for example in
financial corporations. It is becoming increasingly common in such
networks to perform distributed time tagged measurements, such as
one-way packet latencies and cumulative delays on software systems
spread across multiple computers. Furthermore there is often a
desire to check the age of information time tagged by a different
machine. To perform these measurements it is necessary to deliver a
common precise time to multiple devices on a network.
The accuracy currently required can be as tight as 1 µs. Such
accuracy cannot usually be achieved with a traditional time transfer
such as NTP, without adding non-standard customizations such as
Arnold and Gerstung Expires October 25, 2013 [Page 5]
Internet-Draft Enterprise Profile for PTP February 2013
hardware time stamping, fast message rates, non-linear servo loops,
and on path support. These features are currently part of PTP, or
are allowed by it. Because PTP has a complex range of features and
options it is necessary to create a profile for enterprise networks
to achieve interoperability between equipment manufactured by
different vendors.
Although enterprise networks can be large, it is becoming
increasingly common to deploy multicast protocols, even across
multiple subnets. For this reason it is desired to make use of
multicast whenever the information going to many destinations is the
same. It is also advantageous to send information which is unique
to one device as a unicast message. The latter can be essential as
the number of PTP slaves becomes hundreds or thousands.
PTP devices operating in these networks need to be robust. This
includes the ability to ignore PTP messages which can be identified
as improper, and to have redundant sources of time.
5. Network Technology
This PTP profile SHALL operate only in networks characterized by UDP
[RFC768] over either IPv4 [RFC791] or IPv6 [RFC2460]. If a network
contains both IPv4 and IPv6, then they SHALL be treated as separate
PTP systems. Devices MAY participate in both an IPv4 system and an
IPv6 system. The PTP system MAY include switches and routers.
These devices MAY be transparent clocks, boundary clocks, or
neither, in any combination. PTP Clocks MAY be Preferred Masters,
Ordinary Clocks, Boundary Clocks or Slave Only Clocks.
6. Time Transfer and Delay Measurement
Master clocks and Transparent clocks MAY be either one-step clocks
or two-step clocks. The End to End Delay Measurement Method MUST be
used.
6.1. Unicast Mode
All Sync messages MUST be sent as multicast messages to the PTP
event message multicast address. Two step clocks SHALL send Follow-
up messages as PTP event multicast messages. All Delay Request
Messages and Delay Response Messages MUST be sent as unicast
messages.
Arnold and Gerstung Expires October 25, 2013 [Page 6]
Internet-Draft Enterprise Profile for PTP February 2013
6.2. Multicast Mode
All Sync messages MUST be sent as multicast messages to the PTP
event message multicast address. Two step clocks SHALL send Follow-
up messages as PTP event multicast messages. All Delay Request
Messages and Delay Response Messages MUST be sent as multicast
messages.
6.3. Hybrid Mode
All Sync messages MUST be sent as multicast messages to the PTP
event message multicast address. Two step clocks SHALL send Follow-
up messages as PTP event multicast messages. Delay Request Messages
May be sent as either multicast or unicast messages. Master clocks
SHALL respond to multicast Delay Request Messages with multicast
Delay Response Messages. Master clocks SHALL respond to unicast
Delay Request Messages with unicast Delay Response Messages. The
default mode for Enterprise Profile PTP Master Clocks is Hybrid
Mode.
7. Default Message Rates
The Sync, Announce and Delay Request default message rates SHALL
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
seconds, and not more than 128 messages per second. The Announce
message rate SHALL NOT be changed from the default value. The
Announce Time Out Interval SHALL be three Announce Intervals for
Preferred Masters, and four Announce Intervals for all other
masters.
8. Timing Domains
All Master Clocks in the Enterprise Profile SHALL operate with the
PTP timing domain set in the range 0-3 when acting in either the
Hybrid or Multicast Mode. The default timing domain for these modes
is Domain 0. All Master Clocks in the Enterprise Profile SHALL
operate with the PTP timing domain set in the range 40-60 when
acting in the Unicast Mode. The default timing domain for this mode
is Domain 40.
9. Requirements for Master Clocks
Master clocks SHALL obey the standard Best Master Clock Algorithm
from [IEEE1588]. Clocks which are master capable MAY act as
Alternate masters according to [IEEE1588]. Preferred Master Clocks
SHOULD operate as Alternate Masters when they are not the Best
Arnold and Gerstung Expires October 25, 2013 [Page 7]
Internet-Draft Enterprise Profile for PTP February 2013
Master. The Announce Messages SHALL include a TLV which indicates
that the clock is operating in the Enterprise Profile. The TLV
shall have the following structure:
TLV Type (Enumeration16): ORGANIZATION_EXTENSION value = 0003 hex
Length Field (UInteger16): value = 2. The number of octets in the
Data Field
Organization Id (3 Octets): The Organization ID value for the IETF
assigned by IEEE = TBD
Organization SubType (Enumeration24) value = 000001hex (Enterprise
PTP Profile version 1)
Data Field, Delay Request/Response Mode (Enumeration16):
Value 00hex = Multicast Mode
Value 01hex = Unicast Mode
Value 02hex = hybrid mode
Values 03-FFhex = reserved for future use.
10. Requirements for Slave Clocks
Slave clocks MUST be able to operate properly in a network which
contains Alternate Masters. Slaves SHOULD make use of information
from the Alternate Masters in their clock control subsystems.
Slave Clocks MUST be able to operate properly in the presence of a
Rogue Master. Slaves SHOULD NOT Synchronize to a Rogue Master.
Slaves MAY use an Acceptable Master List. If the Best Master is not
an Acceptable Master, but an Alternate Master is an Acceptable
Master, then the Slave SHOULD synchronize to the acceptable
Alternate Master.
11. Management Messages
PTP Management messages MAY be used. If PTP management messages are
used, they MUST be sent as unicast messages.
12. Forbidden PTP Options
Clocks operating in the Enterprise Profile SHALL NOT use peer to
peer timing for delay measurement. Clocks operating in the
Enterprise Profile SHALL NOT use Unicast Discovery to negotiate
Arnold and Gerstung Expires October 25, 2013 [Page 8]
Internet-Draft Enterprise Profile for PTP February 2013
message rates. Grandmaster Clusters are NOT ALLOWED. Clocks
operating in the Enterprise Profile SHALL NOT use Alternative Time
Scales.
13. Interoperation with Other PTP Profiles
Clocks operating in the Enterprise profile will not interoperate
with clocks operating in the Power Profile [C37.238], because the
Enterprise Profile requires the End to End Delay Measurement
Mechanism and the Power Profile requires the Peer to Peer Delay
Measurement Mechanism.
Clocks operating in the Enterprise profile will not interoperate
with clocks operating in the Telecom Profile for Frequency
Synchronization[G8265.1], because the Enterprise Profile forbids
Unicast Discovery with message negotiation. This is the default
mode of operation for the Telecom Profile for Frequency
Synchronization.
Clocks operating in the Enterprise profile will interoperate with
clocks operating in the default profile if the default profile
clocks operate on IPv4 or IPv6 networks, use the End to End Delay
Measurement Mechanism, and use management messages in unicast only.
If any of these requirements are not met than Enterprise Profile
clocks will not interoperate with Default Profile Clocks. The
Default Profile is described in Annex J of [IEEE1588].
Enterprise Profile Clocks will interoperate with clocks operating in
other profiles if the clocks in the other profiles obey the rules of
the Enterprise Profile. These rules MUST NOT be changed to achieve
interoperability with other profiles.
14. Security Considerations
Protocols used to transfer time, such as PTP and NTP can be
important to security mechanisms which use time windows for keys and
authorization. Passing time through the networks poses a security
risk since time can potentially be manipulated.
Specific security mechanisms are outside the scope of this document.
15. IANA Considerations
There are no IANA requirements in this specification.
Arnold and Gerstung Expires October 25, 2013 [Page 9]
Internet-Draft Enterprise Profile for PTP February 2013
16. References
16.1. Normative References
[IEEE1588] IEEE std. 1588-2008, IEEE Standard for a Precision
Clock Synchronization for Networked Measurement and
Control Systems. July, 2008. [RFC2234] Crocker, D.
and Overell, P.(Editors), "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, Internet Mail
Consortium and Demon Internet Ltd., November 1997.
[RFC768] Postel, J., User Datagram Protocol, RFC 768, August,
1980.
[RFC791] Internet Protocol DARPA Internet Program Protocol
Specification, RFC 791, September, 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S., Hinden, R., Internet Protocol, Version 6
(IPv6)Specification, RFC 2460, December, 1998.
16.2. Informative References
[C37.238] IEEE std. C37.238-2011, IEEE Standard Profile for Use
of IEEE 1588 Precision Time Protocol in Power System
Applications, July 2011.
[G8265.1] ITU-T G.8265.1/Y.1365.1, Precision time protocol
telecom profile for frequency synchronization, October
2011.
17. Acknowledgments
The authors would like to thank members of IETF for reviewing and
providing feedback on this draft.
This document was prepared using 2-Word-v2.0.template.dot.
Arnold and Gerstung Expires October 25, 2013 [Page 10]
Internet-Draft Enterprise Profile for PTP February 2013
Authors Addresses
Doug Arnold
Symmetricom, Inc.
3750 Westwind Blvd
Santa Rosa, CA 95403
USA
Email: darnold <at> symmetricom.com
Heiko Gerstung
Meinberg Funkuhren GmbH & Co. KG
Lange Wand 9
D-31812 Bad Pyrmont
Germany
Email: Heiko.gerstung <at> meinberg.de
Arnold and Gerstung Expires October 25, 2013 [Page 11]
_______________________________________________ TICTOC mailing list TICTOC <at> ietf.org https://www.ietf.org/mailman/listinfo/tictoc
This message initiates a two week TICTOC Working Group Last Call on advancing: Title : Security Requirements of Time Synchronization Protocols in Packet Switched Networks Author(s) : Tal Mizrahi Filename : draft-ietf-tictoc-security-requirements-04.txt Pages : 32 Date : 2013-02-07 http://datatracker.ietf.org/doc/draft-ietf-tictoc-security-requirements/ as an Informational RFC. Substantive comments and statements of support for advancing this document should be directed to the mailing list. Editorial suggestions can be sent directly to the authors. This last call will end on 12 March 2013. I realize this WGLC comes right before the IETF; however, this document has been around for a long time, and it is my hope that this can be done expeditiously. Regards, Karen Abstract: As time synchronization protocols are becoming increasingly common and widely deployed, concern about their exposure to various security threats is increasing. This document defines a set of security requirements for time synchronization protocols, focusing on the Precision Time Protocol (PTP) and the Network Time Protocol (NTP). This document also discusses the security impacts of time synchronization protocol practices, the time synchronization performance implications of external security practices, the dependencies between other security services and time synchronization.
RSS Feed9 | |
|---|---|
5 | |
18 | |
27 | |
5 | |
3 | |
11 | |
17 | |
4 | |
23 | |
20 | |
6 | |
3 | |
6 | |
54 | |
2 | |
52 | |
56 | |
44 | |
3 | |
20 | |
13 | |
12 | |
5 | |
37 | |
27 | |
34 | |
68 | |
9 | |
7 | |
3 | |
24 | |
26 | |
101 | |
6 | |
3 | |
1 | |
12 | |
12 | |
3 | |
3 | |
7 | |
16 | |
2 | |
16 | |
14 | |
13 | |
2 | |
1 | |
8 | |
16 | |
17 | |
18 | |
1 |
