Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt

From: [email-masked]
Date: Wed, 5 May 2004 15:23:17 -0400

>> Doesn't this mean you can defeat someone else's ability to RST a
>> connection by flooding them with RSTs?
>>
>> Holding state for a long time in that case means one party can't
>> reset a connection they want - or need to, doesn't it?
>
>Oh, well another approach I'll throw out is not more than one RST
>challenge per time period.  E.g., no more than 1/second.  That limits
>the damage of an ACK war without allowing someone to deny the legitimate
>ripping down of a connection for minutes.  (At the expense of some
>state.)
Would a longer time period be better - reduce the probability of a
successful attack?  If a legitimate reset were lost
when would you expect another?  Can you guess based on RTT?

Sorry for all the questions but I haven't had time to look in to
this more deeply yet.  I'm sure some of you can answer them right off.

I have been wondering about this in the context of the long lived
connections where the RST attack problem occurs.  It seems to me
they can handle some delay unless they need the resources immediately
to start a new connection.  For my application, iSCSI, we probe the
connection at the application level after a period of inactivity in
minutes, so we are OK.  I'm not as familiar with the other long-lived
applications that this affects.  I wonder if what would have the most
problem with the delay.

Aaron

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

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Thu, 06 May 2004 06:18:34 -0400

>when would you expect another?  Can you guess based on RTT?

It seems to me one could add at a minimum a dampening
so that you would respond to RST's/Ack wars with a slower
rate.. say start with RST_ACK_DELAY = 0

Then when you get a RST and respond with an ACK, add
the current RTT to the RST_ACK_DELAY. Next RST since
RST_ACK_DELAY is not 0, you start a timer and at expiration
send your ACK and add yet another RTT to the RST_ACK_DELAY.

This gives you a kind of exponential backoff (not quite though).. and
one could even ignore all further RST's if the timer was running... It
would slow the RST process down a tad.. but you would have to be
real unlucky to get a real RST slowed down more than 1 or 2 RTTs...

The bad side to this is it is no longer  just a tweak to to the stack.. you
really must add a timer and quite a few more bytes to the TCB to
track this...

R

-- 
Randall R. Stewart
ITD - Transport Technologies
815-477-2127(o) or 815-342-5222(c)

---

From: Mitesh Dalal <[email-masked]>
Date: Fri, 7 May 2004 09:51:02 -0700 (PDT)

> really must add a timer and quite a few more bytes to the TCB to

this might work, but as you have already pointed out this is adding
more state which might not be palatable. ACKs, as I see it are supposed
to be stateless. We do not need to remember that we have send an ACK.
Although I do agree that we can make a note of this in the draft and
recommend adding an incoming RST throttling mechanism for scenario
where there is a perceived danger of an offending middlebox that might
cause the RST/ACK war.

Thanks
Mitesh