I suppose there is a possible selective attack vector here based on messing with packets based on their length and transmission timing. It's an interesting topic but I don't think that was the intended topic of this discussion. We want to figure out how/if can we make clock distribution work through an IPSec connection. I guess your point is that an "IPSec connection" should be defined as an IPSec connection _under active attack_. I'm afraid not qualified to assess these larger-picture security questions.
Kevin Gross On Tue, Oct 18, 2011 at 12:16 PM, <[email protected]> wrote: > Absolutely. But if you allow, say, one second round trip time, you have to > assume that your time is off by that amount from the master. In an > environment without active attackers you would assume that the error is a > fair amount smaller, basically the estimate of the difference between the > two legs of the trip plus some allowance for jitter. If you introduce > attackers, you might have an underlying network that offers near-zero > latency, and all the latency you’re seeing is due to active attack on one or > the other legs of the round trip.**** > > ** ** > > paul**** > > ** ** > > *From:* Kevin Gross [mailto:[email protected]] > *Sent:* Tuesday, October 18, 2011 1:45 PM > *To:* Koning, Paul > *Cc:* [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; [email protected] > > *Subject:* Re: [IPsec] [TICTOC] Review request for IPsec security for > packet based synchronization (Yang Cui)**** > > ** ** > > 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 :)**** > > ** ** > -- Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
