Subject: Re: [tcpm] Is this a problem?

From: MURALI BASHYAM <[email-masked]>
Date: Tue, 20 Nov 2007 00:07:21 -0800 (PST)

----- Original Message ----
From: Mark Allman <[email-masked]>
To: MURALI BASHYAM <[email-masked]>
Cc: John Heffner <[email-masked]>; Mahesh Jethanandani <[email-masked]>; [email-masked]
Sent: Monday, November 19, 2007 12:49:19 PM
Subject: Re: [tcpm] Is this a problem? 

> The problem directly stems from TCP's choice to persist
> indefinitely. It seems a very simple notion of allowing the
> application to be the master here (borrowing Joe's words :-)), and
> providing a ceiling on how long this behaviour will continue. This is
> fully in spirit with how the other TCP timers have evolved and added
> over the years. Now this alone does not address the requirements of a
> co-ordinated distributed DOS attack, but the point here is how long
> the connection should be allowed to (re)try sending data is purely an
> *application* decision i.e it MUST be under application control. It's
> a bad design to have an indefinite retry like this in the transport
> layer without providing an override to the app.  

I don't follow this line of thinking.  Let's see ...

  + I don't know where we have added standard timers to TCP except
 where
    we have to (e.g., for time-wait or something).  We basically add
    timers when the only things we can count on is the passage of time.

  + It doesn't seem to me a problem that a connection does this persist
    business indefinitely because both ends are consenting.  It isn't
    like one end is silent or going away.

  + The application *is* in control.  The application can close a
    connection whenever it wants to close a connection.  Giving it a
 way
    to tell TCP when to kill a connection is a distinction without a
    difference. 

Merely closing a connection does not accomplish things, the FIN will simply get
queued behind existing data. What's required is an abort here for termination. But 
abort is a drastic action for the application which it cannot issue w/o some sort of explicit
feedback from TCP...

I don't think you answered my question in any way.  Why do we have to
standardize this?  It seems to me that if some server wants to
 implement
a policy that says "a connection can stay in zero window persist for 60
seconds" then great.  Fine.  I don't care.  Might work fine for the use
case of that server.  Might cause problems for its connections.  But,
 if
that is its policy then wonderful.  Who am I to say that is right or
wrong?  Change the policy and all that still applies.  Seems perfectly
consistent with lots of other things ....

When and how does the application know that the connection entered and exited
the persist condition? Where is the required feedback here? I am not aware of any...
It seems like we are exporting a TCP specific state and knowledge all the way into the 
application to accomplish what seems a simple matter of starting a timer on entry into
persist condition, stop on exit, abort on timeout (if specified by application). 

  E.g., who am I to say which SYNs a TCP should accept?  If they are
  from "bad" IPs and I want to drop them on the floor who are you to
  tell me I am wrong?

  E.g., who am I to say how many retransmits you should conduct before
  determining the peer is somehow gone and you give up?

Why does this persist stuff need to be done in a standard fashion?

Because zero window is a transport layer notion, and it is the responsibility of the transport
layer to provide a robust and fair solution to this issue which benefits ALL applications instantaneously, 
at least that's the way i view it. Why does congestion control require standardization, when every 
client/server application out there is perfectly capable of doing it?  To achieve consistent behaviour
across the widest range of applications...

allman

      ____________________________________________________________________________________
Be a better pen pal. 
Text or chat with friends inside Yahoo! Mail. See how.  http://overview.mail.yahoo.com/

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

---

From: Mark Allman <[email-masked]>
Date: Tue, 20 Nov 2007 07:12:38 -0500

(hat off, clearly)

> Merely closing a connection does not accomplish things, the FIN will
> simply get queued behind existing data. What's required is an abort
> here for termination. 

Yes- sorry for being overly glib in my language in the last bullet.  You
are right ... abort, not close.

> But abort is a drastic action for the application which it cannot
> issue w/o some sort of explicit feedback from TCP...

I don't think so.  I think applications care about getting data through
the network.  If they can't do it then they abort regardless.  This has
been said better by others, however.  I recognize that we disagree here.

> > implement a policy that says "a connection can stay in zero window
> > persist for 60 seconds" then great.  Fine.  I don't care.  Might work
> > fine for the use case of that server.  Might cause problems for its
> > connections.  But, if that is its policy then wonderful.  Who am I to
> > say that is right or wrong?  Change the policy and all that still
> > applies.  Seems perfectly consistent with lots of other things ....
> 
> When and how does the application know that the connection entered and
> exited the persist condition? Where is the required feedback here? I
> am not aware of any...  It seems like we are exporting a TCP specific
> state and knowledge all the way into the application to accomplish
> what seems a simple matter of starting a timer on entry into persist
> condition, stop on exit, abort on timeout (if specified by
> application).

I should have been more careful.  I was thinking of this policy as a TCP
or OS-level policy.  Certainly it could be in the app, too---regardless
of whether the app knows exactly why it has not made progress over some
timescale that it cares about.  Again, this is about *where* to
standardize something and this has been argued better by others.  I am
more interested in the question of whether we even need to have the
"where?" argument because I don't think we need to standardize it
anywhere.  (See below.)

> >   E.g., who am I to say how many retransmits you should conduct
> >   before determining the peer is somehow gone and you give up?
> > 
> Because zero window is a transport layer notion, and it is the
> responsibility of the transport layer to provide a robust and fair
> solution to this issue which benefits ALL applications
> instantaneously, at least that's the way i view it. 

My view is that there need not be one true notion of "robust and fair".
Why should their be?

> Why does congestion control require standardization, when every
> client/server application out there is perfectly capable of doing it?
> To achieve consistent behaviour across the widest range of
> applications...

I think this is a complete mis-characterization.  The answer is that
congestion control is standardized because congestion control is about
dealing with a *shared resource*.  We can do that control from a number
of places in the stack and people have advocated for each of them at
different points.  But, *where* that functionality exists is a second
question after we establish that the functionality needs to exist and we
need to standardize on it.  This persist business is not about
controlling a shared resource, but about controlling a *local
resource*.  Why should the community standardize local resource control?
That seems absurd to me.  So, to me, arguing about where to mitigate the
persist stuff is putting the cart before the horse.  First, we'd need to
establish some reason to standardize local resource control.

allman

---

From: Lloyd Wood <[email-masked]>
Date: Tue, 20 Nov 2007 22:01:07 +0000

>resource*.  Why should the community standardize local resource control?

The community standardised TCP window size advertisements. That's a local resource control issue, surely?

>establish some reason to standardize local resource control.

because it's useful?

L.

Saratoga: http://www.ee.surrey.ac.uk/Personal/L.Wood/dtn/

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

---

From: Joe Touch <[email-masked]>
Date: Tue, 20 Nov 2007 16:01:21 -0800

> The community standardised TCP window size advertisements. That's a local resource control issue, surely?

That's something you have to tell the other end, i.e., it requires a
change to the protocol on the wire. This one can be implemented without
any change to the protocol at all - entirely at the app layer.

>> establish some reason to standardize local resource control.

Useful is a fine metric for a new protocol, not for mucking with such a
ubiquitous and established one unnecessarily, IMO.

Joe

---

From: Mark Allman <[email-masked]>
Date: Tue, 20 Nov 2007 18:10:00 -0500

Lloyd-

> >congestion control is standardized because congestion control is
> >about dealing with a *shared resource*.  We can do that control from
> >a number of places in the stack and people have advocated for each of
> >them at different points.  But, *where* that functionality exists is
> >a second question after we establish that the functionality needs to
> >exist and we need to standardize on it.  This persist business is not
> >about controlling a shared resource, but about controlling a *local

The community has not standardized TCP window size advertisements.  And,
you know it.  The community has standardized an encoding to allow the
end points of a TCP connection to exchange information.  What is your
point?

> >That seems absurd to me.  So, to me, arguing about where to mitigate
> >the persist stuff is putting the cart before the horse.  First, we'd
> >need to establish some reason to standardize local resource control.
> 
> because it's useful?

We disagree on that point.  I certainly can understand that connections
consume local resources and this is something that a system (OS, TCP,
app, whatever) will want to control.  But, I don't agree that we can
determine one global definition of "useful" local resource control that
will hold for everyone.  Should we tell Cisco how to allocate socket
buffers while we're at it?

allman

---

From: Chandrashekhar Appanna <[email-masked]>
Date: Tue, 20 Nov 2007 16:44:27 -0800

> any change to the protocol at all - entirely at the app layer.

  And I think the authors are positioning that there is a better place in
  the architecture to solve this and that is in tcp. I think it is boiling
  down to just a matter of opinions so far.. esp when you keep repeating
  that it could be solved in the app layer (for as long as I recall!!)

> ubiquitous and established one unnecessarily, IMO.

  I do not understand that line of reasoning at all.. I think the point
  was that it could be useful to tcp.. not to some new protocol. I think
  the discussion has to be around that point only.. last I checked this
  was the tcp m mailing list.

  -
  Chandra.

---

From: Ethan Blanton <[email-masked]>
Date: Tue, 20 Nov 2007 20:11:05 -0500

Chandrashekhar Appanna spake unto us the following wisdom:
> And I think the authors are positioning that there is a better place
> in the architecture to solve this and that is in tcp. I think it is
> boiling down to just a matter of opinions so far.. esp when you keep
> repeating that it could be solved in the app layer (for as long as I
> recall!!)

Joe keeps making this point because it is _very important_.  Any
feature which can be accomplished at Layer N can be accomplished at
Layer N - 1, and vice-versa.  However, the Internet protocols have
enjoyed tremendous success and longevity in part because they resist
the urge to push application and other high-layer semantics into the
lower layers.

> was the tcp m mailing list.

"Unnecessarily" is an important word in that statement, which you did
not address.  The question has never been "can this be done in TCP",
it is rather, "should this be done in TCP?"

For my own part, I have not yet seen a reason why application layer
timeouts are not a reasonable solution to this problem, or even the
_correct_ solution to this problem, because only the application knows
how much progress is "sufficient" progress, and as such I cannot see
driving this feature into the TCP _standards_.  I also, however, see
no reason why some particular TCP stack could not provide a socket
tunable for persist timeout, if sufficient userspace demand were
present.

Ethan

-- 
The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
		-- Cesare Beccaria, "On Crimes and Punishments", 1764
_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 20 Nov 2007 17:48:25 -0800

> the urge to push application and other high-layer semantics into the
But  in case of congestion control it was felt that it would be done 
better in TCP. Why? After all nothing stopped applications from 
implementing congestion control.
> tunable for persist timeout, if sufficient userspace demand were
We give reasons as to why a timeout in application will not work. For 
one, a fixed timeout is easy to defeat. If you are not proposing a fixed 
timeout, what kind of timeout are you proposing? Is it going to be based 
on that applications view of how many buffers it is holding on to? What 
if that application is not the problem, but some other application is? 
What if the other application does not even bother about connections in 
persist condition.

The problem is also that the resources in question are TCP resources and 
applications have a snapshot of the problem from their connection point 
of view. They do not see the problem that TCP is seeing.

---

From: Joe Touch <[email-masked]>
Date: Tue, 20 Nov 2007 17:57:20 -0800

> On Tue, Nov 20, 2007 at 04:01:21PM -0800, Joe Touch wrote:
...
>   that it could be solved in the app layer (for as long as I recall!!)

First, the argument above is that this is like standardizing TCP window
advertisements.

Second, the original argument was that this wasn't solvable at the app
layer.

The rationale changes and the arguments persists. That's useful to note, IMO

>   was that it could be useful to tcp.. not to some new protocol.

TCP doesn't need this; users do. TCP doesn't care about hanging around -
or transmitting data very slowly. Some people call both a feature.

Joe

---

From: Ethan Blanton <[email-masked]>
Date: Tue, 20 Nov 2007 21:42:26 -0500

> implementing congestion control.

This has been answered several times; it's not clear to me that you
are actually reading the responses to your emails.

Congestion control is important for the preservation _shared
resources_.  Mistakes in congestion control lead to problems on
somebody else's network.  The timer you are asking for is a change
which affects only _local resources_, and its disposition will have
little or no effect on others.  Congestion control was determined, by
the community, to be both important and tricky enough that it should
be solveld in one place (or a very small number of places), and shared
among applications.  It appears that there is not consensus that a
persist timer tunable has impact which is anywhere near similar.

If you are trying to suggest that stale sockets in zero window probing
are anywhere near the impact of congestion control, I find your
argument disingenuous.

> What if the other application does not even bother about connections in 

I don't follow this, for several reasons.  What do you mean, a fixed
timeout is easy to defeat?  You're *asking* for a timeout which can be
set on zero window probing, are you not?  Regarding your final
statement, are you suggesting that application A should be able to
tell the operating system that application B's sockets should time out
if they are in a persist state?  None of this makes any sense to me.

> of view. They do not see the problem that TCP is seeing.

We fundamentally disagree on this; Joe pointed out that you _can_
indeed know whether or not a TCP connection is open or closed, by way
of blocking calls and appropriate twiddling of SO_LINGER.  The
application therefore knows exactly how many sockets it is using, and
can be tuned appropriately.  I don't see what you think kernel space
can accomplish, that user space cannot.

Ethan

---

From: Chandrashekhar Appanna <[email-masked]>
Date: Tue, 20 Nov 2007 19:14:10 -0800

> the urge to push application and other high-layer semantics into the

  And still it is a matter of opinion as to which layer should have what
  beyond a point of debate. Lot of the current model has also historical
  significance that we try to justify now with good language and architecture.
  But I do not disagree with your point but the repetition, to me, means that
  we are stuck at a stalemate and that is not interesting..

> not address.  The question has never been "can this be done in TCP",

  I think useful to me is still a fine metric even for tcp and therefore
  I stopped there.

  0.02,
  Chandra.

---

From: Mark Allman <[email-masked]>
Date: Tue, 20 Nov 2007 23:59:35 -0500

>   And still it is a matter of opinion as to which layer should have
>   what beyond a point of debate. Lot of the current model has also
>   historical significance that we try to justify now with good
>   language and architecture.  But I do not disagree with your point
>   but the repetition, to me, means that we are stuck at a stalemate
>   and that is not interesting..

I agree with both Ethan's notes about the principles behind the
decisions.  But, I think you are right that there is also an element of
design style to these decisions.

What I really want to do here is to agree with your last bit.  We are
spinning here.  It is not the first time we have gone in circles on this
draft.  As far as I can tell this document has nearly no support in this
WG.  I don't want to cut-off discussion if folks have something new to
add.  But, most of the stuff (mine included) posted is just re-hash.
So, I would like to ask folks to quit saying what they have said before.
New points are welcome.  OK?

allman

---

From: Lloyd Wood <[email-masked]>
Date: Wed, 21 Nov 2007 05:17:54 +0000

>The rationale changes and the arguments persists. That's useful to note, IMO

Joe,

you appear to be confusing me with an author of the draft in question - and confusing my question about window advertisements (which indicate to the other end how it can usefully make use of what is essentially a local resource) for some change in rationale on behalf of the draft authors.

You owe the draft authors and me apologies.

L.

---

From: Lloyd Wood <[email-masked]>
Date: Wed, 21 Nov 2007 05:46:12 +0000

At Tuesday 20/11/2007 18:10 -0500, Mark Allman wrote:
>The community has not standardized TCP window size advertisements. 

okay, e.g. RFC3390 and RFC2581 are marked standards-_track_. But those implicitly suggest how you are expected to have local resources available (congestion/loss window buffer) to meet communication conventions for shared use for a shared goal - communication. (Hmm, indicating when one side should stop communicating doesn't really fit in with the shared goal of communication.)

At what point does a resource stop being shared and start being local (or vice versa)? It seems a bit fuzzy to me.

L.

---

From: Joe Touch <[email-masked]>
Date: Tue, 20 Nov 2007 22:40:26 -0800

Lloyd Wood wrote:
> you appear to be confusing me with an author of the draft in question

Lloyd,

I was not. I was explaining my response above.

> - and confusing my question about window advertisements (which indicate
> to the other end how it can usefully make use of what is essentially a
> local resource) for some change in rationale on behalf of the draft authors.

I was explaining that the authors have changed their rationale;
originally, it was needed in TCP because that was the only way to solve
the problem. I was not asserting that you were creating a new rationale
or changing one.

As to window advertisements, as I noted above, that is a property that
one end communicates to the other. It isn't of purely local impact.

Joe

---

From: Lloyd Wood <[email-masked]>
Date: Wed, 21 Nov 2007 06:55:11 +0000

At Tuesday 20/11/2007 20:11 -0500, Ethan Blanton wrote:

>Layer N - 1, and vice-versa.  

One obvious exception: end-to-end reliabililty.

Another: error-coding for the channel.

L.

---

From: Jakob Heitz <[email-masked]>
Date: Tue, 20 Nov 2007 23:13:13 -0800

RFC2581 specifies behaviour of a host to protect
the network. This is in the interest of all network
users, thus subject to standardization.

The problem of the subject line is a problem of one
host, the solution to which is confined to that
same host. The solution does not affect the network
and requires no change in behaviour of any other
host on the network. Thus it is not subject to
standardization by a network standards body.

The fact that a host chooses to implement TCP in
something it calls a "kernel" is a private matter
of that host and nothing that the rest of the network
is the least bit interested in.

Any host is free to fix this problem with something
it might call a "socket option" or anything else
without violating any IETF standards, nor requiring
any blessing of the IETF.

The IETF does not say that you must keep all TCP
connections alive if you run out of resources,
does it?

---

From: Ethan Blanton <[email-masked]>
Date: Wed, 21 Nov 2007 09:23:47 -0500

> Another: error-coding for the channel.

Not to digress, but ... I think this makes the argument beautifully.
Either of these *can* be handled at any layer, but we obviously agree
that it's a Bad Idea to push these all the way down to the MAC layer.
There is nothing magical about layering, that says "a protocol can
only work if layered".  Separation of concerns simply makes the model
easier to grasp, and easier to Get Right.

We could do end-to-end flow control, reliability, and link
error-coding all in Layer 1 (or Layer 2, depending on which way you
want to push), but we don't, and for a very good reason.

Ethan

---

From: Chandrashekhar Appanna <[email-masked]>
Date: Wed, 21 Nov 2007 08:46:38 -0800

> New points are welcome.  OK?

  My opinion is that this draft deserves a presentation and discussion
  at some IETF.

  0.02,
  Chandra.

---

From: Ted Faber <[email-masked]>
Date: Wed, 21 Nov 2007 09:14:15 -0800

> want to push), but we don't, and for a very good reason.

[hat off]

I think that any layer that can accomplish end-to-end reliability is
a transport layer by definition.

A link layer capable of end-to-end retransmission (say) is inherently
reaching beyond the link.  You could call such a layer a link layer, but
the presence of an end-to-end mechanism makes it a transport layer to
me.

I actually think your functionality statement is a little backward -
anything you can do at layer N, you can do above at layer N+1.  That's
because the information to implement the new feature is potentially
available from the lower layers.  An application can implement
end-to-end reliability because the end-to-end structures/concepts are
created by the transport.

Implementing at layer N+1 also assumes that there's no implementation of
the functionality at layer N that will interfere with your design.
Implementing a retransmission strategy above TCP is fraught with peril.

Perhaps that's a way to reframe this discussion.  It's possible to
constrain TCP to provide this timer.  Are we sure that it's worth it in
terms of additional complexity in TCP and constraints on other
application resource management strategies?

-- 
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
_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Ted Faber <[email-masked]>
Date: Wed, 21 Nov 2007 09:32:49 -0800

Speaking as myself:

On Wed, Nov 21, 2007 at 05:46:12AM +0000, Lloyd Wood wrote:
> At what point does a resource stop being shared and start being local
> (or vice versa)? It seems a bit fuzzy to me.

So, one can make these waters pretty deep.  Communication resources are
shared at some level just because they're being used to swap data
between hosts.  I wouldn't be using a TCP buffer if I wasn't talking to
anyone else, and using it to talk to you precludes me from using it to
talk to Mark.  They are all shared resources.  However for scalability
and convenience, they're all locally administered.  The power to destroy
a thing ...

TCP standards (by and large) recognize that split and are pretty quiet
on how routers and end hosts do the administration.   That's a feature,
IMHO.  TCP standards don't tell hardware designers/application writers
how to make the optimal use of their resources; the standards keep them
from breaking the protocol.  Mostly.

Again, as myself, I prefer to let the TCP standards proscribe resource
allocation systems that breaks the protocol (not applications) rather
than require resource allocation systems that optimize some use of the
protocol.  Even extremely prevalent uses.

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Wed, 21 Nov 2007 10:12:44 -0800

I managed to read all the responses so far on this thread. At the time
of writing this email, there have been 54 email exchanges (includes the
authors' responses) around 9 people have responded so far not counting
the private email exchanges. In order to prevent rat-holing this further
I would like to step back a little and pose the following questions :-

A) Do we agree that it is a problem ? [the title of the thread]

   Most people seem to agree on this.

B) Do we think this is an issue to be dealt at the transport layer?

   Here there seems to be mixed reaction. Granted that there may be many
people feeling that this is an application issue and not a transport
issue.

Now expanding on B), 

Now the draft is talking about 2 things actually 3 things.

1) It is asking to correct/clarify the verbiage of RFC 1122. ie., RFC
1122 tells the connections MUST persist forever as long as ACK's are
received. Now, clearly as demonstrated in the draft, there needs to be
some ammount of robustness that can be built into the TCP layer, which
can allow the connection to be aborted after some stipulated time. Is
this considered a change in the standards? 

2) The draft also outlines a solution that can be helpful to deal when a
particular host is compromised with malicious intent. Agreed this may
not be the only solution possible, but it is one such. This purely falls
into "INFORMATIONAL" category. There is no TCP protocol change, it is
upto the implementation to chose an algorithm of choice. I think the
majority of the objection so far seems to be w.r.t point : "why TCP
layer should be responsible for resource allocation shemes"?  Again, I
think this is merely a suggestion and some implementations can chose to
implement it that way, there is no need to standardize this.

3) It also DOES mention about the application's role. Ie., in particular
it suggests the following :- 
   "Applications can assist TCP's role in solving this problem.  They
can
   register for an event notification when the TCP connection enters or
   exits persist condition.  They can use the notification mechanism to
   implement their own scheme of deciding which persist connections to
   clear.  They can also suggest timeout or retry values to TCP."

This only proves that the draft indeed does mention about application's
role in assisiting the problem. Again the above purely falls into
"informational" category.

So, in summary : Clearly 1) above calls for some change in existing TCP
behaviour. So even though it is not strictly "on the wire" change ( like
someone was pointing out) it is a change to the TCP standards. Now, why
can't TCP be made robust which would help to address situations like
this documented in the draft?  Is there a resistance to change the RFC
1122 verbiage even though it is helpful to do so? It is matter a
providing a new timer in TCP ( I think Ted menioned it in one his
emails)

2) and 3)  doesn't need any change to the standards. They illustrate the
problem and provide solutions and suggestions.

Given that there seems to be an agreement that this is a problem, the
way I look at is 1) above calls for a change in the standards. 2) and 3)
are more informational purpose only.

FWIW, the current "intended status" of the draft stands as
informational. 

Thoughts/comments? Esp. there seems to to be some scope on re-wording
some sections of the draft to make the case more explicit, if that
helps?

-Anantha

---

From: Joe Touch <[email-masked]>
Date: Wed, 21 Nov 2007 10:58:42 -0800

I think it would be very useful to highlight the problem and provide
information on how to solve it at the application layer in an
informational RFC. I'd suggest it'd be useful to include very specific
examples, e.g., with socket options, to show a potential mechanism. I
also think the doc should include a discussion of making slow progress
as related to this issue, and potentially a similar DOS opportunity.

I don't think the doc should change 1122's text; IMO, TCP isn't the one
who ought to make this decision, thus TCP ought to hang out as long as
the application lets it.

I don't think the doc should mention whether the timer should be
embedded in TCP as an implementation decision. IMO, that crosses into a
TCP mod, and since it isn't absolutely necessary, I don't see a reason
to do so there. I do think it would be more useful to give the example
of putting this in the kernel as a shared mechanism, with discussion to
motivate it.

Finally, if this is an informational RFC and the solution is soley at
the app layer, it ought to be taken to TSVWG, rather than in TCPM. I
don't consider this a downgrading, but rather to gain a wider audience
for a very real issue.

Joe

---

From: Ted Faber <[email-masked]>
Date: Wed, 21 Nov 2007 11:29:01 -0800

I haven't spoken to Mark about this, so this is me speaking for myself.

> people feeling that this is an application issue and not a transport

That's not my assessment.

It looks to me that there is considerable resistance to standardizing 
the proposed solution, both on the grounds of placement in the stack and
on the limitations of the solution.  

[ For example, connections that advertise a large initial window and then
read a byte every (proposed timer size -1) seconds will replicate the
problem in the limit. Using timers alone penalizes stopped connections
when there is no resource shortage. ]

Despite the fairly lively discussion, I have seen little support for
standardizing this mechanism in TCP, outside the authors and their
collaborators, and strong resistance from the members of the WG.  

Again, I'm not assessing consensus officially here, but that's how I see
it.

---

From: John Heffner <[email-masked]>
Date: Wed, 21 Nov 2007 14:51:54 -0500

>    Most people seem to agree on this.

I would like to step back even further, and work on the definition of 
"it" -- the problem we want to solve.  In my mail on Nov 14 (which did 
not elicit a response), I tried to make the case that the issues framed 
in the draft are in fact only a special case of a more general problem.

I do not believe the indefinite nature of TCP's persist state is 
intrinsically something we need to fix -- in fact, it is clearly an 
important and useful feature of TCP.  It might not be terrible for a TCP 
implementation to provide a switch for an implicit ABORT after a long 
persist timeout.  However, in my opinion this is not the best solution, 
or even a solution at all to the more general problem.

I think if consensus can be reached on what the problem actually *is*, 
it may be more clear how to solve it, where the solution should go, and 
if this is something the IETF should take on.

   -John

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Wed, 21 Nov 2007 12:22:27 -0800

> >    Here there seems to be mixed reaction. Granted that there may be 
> > many people feeling that this is an application issue and not a 
> > transport issue.
> 

Ok.

> 
> It looks to me that there is considerable resistance to 
> standardizing the proposed solution, both on the grounds of 
> placement in the stack and on the limitations of the solution.  

Ok. That is the reason I pointed that, I believe the draft is not trying
to "standardize" the solution part and that is informational and
illustrational purpose only. It also mentions about the role of the
application, which is again needed to be treated as informational. Do
you see the need for making further clarifications that would make this
look better?.

> 
> [ For example, connections that advertise a large initial 
> window and then read a byte every (proposed timer size -1) 
> seconds will replicate the problem in the limit. Using timers 
> alone penalizes stopped connections when there is no resource 
> shortage. ]

Good point. I would think that this is a non-standard behavior, corner
case, why would an application do this in reality and how many times we
have seen such behaviors? I don't want lengthy thread on this, but this
is debatable, IMO.

> 
> Despite the fairly lively discussion, I have seen little 
> support for standardizing this mechanism in TCP, outside the 
> authors and their collaborators, and strong resistance from 
> the members of the WG.  
> 
> Again, I'm not assessing consensus officially here, but 
> that's how I see it.

Poin taken. But there seems to a confusion on what is being attempted to
be standardized versus what is illustrational/informational purpose
only. Just to re-state :

WHY WE BELIEVE THERE IS A NEED FOR STANDARD CHANGE/EXISTING STANDARD
CLARIFICATION ?
========================================================================
============
[Few people have echoed this question, the response below ]

I think there is a need for some standards change. Reason : I'll give an
example of a TCP proxy which doesn't have an application on top per se.
Now I would want to track the TCP connections ( yes there are several
ways to do this) and monitor the health of those, in particular those
that are "hanging" in persist state forever. I can use some timeout
inside TCP to kick off and kill those connections depending on some
policy, is this considered a voilation of RFC since RFC says " you MUST
keep these connections open as long as you receive ACKs?"  Someone can
point out that the TCP proxy is not RFC compliant since it was
"supposed" to keep these connections but terminated them, esp since
there is no application which owns these TCP connections on this box? 

I immediately realise that there may be some responses like " TCP
connection can be terminated anytime, so it should not be treated as
non-compliance of RFC 1122", Is this a fair enough response?. I am
confused, atleast I feel there is a need to say something like " TCP
MUST keep the connection open as long as it gets ACKS, however, if the
application OR a TCP implementation can abort this connection if it
determines by its own means that the connection needs to be taken off"..
I know.. I could have worded this better, but I hope my point is clear. 

Ok, if you think that there is nothing to be changed in TCP, but yet an
implementation trying to abort TCP connections that persist indefinitely
even though it is getting ACK's is fully compliant, then there is no
further debate on this point, I would think.

Can you and the other work group members clarify the above point?  

-Anantha

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Wed, 21 Nov 2007 12:35:08 -0800

> -----Original Message-----
> From: Joe Touch [mailto:[email-masked]] 
> Sent: Wednesday, November 21, 2007 10:59 AM
> To: Anantha Ramaiah (ananth)
> Cc: [email-masked]
> Subject: Re: Summary of responses so far and proposal moving 
> forward [Was Re: [tcpm] Is this a problem?]
> 
> I think it would be very useful to highlight the problem and 
> provide information on how to solve it at the application 
> layer in an informational RFC. I'd suggest it'd be useful to 
> include very specific examples, e.g., with socket options, to 
> show a potential mechanism. I also think the doc should 
> include a discussion of making slow progress as related to 
> this issue, and potentially a similar DOS opportunity.

Actually the mention of socket option is not explicit as it stands now
in the draft and there is definetly some scope for re-wording, I think.

> 
> I don't think the doc should change 1122's text; IMO, TCP 
> isn't the one who ought to make this decision, thus TCP ought 
> to hang out as long as the application lets it.

Pl see my response to Ted where I explicitly ask a question and provide
why I think there is "some" element of standarization here, your
responses are welcome.

> 
> I don't think the doc should mention whether the timer should 
> be embedded in TCP as an implementation decision. IMO, that 
> crosses into a TCP mod, and since it isn't absolutely 
> necessary, I don't see a reason to do so there. I do think it 
> would be more useful to give the example of putting this in 
> the kernel as a shared mechanism, with discussion to motivate it.

Hmm.. An informational RFC CAN recommend stuff, confused here??

> 
> Finally, if this is an informational RFC and the solution is 
> soley at the app layer, it ought to be taken to TSVWG, rather 
> than in TCPM. I don't consider this a downgrading, but rather 
> to gain a wider audience for a very real issue.

Well, agree with the rationale but not the reasoning. My reasoning may
be :- "since this real issue applies equally well for SCTP as well AND
also to gain a wider audience, may be it is a good idea to take this to
tsvwg".

-Anantha

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Wed, 21 Nov 2007 13:31:52 -0800

John:
 
> I would like to step back even further, and work on the 
> definition of "it" -- the problem we want to solve.  In my 
> mail on Nov 14 (which did not elicit a response), I tried to 
> make the case that the issues framed in the draft are in fact 
> only a special case of a more general problem.

Sorry I haven't read that. Will do.

> 
> I do not believe the indefinite nature of TCP's persist state 
> is intrinsically something we need to fix -- in fact, it is 
> clearly an important and useful feature of TCP.  It might not 
> be terrible for a TCP implementation to provide a switch for 
> an implicit ABORT after a long persist timeout.  However, in 
> my opinion this is not the best solution, or even a solution 
> at all to the more general problem.

Pl see the question I posed to in response to Ted's email. Having an
implicit ABORT or having a socket option is very useful thing. It is the
"basic infrastructure" needed in TCP and TCP API layer (like sockets).
Now, if I follow RFC 1122 language, it seems to preclude me from doing
the above. Doing such a thing is an RFC voliation? Does it need some
clarification? 

> 
> I think if consensus can be reached on what the problem 
> actually *is*, it may be more clear how to solve it, where 
> the solution should go, and if this is something the IETF 
> should take on.

IMO, one problem we are trying to address ( the main issue) is the RFC
language correction/clarification.

Question : OTOH, I think you are asking for clear "problem statement" ?
Are you saying that the the way it is stated in the document is vague,
does it more clarification? I can read it again and again, but if you
can ask some specfic questions, maybe that would help. Other responses
have been of the nature which I summarised earlier and I don't remember
anyone having issues about the problem statement. 

-Anantha

---

From: Ted Faber <[email-masked]>
Date: Wed, 21 Nov 2007 13:36:10 -0800

Continuing to speak for myself.

On Wed, Nov 21, 2007 at 12:22:27PM -0800, Anantha Ramaiah (ananth) wrote:
> illustrational purpose only. 

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.

I (personally) don't see the point of publishing an RFC that describes
a technique that a conformant TCP cannot implement.

>                              It also mentions about the role of the

Section 3 of the draft is very hard to follow and is unclear on what's
being proposed.  If the work were taken up, I'd recommend rewriting it.

> have seen such behaviors? I don't want lengthy thread on this, but this

While one might dismiss a legitimate connection holding a zero window
for a long time as a corner case (though doing so is projecting
application semantics into the transport), the more telling criticism is
the first case.

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.

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 21 Nov 2007 13:42:17 -0800

Anantha Ramaiah (ananth) wrote:
> this considered a change in the standards
I want to try to bring some focus back on the above point that the draft 
is trying to make.

If we agree that there is a problem and the solution lies in aborting 
the connection, however it is done, i.e. by application or by some TCP 
implementation, then at the minimum we believe that a change is required 
in the verbiage of RFC 1122. The change is to say that in case of 
reliable ACK's coming back from the receiver, it is NOT a requirement 
for the sender to keep the connection open indefinitely.

Can we agree on this?

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 21 Nov 2007 14:15:34 -0800

I saw this e-mail just after I had hit the send button for my last e-mail.

> a technique that a conformant TCP cannot implement.
I do not see any reason why the proposed solution cannot be implemented. 
Are you suggesting that because we cannot implement it is why it should 
not be implemented?
> less frequently then if they read a single byte
This is a *proposed* solution. This is not a solution that we want to 
standardize on. I am sure with bright minds on this list we can come up 
with better solutions to the problem and  I am fine with that.

To answer your question, yes, they could. That situation is no different 
from a connection that is slow but is making progress. In fact at that 
point it is not a persist connection. It is not advertising zero window. 
We are specifically concerned about connections that take advantage of 
RFC 1122 verbiage to keep the connection in persist state.

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Wed, 21 Nov 2007 14:24:54 -0800

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

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?
OR do folks in the list have some solution in mind which can be done
without touching the standards?

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.

> > you see the need for making further clarifications that would make 
> > this look better?.
> 
> Section 3 of the draft is very hard to follow and is unclear 
> on what's being proposed.  If the work were taken up, I'd 
> recommend rewriting it.

Ok.

> 
> While one might dismiss a legitimate connection holding a 
> zero window for a long time as a corner case (though doing so 
> is projecting application semantics into the transport), the 
> more telling criticism is the first case.
> 
> 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.

-Anantha

---

From: Joe Touch <[email-masked]>
Date: Wed, 21 Nov 2007 14:37:47 -0800

> why I think there is "some" element of standarization here, your

I saw your responses; I don't agree.

> Hmm.. An informational RFC CAN recommend stuff, confused here??

Informational shouldn't recommend anything. It should state stuff. BCPs
are for recommendations, IMO.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 21 Nov 2007 14:43:11 -0800

> WHY WE BELIEVE THERE IS A NEED FOR STANDARD CHANGE/EXISTING STANDARD

That doesn't exist. TCP always has an application on top. TCP proxies
may have a relatively trivial one, and it may be implemented in the
kernel, but TCP delivers data to an application.

I.e., to TCP, "application" means "software I deliver data to". It
doesn't mean "user space program".

There are TCP "proxies" that translate packets directly; they don't
implement TCP. To implement TCP is to originate and terminate a connection.

Joe

---

From: Ted Faber <[email-masked]>
Date: Wed, 21 Nov 2007 14:45:14 -0800

> Are you suggesting that because we cannot implement it is why it should 

The conformant TCP cannot implement the fix because it would violate
1122 and then no longer be a conformant TCP. 

I understand you can write the code.

---

From: Joe Touch <[email-masked]>
Date: Wed, 21 Nov 2007 14:46:47 -0800

> the above. Doing such a thing is an RFC voliation? Does it need some

RFC1122 allows you to abort a connection explicitly. It allows you to
have an user application timer to abort a connection explicitly. It
allows you to have an OS timer that aborts a connection explicitly. To
TCP, the OS and/or user application are not distinguishable.

Now if you "set a local timer that initiates an explicit call" and want
to call that "implicit", that's fine. It's still explicit ultimately
(i.e., a real abort call is issued), and still supported by RFC793 and
RFC1122.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 21 Nov 2007 14:48:32 -0800

> for the sender to keep the connection open indefinitely.

RFC1122 says that the connection MUST persist as long as ACKs are
received. That means that TCP must not abort it. There is no restriction
that the user (application) must not abort it.

Joe

---

From: Ted Faber <[email-masked]>
Date: Wed, 21 Nov 2007 14:54:38 -0800

Just me, not a chair.

> RFC 1122 verbiage to keep the connection in persist state.

It seems to me that this is the same attack that motivated your defense,
just made *slightly* trickier.  To the owner of the attacked server
there's not much difference in the result.

I'm not thrilled to standardize something so easy to work around.  I
suspect that something hard to work around would be to complex and
application-dependent to standardize into TCP.

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Wed, 21 Nov 2007 15:42:03 -0800

> 
> RFC1122 allows you to abort a connection explicitly. It 
> allows you to have an user application timer to abort a 
> connection explicitly. It allows you to have an OS timer that 
> aborts a connection explicitly. To TCP, the OS and/or user 
> application are not distinguishable.
> 
> Now if you "set a local timer that initiates an explicit 
> call" and want to call that "implicit", that's fine. It's 
> still explicit ultimately (i.e., a real abort call is 
> issued), and still supported by RFC793 and RFC1122.

Ok, I am not sure if the rest of the WG feels the same way you do. If
what you say is true, implicit abort isn't an issue, so in theory I CAN
have a timer inside my embedded system (it can running anywhere inhe
system), and it can abort the connection through some interface.
Actually no-one would even notice this behaviour since one really can't
determine from "outside"" whether the connection was aborted implicitly
or explicitly.

So I gather that there is no need to have a standards change, since you
seem to say that RFC allows you to abort a connection which everyone is
aware of. But it is the same RFC that says you MUST persist a connection
indefinetly as long as you receive ACKS, so you are now providing an
external override for this MUST behaviour. 

Hmm... I would also like to get others comment on this... 

-Anantha

---

From: Joe Touch <[email-masked]>
Date: Wed, 21 Nov 2007 15:53:37 -0800

> determine from "outside"" whether the connection was aborted implicitly

That's right.

> external override for this MUST behaviour. 

I think the relevant text is:

         4.2.2.17  Probing Zero Windows: RFC-793 Section 3.7, page 42

            Probing of zero (offered) windows MUST be supported.

            A TCP MAY keep its offered receive window closed
            indefinitely.  As long as the receiving TCP continues to
            send acknowledgments in response to the probe segments, the
            sending TCP MUST allow the connection to stay open.

TCP. Not the user. Users get to abort connections.

        4.2.2.13  Closing a Connection: RFC-793 Section 3.5

            A TCP connection may terminate in two ways: (1) the normal
            TCP close sequence using a FIN handshake, and (2) an "abort"
            in which one or more RST segments are sent and the
            connection state is immediately discarded.

FWIW.

Joe

---

From: Ted Faber <[email-masked]>
Date: Wed, 21 Nov 2007 16:10:27 -0800

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

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

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

> without touching the standards?

I believe the author's solution violates no RFC. 

> 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 

> > frequently then if they read a single byte.

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

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Wed, 21 Nov 2007 16:10:49 -0800

> 
> > So I gather that there is no need to have a standards change, since 
> > you seem to say that RFC allows you to abort a connection which 
> > everyone is aware of. But it is the same RFC that says you MUST 
> > persist a connection indefinetly as long as you receive 
> ACKS, so you 
> > are now providing an external override for this MUST behaviour.
> 

I know I have read the above text many times, but there is an
inconsitency here. While it says that TCP MUST keep the persist
connection open, in the other hand it also says users can abort the
connection no matter what state it is in. So implementations can chose
to have some optimal schemes built inside TCP module on behalf of the
applications ( it is just a matter of programming/implementation) and
have an implicit timer inside TCP which kills the TCP connection when
timer expires and can inform the application about the connection death.

[All the above actions are compliant to the RFC since RFC doesn't talk
about how to implement TCP and it just gives a guidance, the term
user/application and TCP are just used to illustrate the concept.]

-Anantha

---

From: Ted Faber <[email-masked]>
Date: Wed, 21 Nov 2007 16:13:11 -0800

No hat.

> that the user (application) must not abort it.

The OS may also abort a TCP connection for arbitary reason, in my reading.

---

From: Ted Faber <[email-masked]>
Date: Wed, 21 Nov 2007 16:36:48 -0800

As an individual.

> I understand you can write the code.

This is actually pretty unclear of me.  I seem to be arguing both that
the mechanism in the draft violates 1122 and doesn't.  Let me be more
careful:

A system that requires an IETF standard interface to the TCP stack that
specifies a timeout to abort connections holding a zero window longer
than that timeout violates 1122, IMHO.  Because the interface is to TCP
that implies that TCP would do the abort and this action (TCP doing the
abort) would violate 1122.  You can't describe the system as an
interface to TCP and not have it violate 1122.

A system that adds an OS interface to do the same thing would not
violate 1122.  The interface needn't pass through the IETF, which
doesn't standardize application <-> OS interfaces.  The OS aborting a
TCP connection violates no RFC I can think of.  No IETF standards action
required here, though if you wanted to make it part of a standard OS
interface, the interface would need to be reviewed by the relevant body.

I realize that there's an odd something going on here in that the same
action, described slightly differently, does or doesn't require a
standards change.  The difference is that the first choice - creating a
new TCP interface - has ramifications (admittedly small ones) to other
TCP implementations.  Ramifications to other TCP interfaces means the
changes need to conform to other standards.

Given that you can implement the mitigation either with or without
changing standards, why change them?

---

From: Joe Touch <[email-masked]>
Date: Wed, 21 Nov 2007 21:10:20 -0800

Anantha Ramaiah (ananth) wrote:
> connection no matter what state it is in. 

There is no inconsistency.

TCP keeps things open until told to do otherwise by the application. The
point of the text is that it is not TCP's decision to close the
connection - that's precisely because the application can do so if needed.

TCP always does as instructed by the user - i.e., when an ABORT or CLOSE
is issued. The point of the text is that TCP doesn't make a decision to
close the connection itself, not that the user can't make that command.

> So implementations can chose

That timer would need to have a default of "infinite" - i.e., it would
default to never going off - to be compliant with RFC1122. Only if the
application instructed it otherwise could it activate.

Putting the timer inside TCP does nothing useful at that point except
complicate TCP. The timer can be in the OS or in the application with
exactly the same effect.

> user/application and TCP are just used to illustrate the concept.]

If the timer defaults to "infinite", then yes, it would be compliant
with RFC1122. That doesn't change current behavior, though.

Joe

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Wed, 21 Nov 2007 21:33:41 -0800

> That timer would need to have a default of "infinite" - i.e., 
> it would default to never going off - to be compliant with 
> RFC1122. Only if the application instructed it otherwise 
> could it activate.
> 
> Putting the timer inside TCP does nothing useful at that 
> point except complicate TCP. The timer can be in the OS or in 
> the application with exactly the same effect.

That is your viewpoint, I can list the advantages of why putting the
timer inside TCP works for me. It may add some extra code to TCP but
make the application(s) life easier. 
 
> If the timer defaults to "infinite", then yes, it would be 
> compliant with RFC1122. That doesn't change current behavior, though.

Yes, needless to say the timer would be initialised to infinity OR the
timer would never be started unless it is programmed to do so.

So, I think we are in agreement here that it doesn't matter from which
context you are aborting the TCP connection which is hanging in the
persist state. Any abort is compliant with the RFC. 

-Anantha

---

From: Joe Touch <[email-masked]>
Date: Thu, 22 Nov 2007 11:24:21 -0800

> persist state. Any abort is compliant with the RFC. 

Any abort under application control is compliant with 1122.

At which point, putting it inside the TCP code vs. elsewhere in the OS,
vs. in the application are all implementation decisions. That would not
be a change to TCP, and would not include a recommendation to implement
it inside TCP.

If you're asking to extend the TCP API to include access to a TCP timer
for this purpose - and thus to make that standard (which is what an API
extension would require), I think the consensus has been that lazy
application design is not a motivation for unnecessarily
overcomplicating the TCP API.

Joe

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Thu, 22 Nov 2007 20:01:19 -0800

> At which point, putting it inside the TCP code vs. elsewhere 
> in the OS, vs. in the application are all implementation 
> decisions. That would not be a change to TCP, and would not 
> include a recommendation to implement it inside TCP.

Correct. Anways an informational RFC should not be recommending anything
(which you also pointed out)

> 
> If you're asking to extend the TCP API to include access to a 
> TCP timer for this purpose - and thus to make that standard 
> (which is what an API extension would require), I think the 
> consensus has been that lazy application design is not a 
> motivation for unnecessarily overcomplicating the TCP API.

Not sure what you mean above. RFC Compliance applies to protocol, not to
API. API is a local thing. One implementation can use sockets, whereas
other can using something totally different, what matters is what is
sent on the wire and the response which is received. 

-Anantha

---

From: Joe Touch <[email-masked]>
Date: Thu, 22 Nov 2007 23:13:06 -0800

> API. 

Please see RFC793. It specifies an API. Although the IETF avoided APIs
for a while, my understanding is that they are again considered relevant
standards work.

> API is a local thing. One implementation can use sockets, whereas

A protocol is defined by:

	- formats of packets sent on the wire
	- state at the endpoints
	- events that cause state transitions, packet emissions,
	  and signals to the application, triggered by:
		- packets arriving
		- upper layer commands (i.e., "application" events)
		- time

RFC793 is a good example of this set.

The upper layer commmands and signals to the upper layer constitute the
API, and it is as much a part of the protocol as packets on the wire.
Although there are a variety of ways to implement a SEND, RECEIVE, OPEN,
CLOSE, STATUS, or ABORT, all TCP implementations must include them in
their API, and they and their basic arguments are specified in RFC793.

Joe

---

From: "Tom Petch" <[email-masked]>
Date: Fri, 23 Nov 2007 16:04:57 +0100

----- Original Message -----
From: "Anantha Ramaiah (ananth)" <[email-masked]>
To: "Joe Touch" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, November 22, 2007 12:42 AM
Subject: RE: Summary of responses so far and proposal moving forward [WasRe:
[tcpm] Is this a problem?]

<>
Anantha

No, that is not what the RFC says; as Joe has pointed out, the RFC says what TCP
MUST do (and that changing it is a big deal).  Note the title of the RFC -
'Requirements for Internet Hosts - Communication Layers' - and that there is a
companion RFC1123, dated now because applications have moved on, but you will
not find in the latter prohibitions on applications terminating connections.
RFC1122 defines what is available for applications to use, what applications can
rely on; it does not define what those applications do with that functionality.

So; is there a problem?  Yes, but it could be regarded as an implementation
problem rather than a protocol one, and certainly not worth a change in TCP.
Worth an RFC? may be.

Tom Petch
<>

-Anantha

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Fri, 23 Nov 2007 23:53:37 -0800

> > Not sure what you mean above. RFC Compliance applies to 
> protocol, not 
> > to API.
> 
> Please see RFC793. It specifies an API. Although the IETF 
> avoided APIs for a while, my understanding is that they are 
> again considered relevant standards work.

I don't think so. The API's specified by 793 needs to treated as
illustrational purposes only, they are not supposed to be interpreted as
standards. Like you noted above : "It specifies an API" not "the API".
Now RFC 793 doesn't talk about sockets, it doesn't talk about SO_LINGER
and SO_KEEPALIVE for example, does it mean that any stack which
implements API's not mentioned by RFC 793, isn't compliant? Nope.  

Again for example Keepalive option is very common in all TCP stacks, now
RFC doesn't mention about TCP keepalives, 
does it make a particular TCP stack which implements Keepalive
non-compliant, if so all TCP stacks out there (BSD, Linux etc.,) would
become non-compliant :-)

So, the point in short is if I have an socket API, which tells TCP,
abort this connection after a stipulated time in persist state, the TCP
implementation can start a timer (a new timer OR overload an unused
timer) the moment the connection enters persist state, and can tear down
the connection after the timer expiry. This action would be treated as
compliant to 1122 as would the OS running a timer in it's own context
and killing the TCP connection. The key point is that resulting action
is the same no matter which method you chose to exercise a particular
protocol action.

> 		- upper layer commands (i.e., "application" events)

True but protocol (TCP) is one thing, upper (application) and lower
layer (IP) interfaces is another. The protocol compliance is measured by
"if I send something, what do you I get in response" "If I send
something in state X, is the behaviour as defined by the standard?".
Upper layer and lower interface are simply local and they tend to evolve
and that is benefit of a generic design of a particular protocol layer.

> The upper layer commmands and signals to the upper layer 
> constitute the API, and it is as much a part of the protocol 
> as packets on the wire.
> Although there are a variety of ways to implement a SEND, 
> RECEIVE, OPEN, CLOSE, STATUS, or ABORT, all TCP 
> implementations must include them in their API, and they and 
> their basic arguments are specified in RFC793.

Right, but these are the basic API's. The API's tend to expand and
evolve and as long as their evolution doesn't "disturb" the standard,
then we are golden.

-Anantha

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Sat, 24 Nov 2007 00:07:18 -0800

> 
> No, that is not what the RFC says; as Joe has pointed out, 
> the RFC says what TCP MUST do (and that changing it is a big 
> deal).  Note the title of the RFC - 'Requirements for 
> Internet Hosts - Communication Layers' - and that there is a 
> companion RFC1123, dated now because applications have moved 
> on, but you will not find in the latter prohibitions on 
> applications terminating connections.
> RFC1122 defines what is available for applications to use, 
> what applications can rely on; it does not define what those 
> applications do with that functionality.
> 
> So; is there a problem?  Yes, but it could be regarded as an 
> implementation problem rather than a protocol one, and 
> certainly not worth a change in TCP.
> Worth an RFC? may be.

IMO, the informational RFC which is what is being attempted, should
clarify this. The whole point of my question was to understand whether
terminating a connection stuck in persist state is considered RFC 1122
compliant. It appears from responses so far, it is compliant.

-Anantha

---

From: Joe Touch <[email-masked]>
Date: Sat, 24 Nov 2007 09:10:01 -0800

Anantha Ramaiah (ananth) wrote:
> standards. 

Please review RFC793. It does talk about the fact that considerable
flexibility is afforded to the implementer, but also expects the basic
functions described there.

. Like you noted above : "It specifies an API" not "the API".
> Now RFC 793 doesn't talk about sockets, 

Sockets are implementation-specific.

> it doesn't talk about SO_LINGER

1122 talks about keepalives; how they're implemented is up to the coder.
Some of the functions of so_linger are an artifact of blocking OS calls;
it is expected that apps can call ABORT at any time, and so if calls
block, there needs to be a mechanism to get around it.

> non-compliant, if so all TCP stacks out there (BSD, Linux etc.,) would

See 1122.

> is the same no matter which method you chose to exercise a particular

That is true. However, just like we don't require everyone to implement
so_linger, we would not accept a requirement for that timer option to TCP.

> and that is benefit of a generic design of a particular protocol layer.

Upper and lower layers to given protocol define its semantics and the
semantics it expects from the lower layer. While implementations evolve,
the requirements - the minimums required for correct interoperation -
don't unless they are accompanied by changes to the specification.

> evolve and as long as their evolution doesn't "disturb" the standard,

If you want to extend your implementation's API, that's fine, but not an
RFC. If you want to extend the basic minimum required API, that would
require a change to the protocol - as other changes (e.g., keepalives,
nagle, ecn, etc.) have over the years.

Joe

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Sun, 25 Nov 2007 15:19:05 -0800

<snip>

Snipped most of the thread, since I don't intend to start a debate on
"TCP keepalives" :-)

> > abort this connection after a stipulated time in persist state, the 
> > TCP implementation can start a timer (a new timer OR overload an 
> > unused
> > timer) the moment the connection enters persist state, and can tear 
> > down the connection after the timer expiry. This action would be 
> > treated as compliant to 1122 as would the OS running a 
> timer in it's 
> > own context and killing the TCP connection. The key point is that 
> > resulting action is the same no matter which method you chose to 
> > exercise a particular protocol action.
> 
> That is true. However, just like we don't require everyone to 
> implement so_linger, we would not accept a requirement for 
> that timer option to TCP.

I think based on the collective wisdom of the responses so far, that you
don't need to change the standard for solving the problem described in
the draft. ( any solution, for that matter, and not necessarliy the ones
suggested in the draft). In other words, the text specified in the draft
doesn't voilate any TCP standard (RFC 1122) which was my original
question :-). 

-Anantha

---

From: Joe Touch <[email-masked]>
Date: Sun, 25 Nov 2007 20:59:05 -0800

> compliant. It appears from responses so far, it is compliant.

1122 allows terminating a connection at any time for the reason that the
application has instructed so. 1122 makes no distinction about the
progress of a connection affecting that control.

Joe

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Sun, 25 Nov 2007 22:04:51 -0800

> 1122 allows terminating a connection at any time for the 
> reason that the application has instructed so. 1122 makes no 
> distinction about the progress of a connection affecting that control.

Implicit above OR an example scenario of the above statement is :, "1122
allows terminating connection stuck in persist state". Now how and where
it is done is beyond the scope of any standard RFC (including 1122) and
there are several ways to implement the rules.

Now "progress of a connection and taking some action" all fall under
implementation section, aborting of the connection is like a knob, you
turn it when you determine that you need it.

-Anantha

---

From: Joe Touch <[email-masked]>
Date: Sun, 25 Nov 2007 22:55:58 -0800

> there are several ways to implement the rules.

Explicit above is that the application must initiate ABORTs - either by
control of a timer or directly.

1122 prohibits TCP from, absent explicit indication from an application,
deciding to abort a connection based on the lack of progress.

> turn it when you determine that you need it.

1122 specifically prohibits TCP from deciding to abort a connection
because the offered window isn't open (sec 4.2.2.17). The difference of
which entity controls the abort - the application or TCP - is important
to whether 1122 prohibits it or permits it.

Timers inside TCP are equivalent to user action outside TCP, but events
inside TCP that depend on state that TCP can determine but applications
cannot are not equivalent in that regard.

I.e., there is latitude in implementation, but it is not full latitude.

Joe

---

From: Mark Allman <[email-masked]>
Date: Mon, 26 Nov 2007 09:26:35 -0500

[hat off]

I am not sure where in this thread to weigh in, so I am just replying to
the last thing in my inbox.

I think a couple of things:

  + I disagree with everyone who says this problem of a bunch of clients
    wedging connections on a server into ZWP in the attempt to consume
    a large number of resources can be mitigated effectively at the
    application layer.  Perhaps if a server has one application process
    (or a bunch of tightly coupled processes under one app controller)
    then this could be handled.  But, fundamentally a set of
    applications cannot be expected to have the cross-connection and
    cross-application viewpoint that TCP or the operating system has.
    Therefore, applications cannot solve such a problem.

  + I disagree with the reading of RFCs 793 & 1122 that a connection
    that is doing zero window probing must remain up forever as long as
    the probes are being ACKed.  I think in 'times of trouble' a TCP is
    well within its rights to terminate a connection and I do not think
    that should in any way be viewed as non-compliant.  TCP connections
    are local resources and therefore should remain under local
    control.  If something locally determines that resources are low and
    connection should be terminated for whatever reason then I don't see
    how that is any of anyone else's business.

    That doesn't mean I think the words in 1122 are wrong.  That means I
    think that if folks would call a stack that has run out of memory
    (or, hits some threshold, say) and therefore kills some connections
    that are doing ZWP "non-conformant" then they are simply wrong and
    applying too much protocol lawyering and too little common sense.

    Hence, I don't think the standards need changed in any way.

  + I believe that managing local resources according to local policy is
    reasonable.  Therefore, I don't think we need to standardize *a* way
    to mitigate the attack described in this document.  I think stacks
    can be free to mitigate it (or not) as they see fit.

  + I would not have a problem with a crisp and clean document that
    showed *a* solution to the problem.  Especially good would be a
    demonstration that the problem is a problem in the wild and has not
    been mitigated.  [See my previous---unanswered as far as I can
    tell---note on why I think the tests in the draft are inconclusive
    at best.]  This document could be a technical report or a short
    workshop paper or an informational RFC.

    (As an example, see the SYN-flood RFC.  This describes a fully local
    solution to a problem in an informational way.  There is no strict
    reason to standardize anything in that document, but it is crisp,
    clean and complete and the WG found it something nice to have
    documented.  This persist document is a far cry from the SYN flood
    document at the moment, but I suppose one could envision that a
    document that covers purging connections when resource constrained
    could be developed.)

allman

---

From: Mark Allman <[email-masked]>
Date: Mon, 26 Nov 2007 09:29:16 -0500

[hat on]

> Again, I'm not assessing consensus officially here, but that's how I see

My view is largely the same.  I think folks have a variety of reasoning
that leads them to the same place, as Ted notes above.

I would like to flip this around and ask for folks who might not have
chimed in yet, but do support this document to please speak up.

allman

---

From: Joe Touch <[email-masked]>
Date: Mon, 26 Nov 2007 07:52:20 -0800

...
>     how that is any of anyone else's business.

The point of 1122 is that TCP isn't the one to decide this, AND that
connections with zero windows with ACKs aren't to be singled out.
Applications can kill connections, and certainly the OS can just shut
down. However, an OS that decides to kill connections because it runs
out of resources is noncompliant.

That OS is required to reserve per-connection resources when connections
are created. It can halt new connections.

It *CANNOT* kill existing connections to make up for poor resource
management and call itself compliant with the current language in 1122.

>     applying too much protocol lawyering and too little common sense.

The lack of common sense came when the OS designer failed to allocate
sufficient per-connection resources. Throw your stones in their
direction, please.

Joe

---

From: Mark Allman <[email-masked]>
Date: Mon, 26 Nov 2007 11:12:59 -0500

Joe-

You and I are just going to disagree.

> That OS is required to reserve per-connection resources when
> connections are created. It can halt new connections.

If this is the general reading of the spec then TCP has a built-in DoS
vulnerability that we need to fix.

> management and call itself compliant with the current language in

I disagree.

> sufficient per-connection resources. Throw your stones in their

Huh?  The lack of allocation of sufficient per-connection resources?
What?  The problem here is that the OS *did* allocate resources and with
a low-rate handshake those resources can be tied up indefinitely.  I
have no idea how the OS "failed to allocate sufficient per-connection
resources".

If a TCP were omniscient and could know the workload to be imposed on it
arbitrarily far into the future then perhaps it could wisely allocate
resources to avoid this problem.  But, since that is impossible then a
host can get into resource contention problems and in that case it
should have the flexibility to mitigate these problems.

It is absurd to me that a TCP (or any protocol) would allow a peer to
indefinitely tie up a local resource without being subject to local
policies on that resource.  I cannot imagine that such a notion falls
within the spirit of 793 & 1122.  If we have wide-spread agreement that
your interpretation is right then I support a one-page standards-track
RFC that says it is not.

allman

---

From: Joe Touch <[email-masked]>
Date: Mon, 26 Nov 2007 08:24:43 -0800

> vulnerability that we need to fix.

There's nothing in TCP that says that new connections will ALWAYS succeed.

Or can you find that in the requirements?

...
> policies on that resource.

It's very specifically in 1122. Local policies can kill applications,
but can't go around gleaning connections it *thinks* aren't useful.

If you want a new RFC that allows connection revocation, then it's
*definitely* a standards change.

I would favor a BCP that says that:

---
an OS under attack MAY terminate applications to recover their
resources, and the decision of which applications to terminate is a
matter of local policy. when such applications are terminated, their TCP
sessions would, as usual, be aborted
---

Note also that DOS attacks would likely not keep TCP connections around
with zero windows AND continue to ACK - they'd stop ACKing, the
connection would drop for *that* reason, and be recovered.

I would object to an RFC that allows TCP connection revocation to
compensate for not wanting to kill the apps.

Joe

---

From: Mark Allman <[email-masked]>
Date: Mon, 26 Nov 2007 11:33:05 -0500

> There's nothing in TCP that says that new connections will ALWAYS

Can you find a prohibition on connections failing?

Joe, you surely see the problem, right?  I am not saying that new
connections always have to succeed.  I am saying that if the spec allows
for a case whereby an attacker can coax a host into a state whereby all
new connections will fail that is a DoS attack.  Do you disagree with
that?

> but can't go around gleaning connections it *thinks* aren't useful.

Nobody said it thought these connections were not useful.  I don't read
the standards as saying that when resources are severely constrained
then action cannot be taken based on some local policy decisions.  But,
that is just me.

> *definitely* a standards change.

I don't think we need to change anything.  I think the current version
covers this fine.  You and I just disagree on this point.  If consensus
is with you, then I would agree that it would be a standards track
change.

allman

---

From: Joe Touch <[email-masked]>
Date: Mon, 26 Nov 2007 08:58:18 -0800

Mark Allman wrote:
> Joe, you surely see the problem, right?

I see an OS that has to decide how to allocate resources:

	a- leave them with existing apps and prohibit new ones

	b- terminate existing apps to make room for new ones

I expect that a reasonable, modern OS would do (a).

> I am not saying that new

I agree that attackers, as well as legitimate users, can consume local
resources on servers, and that such consumption can reach a limit beyond
what the server can support.

The question is "what do you do when you run out of resources?"

TCP allows killing connections where the other end doesn't respond, via
timeouts. We're all talking about what to do when the attacker is
willing to commit more resources, i.e., to keep ACKing, or even just go
very slowly.

IMO, under those conditions you cannot know the difference between a
legitimate user and an attacker. Under those conditions, 1122
specifically claims that not making progress due to an ACKd zero window
isn't a connection failure.

IMO, the application (i.e., service) ought to determine when to give up
on a connection, and issue ABORTs.

That solves the problem entirely and is entirely within the scope of
1122 as it currently exists.

I don't agree that the OS has any business terminating connections to
make up for poorly-written, and thus DOS-susceptible applications, or
that 1122 should be modified to either permit or encourage this sloppy
handling of DOS attacks.

Joe

---

From: Mark Allman <[email-masked]>
Date: Mon, 26 Nov 2007 14:38:03 -0500

> The question is "what do you do when you run out of resources?"

Yep.

> TCP allows killing connections where the other end doesn't respond,
> via timeouts. We're all talking about what to do when the attacker is
> willing to commit more resources, i.e., to keep ACKing, or even just
> go very slowly.

Yep.

> specifically claims that not making progress due to an ACKd zero
> window isn't a connection failure.

I agree that you cannot tell the difference, per se.  But, IMO, one can
look around at the context and make a good guess and accept the
collateral damage.  I.e., if I see a zillion of these ZWP connections
when I normally see ~none I could decide that this is an attack and take
what I consider appropriate actions, knowing full well that everything
in the class of connections may not be an attack.

> IMO, the application (i.e., service) ought to determine when to give
> up on a connection, and issue ABORTs.

That's great, but the problem with that is that an application hasn't
the context of the underlying TCP or OS.  Clearly you could feed
something to the app that says "kill some connections" and the apps
might or might not.  So, that might or might not solve the problem and
it is more complicated and depends on much more software being right. 

> 1122 as it currently exists.

I see a TCP solution as being within the scope of the 1122 we have.

> that 1122 should be modified to either permit or encourage this sloppy

I can't even believe I am having this discussion, Joe.  It isn't the app
that is DoS-ed.

Like I said: you and I are not going to agree about how to interpret
RFC112 (in 2007).  It would be good to hear other opinions.

allman

---

From: John Heffner <[email-masked]>
Date: Mon, 26 Nov 2007 14:41:53 -0500

> management and call itself compliant with the current language in 1122.

I really have to disagree here; I do not believe an OS terminating a 
connection violates the spirit of 1122.  Things like processes, address 
spaces, etc., are well outside the TCP standard's realm.  In my view, an 
operating system (the kernel, a helper daemon, or other) can be 
considered a "User" of TCP (in RFC793 terminology), and be fully 
compliant when making API calls (including ABORT) to connections that 
might be "owned" by some other process.

One question: is the deleteTCB(12) state of RFC4022 in conflict with 
RFC1122/RFC793?

   -John

---

From: Ted Faber <[email-masked]>
Date: Mon, 26 Nov 2007 11:53:51 -0800

> might be "owned" by some other process.

I agree with this interpetation, you know, as a regular guy.

> One question: is the deleteTCB(12) state of RFC4022 in conflict with 

There's nothing there that offends me.  That looks like a request by a
manager to an operating system to call ABORT on a connection.  I assume
that the managed entity might choose to ignore such a request (e.g. it
is a request to terminate the connection to the manager over which the
request came :-)).

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 26 Nov 2007 21:03:07 +0000

>I expect that a reasonable, modern OS would do (a).

That presumes that all TCP connections are long-lived. It permits a few long-lived connections to tie up resources that could service short-lived connections.

(http, beep, xml-rpc and other short-lived transactions over TCP weren't invented when RFC1122 was written.)

L.

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 26 Nov 2007 13:35:49 -0800

> connection would drop for *that* reason, and be recovered.
Quite the contrary. Our experimentation revealed that DoS attackers 
responded reliably with an ACK to all zero window probes and that 
connections stayed in established state for days.

---

From: Joe Touch <[email-masked]>
Date: Mon, 26 Nov 2007 19:46:02 -0800

Lloyd Wood wrote:
> That presumes that all TCP connections are long-lived. It permits a
> few long-lived connections to tie up resources that could service
> short-lived connections.
> 
> (http, beep, xml-rpc and other short-lived transactions over TCP
> weren't invented when RFC1122 was written.) 

It presumes only that a connection shouldn't be terminated to make room
for new ones. It says nothing about the duration of the connection.

1122 says that connections that are active - i.e., actively exchanging
packets - MUST NOT be terminated. Connections are terminated only when
applications indicate, OR when the endpoints cannot communicate.

If you start "robbing Peter to pay Paul" - i.e., killing some
connections to make room for others - you end up with a very unreliable
kind of TCP. One where connections just disappear.

Modern OS's don't kill apps to make room for new ones (presuming they're
static in resource use). This is the connection equivalant.

I agree that having the OS - who is SOLELY in view of shared resources -
informing the application when resources are critical, and applications
being designed to decide which connections to keep and which to drop
based on *knowlege about the connections they alone possess*.

However, once a connection is opened, I don't agree that it's the OS's
perogative to kill it for any reason, any more than it would kill a
process that isn't running away. Holding resources already granted is
how current app/OS interfaces work; revocation isn't normal.

Yes, this means that *applications* can be DOS attacked, and they need
to be written to react accordingly.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 26 Nov 2007 19:47:42 -0800

> connections stayed in established state for days.

OK - so how do you know these were attacks? Or are you calling any
consumption of resources you don't expect an attack?

I.e., all flash crowds are attacks?

Joe

---

From: Lloyd Wood <[email-masked]>
Date: Tue, 27 Nov 2007 11:30:06 +0000

>for new ones. It says nothing about the duration of the connection.

well, obviously. that's because all connections were presumed to be long-lived.

>packets - MUST NOT be terminated. 

If only it said connections actively exchanging data...

>Connections are terminated only when

I'd argue we have that unreliable TCP already - e.g. varying # of SYNs repeated to ensure a connection is opened on different OSs, with different application behaviour as a result. Your connection just disappeared because the SYN and the sole repeat Windows sends were lost? Hit reload in your web browser! (How applications handle end-to-end reliability across TCP is a separate problem, but the end-to-end argument suggests that TCP can be unreliable - it's not the highest level.)

>static in resource use). This is the connection equivalant.

What's the connection equivalent of swapping an unused app out to virtual memory and forgetting about it?

L.

---

From: Joe Touch <[email-masked]>
Date: Tue, 27 Nov 2007 06:10:16 -0800

Lloyd Wood wrote:
...
> If only it said connections actively exchanging data...

See 1122 sec 4.2.2.17, as I cited before. Active exchange of probes is
sufficient.

> I'd argue we have that unreliable TCP already - e.g. varying # of
> SYNs
> repeated to ensure a connection is opened on different OSs, with
> different application behaviour as a result. Your connection just
> disappeared because the SYN and the sole repeat Windows sends were lost?
> Hit reload in your web browser! (How applications handle end-to-end
> reliability across TCP is a separate problem, but the end-to-end
> argument suggests that TCP can be unreliable - it's not the highest level.)

I agree that unpredictable OPEN behavior isn't good, but it's not
unreliable. TCP is reliable only after a connection is open, not on the
open itself.

> What's the connection equivalent of swapping an unused app out to virtual memory and forgetting about it?

Sounds like advertising a zero window would be similar; note that
starvation-free OS's don't "forget" about swapped processes, though --
so I wouldn't expect either to starve a process/connection indefinitely,
or to just kill a connection/process.

Joe

---

From: David Borman <[email-masked]>
Date: Tue, 27 Nov 2007 08:58:40 -0600

Ok, I haven't chimed in yet on this conversation.

While I agree with the document on the identification of the problem,  
I disagree with the proposed solution (changing TCP to time out  
connections in persist state).  Having a connection stay in persist  
state for long periods of time (i.e., zero window probes continue to  
be ACKed) by itself is not a bad thing.  That is how TCP was designed  
to work.  Connections can survive through lots of adversity.  If a  
connection is stuck because it is waiting for user action and the user  
walked away and went home for the day, he should be able to come back  
the next morning and do what needs to be done, and then the connection  
will continue.

As has already been stated, the issue is what should the OS do when it  
runs out of resources.  TCP implementations typically oversubscribe  
their resources, and run into problems when all the open connections  
try to use up all the resources that they've been told they can use.   
In this situation, the OS has to figure out some way to free up  
resources.  There may be some things it can do without killing  
connections (e.g., flush TCP resequencing queues), but usually that  
won't be sufficient if you have a runaway or malicious source that is  
causing the resource problem in the first place.  In this situation,  
anything the OS decides to do, including killing TCP connections, is  
at the discretion of the OS, and I don't that view as violating any  
RFC.  You're out of resources, you have to do something.  This is not  
a TCP protocol issue, it is an OS implementation issue.

Now, it might be that connections that have been in persist state for  
a long period of time are good candidates for the OS to abort to free  
up resources.  But doing that has to be a decision of the OS or the  
application, not of TCP.  TCP can keep track of how long connections  
are in persist state, so that if the OS or application asks, it can  
judiciously choose which ones are the best to abort.

Let's look at keep-alives.  They are not part of the TCP  
specification.  They aren't perfect.  In RFC 1122, we acknowledged  
their existence, and placed restrictions on them.  The must default to  
off.  The default interval for sending keep-alives must be at least 2  
hours.  You don't drop a connection due to just one missed keep- 
alive.  "A TCP keep-alive mechanism should only be invoked in server  
applications that might otherwise hang indefinitely and consume  
resources unnecessarily if a client crashes or aborts a connection  
during a network failure."  But they do serve a useful purpose.

In the end, it is the responsibility of the application to place  
limits on its TCP connections.  If the OS provides a simple way for  
the application to say "ABORT this TCP connection if it remains in  
persist state (or idle state, or...) for more than X period of time",  
I don't have any objection to that.  That's an agreement between the  
application and the OS.  It has the nice advantage that the OS knows  
what to do with the connection after the application has written all  
its data and closed its side of the connection, and hence is no longer  
able to ABORT the connection.  When the system runs out of resources,  
it is the responsibility of the OS to decide how to deal with that  
situation.  If TCP is consuming large amounts of resources, then the  
OS will have to have some way to tell TCP how to free up resources,  
including ABORTing connections.

There have always been ways that TCP implementation can tie up  
resources, and we've been working to mitigate those things all along.   
(The first one I remember dealing with was the "send each octet in a  
separate packet, but don't send the first octet".  That tied up  
resources on BSD on the TCP resequencing queue.) One difference  
between now and 15-20 years ago, is that back then many of the  
resource issues were not intentional, but due to poorly written  
applications or just new scenarios that hadn't been exercised before.   
But what hasn't changed is that the problems are usually due to  
implementation issues, not problems with the TCP protocol.  And that  
holds true in this case.

			-David Borman

On Nov 26, 2007, at 1:38 PM, Mark Allman wrote:

...

---

From: [email-masked]
Date: Tue, 27 Nov 2007 10:04:44 -0500

On Tue, Nov 27, 2007 at 08:58:40AM -0600, David Borman wrote:
>
> While I agree with the document on the identification of the problem, I 
> disagree with the proposed solution (changing TCP to time out connections 
> in persist state).

I'm in harmony with this and everything else Dave said.

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 27 Nov 2007 13:56:53 -0800

Joe Touch wrote:
> consumption of resources you don't expect an attack
They were attacks because we had initiated them as such.

The point is that (and you seemed to have accepted it by saying ok) that 
you cannot rely on the attacker giving up and going away to free the 
resources.
-- 
/mahesh
_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 27 Nov 2007 15:21:39 -0800

> Ok, I haven't chimed in yet on this conversation.
I am glad you finally did :-)
My understanding of rfc 1122 is and I quote from the rfc itself:

>             DISCUSSION:
>                  It is extremely important to remember that ACK
>                  (acknowledgment) segments that contain no data are not
>                  reliably transmitted by TCP.  If zero window probing is
>                  not supported, a connection may hang forever when an
>                  ACK segment that re-opens the window is lost.
>   
This tells me that the concern was with ACK's getting lost in the 
network and that is why the need to keep the connection open. The point 
we bring up in the draft is in the case the ACK's are being received 
reliably then the need to keep the connection open just to make sure the 
ACK has made it to the other end goes away. That is why the request to 
change the language to say that *in case of reliable ACK*, TCP MAY tear 
the connection down if it is not able to service existing or new 
connections.

We seem to agree on the user scenario you describe above.  That is why 
we make it clear in the draft that we should not tear down a connection 
just because the connection is open for a long time. Where there is one 
or a few connections that are keeping the connection open, the solution 
will not tear the connection down. The problem happens is when lots of 
users (or attackers) do the same.
> a TCP protocol issue, it is an OS implementation issue.
True. But it was caused by TCP's insistence on keeping the connection 
open that causes the OS to even run out of resources, even if the reason 
to keep the connection open (unreliable ACKs) may not be true.

I know there is very little support for this argument, but for a reader 
reading the rfc there is sufficient confusion on whether the connection 
can be cleared or not. Why not change the MUST to a MAY for reliable ACKs?

People on this mailing list have been arguing on the point of if 
connections can even be cleared and this is tcpm mailing list!! 
Everybody is a TCP expert here. Is it not telling of a problem in the 
language of the rfc?

/mahesh

---

From: Ethan Blanton <[email-masked]>
Date: Tue, 27 Nov 2007 18:34:27 -0500

Mahesh Jethanandani spake unto us the following wisdom:
> RFC1122:

I hate to wade back into this, and this may be tangential to the
discussion at hand, but the reason for allowing TCP connections to
persist indefinitely is NOT because ACKs may be lost; it is because
applications may be busy indefinitely.  ACK loss is merely the reason
for continued ZWP.

> to keep the connection open (unreliable ACKs) may not be true.

Only in the *very specific* *corner case* that the open connections
are connections in PERSIST.  As best I can tell, you have noted
elsewhere that you have never even seen this in the wild; you ran your
own DoS with a homemade tool and called that the wild.  Again,
unreliable ACKs are NOT the reason to keep the connection open, you
misread or misunderstood 1122.

Your argument seems to dance around a lot, which makes it difficult to
discuss.

Ethan

---

From: Ethan Blanton <[email-masked]>
Date: Tue, 27 Nov 2007 18:37:33 -0500

> They were attacks because we had initiated them as such.

This is _very different_ from what you claimed before.  You are
claiming that attacks *do exist* which reliably ACK zero window probes
-- but you don't know that, and have no support for it.  You have
support for the fact that an attack *can be created* which ACKs zero
window probes.

Joe's point, and I think it is valid, is that this is an attack which
requires a commitment of resources on the part of the attacker.

That said, I agree that such an attack *could* be created, though it
appears that no one has.

Ethan

---

From: David Borman <[email-masked]>
Date: Tue, 27 Nov 2007 18:16:29 -0600

On Nov 27, 2007, at 5:21 PM, Mahesh Jethanandani wrote:

> network and that is why the need to keep the connection open. The  
> point we bring up in the draft is in the case the ACK's are being  
> received reliably then the need to keep the connection open just to  
> make sure the ACK has made it to the other end goes away. That is  
> why the request to change the language to say that in case of  
> reliable ACK, TCP MAY tear the connection down if it is not able to  
> service existing or new connections.

You are misreading this.  This section (4.2.2.1) has two requirements:  
1) Zero Window Probing must be supported (to guard against lost window  
updates), and 2) as long as you get responses to the ZWP, you must  
keep the connection open.  That's it.  You aren't keeping it open to  
get lost ACKs, you're keeping it open because the other side of the  
connection is still there and responding.

			-David Borman

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 27 Nov 2007 22:51:48 -0800

> connection is still there and responding.
You are right. Thanks for correcting that perception.

What I should have said is that the fact that the above statement in RFC 
1122 that "TCP MUST allow the connection to stay open" in response to 
probes has caused a lot of confusion. We have opinions all the way from 
it is ok for TCP to terminate the connection "in times of trouble" to it 
is not for TCP to terminate any connection. We have had mails that have 
said that it is ok for application/OS/socket layer to terminate the 
connection but it is not ok for TCP to terminate the connection. Does it 
mean that if socket interface makes a call to tcp_abort() to abort a 
connection, that it is not TCP that is aborting the connection, but it 
is socket interface that is, and therefore it is fine?

Would it not help to clarify the statement in the rfc?
--

---

From: Joe Touch <[email-masked]>
Date: Wed, 28 Nov 2007 05:21:00 -0800

> Would it not help to clarify the statement in the rfc?

It would be useful to clarify that in the Unix man pages for
tcp_abort(), if there is in fact any real confusion in the Unix
community on this issue.

As Dave noted, RFC1122 is clear on the context of not aborting
connections within TCP due to zero windows with active probes.

The rest of this discussion has been addressing a moving target based on
falsified claims of a vulnerability, which, as others have noted, is not
more advantageous than many others in TCP, e.g., slowly draining
buffers. It makes no sense to single out "victims" of this "attack" by
"cleaning up" TCP state to save resources vs. any other mechanism to
limit resource overuse (e.g., prohibiting new connections, deleting
those with the largest socket buffers, etc.).

The key issue is that a zero receive window with active probes is a
valid, active TCP connection - as valid as any other in its use of
resources. If we need a document to describe what to do in the event of
resource overuse (and I don't think we do), the current document - and
motivating threat - are notable only in how NOT to single out
connections for resource recovery.

Joe