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

Re: [RPSEC] rate limiting management traffic, redux

At 6:32 PM -0400 4/17/03, sandy@raven.gw.tislabs.com wrote:

 >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.
I didn't mean to suggest that this was your opinion, but I did want to make the point that not all crypto is slow.



A simple stream cipher would probably
suffice.



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



Understandable, but not the only option.




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




Also, the MD5 checksum is computed over the whole TCP payload, and 
that IS a lot slower than a function computed over just two, small 
values.




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



Right.

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