Hi, Reading this thread, I think it might be useful to clarify the context (again...). E.g. frequency or phase/time, and mono or multi-operator context.
The main use case which has been highlighted for transporting PTP into an IPSec tunnel is the femto cell application. This application requires generally today only frequency, but might require in the future phase/time in some cases. This application may be used in a mono-operator context (e.g. the entire network is owned by a single operator) or in a multi-operator context (the operator providing the femto cell service is using another operator's network). If only frequency is needed (250ppb, which is a quite relaxed requirement), an end-to-end scenario where none of the boxes in the network have to recognise and process the PTP packets might be suitable, provided that the network is not generating too much PDV. In this case, the PTP packets might be encrypted (e.g. transported in the IPSec tunnel, as the rest of the traffic), again, provided that the encryption itself does not generate too much PDV. These points are applicable both to the mono and multi-operator cases. If very accurate phase/time is needed (e.g. sub-µs accuracy), the situation is much more challenging, and an end-to-end scenario with a network not supporting specific hardware for PTP will likely not be suitable. As mentioned several times, an hop-by-hop scenario will very likely be required to meet this stringent requirement. In this very accurate phase/time case, in the mono-operator case, it is likely that the phase/time reference will be delivered by the network infrastructure directly to the femto cell, via an hop-by-hop scheme, and therefore, that the PTP packets will not be included inside the IPSec tunnel. It is similar to the discussion regarding PTP over MPLS : if one want to use an hop-by-hop scheme, why to put the PTP packets into a tunnel, whereas at the end, the destination of the PTP packets is the next equipment? Note that in this case, the support for a single clock domain is enough. For this very accurate phase/time case, in the multi-operator case now, it might be questioned if the PTP packets could be transported end-to-end into an IPSec tunnel over another operator's network. I personally believe that if this situation happens, then the µs accuracy requirement will not be met at the output of the carrier operator network. Except if the entire carrier operator network supports dedicated hardware for PTP to enable transporting transparently a "service phase/time clock", but I have real doubts that operators will invest money for such feature. Instead, they will very likely propose to deliver their own "network phase/time clock" as part of the service, and we are back to the previous mono-operator case, with single clock domain hop-by-hop scenario where PTP is outside the IPSec tunnel, since there is now only a single clock to be carried. In conclusion: as far as I can anticipate the different scenarios today, the PTP packets would be carried in an IPSec tunnel only in the end-to-end scenario for frequency-only, where none of the boxes in the network have to recognise and process the PTP packets. I am therefore not convinced (once again, sorry) that there is really a problem to solve here... Thanks. BR, Sébastien -----Message d'origine----- De : [email protected] [mailto:[email protected]] De la part de [email protected] Envoyé : vendredi 30 juillet 2010 10:54 À : [email protected]; [email protected]; [email protected]; [email protected] Objet : Re: [TICTOC] Encrypting timing packets Yaakov, Valid point. I was also thinking about the complexity if timing is part of a traffic flow that needs to be encrypted although hadn't really given it too much thought. Now think this through I really don't see how some form of hop by hop PTP will work in this case without issues. How do you recognise the packets as you point out? Do you have to decrypt the entire flow, process timing then inject it back in and encrypt. If you don't surely you will break the encryption? If you do this process surely you will add significant delay and variability. Would welcome some comment from those who have a better understanding on this. Regards, Mike -----Original Message----- From: Yaakov Stein [mailto:[email protected]] Sent: 29 July 2010 17:43 To: Gilson,MJ,Mike,DMQ7 R; [email protected]; [email protected]; [email protected] Subject: RE: [TICTOC] Encrypting timing packets Mike I think that you are missing the point. No-one is proposing purposely encrypting timing packets. We are talking about a scenario where everything is encrypted, including the timing packets. This makes it hard for a box in the middle to recognize timing packets. Y(J)S -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Thursday, July 29, 2010 15:32 To: [email protected]; [email protected]; [email protected] Subject: Re: [TICTOC] Encrypting timing packets Several points. Requirement for encryption is unclear, I can see a reason to authenticate and know where the timing packets have come from. If encryption is required I think there are issues. Just reusing something designed for another application may just create more problems. Regards, Mike -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Greg Dowd Sent: 28 July 2010 18:16 To: STUART VENTERS; [email protected] Subject: Re: [TICTOC] Encrypting timing packets Keep in mind that this requirement wasn't designed with timing or synchronization in mind. This protocol is designed to backhaul phone calls across public IP domains. As such, a strong security environment is an absolute requirement. The fact that we MIGHT need to get sync through the same pipe is a footnote. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of STUART VENTERS Sent: Wednesday, July 28, 2010 7:13 AM To: [email protected] Subject: Re: [TICTOC] Encrypting timing packets -----Original Message----- From: [email protected] [mailto:[email protected]]on Behalf Of [email protected] Sent: Wednesday, July 28, 2010 7:40 AM To: [email protected] Subject: TICTOC Digest, Vol 44, Issue 91 If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to https://www.ietf.org/mailman/listinfo/tictoc Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME. You can set this option globally for all the list digests you receive at this point. Send TICTOC mailing list submissions to [email protected] What threat model is this new feature attempting to protect from? 1) Somebody observing the time. 2) Somebody changing the time. #1 seems feasible given enough resources, but I'm not sure what application cares. #2 is interesting because time transfer is a strange application in that a man in the middle only needs to delay packets, modification and inspection are not required. It's not clear to me how encryption helps this? Unless it's used to put a defined bounds on the size of the time offset the attacker can cause? (Maybe Offset change < RTT change?) To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/tictoc or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of TICTOC digest..." Today's Topics: 1. Re: Encrypting timing packets (Stefano Ruffini) ---------------------------------------------------------------------- Message: 1 Date: Wed, 28 Jul 2010 14:39:54 +0200 From: "Stefano Ruffini" <[email protected]> Subject: Re: [TICTOC] Encrypting timing packets To: <[email protected]>, "Mikael Abrahamsson" <[email protected]> Cc: [email protected] Message-ID: <7d33ca0905ce1443bada4bd279acfc60084d2...@eitrmmw021.eemea.ericsson.se> Content-Type: text/plain; charset="iso-8859-1" Hi, See answer to one question below Best Regards Stefano -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Danny Mayer Sent: mercoled? 28 luglio 2010 14.07 To: Mikael Abrahamsson Cc: [email protected] Subject: Re: [TICTOC] Encrypting timing packets On 7/28/2010 4:45 AM, Mikael Abrahamsson wrote: > On Wed, 28 Jul 2010, Yaakov Stein wrote: > >> The problem is that you have to put in a timestamp that reflects the >> time the packet is placed on the wire. >> So you have to sign after timestamping, and unless this signature can >> be computed in zero time (or with completely deterministic latency >> that can be pre-added) the signing degrades the timing accuracy. > > Since things are timestamped on the ingress in the PHY in some cases > (1588), then perhaps the same methodology could be used here, in that > a device might add a compensation factor that includes how long the > signing took. This adjustment value would of course not be signed in > itself, but it could have a maximum value that would mean at least for > time, the signed stated time wouldn't be too much off (an attacker > could only tamper with the adjustment value) ? > > Or perhaps this doesn't really help, it's still a too big attack vector? > For server time setting it might be enough... Or is the recommendation > to just run NTP over IPSEC so NTP itself doesn't have to care? > Having NTP not care is much better except that the protocol used to transport the packets affect the latency and jitter of the timing offset. I'm not sure how you would even be able to measure that. It's one of the reasons that NTP will never use TCP for a transport. >> I think that this should be thoroughly tested. In systems that I have >> seen in the lab, the degradation rules out sub-microsecond accuracy. > > I have little doubt of that, but I can imagine applications where > sub-microsecond isn't needed but one still wants to know the time is > not off by more than that? Applications that don't need sub-microsecond accuracy can probably just stick with NTP. What I'm hearing in this WG is that the big potential consumers are areas like backhaul networks and femtocells. I haven't seen anyone spell out why they need sub-microsecond accuracy but I'm sure they have good reasons. SR: slide 7 in http://www.ietf.org/proceedings/78/slides/tictoc-4.ppt provides a few examples (and related specifcation), for applications requiring accuracy in the microsecond level . Danny _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc ------------------------------ _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc End of TICTOC Digest, Vol 44, Issue 91 ************************************** _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
