RE: key change for TCP-MD5
At 04:23 PM 6/20/2006 -0700, Bora Akyol wrote:
...The DOS is a concern whether you have a valid key or not, correct?
Yes, People who do NOT have a valid key can certainly launch DOS attacks.
I can DOS the router with fake packets that it needs to verify as long as I want.
Yes, but the attack needs to get past whatever packet filters (ACLs) are between them and the CPU that they are trying to overwhelm. This might include packet filters on ingress to whatever network the attacker is in, packet filters on ingress to the network of the victim, or on ingress to the router under attack.
All the multiple keys do is to decrease the cost of the DOS.
Yes
...For example, if we allow 4 keys at a time and the router dies at a 100 Mbps attack traffic, now it will die at 25 Mbps. While this may look like a big deal, I think the dark side has enough firepower that essentially 25 equals 100.
There are of course two multiplicative effects: The effect of using authentication at all, and the effect of having multiple keys active at once. However, yes, the effect of having "n" keys active at once is no worse than n times the effect of using authentication.
If DOS is such a large concern, IPSEC to an extent can be used to mitigate against it. And IKEv1/v2 with IPSEC is not the horribly inefficient mechanism it is made out to be. In practice, it is quite easy to use.
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. If a packet is authenticated at the TCP level, then the attack packet needs to get past (hopefully line rate) packet filters on the IP header, and some fields in the TCP header before it can contribute to the DOS attack (but it can still contribute to DoS even if the authentication fails). If the TCP sequence number is out of range, then a smart implementation may indeed discard the packet before checking the authentication, but it still likely has gotten past the packet filters and gotten to the CPU. If a packet is authenticated using IPSEC (between IP and TCP), then it only needs to get past the IP packet filters before it can contribute to the DOS, and doesn't need to get past whatever checks occur at the TCP level (including not having to get past the sequence number check prior to having the authentication checked). Ross
All the multiple keys do is to decrease the cost of the DOS. Yes
let's try to remember that, in reality, this is all about allowing two bgp peers to move to a new key without having the operators on the phone to keep the bgp session from resetting. i.e., o it will be uncommon that there is more than one key active at any one time o it is not expected that there are more than two, current and new (soon to be current and old:-) active at any one time smb is proposing a simple, compatible, unilaterally implementable, and unilaterally deployable hack to solve a real ops problem. the RSs aside, a lot of very big and small networks use tcp/md5 on their bgp sessions, and key roll is a major pita and therefore a serious barrier to good key hygiene. randy
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...
* iljitsch@muada.com (Iljitsch van Beijnum) [Wed 21 Jun 2006, 19:05 CEST]:
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.
Actually, no. In a router you can easily filter away all IP packets not destined to port 25 to a certain host (for, say, a mail server). However, if those packets are IPsec encrypted, these TCP headers are unavailable to routers in the path. I do not expect a complete IPsec implementation in the filtering engines of routers, nor that they be able to keep track of window sizes in specific conversations (after all, they don't get to see RST packets either). Web servers generally do not come with hardware-based filtering capabilities to protect "the CPU." -- Niels.
On 26-jun-2006, at 2:06, Niels Bakker wrote:
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.
Actually, no. In a router you can easily filter away all IP packets not destined to port 25 to a certain host (for, say, a mail server). However, if those packets are IPsec encrypted, these TCP headers are unavailable to routers in the path.
You can't have it both ways: either you encrypt the packet so that nobody can look inside it, or you don't and people can. But we weren't talking about encryption. Or about filtering packets that go _through_ a router. What we were talking about was using the IPsec authentication on BGP sessions and whether that's better than using TCP with MD5 in relation to DoS attacks.
participants (4)
-
Iljitsch van Beijnum -
Niels Bakker -
Randy Bush -
Ross Callon