nanog mailing list archives
Re: key change for TCP-MD5
From: Iljitsch van Beijnum <iljitsch () muada com>
Date: Sat, 24 Jun 2006 12:10:49 +0200
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.
Current thread:
- RE: key change for TCP-MD5, (continued)
- RE: key change for TCP-MD5 Randy Bush (Jun 21)
- Re: key change for TCP-MD5 Richard A Steenbergen (Jun 21)
- backbone threats [Re: key change for TCP-MD5] Pekka Savola (Jun 26)
- RE: key change for TCP-MD5 Randy Bush (Jun 21)
- RE: key change for TCP-MD5 Barry Greene (bgreene) (Jun 23)
- Re: key change for TCP-MD5 Todd Underwood (Jun 23)
- Re: key change for TCP-MD5 Richard A Steenbergen (Jun 23)
- Re: key change for TCP-MD5 Richard A Steenbergen (Jun 23)
- Re: key change for TCP-MD5 Todd Underwood (Jun 23)
- RE: key change for TCP-MD5 Owen DeLong (Jun 23)
- Re: key change for TCP-MD5 Iljitsch van Beijnum (Jun 23)
- Re: key change for TCP-MD5 Patrick W. Gilmore (Jun 23)
- Re: key change for TCP-MD5 Iljitsch van Beijnum (Jun 24)
- Re: key change for TCP-MD5 Valdis . Kletnieks (Jun 23)
- Re: key change for TCP-MD5 Roland Dobbins (Jun 23)
- Re: key change for TCP-MD5 Richard A Steenbergen (Jun 24)