response to ops reviewer on draft-ietf-tsvwg-tcp-eifel-alg

[Scott Bradner <sob@harvard.edu>]

>From Reiner.Ludwig@eed.ericsson.se  Tue Feb 18 06:41:39 2003
X-Sender: eedrel@mailhost.eed.ericsson.se
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 18 Feb 2003 12:41:22 +0100
To: Scott  Bradner <sob@harvard.edu>
From: Reiner Ludwig <Reiner.Ludwig@eed.ericsson.se>
Subject: Re: a comment on draft-ietf-tsvwg-tcp-eifel-alg
Cc: Michael.Meyer@eed.ericsson.se, Reiner.Ludwig@eed.ericsson.se,
   mankin@psg.com
In-Reply-To: <200302162312.h1GNCacR019881@newdev.harvard.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

I would argue against the view of the ops-dir reviewer:

* This is only a detection algorithm that does not alter TCP sender nor 
receiver state. Thus, no danger here.

* When used together with a response algorithm, e.g., 
draft-ietf-tsvwg-tcp-eifel-response-02.txt, this is a different story. I 
don't know what the reviewer means with "take out the session". But 
clearly, by manipulating ACKs at the TCP receiver or by a flow-state-aware 
box in the middle, congestion control at the TCP sender could be pretty 
much disabled. So, one could argue along the lines of the ops-dir reviewer 
when combining the Eifel Detection algorithm with a response algorithm that 
alters TCP state. On the other hand, we know (see Savage paper in ACM CCR, 
Oct. 99) that even a "standard conformant" TCP sender's congestion control 
is easily disabled. So, why be extra strict here?

This is actually a relevant issue for the mailing list. Since, if we would 
follow the ops-dir reviewer's suggestion, we raise the bar quite high also 
for the alternative schemes like F-RTO and DSACK-based schemes. Those 
should then also be comparably safe against misbehaving TCP receivers, I think.

///Reiner


At 00:12 17.02.2003, Scott  Bradner wrote:


>from an ops-dir reviewer
>
> > **** The Eifel Detection Algorithm for TCP (Experimental)
> >         <draft-ietf-tsvwg-tcp-eifel-alg-07.txt>
>
>I have read this briefly. To me this seems ok, but I am somewhat
>worried that this would open up a new type of ACK DOS as you could
>potentially guess timestamps and attack the algorithm. The 2' and 5'
>suggestions work around this, so I am (thinking out loud) if that
>should not be the default. OTH it's easier to take out the session by
>simply DoSing either the sender or the receiver...