> 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.

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



_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc

Reply via email to