I agree with Kevin Gross that this document on security requirements is welll written, organized and informative. The background material is comprehensive, and yet very concise. It is potentially useful to the IEEE 1588 committee as well as to the IETF. I have some comments on the choices for SHALL (required), SHOULD (recommended) and MAY (allowed) amongst the various requirements.
The authentication of PTP slaves and NTP clients a aught to be allowed, but not required or recommend (MAY). There are likely many applications where authentication of slaves is undesirable or unimportant. This is especially true for the design of an Ordinary Clock, which is master capable, but is not usually in that mode. Such devices often have less processing resources than Preferred Grandmasters. It is likely also true for NTP servers when there are a large number of clients, and the policy is for servers to answer them all, to the best of their ability. Note that the draft calls for low storage and bandwidth demands for NTP servers. That could be challenging if there are thousands of clients to authenticate. I suggest demanding that Announce Messages SHALL be authenticated since these are crucial to proper functioning of the PTP Best Master Clock Algorithm in multicast mode. I second the comments of Kevin Gross on DoS security (see below). Protection against delay attacks is too important a topic only to be a MAY. I suggest that this be recommended (SHOULD). Realistically it might be that the protocol only makes this possible, and doesn't solve it. Part of the solution might be in the end device clock control software which, at least for PTP, is outside of the scope of the standard. //Doug Arnold ________________________________ From: [email protected] [[email protected]] on behalf of Kevin Gross [[email protected]] Sent: Friday, November 16, 2012 3:01 PM To: [email protected] Subject: [TICTOC] Comments on draft-ietf-tictoc-security-requirements-03 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<http://www.AVAnw.com>, www.X192.org<http://www.X192.org>
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
