On 2004-04-20-23:09:31, David Luyer <david@luyer.net> wrote: [...]
Answering another poster's concern about DoS risk... TCP MD5 is not a significant DoS risk as you only MD5 once the source, destination, sequence, etc are valid - ie. you only MD5 a packet which would already have broken your BGP session! [*] [...]
If only this were true. Fact of the matter is, MD5 computation/verification is not cheap, and many Cisco and Juniper platforms aren't designed to handle a barrage of MD5-hashed TCP packets. We've found that ower-end Cisco gear, like the kind your customers would use for DS1/DS3 CPE, is particularly flaky in this regard, though even a Juniper RE2-333-768 could be made to fall over with < 20mb/s of traffic, as was pointed out earlier. All things considered, I think MD5 authentication will lower the bar for attackers, not raise it. I'm sure code optimizations could fix things to some degree, but that's just not the case today. Which begs the question, what is one to do, shy of moving (private) peering/transit/customer /31's and /30's into non-routable IP space, which opens up an entirely new can of worms? Differentiating between legitimate "directly connected" and spoofed traffic is a Good Thing(tm), and the TTL hack sounds great on paper, but isn't exactly easy to implement when you consider that vendor J and others can't filter based upon TTL... yet.
[*] in any reasonable implementation. it is possible some old implementation does this wrong, though.
Try IOS 12.0S, JunOS 6.2, etc... the kind of stuff still in wide deployment. -a