nanog mailing list archives
Re: key change for TCP-MD5
From: Iljitsch van Beijnum <iljitsch () muada com>
Date: Wed, 21 Jun 2006 19:04:19 +0200
On 21-jun-2006, at 16:24, Ross Callon wrote:
If DOS is such a large concern, IPSEC to an extent can be used to mitigate against it.
Well, this one comment is the one that I don't understand. I don't see how IPSEC mitigates against DOS attacks. In fact, it seems to make things worse, since it hides the TCP header.
Only if you use encryption. You can also use authentication only, in two ways: with ESP, which only protects and/or encrypts the payload, or with AH, which protects the entire packet except for fields that may/must be changed in transit. But due to layering, it's unlikely you'll be looking at TCP stuff before performing the authentication check.
The reason IPsec helps against a DoS against the CPU is that it has an anti replay counter. IPsec implementations are supposed to maintain a window, not unlike a TCP window, that allows them to reject packets with an anti replay counter that's too far behind or ahead of the last seen packets. So in order to make a packet reach the CPU an attacker has to observe or guess an acceptable value for the anti replay counter.
An even better way to protect against spoofed BGP packets (ones that come from "far away" at least) is GTSM (RFC 3682), as Randy remarked in his usual concise manner. GTSM means setting the TTL to 255 when sending and checking if it's still 255 when receiving BGP packets. This way you know that there weren't any routers between you and the real source of the packet.
Unfortunately, GTSM isn't used much in practice because the BGP RFC requires routers to set and check for TTL = 1, so a router employing GTSM can't talk to one that doesn't. This means you have to enable it manually at both ends and suffer downtime during the period where one end has it enabled and the other doesn't. If only someone would have taken the extra time to define a BGP option that would allow routers to negotiate the use of GTSM automatically...
Current thread:
- Re: key change for TCP-MD5, (continued)
- Re: key change for TCP-MD5 Randy Bush (Jun 20)
- Re: key change for TCP-MD5 Ross Callon (Jun 21)
- Re: key change for TCP-MD5 David Barak (Jun 21)
- RE: key change for TCP-MD5 Randy Bush (Jun 20)
- Re: key change for TCP-MD5 Jared Mauch (Jun 21)
- Re: key change for TCP-MD5 Randy Bush (Jun 21)
- Re: key change for TCP-MD5 Steven M. Bellovin (Jun 26)
- RE: key change for TCP-MD5 Randy Bush (Jun 21)
- Re: key change for TCP-MD5 Iljitsch van Beijnum (Jun 21)
- Re: key change for TCP-MD5 Niels Bakker (Jun 25)
- Re: key change for TCP-MD5 Iljitsch van Beijnum (Jun 26)
- 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 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)