Subject: Re: Re: [RPSEC] DDoS of routing ?

From: [email-masked]
Date: Fri, 14 Mar 2003 17:04:53 -0500 (EST)

>A better way to deal with this is use some kind of magic cookie in each
>packet that can be precomputed and easily checked. For instance, each
>segment includes an MD5 over the previous segment and a secret key.
>Since the MD5 operation needs to be done only after processing a valid
>segment rather than after each segment, an attacker can't trigger
>unnecessary MD5 operations, just some 16 byte compare operations. These
>are somewhat less costly to implement in a linecard than even the
>fastest crypto...

Could you explain what you mean some more?

First, an MD5 over data+shared secret *is* a crypto operation.  (Not
the best, most people recommend the HMAC-MD5 over data+sharedsecret, but hey)

When you say "segment" are you talking TCP segment?

You imply that this is a win because the bad guy would have a hard
time coming up with valid segments.  Is that the advantage?  If so,
why do you think that's hard?

--Sandy
_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 15 Mar 2003 01:00:07 +0100 (CET)

On Fri, 14 Mar 2003 [email-masked] wrote:

> >unnecessary MD5 operations, just some 16 byte compare operations.

> First, an MD5 over data+shared secret *is* a crypto operation.

I know.

> (Not the best, most people recommend the HMAC-MD5 over data+sharedsecret, but hey)

Of course, but let's leave some details for an actual draft.  :-)

> When you say "segment" are you talking TCP segment?

Yes. If the magic cookie for packet n is created by doing an HMAC over
packet n - 1 then we have to be sure we don't miss any packets. This is
possible with TCP, I don't see how with IP. Of course there can also be
other ways to set up the magic cookie: derive it from the time, simply
communicate it to the other side, stuff like that.

> why do you think that's hard?

I'm not sure what you mean here by "valid segments". I'm not
suggesting we should forget about regular authentication (IPsec or BGP
TCP MD5 hack). (But maybe further study will show we can. Probably not,
though.) So we know which segments are valid and which aren't the same
way we do now.

The advantage is that if we receive 1 valid packet and 999 DoS packets
per second, doing regular IPsec/RFC2385 needs 1000 crypto operations per
second. My suggestion would need 2: one for the regular IPsec/RFC2385
for the valid packet and then another to generate the cookie for the
next packet. The 999 DoS packets don't have the right cookie so they can
be discarded without having to do any crypto.

Iljitsch

---

From: Stephen Kent <[email-masked]>
Date: Tue, 18 Mar 2003 11:50:21 -0500

>be discarded without having to do any crypto.

I think you're getting pretty far ahead re details of engineering a 
solution, when we don't even have a good characterization of, or 
agreement on, the requirements.   On that basis, I think we ought not 
spend the time now trying to evaluate a proposal such as this one.

Steve

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 18 Mar 2003 18:02:51 +0100 (CET)

> spend the time now trying to evaluate a proposal such as this one.

Fine.