Re: [tcpm] Q&C regarding tcpsecure-09 recommendations

["Anantha Ramaiah (ananth)" <[e-mail]>]

Andre,
   Sorry about the late response, I had marked it for later response and
got to it just now. 

<snip>
   
> 
> This +-1 extension is done to accept the initial RST w/o 
> having to send a challenge ACK.  It has been observed by my 
> fellow FreeBSD developer Qing Li that certain system send the 
> RST to weird off-by-one places in either direction.
> 
> A surprisingly large number of RSTs are generated by socket 
> closes of connections that actually were in use shortly 
> before.  Depending on the exact timing of the connection 
> teardown the RST is not sent in response to some incoming 
> segment but from the tcpcb state to inform the other end of 
> the immediate termination of this connection.

Ok, but do you see the need to mention this +-1 case in the draft, since
the mitigation is the same from all the cases. Whether or not to send
the challenge ACK for the cases you mention should be treated as an
optimization and should be left to implementers choice, IMO.

<snip>

>>   This seems to be incorrectly transcribed.
> 
> Good catch, I'll change it. I thought I had removed it before.
> 
> [I think I know the reason why this = got added, this is one of the 
> corner cases which we have fixed it long back, I'll see if I can 
> remember that and post it later, in any case I don't want to fix that 
> in this draft.]
> 
> Would be great to hear about the corner case.

I'll mention this in a separate email, I need to dig up my notes since
on top of my head I am unable to construct it.

<snip>

> 
> I can only partly follow you here.  My interpretation of the 
> text in RFC793 tells us to send back a challenge-ACK to 
> re-synchronize the connection.
> Not to ACK something not yet sent.

Correct, I should have been clear : 793 tells : if you receive an ACK
for unsent data send a corrective ACK to re-sync the connection. 

<snip>

> 
> I don't doubt the extended check at all.  I'm only concerned 
> about its relationship to the ACK check in RFC793 (section 
> 3.9, page 72, fifth check, ESTABLISHED STATE, first 
> paragraph, last sentence) in two ways:
> 
>   a) tcp-secure section 5.2 essentially makes this check just 
> tighter with
>      the addition of the lower bound of (SND.UNA - 
> MAX.SND.WND).  Instead
>      of being another check (with a as of yet unclear 
> ordering relative
>      to RFC793) this one could simply replace the one from 
> RFC793.  Would
>      make the text and application of the check more clear.
> 
>   b) the change from a challenge-ACK (as my interpretation of 
> RFC793) into
>      a silent drop.


Actually I did a deeper look into the implementation what we have and we
are infact (for the same reasons) which you mention above dropping the
segment and sending the corrective ACK. 

> 
> >>   The second related issue is where this check should be placed 
> >> relative to
> >>   RFC793 ordering?  Before the fifth check, last sentence 
> (page 72) 
> >> "If the ACK
> >>   acks something not yet sent (SEG.ACK > SND.NXT) then 
> send an ACK, 
> >> drop the
> >>   segment, and return." or right after it?  This has
> > 
> > Should be before that, this is what we have tested with. Although I 
> > can't think of on top of my head what would happen if we put after 
> > that...
> 
> Then it should only test for the lower bound, not the upper one.
> Otherwise the check from RFC793 would never trigger again.  
> Everything is already filtered.

Correct. Something like this :

if (TCP_SEQ_RANGE (TCB.SNDUNA, SEG.ACK, TCB.SNDNXT) {
    // new acknowledgement, do the necessary action
} else {
    if TCP_SEQ_RANGE ((TCB.SNDUNA - max_window), SEG.ACK, TCB.SNDUNA) {
         do nothing; /* accept it */
    } else {
        discard the segment;
        send corrective ACK;  // this step is the same as what RFC is
saying today. 
    }
}

Where max_window is hardcoded to some value [ taking into account window
scaling as well]

....
....
process the segment text.

> 
> My vote goes to replacing the fifth check of RFC793.  Whether 
> to silently ignore or sending a challenge-ACK I'm still undecided.

Sure, like I said our implementation already does what you are
mentioning. We do send the corrective ACK for tcp-secure case as well.
So I have no problems mentioning that in the document. I can add this in
the document. 

Good comments, thanks!

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