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

[Rob Sherwood <[e-mail]>]

On Thu, Mar 27, 2008 at 07:14:44PM -0400, Caitlin Bestler wrote:
> 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.

Again, I think we have missed each other's point here.  I think you are
over estimating the _frequency_ that the test need be applied.  How
often the test is applied is a local decision made by the sender, in a
trade off between efficiency and how pro-actively attackers are
detected.  My intuition as to why the test has such low over head is
that it is applied less frequently then the regular packet loss rate
(caused by congestion and the TCP saw tooth) so it does not increase
the apparent packet loss rate significantly.  Applied to your
high-speed connections, this means that the rate of notifications
between the layers would not increase significantly either.

Further, the parameters for how often the test is applied are tunable:
my experiments recommend skipping a segment once every 1-200 segments,
which, for for the machines I had available to me, seemed to be a
reasonable compromise between overhead and detection.  The higher rate
connections that you speak of may be better suited with different
parameters: skipping a segment every 1-2000 or something similar.

In short, I don't see how you can say that this solution is too
inefficient; one can reduce the overhead of the test arbitrarily ( at
the cost of reduced detection),


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

I believe that the security implications of this design are independent
of the test I've proposed here.


> 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. 


I guess this is another argument that I don't understand: you're saying
it's better to changes all applications individually than solve this in
one single place?  I agree that adding a challenge-response to all
applications would solve the problem, but it assumes modifying the
entire world several times over: all applications * all clients * all
servers.  I just don't see how that is feasible - to say nothing of
having to do a per-application analysis of what challenge response is
best for the least amount of overhead.

> And if the client was
> unwilling to provide these echoes, just limit the bandwidth that
> you will provide to them.

As I mention in my previous mail, using "each host limits the bandwidth
each connection gets", even as a fall back for compatibility, does not
stop the attack.  The attacker can simply target more victims to
generate the same aggregated amount of traffic.

> 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.

Assuming the source ISP was responsive, this might work.  But, I
contend that most operators looking at the traffic patterns would
assume that the attack was backwards, i.e., that it was the victims
targeting the attacker.  I don't believe that the actions that an
operator would be likely to take to stop the mistaken backwards attack
(blocking traffic from victim to attacker) would stop the actual
attack.  This attack works (with reduced efficiency) when the attacker
is totally blind with respect to the victims traffic.  But yes, IF the
source ISP cared, IF they detect the attack, and IF they do the right
thing by blocking the senders Acks, then the attack would stop for that
one attacker.  It just seems like a lot of "if"'s and a lot of
dependence on other people doing the right thing when it is your
network that is congested.

> 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.

At least from your description here, it would seem that they have DoS
implications independent of this test.  I will have to read up on these
issues, thank you for pointing them out.

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