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
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc
