Re: [tcpm] PoC for draft-moncaster-tcpm-rcv-cheat-02

> -----Original Message-----
> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf
Of
> Rob Sherwood
> Sent: Wednesday, March 26, 2008 1:25 PM
> To: Jakob Heitz
> Cc: tcpm@ietf.org
> Subject: Re: [tcpm] PoC for draft-moncaster-tcpm-rcv-cheat-02
> 
> On Wed, Mar 26, 2008 at 01:05:27PM -0700, Jakob Heitz wrote:
> > Intentionally dropping segments at the sender
> > has an unacceptable negative impact on honest
> > connections. No wonder this never flew.
> 
> My experiments have show this to be a <0.01% impact on perfomance and
> no impact on correctness.  You might argue that my experiments do not
> have a wide deployment and might depend on network conditions, but I
> don't know why you say the solution is "unacceptable".
> 

As a *test* described in an informational RFC there is no real 
problem with it. As a routine counter-measure it would have
severe problems.

On very high speed links the NIC and/or driver has very little
choice but to implement one or more strategies to reduce the number
of interactions with the TCP consumer. Delivering each TCP segment
as soon as it is deliverable is not a viable option.

These techniques could include interrupt coalescing, Large Receive
Offload, TCP offload and others. Large Receive Offload in particular
will be negatively impacted whenever the TCP sender does not faithfully
send entire  messages in order and as promptly as the TCP congestion
control algorithms expect. LRO seeks to reduce the number of distinct
notifications required to deliver a sequence of TCP Segments for the
same connection, but in a manner that minimizes latency delays.

When a gap indicates a lost packet the answer is simple, aggregate
what you have and deliver it. When a gap really means that the sender
is testing you then you still aggregate what you have and deliver it.
And then deliver the deliberately mis-ordered segment separately.

So the issue is not just the memory resources, but the number of
distinct inter-layer notifications required, the number of times
that a context switch between TCBs is required and the number of
times a user context is switched. These all have a negative impact
on not only memory usage, but memory bandwidth and cache efficiency.

Indeed, if a sender engaged in deliberate TCP segment misordering
on a regular basis it could be considered a Denial-of-service attack.

This is something that can very easily be solved at the application
layer, by simply requiring the application layer to periodically
echo an application layer cookie back to the sender. A trivial AJAX
script could handle this without a single change to the TCP layer.
Using timestamps would also probably work. And if the client was
unwilling to provide these echoes, just limit the bandwidth that
you will provide to them.

As for the "network" implications, this attack is a very poor 
candidate for a successful DoS attack because it requires the
attacker to saturate a link that actually leads to them. The
pattern of the attack would be easily detected, and once detected
the destination IP address is easily traceable.

Work in the IEEE's Data Center Bridging task group should lead to 
reduction or elimination of congestion drops within IP subnets.
That means that TCP handling optimizations in NICs, drivers or
TCP stacks that expect in-order delivery will be even more effective.

The NICs and Bridges supporting these techniques will be going through
a lot of extra work to provide largely lossless and in-order delivery
of TCP segments. Deliberately sending them in the wrong order borders
on being ungrateful.

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