Subject: [tcpm] TCP Adaptive User TimeOut (AUTO) Option

From: Fernando Gont <[email-masked]>
Date: Thu, 20 May 2004 14:22:20 -0300

Folks,

I've submitted a draft entitled "TCP Adaptive User TimeOut (AUTO) Option".
It's an alternative proposal on the issue of having TCP "negotiate" the 
USER TIMEOUT parameter.

My proposal is to not really *negotiate* the USER TIMEOUT, but have TCPs 
"suggest" a value to be used for it.
The option must sent during the connection-establishment phase in segments 
with the SYN control bit set (*only*), in a similar fashion to other TCP 
options (such as MSS). The option may also be used during the life of a 
connection, so that TCP peers can suggest a different USER TIMEOUT value to 
be used for the connection, adapting the USER TIMEOUT parameter to changing 
network conditions.

I'd appreciate any comments on the draft.

It can be found at:
http://www.ietf.org/internet-drafts/draft-gont-tcpm-tcp-auto-option-00.txt

--
Fernando Gont
e-mail: [email-masked] || [email-masked]

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

---

From: Kostas Pentikousis <[email-masked]>
Date: Thu, 20 May 2004 19:42:11 -0400 (EDT)

Hi folks,

FWIW, I would prefer a single document addressing the problem.
Both drafts have good points and seem quite complimentary.

The initial request/negotiation in ATO and the "suggestion" in
AUTO can be merged. A single bit can indicate whether this is a
suggestion (AUTO) or a (strict) request (ATO).

I like the idea of knowing whether one's request/suggestion will
be in effect after connection setup. This is present in ATO but
missing from AUTO. On the other hand, I like the "Granularity" bit
proposed in AUTO (but missing from ATO).

AUTO allows for announcing a different timeout value after
connection establishment, while ATO leaves the issue open for a
future refinement. Yet another point where they can be merged.

Finally, while ATO has a more detailed Security section AUTO
features an interoperability section.  (I am no security expert,
so take this with a couple of extra grains of salt :)

There is simply too much common material to have two "competing"
proposals dealing with the problem.

Of course there are issues to be straightened out, but I see
little reason  to introduce alternative mechanisms, request
different TCP option kind numbers etc.

More comments and nits sent directly to the authors.

Best regards,

Kostas

PS: Is there any reason for calling the same thing USER TIMEOUT in
one document and abort timeout in the other?

__________________________________________________________________
Kostas Pentikousis                   www.cs.stonybrook.edu/~kostas

---

From: Fernando Gont <[email-masked]>
Date: Fri, 21 May 2004 01:37:43 -0300

>suggestion (AUTO) or a (strict) request (ATO).

Is there any good reason for a "strict" request?

Say host A wants to communicate with host B. Say host A is a mobile host 
connected to the network by means of a wireless link, and host B is 
connected to the network by means of a DSL link.
Say host A suggests B a USER TIMEOUT of 10 minutes.

All host A wants to do is let host B know that it should be using a USER 
TIMEOUT of at least 10 minutes, or else it may end up aborting connections 
unnecessarily.

It's up to B what it ends up doing.

What's the reason for having host A know what USER TIMEOUT host B will use?
OTOH, what's host A supposed to do if host B doesn't honor its suggestion?
Close the connection?

>missing from AUTO.

It's *intentionally* "missing" in the AUTO option.

>future refinement. Yet another point where they can be merged.

Once again: what would you do if, while a connection is in the ESTABLISHED 
state, you suggest a USER TIMEOUT value to the remote TCP peer, and it does 
not honor it?

>so take this with a couple of extra grains of salt :)

IMHO, it's not that the "Security Implications" section in the AUTO Option 
draft is less detailed: it's just that I considered that the option does 
not really raise any new "Security Implications". Note that TCP requires no 
message exchange for maintaining connections in the ESTABLISHED state.
So you don't need the AUTO Option for performing this type of attack. You 
could just connect to any service, wait for their greeting message, and 
then throw away the connection. The server will keep resources for the 
connection, as it will wait for you to send data to it.
Furthermore, there are protocols (for example, HTTP) which won't even send 
a greeting message... so you could just complete TCP's three-way handshake, 
and then throw away the connection immediately.

So the AUTO option does not really raise any *new* type of attack.

>one document and abort timeout in the other?

In the AUTO draft, I use "USER TIMEOUT" to refer to the timeout parameter 
defined in the original TCP specification (RFC 793).

As for the option name, I sent a comment to Lars (and posted it to this 
list, too) on this issue. It's not the "abort" that times out, but the 
*user* (or the "connection", if you want).