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)
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
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 …
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
126.96.36.199 please add reference to the appropriate 1588 section describing correctionField
Also, induction -> tracing back or something similar
188.8.131.52 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
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.