Re: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?]

On Wed, Nov 21, 2007 at 02:24:54PM -0800, Anantha Ramaiah (ananth) wrote:
>  
> > 
> > I don't understand your snicker quotes around standardize.  
> > Changing a MUST NOT to a MAY or SHOULD NOT in 1122 is about 
> > as serious as standardizarion effort as one can undertake in TCPM.
> 
> Actually I asked the same question below :-) My understanding was the
> same ie., changing verbiage is indeed a standardization effort. 

That's because you're asking to change the standard.  There's no issue
of clarification here.  A conformant TCP implementation allows
connections to hold a zero window indefinitely.  Consumers of the
stack's service (OS,applications) can abort TCP connections at will.

Admittedly that's a fine distinction, but that's not necessarily a bad
thing.  It basically gives you the leeway to manage your local
resources.

> > 
> > I (personally) don't see the point of publishing an RFC that 
> > describes a technique that a conformant TCP cannot implement.
> 
> I agree. So my understanding is that wherever the solution lies, be it a
> socket option that can be set by the application OR an implicit timer
> within TCP or whatever means, irrrespective of the method chosen, this
> warrants a change in the RFC 1122 or atleast a clarification in the
> existing verbiage w.r.t zero window probes? Do you agree?

I think 1122 is perfectly clear and perfectly workable.  The TCP stack
cannot terminate those connections.  The OS or an application may.

People who wish to manage their resources in the way the authors
advocate can do it in the OS or the application.  The admitted fuzzyness
of the lines between OS and TCP stack allows a broad interpretation of
whether a given piece of code is in the OS or TCP stack.

I don't see a pressing need to change the standards to implement a
persist state killer in the OS.

> 
> If so then do we agree as a WG to make the change since this is required
> irrespective of the fact where the solution lies?

I categorically disagree.  Having your OS terminate a TCP connection
through TCP's abort interface violates no RFC that I can see.

FWIW, I think that looking for the persist state rather than resource
use and slow progress is the wrong way to select connections for abort,
but I believe that the standards allow the OS to do either.

> OR do folks in the list have some solution in mind which can be done
> without touching the standards?

I believe the author's solution violates no RFC. 

> 
> Sorry, I haven't yet seen this particular discussion happening which is
> the main purpose of my email. The only thing so far was a few people
> saying that there is no need to change RFC 1122, but I am afraid I
> haven't seen the reasons and/or alternate proposals.

The application can identify connections making slow progress when
alerted by the OS that there is resource contention, or when resource
use by the application passes a threshold.

The application can implement the authors' scheme exactly using
information from the STATUS call in RFC 793, which TCP implementations
provide.  Put it in a library so other apps can link to it.

The application can cull connections holding a zero window when the OS
alerts it to low resources.

The OS can terminate the connections with the largest memory usage in
the face of resource exhaustion.

The OS can terminate connections that have been open the longest in
times of resource contention.

The OS can terminate connections that have been open longer than a fixed
threshold.

The OS can terminate applications using a large amount of resources in
time of contentention or deadlock, terminating their connections 

> > An attacker who wanted to mount the DoS attack described in 
> > the draft could defeat your proposed mitigation by asking for 
> > the same large window and then draining it slowly rather than 
> > simply holding the zero window.  The draft mentions that the 
> > silly window avoidance makes this difficult, but it just 
> > requires the attacker to ACK an MSS worth of data less 
> > frequently then if they read a single byte.
> 
> Agreed.

Didn't you just agree that the proposed system has a simple workaround?

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG