Subject: RE: [tcpm] I-D ACTION:draft-ietf-tcpm-tcpsecure-00.txt

From: "sanjay kaniyar" <[email-masked]>
Date: Tue, 20 Apr 2004 19:43:20 -0700

Hello,

I read through the draft and there might be an issue with how it deals with 
one of the reconnect cases. My question is outlined below:

------------------------------------------------------------------------
Let's consider the case where we have server[S] implementing this draft
and a client[C] which is trying to connect to it and the ISS chosen by
the client happens to be the same as the next expected sequence number
on server.

[S]
Sitting in established state.
RcvNxt = x
SndUna = SndNxt = SndMax = y

[C]
comes up after a reboot,
tries to reconnect to [S] (chooses the same 4-tuple)
ISS = x
Sends a SYN (seq = x, Ack = invalid)

Follwing 3.2 (B), [S] sends back an ACK

      If the SYN bit is set and the sequence number is an exact match to
      the next expected sequence (RCV.NXT == SEG.SEQ) then send an ACK
      segment to the peer but before sending the ACK segment subtract
      one from value being acknowledged.

[S] -> [C], ACK (seq = y, Ack = x)

The segment reaches the client.

[C] follows RFC 793 - and does the following:

    If the state is SYN-SENT then
      first check the ACK bit
        If the ACK bit is set
          If SEG.ACK =< ISS, or SEG.ACK > SND.NXT, send a reset (unless
          the RST bit is set, if so drop the segment and return)
            <SEQ=SEG.ACK><CTL=RST>
          and discard the segment.  Return.

[C] -> [S], RST (seq = x, Ack = invalid)

The Reset reaches the server:

[S] follows (either 793 or the draft 2.2 [A]):

   A) If the RST bit is set and the sequence number is outside the
      expected window, silently drop the segment.

.. and drops the RST.

The client might/will retry a few times - but each time the sequence of
events is the same - and this results in a valid connect attempt from
succeeding - which would not have happened had the server followed RFC 793
processing rules.

My suggestion would be to abort the connection at [S] when ISS == RcvNxt.
That would take care of this problem while not being any easier to exploit
than just sending a RST is.

Thanks,
Sanjay

_________________________________________________________________
Get rid of annoying pop-up ads with the new MSN Toolbar – FREE! 
http://toolbar.msn.com/go/onm00200414ave/direct/01/

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

---

From: Anantha Ramaiah <[email-masked]>
Date: Tue, 20 Apr 2004 21:35:28 -0700 (PDT)

Sanjay,
      Randall can answer this but we thought about this case it is
one of the *real corner cases* Good eye :)

Actually B could be reworded as :

C) If the SYN bit is set and the sequence number(isn) is one less then the
next expected sequence (RCV.NXT) then send an ACK segment with the peer
but subtracting one from RCV.NXT. to the peer.
        ie SEG.SEQ = (RCV.NXT - 1)

By sending a ACK that is less than the RCV.NXT value in case of a spoofed
segment the true peer will drop the ACK as an old duplicate. The restart
case also gets satisfied and the reset would be sent back!

Most of the TCP stacks treat (RCV.NXT - 1) as an RST of a keepalive packet
and would accept that. Hmm.. we may have a corner case here in case if
the RST gets dropped because of outside window.

Also the suggestion of sending the RST for an exact match (SEG.SEQ =
TCB.RCVNXT) was thought about, but the idea to squeeze as much as possible
to make the attacker's life harder.. Probably needs more thought to
address this corner case.

Randall and Mitesh may have more comments here..

-Anantha

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Wed, 21 Apr 2004 10:59:37 -0500

Anantha:

I agree with you... we need to fix this... but also
it may not even be worth the extra code to check
these conditions and generate a ACK accordingly.. it
is a real real corner case...

R

Anantha Ramaiah wrote:

>>Get rid of annoying pop-up ads with the new MSN Toolbar ? FREE!

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