Nico's contention is that it should take a constant amount of time to decrypt a packet once it is received. I don't think this is exactly true but when compared to other (variable) latencies in the system, possibly a reasonable approximation.
If an attacker delays or drops synchronization packets, clock quality will suffer. In the extreme case, all useful clock communication is lost and nothing works. I don't think this situation is any different for clock traffic than it is for other traffic. Encryption cannot prevent denial of service. Kevin Gross On Tue, Oct 18, 2011 at 10:49 AM, <[email protected]> wrote: > But why would you assume that the delays are consistent?**** > > ** ** > > In the non-encrypted case, you can reasonably assume that because there is > an underlying assumption that there are no malicious agents in the network. > However, if you believe that encryption is needed because the network does > contain malicious agents, you would want to assume that anything that’s > interesting to attack is in fact attacked.**** > > ** ** > > In particular, if you assume that active attacks are taking place where > time sync packets are selectively delayed, what does that do to your > protocol?**** > > ** ** > > paul**** > > ** ** > > *From:* [email protected] [mailto:[email protected]] *On Behalf > Of *Kevin Gross > *Sent:* Tuesday, October 18, 2011 12:43 PM > *To:* Nico Williams > *Cc:* [email protected]; Danny Mayer; [email protected]; Cui Yang; David L. > Mills > *Subject:* Re: [IPsec] [TICTOC] Review request for IPsec security for > packet based synchronization (Yang Cui)**** > > ** ** > > It does seem reasonable to consider modeling encryption and decryption in > as part of network latency. As long as delays introduced are the same each > direction, the sync protocols will naturally subtract out this contribution. > **** > > ** ** > > Kevin Gross**** > > ** ** > > On Fri, Oct 14, 2011 at 11:25 AM, Nico Williams <[email protected]> > wrote:**** > > ** ** > > The cost of crypto can be measured, and performance generally > deterministic (particularly when there's no side channels in the > crypto) (assuming no mid-crypto context switches), so that it should > be possible to correct for the delays introduced by crypto (just as > it's possible to measure and estimate network latency). Indeed, > crypto processing will likely be more deterministic than network > latency :)**** >
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
