RE: key change for TCP-MD5

Good comments, please see inline:

From: Ross Callon []
Sent: Tuesday, June 20, 2006 2:06 PM
To: Bora Akyol;
Subject: RE: key change for TCP-MD5

>The draft allows you to have a set of keys in your keychain and the
>implementation tries all of them before declaring the segment as

DoS against routers is of course a major concern. Using
encryption has the potential of making DoS worse, in the
sense that the amount of processing that a bogus packet can
cause is increased by the amount of processing needed to
check the authentication. If the router needs to check
multiple keys in the keychain before declaring the segment as
invalid, then this multiplies the effect of the DOS by the
number of keys that need to be checked.


The DOS is a concern whether you have a valid key or not, correct?

I can DOS the router with fake packets that it needs to verify as long
as I want.

All the multiple keys do is to decrease the cost of the DOS. For
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.

For device vendors, they need to solve this problem regardless of the
of simultaneous key checks. For example,
they can use a TCP-offload-engine for their CPU. The TOE engines are
used in servers for a long time now.

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.

>No time synchronization required. No BGP message required.
>The added cost for CPU-bound systems is that they have to try
>(potentially) multiple keys before getting the **right** key but in
>real life this can be easily mitigated by having a rating
system on the
>key based on the frequency of success.

This mitigates the effect of authenticating valid packets.
However, this does not appear to help at all in terms of
minimizing the DOS effect of an intentional DoS attack that
uses authenticated packets (with the processing time required
to check the keys the intended damage of the attack).


Please see my comments above.