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

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:

>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
>On Tue, 20 Apr 2004, sanjay kaniyar wrote:
>
>  
>
>>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
>>tcpm@ietf.org
>>https://www1.ietf.org/mailman/listinfo/tcpm
>>    
>>
>>
>
>  
>

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

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm