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

[Rob Sherwood <[e-mail]>]

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