Subject: Re: [TICTOC] Security and management of IEEE1588 (PTP)

From: "Chen David-QA5646" <[email-masked]>
Date: Wed, 24 Mar 2010 12:25:53 -0400

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-masked]

----------------------------------------------------------------------

Message: 1
Date: Wed, 24 Mar 2010 13:48:10 +0200
From: "Pietilainen, Antti (NSN - FI/Espoo)"
	<[email-masked]>
Subject: [TICTOC] Security and management of IEEE1588 (PTP)
To: <[email-masked]>
Cc: Greg Dowd <[email-masked]>
Message-ID:
	
<[email-masked]>
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-masked]
https://www.ietf.org/mailman/listinfo/tictoc

End of TICTOC Digest, Vol 40, Issue 4
*************************************

---

From: Yaakov Stein <[email-masked]>
Date: Wed, 24 Mar 2010 18:43:47 +0200

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-masked] [mailto:[email-masked]] On Behalf Of Chen David-QA5646
Sent: Wednesday, March 24, 2010 18:26
To: [email-masked]
Cc: [email-masked]
Subject: Re: [TICTOC] Security and management of IEEE1588 (PTP)

Hi! Antti:

David T. Chen, PhD

Message: 1

Hi Greg,

Security

Management

Conclusion

Best regards, Antti

Antti Pietilainen
Nokia Siemens Networks

---

From: "Pietilainen, Antti (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 24 Mar 2010 19:38:46 +0200

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-masked]] 
Sent: Wednesday, March 24, 2010 6:26 PM
To: Pietilainen, Antti (NSN - FI/Espoo)
Cc: [email-masked]
Subject: RE: [TICTOC] Security and management of IEEE1588 (PTP)

Hi! Antti:

David T. Chen, PhD

Message: 1

Hi Greg,

Security

Management

Conclusion

Best regards, Antti

Antti Pietilainen
Nokia Siemens Networks