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

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.

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

Ross

I'd still like someone to explain why we're wasting man hours, CPU time,
filling up our router logs, and potentially making DoS easier, for an
attack that doesn't exist. After that, I'd like them to explain why we
need to devote more resources to protecting against the attack that
already doesn't exist, and that is already protected against just fine
even if it were to exist.

Of course any not completely insane implementation should be checking for
a valid TCP window range (or an existing TCB for that matter) before
wasting CPU time on an MD5 calculation. It's just not possible in reality
for any sufficiently large number of packets to get through those check to
then be affected by an MD5 DoS (unless of course you're peering with 7018,
and the NSA has an extra copy of your packets laying around).

We already collectively wasted our time deploying MD5 passwords over a big
scare that turned out to be nothing more than someone cracking open the
manual and rediscovering how stuff worked all along. Why don't we spend
our time going forward solving actual issues like filtering/announcement
authentication, and stop trying to solve the non-existant problems.

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

gstm

We already collectively wasted our time deploying MD5 passwords over a big
scare that turned out to be nothing more than someone cracking open the
manual and rediscovering how stuff worked all along

Bwahahahhahaha.

I work with that "someone" --- he (and the rest of his group) are wildly proud of this "l33t discovery"

W

I'd still like someone to explain why we're wasting man hours, CPU time,
filling up our router logs, and potentially making DoS easier, for an
attack that doesn't exist.

because the non-existent attack(s) have occurred. and keys have
been compomised.

randy

this doesn't help if the vendor can't implement it
correctly and does the md5 calc before checking the ttl :frowning:

  - jared

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

gstm

this doesn't help if the vendor can't implement it
correctly and does the md5 calc before checking the ttl :frowning:

hard to imagine anything that will help such a vendor

randy

I think that it does make sense to be clear what attack
or set of attacks we are trying to protect against.

One type of attack is the TCP reset attack. I personally don't
have a strong opinion regarding whether it is worth protecting
against only this attack.

Another potential attack is an attempt to insert information
into a BGP session, such as to introduce bogus routes, or
to even become a "man in the middle" of a BGP session. One
issue that worries me about this is that if this allows routing to
be compromised, then I can figure out how to make money off
of this (and if I can think of it, someone even nastier will probably
also think of this). Of course this would be much more difficult to
pull off, and might require viewing packets between routers to pull
off, but if pulled off and not quickly detected could be unfortunate.

Ross

But it's safe to say that it would be a lot easier to
crack a router itself than to unobtrusively insert
useful false information, or if the ISP's routers are
sufficiently hardened, it would be easier to crack a
customer (or peer)'s router, and use that for the
injection.

The same mechanisa which can detect bogus prefixes
from a peer/customer can detect them from a hijacked
session. The cost/benefit ratio is better for
securing the routers themselves.

-David

David Barak
Need Geek Rock? Try The Franchise:
http://www.listentothefranchise.com

You're quite right, and the next version of the draft contains the
following additional text in the Security Considerations:

     Having multiple keys makes CPU denial of service
     attacks easier. This suggests that keeping the
     overlap period reasonably
     short is a good idea. In
     addition, the Generalized TTL Security Mechanism
     <xref target="RFC3682" />, if applicable to
     the local topology, can help.
     Note that there would almost never be more than
     two keys in existence at any one time in any event.

    --Steven M. Bellovin, http://www.cs.columbia.edu/~smb