North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

RE: key change for TCP-MD5

  • From: Ross Callon
  • Date: Wed Jun 21 10:52:29 2006

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

All the multiple keys do is to decrease the cost of the DOS.

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