Hi Stefano, Thanks for the very thorough review. We will be sure to address your comments in the next draft.
> 16) 4.9: I don't think both "Secure Mode" and "Hybrid Mode" should be > explored. Either the security is on or off. Nothing inbetween because that > creates the opportunity for a proverbial backdoor. Strictly as a security enthusiast I agree, but our feeling was that a hybrid mode is called for. IEEE 1588 Annex K (informative) discusses the need for a mixture of secure and nonsecure nodes. NTP allows a network with a mixture of secure and nonsecure clients. I am not sure whether we can avoid a hybrid mode. Thanks, Tal. From: Stefano Ruffini [mailto:[email protected]] Sent: Tuesday, July 10, 2012 2:22 PM To: Tal Mizrahi; [email protected] Subject: RE: Updated draft-ietf-tictoc-security-requirements-02 Dear Authors I had a look at the security draft (draft-ietf-tictoc-security-requirements-02.txt) and here are some comments/questions/proposals. In general I think the document is very good and presents very useful information. General considerations 1) In the introduction it is clarified that this draft addresses time synchronization protocols (PTP and NTP) Security requirements and in Section 4 the requirements refer to "security mechanisms" for a timing protocol. NTP and PTP are the timing protocols, whereas integrity, authentication, and confidentiality are security mechanisms that can either be introduced to those protocols or solved by using other protocols, such as IPsec. The draft mentions both, but it is sometime unclear on which some of the discussion applies. It would be clearer if a distinction between introducing new security mechanisms to NTP/PTP vs. using other security protocols is made wherever applicable (e.g. adding some introductory text in section 4). 2) A related aspect is that it could be reminded that current packet timing deployments may not involve any security protocol. Indeed in some cases it may not be strictly necessary (e.g. due to other security practices in place, and/or the architecture of the network). In general there needs to be a risk based decision when applying these security controls. It should also be considered that applying multiple security controls may introduce disturbances in the timing service. In addition, the draft provides a good overview and introduction to the subject of packet timing and security, however since it is not targeting a specifc set of applications and does not set a clear definition of what a reasonable level of security is for timing, the draft may address more than it really needs to. Benefit vs. drawback for a specific application need to be taken into account (for example, what is the impact on network timing performance for a specific application). A note addressing these considerations could be added in the Introduction of the draft . Detailed comments/questions: 3) Abstract: - Instead of "This document defines a set of requirements for security solutions for time synchronization protocols...", I think it is more correct to say: "This document defines a set of security requirements for security solutions for time synchronization protocols..." 4) Abstract Refer to "PTP and NTP", rather than "IEEE1588 and NTP " 5) In section 3.1.2 the distinction betwen MITM and Packet Injector is not fully clear : "intercept a packet" or "record a packet" look equivalent. In particular the existing description for packet injector is not fully clear. A packet injector doesn't necessarily need to "record a packet" in order to inject traffic in to the network. It is sufficient to know what protocol to use and the necessary parameters needed to launch an attack (e.g. address of the slave and master). It may be possible to argue that in order to get this information, the attack must first intercept a packet with this data. 6) 3.2.2: Could clarify that the spoofing implies generating your own packets and not relying on recorded or intercepted packets. At least that may clarify the difference with the other attacks. 7) 3.2.3: I think it's important to note that in a replay attack, the message is not altered or manipulated. 8) From the description it is not fully clear the difference between Packet Delay Manipulation (3.2.6) and "Replay Attack" (3.2.3). They look equivalent. Probably the only difference is that in case of Replay attack the recorded packet can be injected multiple times ? Some clarifcation could be added. 9) 3.3: In the case of a prolonged "interception and removal" attack, I would add DoS as an impact. This is evident in mobile networks as it will eventually mean, or may prevent the, that the mobile services from being available. On further thought, I guess one could argue that for certain mobile scenarios, all the mentioned attacks could result in the mobile service becoming unavailable. I expect that is the end goal when attacking the sync service in a mobile network. 10) 3.3, I think "Master Time source spoofing" attacks may be difficult - in many cases, impossible from outside the network. This is case dependent. I would propose to remove the " External" from the table 11) 4.2.1.2: a note could be added for the "End to Ent Integrity Protection" method, clarifying that it can add complexity because it requires multiple fields to be protected separately and using different keys, presumably. 12) 4.3: even in case of external attacks, Authentication alone is not sufficient to prevent DoS attacks, or attackes against availability. It can mitigate some risks. I think when it comes to availability, other mechanisms - possibily in conjunction with cryptographic mechanisms - are probably more reliable to address the issue. 13) 4.5.1: this section implies a fairly heavy solution; Even if the handling of the association protocol is not implemented by the clock (but is handled transparently to the sync application as in case of IPsec/MACsec), it introduces an additional overhead and complexity when managing large networks. A security association is essentially a set of shared security attributes between two network elements. How these security attributes are configured/negotiated can be either accomplished with a protocol such as IKEv2 or by other means, e.g. manual configuration or via NMS/OSS . By only mentioning "association protocol" the draft is pushing towards a specific implementation. . In conclusion , 4.5.1 should be optional. Other ways to distribute the security attributes should be considered 14) 4.7: Comment on the last sentence on MITM. Because both NTP and PTP have predictable behavior it could be possible to launch a successful attack targeting sync packets despite the fact that they are encrypted. 15) 4.8, requirement. I guess the reason for the MAY is that it may be impossible to distinguish between a delay attack from delay introduced by disturbances in the network? 16) 4.9: I don't think both "Secure Mode" and "Hybrid Mode" should be explored. Either the security is on or off. Nothing inbetween because that creates the opportunity for a proverbial backdoor. 17) 6.2. Comment on "Note that if an encryption mechanism is used, it presents a challenge to the timestamping mechanism, since time protocol packets are encrypted when traversing the physical interface, and are thus impossible to identify." This is dependent on what is encrypted. This has actually not been discussed in the draft. The above statement assumes that the entire IP packet is encrypted. But if it is only the "sensitive" information, e.g. the NTP/PTP payload, then it would be possible to identify sync packets even if they are encrypted. On the other hand, if IPsec is used, then the statement is correct. 18) Section 6.4. As discussed at last TICTOC meeting, it is not mandatory to deliver timing packets in the same IPSEC tunnel used for the traffic, even in case of Femtocell The text should be revised, for instance adding "may" in the folloiwng sentence: A typical example is the 3GPP Femtocell network [3GPP], where IPsec is used for securing traffic between a Femtocell and the Femto Gateway. In some cases, all traffic between these two nodes may be secured by IPsec, including the time synchronization protocol traffic. This use-case is thoroughly discussed in [IPsecSync]. 19) Section 6.5 refers to a requirement of being time synchronized: what is the requirent in this case ? 0.5 sec accuracy? Best Regards Stefano ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Tal Mizrahi Sent: domenica 17 giugno 2012 9.21 To: [email protected] Subject: [TICTOC] Updated draft-ietf-tictoc-security-requirements-02 Hi, The following changes have been made in this draft compared to the previous draft: 1. Following feedback from IETF 83, a threat analysis section was added. 2. Made various corrections to address comments received on the mailing list. 3. Wrote section 6, which was previously just a placeholder. http://www.ietf.org/id/draft-ietf-tictoc-security-requirements-02.txt Comments will be appreciated. Thanks, Tal.
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
