Re: [RPSEC] rate limiting management traffic, redux

[sandy@raven.gw.tislabs.com]

>I think it would be wrong to maintain that "no crypto techniques run
>fast enough"

I'm not advocating the opinion, just wondering if your approach was
going to convince the folk who needed to be convinced.

>A simple stream cipher would probably
>suffice.

Ah, I saw "one way function" and immediately jumped to the conclusion that
you meant "cryptographic hash".

>Moving MD5 to the interface card would address the current 
>problem for BGP neighbor traffic, but since it is a TCP-level 
>mechanism, it would entail moving a lot more mechanism to the card 
>than just the crypto check.

Welllll, I was thinking that if you could accept the layer violations,
the interface card could do just the MD5 authentication, and let the
other processor do all the TCP processing.  Of course, the whole question
is moot, as you're suggesting a faster crypto.

>However, the TTL=255 trick is certainly tough to beat :-) in terms of 
>performance, and it may be sufficient for a dedicated point-to-point 
>link

I was wondering for a bit about routers that accepted IP-in-IP and
whether that would be a way to disguise traffic so it had a 255/254 TTL,
but the word I hear is that routers in general do not accept IP-in-IP
packets.  MBONE tunnels used to be IP-in-IP, but that's not used much
anymore.

>Maybe the more important context is the remote management workstation 
>path to a router, vs. a neighbor router.

Any protocol a router is likely to run in the off-data-path processor
has to be looked at.  Network management protocols are a good bet to be there.

--Sandy
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec