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

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

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

---

From: Yaakov Stein <[email-masked]>
Date: Wed, 24 Mar 2010 14:07:44 +0200

> security unless the timing community requests it.

Antti -

I'm sorry, but I can't quite parse these statements.

Saying that timing flows will go through the same IPsec tunnels as data
basically says that there are no timing-specific security mechanisms
being used.

That is precisely what we want to address.

In our requirements work we already came to the conclusion that there
was no pressing reason for encrypting timing packets,
and tunneling them through IPsec may be useful for anti-tampering -
but comes at a price of performance degradation.

Saying that the security experts from NIST (whom I respect a great deal)
have looked at this and are happy is also close to meaningless.
Security experts are not necessarily timing experts (and vice versa),
and I have yet to see the security experts address the security issues
that have already been well documented by the NTP community.

TICTOC is not declaring itself the owner of anything.
In particular, at this point I believe that most of us want
to avoid focusing on mobile backhauling, 
and while 1588 is one of the possible timing protocols,
it is not our only or main interest.

Y(J)S