[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RPSEC] rate limiting management traffic, redux
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.
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.)
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...).
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec