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

[<[e-mail]>]

Hi Rob,

We were under the impression that you were keen that the skipped
segments solution be implemented with SACK enabled as otherwise there is
a risk that it could delay the notification of congestion by up to 1 RTT
more. Apologies if we have got this wrong.

The condition we give in 6.2.4 that "Periodically and randomly, any
heavily loaded TCP sender SHOULD check the honesty of its receivers
using the probabilistic test." wasn't meant to imply that this was the
ONLY time a sender should test its receivers. It might be better in a
future draft to change it to something wider like: 

"Any TCP sender SHOULD check the honesty of its receivers using the
probabilistic test periodically and randomly. In particular, it would be
advantageous for any sender that is heavily loaded to identify if it is
taken advantage of by an attack by a dishonest receiver".

We would hope that senders would check at other times as well, hence the
second bullet point in section 6.2.4.

Final point, as Gavin McCullagh has already pointed out, apart from
legacy Tahoe TCP implementations a receiver can be reasonably safe if it
sends less than 3 duplicate ACKs for a missing segment as this will not
trigger fast re-transmit. Consequently we have specified that the
displacement should be at least this large.

Toby

________________________________________________________________________
____
Toby Moncaster, <[e-mail]> Networks Research Centre, BT
Research
B54/70 Adastral Park, Martlesham Heath, Ipswich, IP53RE, UK.  +44 1473
648734 


-----Original Message-----
From: Rob Sherwood [mailto:[e-mail]] 
Sent: 20 February 2007 19:37
To: Moncaster,T,Toby,CXR9 R
Cc: [e-mail]
Subject: Re: [tcpm] New I-D posted : draft-moncaster-tcpm-rcv-cheat-00

On Tue, Feb 20, 2007 at 05:27:03PM -0000, [e-mail] 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 a request made to Bob Briscoe at IETF 67. There he mentioned to 
> TVWG that we would be happy to produce a transport layer nonce to 
> protect against receivers concealing lost packets. This suggestion was

> broadly welcomed by the WG and this draft is our response. Initially 
> we intended to submit this to TSVWG as they requested it. However 
> after checking with the co-chairs of both TCPM and TSVWG it was agreed

> that TCPM would be the best forum for the draft. The draft is 
> available in various formats at 
> http://www.cs.ucl.ac.uk/staff/B.Briscoe/pubs.html#tcp-rcv-cheat.

Hi Toby,

I gave a quick read through the draft on your website, and have a few
comments.


Section 5.1) 

I think there might be some confusion here, but the skipped segment
solution that we proposed in our paper does not require the receiver
supports SACK.  Trivially, our paper presents performance results for
receivers that do and do not support SACK.  If the sender skips segment
N, any ACK > N indicates misbehavior; SACK is simply not involved for
correctness.  If SACK is not supported in the connection, then the
standard performance penalties for not implementing SACK apply, i.e.,
the receiver has to duplicate ACK each loss in turn.  Am I missing
something here?

Section 6.2.4)

"Periodically and randomly, any heavily loaded TCP sender SHOULD check
the honesty of its receivers using the probabilistic test."

I don't think it is sufficient that only heavily loaded TCP senders
perform this test.  Attackers can simply draw a small amount of traffic
from many ("jillions" to quote Mark :-) of servers, not loading any one,
but still have a large aggregate amount of traffic.  In other words, if
the solution is only applied to loaded servers, then the attack still
exists.



At a high level, I like the proposed two phase test in that it is
slightly more efficient then the randomly skipped segment test alone,
i.e., instead of honest receivers being penalized 1 RTT every test, they
are only penalized the buffer time and 1 RTT if network reordering
(pathologically?) undoes the reordering test.  It is not clear, to me at
least, how the efficiency gain weighs against the additional complexity
of code, but presumably others can comment on that.  However, my
understanding of the concern raised on this list (if I can summarize
other's opinions) was that there was a philosophical objection to
mucking up[1] the TCP code for an attack which is not being actively
exploited.
In other words, it wasn't the efficiency of the solution that was at
issue, but whether is should be applied at all.

Should people decide that this two phases approach is preferable, it
might be possible to simplify the first phase test as follows.  Rather
then reordering segments N-1,N,N+1,..,N+D to N-1,N+1,..,N+D,N as Toby
et. al suggest, it might be better to more frequently perform this test
with D=1, (i.e., simply swap the order of two sequential segments) and
after some threshold number K failures, apply the second phase randomly
skipped segment test.   I only suggest this as the analysis is probably
slightly simpler in that the reordering rate of pairs of packets have
been previously measured, where as the probability that the
N-1,N,N+1,..,N+D to N-1,N+1,..,N+D,N reordering would be undone is less
well studied.


- Rob
.

[1] "mucking up" is clearly a technical term :-)

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