[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RPSEC] rate limiting management traffic, redux
On vrijdag, apr 25, 2003, at 19:41 Europe/Amsterdam, Stephen Kent wrote:
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?
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."
I agree here, but that's not that I was getting at. What I meant was
that it makes sense to somehow make this new scheme part of the larger
world of IPsec rather than create a new, independent protocol that
handles this.
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.)
Only the destination router needs to look at these values, not
intermediate routers.
I talked to some vendors at the IETF meeting in Atlanta and they told
me that due to the fact that customers demand filtering on TCP/UDP port
numbers on all interfaces, their IPv6 ASICs must support following the
protocol chain to find the TCP/UDP header, and for this they must know
about all the intermediate option headers to some extent, even though
the router isn't supposed to look at these. This means that having
"strange" options in an IPv6 packet will make said packet take the slow
(software) path.
So if you want to implement an IPv6 option, be sure to consult with a
good number of vendors first to make sure you're not shooting yourself
in the foot. Hopefully this problem will go away at some point but I
gather it's very real now.
I just now realized that we might be talking IPv4 and not IPv6 here.
:-)
Another way to do this what would work in both IPv4 and IPv6 is
encapsulate the whole thing in UDP...
Finally, the really hard problem we face is the (re)initialization
protocol.
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...).
It's not that the endpoints ought not communicate to establish fresh
state (that would be a neat trick!). rather, we want the communication
to be such that the responder to a re-init request to expend minimal
effort, to avoid using this sort of request as yet another form of
DoS. We can ensure (via an extra round trip) that we are having an
exchange with a live partner (to reject replays) and we can ensure
that after doing a crypto operation that the partner is who it claims
to be.
However, if a box goes down and the correspondent is still doing
accelerated pre-authentication, the session re-establishement packets
probably won't make it through to the CPU. NOT having the pre-auth
isn't an attractive option as an attacker can now saturate the path to
the CPU.
But maybe we don't really have to solve this. Would it be extremely
hard to implement a feature that automatically stops traffic being
_routed_ towards a router or management station if the management or
routing session with this station is down? (Locally source packet
should still be allowed through so sessions can be reestablished.)
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec