key change for TCP-MD5

Sat Jun 24 10:10:49 UTC 2006

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.