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
