RE: key change for TCP-MD5

Mailman List Mirror (Read Only)
1

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

2

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

3

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

4

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

5

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.