At 10:44 AM +0200 4/23/03, Iljitsch van Beijnum wrote:
Yes, as I noted, ESP or AH compute integrity checks over payloads, whereas ll we need for rate limiting is a function computed over a secret value and a sequence number. That means that we can perform a much faster computation, with an equivalent level of security (relative to working back to find the key). Thus it makes sense to explore this approach vs. just saying "implement a line-rate capable IPsec chip on each interface."On woensdag, apr 23, 2003, at 03:30 Europe/Amsterdam, Stephen Kent wrote:Does it make sense to reinvent the wheel here? Especially as we can at least reuse the anti-replay counter and possibly borrow some space from the initialization vector to store the tag. Obviously this mechanism would be entirely optional.
Well, having invented this particular wheel, I am comfortable saying that the sequence number and windowing mechanisms should be reused, but nothing else :-)
Any particular reason for this?
More seriously, the focus of this proposal is a rate limiting authentication mechanism, and that is not very closely aligned with the security services that IPsec offers.The phrase "rate limiting authentication mechanism" isn't clearly defined (or I'm unaware of this definition) but if you mean something that can effectively rate limit unauthentic traffic to very low levels without impacting authentic traffic, we are in agreement. Now obviously we can't immediately rule out any synergy between the simple authentication mechanism and the full-fledged one that IPsec provides... And in practice I think it's safe to assume (or mandate) that the new scheme will always be used together with ESP authentication or AH.
Agreed.
Only the destination router needs to look at these values, not intermediate routers.So I do not think it likely that we will add this sort of facility, even as an option, to AH or ESP (said the editor of those documents).I don't care all that much what goes in which document, but I'd hate to see this take up unneeded space in the headers. Also, the hardware builders are probably not going to like this as option processing uses up silicon. This wouldn't be a problem for linecards implementing this, but the packets must also be forwarded using the fast path in routers that don't implement this, unless we can be positive that packets containing this option never traverse any routers in the middle. (Which we can't for iBGP.)
IKE embodies mechanisms to make IT less susceptible to certain forms of DoS attacks. ESP is engineered to be able to process packets in a fashion to minimize opportunities for DoS, but not to the extent that we are discussing here.Finally, the really hard problem we face is the (re)initialization protocol. This is a difficult problem to solve, since we want to minimize the opportunity for DoS attacks at both ends (so that we can use this between routers, not just between a management station and a router), to a greater extent that existing protocols like IKE (v2).Does IKE have explicit support for negotiation in the presence of DoS?
I guess what we need for this is for the two endpoints to establish some bootstrapping authentication state without actually communicating. This should be doable in the presence of a pre-shared key for this purpose along with something that changes over time in a predictable way (such as the clock...).