[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RPSEC] rate limiting management traffic, redux

At 9:49 PM +0200 4/25/03, Iljitsch van Beijnum wrote:

...
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.
OK, I understand. Let me say why I think it is very unlikely for that to happen. IPsec is trying to remove complexity from implementations, whereas adding this functionality would add complexity. Moreover, the rate-limiting goal for this mechanism is not one that the IPsec WG, or most IPsec customers, see as relevant to the overall set of security features that IPsec offers. Thus I doubt that IPsec would add this feature.



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.


OK. Then we just need to be defined as "not strange" :-)




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...


yes, that might be an option.






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.)



since a correspondent does not always know when its peer has crashed 
and recovered, our goal is to have a way to re-initialize without 
involving the CPU, to avoid the problems you cite.



Steve

_______________________________________________

RPSEC mailing list

RPSEC@ietf.org

https://www1.ietf.org/mailman/listinfo/rpsec