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

[<[e-mail]>]

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.

After some background research we decided that an actual nonce would
probably be impractical since it would require modifications to both
sender and receiver. This would make it very hard to enforce as the
receiver could simply pretend to be a legacy one that didn't support the
new nonce. We were keen that our system should be robust and should
require the receiver simply to behave as mandated by the existing TCP
protocols. Indeed the idea was that the solution should actually
leverage the existing TCP behaviours in order to test the honesty of the
receiver. We decided to base our new solution on a solution by Rob
Sherwood et al presented in "Misbehaving TCP receivers can cause
Internet-wide congestion collapse". Their solution, called the randomly
skipped segments solution, suggests purposely removing a segment from
the transmitted data stream and only transmitting it after the receiver
sends a NACK for that segment. If in the meantime the receiver sends an
ACK for a later segment then they are deemed to be behaving dishonestly.

A recent thread on the TCPM mailing list (starting 11th January 2007
"DoS attack from misbehaving receivers") has been discussing the
randomly skipped segments solution in some detail and reveals that there
is a lot of unease about such a test. Our solution is hopefully more
palatable and consists of 2 stages. In the first stage we
probabilistically test the honesty of a receiver. To do this we select a
segment N and a displacement D. Instead of transmitting segments N-1, N,
N+1, N+2, etc we transmit N-1, N+1, N+2, ..., N+D, N, ... An honest TCP
receiver should respond to this missing data by generating a stream of
duplicate ACKs for segment N-1. Any receiver that doesn't do so is
probably behaving dishonestly but, because TCP doesn't guarantee
reliable delivery of ACKs we can't state this for certain. We therefore
state that any receiver that fails this test should be subjected to a
further test that is essentially the same as the Sherwood test. It is
felt that the first test causes minimal damage to an honest receiver and
is essentially compliant with the TCP protocol. The second test is then
reserved for those receivers that we are pretty certain are behaving
dishonestly. We have currently left it up to the community to decide how
to sanction any receiver that fails the second test. We suggest the
appropriate response might be to terminate the connection but others
might instead feel that other sanctions such as reducing the congestion
window and slow start threshold to 1 would be more appropriate.

Both our tests force accurate reporting of losses which was our initial
aim. They also both make it much harder for a receiver to optimistically
ACK data which is an added benefit given the possible harm such
optimistic ACKs might cause.

We will be presenting this at IETF 68 in Prague and would welcome any
comments from people as to the utility of our solution and any
improvements that could be made.

Toby Moncaster 
Future Communications Architecture
Networks Research Centre
BT Group Chief Technology Office
_________________________________________________
t: (+44) (0) 1473 648734
m: (+44) (0) 7764 185416 
________________________________________________________________________
___

Notice: This contribution is the personal view of the author and does
not necessarily reflect the technical nor commercial direction of BT
plc.


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