On 10/18/2011 3:33 PM, Nico Williams wrote: > On Tue, Oct 18, 2011 at 12:45 PM, Kevin Gross <[email protected]> wrote: >> 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. > > Not constant so much as deterministic (for some algorithms, and some > implementations, but I assume that side-channels are not desirable, > which leads to the assumption of deterministic timing) or measurable. > In practice measuring this time is probably difficult, for example, in > preemptible kernel designs, or if the HW lacks a sufficiently high > resolution timer or CPU cycle counter. I grant then that the proposed > solution is simpler to implement. But should the proposal be > negotiable, and if so, how? > >> 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. > > However, encryption can make it harder for an attacker to delay just > the timing packets (though not impossible given enough meta-data > leaking to mount effective traffic analysis). Or, to put it > differently, making timing packets identifiable makes it easier for an > attacker to DoS only the timing exchanges but not the rest. > > DoS attacks based on not allowing packets through, or delaying them, > generally cannot be avoided, so perhaps there's no cause for concern. > I think you'd want to have a security consideration describing the > problems that might arise from a selective DoS attack on timing, as > well as mitigations.
For NTP at least, the loss of some packets doesn't matter, it will continue on disciplining the clock at the same rate until it decides it has enough reliable data to adjust the frequency of the clock to bring it back in line with its NTP reference clock servers. Even then it will throw out packets which show large variations. In the worst case it will be receiving no valid packets and just won't make changes to the clock. NTP is robust enough that the clock will be accurate enough even if it hasn't received a single packet for hours. I cannot answer for PSP since I don't know what it does. Danny _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
