Thanks for putting this draft together. I found it to be well written, well
organized and very informative. I have some comments.
General:
Use MITM acronym defined in 2.2 instead of spelling it out many times
By sections:
1 - Add playback to the list of attacks when synchronization is compromised.
1 - s/The IEEE 1588 includes/IEEE 1588 includes/
1 - Provide definition or example for "packet timing deployments"
2.1 - s/"protocol packets" is refers/"protocol packets" refers/
3.1 - s/documents/document/
3.1.1 - Authentication and encryption can be used together. s/by an
encryption or an authentication mechanism./by an encryption or an
authentication mechanism or both.
3.1.2 - s/eavesdrop to protocol/eavesdrop on protocol/
3.2 - Other threats to consider:
Rogue transparent clock. A remedy is discussed in 4.1.4 but it is not
documented as a threat.
Rogue boundary clock
Unauthorized receipt
3.2.9 - s/spoof the GPS satellites/spoof GPS satellite signals/
3.3 s/Attacket/Attacker/
Table 1 - Add a couple +'s:
Replay attack can be perpetrated by an external injector
Packet delay manipulation can cause accuracy degradation
4 - Add references for IPsec and MACsec
4.1.4 - Discuss TC authentication can prevent rogue TC from degrading
accuracy. Mention that this whole section is not applicable to NTP.
4.1.5 - Repeats discussion in 4.1. These two sections should at least
acknowledge each other.
4.1.5 - s/prevent malicious master/prevent rogue master/
4.2 - s/ensures the authenticity and completeness/ensures the integrity and
completeness/
4.2.1.1 - s/Hop by Hop Integrity Protection/Hop-by-Hop Integrity Protection
4.2.1.1 - s/allows malicious TCs/allows rogue TCs/
4.2.1.1 - a/End to End Integrity Protection/End-to-End Integrity Protection/
4.3 - I guess depends on the scope of these recommendations but I don't
think is it feasible to require DoS protection. Also, you don't protect a
protocol from DoS you protect a device or a service. We SHOULD be
protecting the device and its network stack from DoS. Or the device and its
network interface MUST recover once a DoS has resolved.
4.4 - "MUST be resistant" is not a well-defined requirement
4.4 - This section is missing a Discussion sub-section
4.5.3 - This section is missing a Discussion sub-section
4.6 - "SHOULD be relatively lightweight" is not a well-defined requirement.
Suggestion: "SHOULD minimize computational load".
4.6 - "SHOULD not require excessive storage" is not a well-defined
requirement. Suggestion: "SHOULD minimize storage requirements".
4.6 - Move "as client restrictions often dictate a low processing and
memory footprint, and because the server may have extensive fan-out."
from requirements to discussion sub-section
4.7 - s/against packet delay attacks/against packet delay, manipulation and
interception and removal attacks/
4.9 - s/a gradual process/incremental deployment/
6.1 - No packets are required to be modified on reception. The requirement
is to record and associate an arrival timestamp with received packets.
Remove discussion of reception modifications. Suggested modified text:
Time synchronization protocols often require protocol packets to be
modified during transmission. Both NTP and PTP in one-
step mode require clocks to modify protocol packets with the time of
transmission.
In the presence of a security mechanism, whether encryption or
integrity protection:
o During transmission the security protocol must be applied after
integrating the timestamp into the packet.
To allow high accuracy, timestamping is typically performed as close
to the transmission time as possible. However, since the
security engine must be placed between the timestamping function and
the physical interface, it may introduce non-
deterministic latency that causes accuracy degradation. These
performance aspects have been analyzed in the literature, e.g., in
[1588IPsec] and [Tunnel].
6.2 - Two-step pertains only to transmission times. Suggested modified text:
PTP supports a two-step mode of operation, where the time of
transmission of protocol packets are
communicated without modifying the packets. As opposed to one-step mode,
two step timestamping can be performed without the requirement to
encrypt after timestamping.
6.5 - Discuss bootstrapping issue. You need a certificate to receive time.
You need time to validate a certificate.
Kevin Gross
+1-303-447-0517
Media Network Consultant
AVA Networks - www.AVAnw.com, www.X192.org
_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc
