Hi Dan, I understand your concern: basically the synchronization protocol can be compromised by a MITM attack even if the TCs are authenticated. However, it sounds like you are suggesting a solution, and this document attempts to focus on requirements and not solutions. Authenticating the TC prevents simple attacks that can be performed by "weak" attackers, referred to in the document as external injector attackers. It does not prevent more advanced attacks from "advanced" attackers, e.g., internal attackers, or MITM delay attacks. I find it essential to require that the security mechanism prevents the easiest-to-implement attacks, as these are the most likely ones.
I suggest to add a description to this section in the document, and clarify the point above. Tal. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Dan Grossman Sent: Thursday, August 02, 2012 9:50 AM To: [email protected] Subject: [TICTOC] TICTOC Security Requirements Tal, I wasn't able to get meeting audio, so don't know whether this was discussed. My main concern with the draft concerns transparent clocks, as in section 4.1.4. A PTP transparent clock is really just a Layer 2 or IP forwarder with a timestamping mechanism based on a syntonized timebase. Every forwarder on the master-slave path with significant queueing and other variable delays must have the transparent clock mechanism, else there will be loss of accuracy. Any forwarder can mount a MITM DOS attack on a secured clock correction field by corrupting it. To say nothing of greatly complicating the forwarding process and perhaps even adding inaccuracy. Which leads me to suggest that perhaps rather than trying to authenticate the TC and protect the clock correction field as security mechanisms in the PTP or its encapsulation might cause more problems and risks than the threats they eliminates. Maybe it would be better to think about this as a secure routing or signaling problem, and use signaling or routing to constrain the set of feasible paths to those which have a trusted, authenticated TC on each hop. This becomes a problem for RSVP or LDP for the MPLS encapsulation, and OSPF and ISIS for IP tunneling. I suspect (have not dug into it, though) that most of the mechanisms we'd need already exist. Dan On 8/2/2012 12:10 PM, [email protected] wrote: > > > Date: Thu, 2 Aug 2012 19:10:39 +0300 > From: Tal Mizrahi <[email protected]> > To: "[email protected]" <[email protected]> > Subject: [TICTOC] TICTOC Security Requirements > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="us-ascii" > > Hi, > > http://tools.ietf.org/html/draft-ietf-tictoc-security-requirements-02 > > Following this week's TICTOC meeting: > > 1. We plan to release draft 03 within a month, and proceed to WG last > call. > > 2. Therefore, I will appreciate if people can send any comments they > may have by Aug 22. > > 3. There was some discussion about the "proventication" requirement. I > would like to suggest to change the terminology in the document, since I > understand this term is not very popular. > However, I believe that the requirement for a chain of trust is still an > important and valid requirement. Please comment if you think otherwise. > > Thanks, > Tal. > > -------------- next part -------------- An HTML attachment was > scrubbed... > URL: > <http://www.ietf.org/mail-archive/web/tictoc/attachments/20120802/840b > 451f/attachment.htm> > > ------------------------------ > > _______________________________________________ > TICTOC mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tictoc > > > End of TICTOC Digest, Vol 68, Issue 10 > ************************************** > _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
