Subject: Re: [RPSEC] rate limiting management traffic, redux

From: [email-masked]
Date: Thu, 17 Apr 2003 18:32:22 -0400 (EDT)

>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
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec

---

From: Stephen Kent <[email-masked]>
Date: Fri, 18 Apr 2003 08:38:38 -0400

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

>you meant "cryptographic hash".

Understandable, but not the only option.

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

>has to be looked at.  Network management protocols are a good bet to be there.

Right.

Steve