key change for TCP-MD5

Wed Jun 21 17:04:19 UTC 2006

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...