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

From: "sanjay kaniyar" <[email-masked]>
Date: Wed, 21 Apr 2004 00:00:00 -0700

Section [4.2]:

I think this mitigation can be strengthened. For connections with larger 
(scaled) window sizes, the protection offered by ACK validation is quite 
minimal.

Here is a suggestion to improve upon what you have for long lived 
connections with large windows which send/receive data intermittently: 
Consider a connection between a server [S] and a client [C]. A TCP can never 
send more than a receive window worth of data in a given RTT. This can be 
used in validating the ACK number as well. Let the RTT as seen by S be 
RTT(S) and maximum receive window ever seen by S (advertised by C) be 
MaxSndWnd. Let’s assume the maximum amount of time we expect a reordered 
segment sent by C to stay in the network be N * RTT(S) (I know – it is MSL 
in theory). This means, the ACK number on a segment that S accepts should be 
between {SndMax} and {SndMax - N * MaxSndWnd}. N should be reduced by 1 each 
RTT S does not send any data on this connection, eventually becoming just 1 
byte (SndUna).

For simplicity, one could just start with [SndUna - MaxSndWnd, SndMax] and 
clamp it down to [SndUna] if the connection does not send anything for 1 
MSL.

Thanks,
Sanjay

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar – get it now! 
http://toolbar.msn.com/go/onm00200415ave/direct/01/

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

---

From: Mika Liljeberg <[email-masked]>
Date: Wed, 21 Apr 2004 21:28:10 +0300

Fast recovery and SACK already assume that the maximum reordering
distance in the network is 3 segments or less. The ack validation rule
could be specified simply as:

	[SND.UNA - N * MSS, SND.NXT], where N = 3

No need to make it too fancy.

Also, I believe SND.NXT is correct in the above. RFC793 does not
recognize SND.MAX. Backing SND.NXT to SND.UNA on retransmit is a feature
of a particular implementation, not something prescribed by RFC793.

Regards,

	MikaL

On Wed, 2004-04-21 at 10:00, sanjay kaniyar wrote:
> MaxSndWnd. Lets assume the maximum amount of time we expect a reordered 
> segment sent by C to stay in the network be N * RTT(S) (I know  it is MSL 
> FREE pop-up blocking with the new MSN Toolbar  get it now!

---

From: Anantha Ramaiah <[email-masked]>
Date: Wed, 21 Apr 2004 15:13:45 -0700

Wanted to reply to this yesterday. I agree with MikaL that SND.NXT is
correct in the proposed equation. Backing SND.NXT to SND.UNA is done in
the BSD based stacks and it is not a RFC requirement.

I am also inclined to have a fixed range for acceptability otherwise it
becomes more implementation specific. An implementation can chose to add
intelligence into it by considering the MSS and RTT etc and decide the N. 
The question then becomes should RFC recommend tha math or probably suggest 
some preferable values ?

The hard issue is chosing the value of N. It needs to be conservative 
( as any RFC is) and should accomadate various networks for eg:
the networks with high bandwidth * delay (LFN's) where assuming the 
network re-ordering distance to be 3 is kind of aggressive. 

-Anantha
Mika Liljeberg wrote:
> > MaxSndWnd. Let?s assume the maximum amount of time we expect a reordered
> > segment sent by C to stay in the network be N * RTT(S) (I know - it is MSL
> > FREE pop-up blocking with the new MSN Toolbar - get it now!

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Thu, 22 Apr 2004 06:35:20 -0500

>the BSD based stacks and it is not a RFC requirement.

Ok, I will stick with SND.NXT for the next revision...

>network re-ordering distance to be 3 is kind of aggressive. 

Hmm.. should we instead leave the current equation and
add some wording like:

"The equation given will allow for any network reordering, a
  specific implementation MAY wish to use a smaller value
  then SND.MAX."

Word smithing needed of course..

R

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