RE: [tcpm] New I-D posted : draft-moncaster-tcpm-rcv-cheat-00

Hi Michael.

Just to clarify, I was not talking about the ECN nonce which, as you
rightly say, is intended to address a different problem (the concealing
of ECN marks). I was actually referring to a solution presented by
Stefan Savage et al in the paper "TCP Congestion Control with a
Misbehaving Receiver". In this paper they present two versions of a
transport layer nonce which they call the "Singular Nonce" and
"Cumulative Nonce". We do look at the ECN nonce in the actual draft
since that claims to protect against the two attacks our test is
designed to identify.

Thanks for the pointer as to the slightly surprising wording in RFC2581.
As far as I can tell everyone seems to assume this was a MUST anyway...!

Toby

________________________________________________________________________
____
Toby Moncaster, <toby.moncaster@bt.com> Networks Research Centre, BT
Research
B54/70 Adastral Park, Martlesham Heath, Ipswich, IP53RE, UK.  +44 1473
648734 

-----Original Message-----
From: Michael Welzl [mailto:michael.welzl@uibk.ac.at] 
Sent: 21 February 2007 07:56
To: tcpm@ietf.org; Moncaster,T,Toby,CXR9 R
Subject: Re: [tcpm] New I-D posted : draft-moncaster-tcpm-rcv-cheat-00

On Tue, 2007-02-20 at 17:27 +0000, toby.moncaster@bt.com wrote:
> All,
> 
> As you will shortly see we have just posted a new ID called "A  TCP 
> Test To Allow Senders to Identify Receiver Cheating"
> draft-moncaster-tcpm-rcv-cheat-00. This draft was written as a result 
> of
> (..)
> http://www.cs.ucl.ac.uk/staff/B.Briscoe/pubs.html#tcp-rcv-cheat.
> 
> After some background research we decided that an actual nonce would 
> probably be impractical since it would require modifications to both

If you're referring to the ECN nonce, I think that it's not fair to
compare this with it (as you also do in the draft), as it additionally
tackles a different problem: concealing the reception of an ECN mark is
much easier to do / less problematic than optimistic acking / concealing
packet loss, and this is what the ECN nonce does but your scheme
doesn't.

On a side note, the following statement in the draft:

> The proposed solution depends, like the skipped segments solution, on 
> the strict requirement that all TCP receivers have to send a duplicate

> acknowledgement as soon as they receive an out-of-order segment.

is at odds with RFC 2581, which says:

> Out-of-order data segments SHOULD be acknowledged immediately, in 
> order to accelerate loss recovery.

...although I wonder why this is only a SHOULD, and not a MUST, and
herewith suggest to change this in 2581bis, unless there's a good reason
not to do so.

Cheers,
Michael

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