|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: key change for TCP-MD5
On 24-jun-2006, at 1:34, Patrick W. Gilmore wrote: If you care that much, why don't you just add an extra loopback address, give it an RFC 1918 address, have your peer talk BGP towards that address and filter all packets towards the actual interface address of the router? The chance of an attacker sending an RFC 1918 packet that ends up at your router is close to zero and even though the interface address still shows up in traceroutes etc it is bullet proof because of the filters. Why is this better than using the TTL hack? Which is easier to configure, and at least as secure.There are several tradeoffs. GTSM (or "TTL hack") requires that both ends implement it and this check may or may not be inexpensive. (Looking at the CPU stats when running with MD5 and then looking up how fast MD5 is supposed to be processed on much older hardware doesn't give me much confidence in router code efficiency.) If you're truly paranoid, making sure that as few people as possible can enter packets into your router's CPU input queue makes a lot of sense. I prefer having a regular next hop address that shows up in traceroutes and can generate PMTUD packets but if you move the BGP session to some other address there is no need for the interface address to ever receive any packets. That's a lot better than expending resources on AH processing, which I was replying to. RFC 1918 are an obvious choice for the addresses terminating the BGP session because they're mostly unroutable by default, but an address range that's properly filtered by your peer is even better. And if you're on a public peering LAN (internet exchange) obviously you'll want to have static ARP and MAC forwarding table entries.
|