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