Hi David, In the 3GPP way of using IPSEC, the payload is encrypted. Thus, intermediate nodes cannot access the timing packet without decrypting all traffic in that IPSEC tunnel. The end-to-end security would be partly compromized if a large number of intermediate nodes would be authorized to decrypt the content. Some security mechanisms allow only the two endpoints participate in the encryption/decryption. Thus, maybe it is impossible to access the packets on the way.
If the PTP packets are put in a separate IPSEC tunnel without encryption, then the time stamp fields could be changed without decryption. Regardless, the TCs need to be authenticated and they need to carry out key exchange so that they can change the correction field and the integrity check code to correspond to the new time value in the correction field. In case of PTP TC and BC -----Original Message----- From: ext Chen David-QA5646 [mailto:[email protected]] Sent: Wednesday, March 24, 2010 6:26 PM To: Pietilainen, Antti (NSN - FI/Espoo) 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
