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

[Mitesh Dalal <[e-mail]>]

On Tue, 4 May 2004, Mark Allman wrote:

>
> > I don't agree that the current proposal uses the "behavior
> > described in 793" for protection.  Responding to a RST is
> > not a correct behavior.  It is very clear in RFC 793 what
> > a RST means.  A stack can ignore the RST (pretend that the
> > RST is dropped elsewhere (-:), but responding to it is bad.
> > I think any proposal suggesting a response to a RST is not
> > acceptable to a host vendor.
>
> I agree that the proposed scheme is not rfc793 conformant.  But, I don't
> see how the last sentence above follows from the previous few.  We can
> evolve and change.  RFC793 has been and will continue to be updated.
> (I'm not arguing that the proposed change is The Way To Go, just trying
> to understand your argument.)

Here are few of my thoughts to the above discussion:

There are 2 main aspects of our solution that needs justification
as to how they may fit into the existing spec.

1. Only an exact match RST is acceptable.
(as opposed to a RST within window)

2. Sending an ACK for an in-window RST
(as opposed to aborting the connection).

The case 1 above is easy to see. An RST is unreliable and can be
dropped in the network. Hence if we drop a RST that was in window
but not an exact match, we can safely assume that it was never send.
No harm done. I believe Kacheong and others have already figured this out.

Now case 2 above:

Here is a scenario which can readily happen with base spec.  A and
B are peers in ESTAB state.  B is sendind data to A.  data 2 gets
dropped.  B has a critical failure, decides to send a RST.  sequence
number 4 is within window of A.  A sends ACKs; which are in flight
relative to RST 4, for data 1 and 3 (hence I have shown the RST
to reach A after the ACK has been sent out).  But as far as B (and the
imaginary middlebox) is concerned, it appeared later in time wrt to
RST and may have actually be triggered by the RST itself.  B has no
way of knowing this. It will ultimately send an RST with a sequence
number that was borrowed from the ACK. So, if this scenario cannot be
successfully handled by middleboxes and endhosts, it may not be able
to handle our changes as well. The point I am trying to emphasize is
sending an ACK looks totally benign and is still looks like a plausible
scenario within the semantics of the base spec.

A				  B
|<----1---2-----3--------<--------|
|				  |
|               <--RST--4---------|
|---------> ACK 1-------->	  |
|---------> ACK 1 (for 3)	  |
|<---RST-4---			  |
|				  |
| <--RST-1------------------------|


similarly for the SYN part, ACKs from A to B maybe in flight, when
a SYN lands up at A. Middleboxes and endhost have no way of knowing
if the ACK was send after the SYN was received at A or otherwise and
given the liberal principle, they will still need to act on it based
on the guidelines laid down in 793.
Further, I even hypothesize that the middleboxes on receiving the
SYN, will actually send a RST to the inside endhost and not
simply forward the SYN and hence converting the SYN scenario to
a RST scenario. If there are no middleboxes, our fix is even more
cleaner (except for the very rare scenario where the SYN carries
an ISN that matches our rcv.nxt-1)

The above logic can be extrapolated if we put in a middlebox.
Difference will be seen based on where the RST gets dropped, between
the middlebox and B or between the middlebox and A. But since both
of them have equal probability of happening, we can safely disregard
the details.

Thanks
Mitesh


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