Subject: [tcpm] alternative RST processing

From: Wesley Eddy <[email-masked]>
Date: Thu, 22 Apr 2004 08:34:13 -0400

As an alternative to combat the blind RST attack, instead of using ACKs
for challenge-response, it should also suffice to modify the TCP state
machine to not go into CLOSED on a RST, but transition into the
TIME-WAIT state.  With another transition to come back to ESTABLISHED on
receipt of data, this seems like it would work.

-Wes

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Thu, 22 Apr 2004 07:00:42 -0500

>receipt of data, this seems like it would work.
Wes:

Would this not cause any TIME-WAIT state connection to
"revive" if a old data segment arrives from the network then?

R

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

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

---

From: Wesley Eddy <[email-masked]>
Date: Thu, 22 Apr 2004 09:05:41 -0400

> "revive" if a old data segment arrives from the network then?

It would likely make the most sense to only revive on the next expected
data segment.

-Wes

---

From: Ted Faber <[email-masked]>
Date: Thu, 22 Apr 2004 14:45:45 -0700

> It would likely make the most sense to only revive on the next expected

It would make a nice companion document to RFC1337 - TIME-WAIT
Ressurrection Hazards. :-)

I'm a little nervous about adding arcs to the TCP state diagram.

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG

---

From: Joe Touch <[email-masked]>
Date: Thu, 22 Apr 2004 17:00:22 -0700

> "revive" if a old data segment arrives from the network then?

At best, as I suggested in another post, it is the source of the RST 
that should go into TW not the receiver. There's no way for the source 
to know whether the receiver got the RST or not.

FWIW, as Ted just pointed out when he walked by, TCP doesn't require 
this. Perhaps it's time for _that_ ID as a WG item?

Joe

---

From: Wesley Eddy <[email-masked]>
Date: Fri, 23 Apr 2004 09:14:10 -0400

> I'm a little nervous about adding arcs to the TCP state diagram.

The ACK challenge-response mechanisms add arcs to the state diagram too.
They self-loop in established where previously they transitioned to
closed.  The differences don't seem hugely significant.

It seems like if the sequence space had been guessed and an attacker sent
a blind reset within the acceptable space, but not exactly correct,
they might also be able to guess the proper response to the challenge.
It's not as if the problem is cryptographically hard (or even close).
Looping in TIME-WAIT instead of this challenge-response behavior seems
to be significantly less gameable.

-Wes

---

From: "Paul Goyette" <[email-masked]>
Date: Fri, 23 Apr 2004 06:58:09 -0700

> they might also be able to guess the proper response to the challenge.

True.  But then the guessing problem is expanded (returned?) to a 
probability of one-in-2**32 rather than one-in-(2**32 / RCV.WND).  
In other words, any RST segment with an exactly matching sequence 
number will still reset the session.

---

From: Wesley Eddy <[email-masked]>
Date: Fri, 23 Apr 2004 10:00:51 -0400

> number will still reset the session.

That statement is true of the solution in Randall's draft as well.  See
page 4, behavior B.

-Wes

---

From: "Paul Goyette" <[email-masked]>
Date: Fri, 23 Apr 2004 07:12:00 -0700

> That statement is true of the solution in Randall's draft as well.  See

Agreed.

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Fri, 23 Apr 2004 11:11:06 -0400

>to be significantly less gameable.

The guess MUST be exact.. not close.. so when the
normal ACK is sent to the true peer.. the attacker must still
turn around and guess a 1 in 2^^32 number.... and the
attacker will not see the ACK itself.. or know the challenge
went on....

R

---

From: Ted Faber <[email-masked]>
Date: Fri, 23 Apr 2004 10:37:59 -0700

> closed.  The differences don't seem hugely significant.

Let me be more precise in my objections and try to point out where I
believe the complexity lies, then.  My concern is not really in adding
arcs to a graph, which as you say, we're doing anyway.  My concern is
that in jumping from the ESTABLISHED state where the TCP connection is
open to one in which the connection is closed (TIME-WAIT) there will be
both transient behavior that will break applications or that the
solution will require significant changes to the semantics of the
TIME-WAIT state in order to work.  The Stewart changes to the semantics
of ESTABLISHED are minimal by comparison.

Data in segments arriving to a connection in TIME-WAIT are essentially
discarded as it stands now.  The state is currently only entered after a
successful FIN exchange, so any arriving data segments are assumed to be
invalid because the endpoints have agreed that there is no more data to
be transferred.  So, if the endpoint enters TIME-WAIT on reciept of a
segment containing a valid RST flag from a blind attacker, the fate of
subsequent valid data from the real sender arriving at the connection in
TIME-WAIT is unclear.  I understand that you're proposing that one
returns to ESTABLISHED on reciept of data, but this means that the
TIME-WAIT state that the connection entered has to contain the extra
information that the conection is not in a "real" TIME-WAIT state, but
one that will be invalidated on receipt of new data.  That seems like a
different state to me.

Furthermore consider in this case: a blind RST arrives to a largely
quiescent connection.  The connection enters TIME-WAIT and 2 MSL time
passes before the endpoint that knows nothing of the RST  sends another
packet.  The connection closes on the endpoint that got the RST, or
there's some more state in the TIME-WAIT state that will ignore the 2
MSL timeout if it was entered as a result of a questionable RST.

I wouldn't be surprised to see some other complexities working in there,
to.  Jumping from ESTABLISHED around all the state changes implied in
the FIN_WAITs/CLOSING nest over there is not to be undertaken lightly,
IMHO.

It seems to me that the state you're talking about transitioning to
really isn't TIME-WAIT but something like BAD-RESET-P.  I think that the
insight from Randall and company is that one can emit a challenge from
ESTABLISHED that requires no change of state in the TCB or in the state
diagram (I know one implies the other, it's just for emphasis :-)), but
provides some protection.  The connection doesn't have to remember that
it's seen the RST, nor does it have to change how it handles data or
other packets until theres some confirmation elicited by the simple
challenge that is embodied in the new ACK.  (The fact that this
interoperates with unmodified TCPs, and that an unmodified TCP partnered
with one that generates the challenge will do the right thing whether
trying to reset or being attacked is also good).

Now, there may be an argument to be made that staying in ESTABLISHED
doesn't keep track of some new state needed to resolve the validity of
the RST and that a new state is needed, but you haven't convinced me
that we need that state, or that TIME-WAIT is that state.

> they might also be able to guess the proper response to the challenge.

The attacker in question cannot see the challenge, or the attack
wouldn't be a blind one.  If the attacker can snoop packets, the system
in the Stewart draft is useless, because the attacker will simply pick
the correct sequence number for the RST the first time, and never elicit
a challenge.

> It's not as if the problem is cryptographically hard (or even close).

No, it would be "read back the sequence number" hard. :-)  The challenge
would be an indication to the attacker that they'd been close, but if
the attacker can see it, they not only know that they're close, but what
the correct answer is.

> to be significantly less gameable.

My concerns aren't with the difficulty for the attacker, but in the
disruption to the protocol.  I don't want to add a state unnecessarily,
and I believe that the modifications necessary to make TIME-WAIT serve
this purpose amount to adding a new state.

Your mileage may, of course, vary.

---

From: Wesley Eddy <[email-masked]>
Date: Fri, 23 Apr 2004 13:51:21 -0400

> this purpose amount to adding a new state.

Mark convinced me a little earlier today that the behavior in the Stewart
draft is more reasonable than changing states, so I'm now in full agreement.
We had one slight refinement though ...

A connection could be slightly disturbed by RST probing that sent 3 segments
per slice of sequence space.  If 3 duplicate acks were generated then there
could be an unwarranted congestion response as a result of the RST attack
on the other side.  Although not breaking the connection, it could be slowed
a bit, and the process might be repeated.  This is probably not a huge
issue.

The fix would just consist of not sending repeated ACKs for multiple RSTs
within the same window.

-Wes

---

From: Ted Faber <[email-masked]>
Date: Fri, 23 Apr 2004 11:27:57 -0700

> draft is more reasonable than changing states, so I'm now in full agreement.

Cool.

> The fix would just consist of not sending repeated ACKs for multiple RSTs

Hmmm.  That's an interesting problem.  While we can fix it for RSTs, I
think the attacker could just send bogus short data packets and achieve
the same effect, right?

---

From: Mika Liljeberg <[email-masked]>
Date: Fri, 23 Apr 2004 21:40:16 +0300

> The fix would just consist of not sending repeated ACKs for multiple RSTs

I don't think we need to worry about a blind attacker sending 100k
packets just to cause a fast retransmit. :-) Certainly not worth
introducing another state variable.

	MikaL

---

From: Joe Touch <[email-masked]>
Date: Fri, 23 Apr 2004 11:46:29 -0700

Hi, all,

The draft currently under discussion tries to secure TCP from 
third-party attacks via RSTs. This is only one of a number of attacks, 
including (but not limited to):

	- SYN attacks
	- RST attacks (as per the current discussion)
	- ACK attacks (as per Savage's pubs, throwing either
		data, or acks, or - in the new discussion -
		RSTs, to force a sender to open their window
		too much and flood the net)

As has been said (someone can help with attribution or correcting the 
quote):
	Think twice before you modify TCP. Then don't.

Since the current attack is already well-handled by the use of IPsec, 
I'd like to suggest that IF TCPM is going to move forward on 'radiation 
hardening' of TCP, we do so as a concerted effort, rather than as a set 
of potentially mutually-interfering point-wise solutions.

Joe

---

From: Mitesh Dalal <[email-masked]>
Date: Fri, 23 Apr 2004 12:35:13 -0700 (PDT)

> introducing another state variable.

exactly. there are so many places in the spec that ask to
send an ACK that the above can be caused even without the new
solution (ACK was supposed to be a no cost solution for all
problems). Morever in the new solution, the packet has to be
in the window thrice in a row.

thx
Mitesh