David This is yet another consequence of the layer violation inherent in TCs.
Even without encryption, if the packet is modified on-the-fly integrity assurance mechanisms will cause a TC-updated packet to be discarded. Of course, the packets may not even be identifiable due to encryption, but were we to open and close encryption along the way the added delay and jitter would become intolerable. Furthermore, a true timing-specific security mechanism needs to ensure that the traceability of the timing flow, i.e., not only authenticate the source, but check that the received packet took the expected path. Furthermore, security certificates have time of validity - but if the timing flow is bringing this time there is an obvious attack here that has to be handled. In past TICTOC meetings we have discussed some of these issues, none of which are addressed in any way by putting timing flows inside IPsec. (In fact, I don't see any useful gain by doing that, but much harm.) Y(J)S -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Chen David-QA5646 Sent: Wednesday, March 24, 2010 18:26 To: [email protected] Cc: [email protected] Subject: Re: [TICTOC] Security and management of IEEE1588 (PTP) Hi! Antti: I have been monitoring the TICTOC activities for quite some time and I do not recall whether the apparent conflict between PTP TC (Transparent Clock) feature and the IPSEC for securing mobile backhaul. To implement PTP Transparent Clock, a network node needs to be able to identify the PTP packet (e.g., through a Protocol ID) and calculate its residence time. It then need to insert the residence time when the PTP packet exits the node. With IPSEC, PTP packet may not be able to be identified. I believe this issue must have been discussed in the past TICTOC meetings but I must have just overlooked it. Appreciate if you can provide some quick feedback on this very matter. Thanks and best regards, David David T. Chen, PhD Distinguished Member of Technical Staff Networks Advanced Technologies Enterprise Mobility Solutions and Networks Motorola Inc. +1-847-632-2664 [email protected] ---------------------------------------------------------------------- Message: 1 Date: Wed, 24 Mar 2010 13:48:10 +0200 From: "Pietilainen, Antti (NSN - FI/Espoo)" <[email protected]> Subject: [TICTOC] Security and management of IEEE1588 (PTP) To: <[email protected]> Cc: Greg Dowd <[email protected]> Message-ID: <b5535400d800ae498532700125acf3df023c7...@fiesexc014.nsn-intra.net> Content-Type: text/plain; charset="us-ascii" Hi Greg, I went through your presentations in the TICTOC meeting. The work items are valid. However, I would like to raise discussion of the suitable standards group in the case of telecom profiles of PTP. My viewpoint is a mobile network vendor's. Security Frequency synchronization without on-path support: 3GPP has specified the use of IPSEC for securing mobile backhaul if necessary. PTP can use the same IPSEC tunnels that are set up for the rest of the base station traffic. Thus, no new security methods are needed at least considering mobile backhaul. In the case of time synchronization with on-path support, if security-enabled, all PTP nodes need to authenticate their immediate neighbors in terms of synchronization. On the other hand, the data traffic rather needs end-to-end security, moreover with end-to-end encryption. Therefore, probably a separate security solution is needed for PTP. There is already an experimental annex in PTP, which covers security for PTP in general - i.e. not only for PTP/UDP/IP stack but also PTP/Ethernet stack. The solution has been verified by security experts of NIST. TICTOC should not declare itself as the owner of PTP security unless the timing community requests it. Management ITU-T Q13/SG15 has decided that management is out of scope of the PTP telecom profile for the time being. Telecom vendors have incorporated the management of packet timing into their network management systems. I don't see that the telecom companies have done a mistake in standards work that needs to be corrected by TICTOC. Surely it is possible to raise the management issue again in Q13 if needed. Conclusion I propose that the possible security & management work carried out in TICTOC would not concern telecom usage of PTP unless IETF and ITU decide together to do otherwise. Best regards, Antti Antti Pietilainen Nokia Siemens Networks Mobile transport research Linnoitustie 6 02600 ESPOO Finland tel. +358-71-8036660 ------------------------------ _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc End of TICTOC Digest, Vol 40, Issue 4 ************************************* _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
