Subject: [tcpm] WGLC for UTO

From: Mark Allman <[email-masked]>
Date: Wed, 10 Oct 2007 09:36:00 -0400

Folks-

We are starting a WGLC on the UTO specification,
draft-ietf-tcpm-tcp-uto-06.txt.  We believe the document has addressed
the concerns raised by the WG and that there is good consensus for
publishing the document.  Our charter says the intended status for the
document is "Proposed Standard".  However, in the draft tracker it says
"Experimental".  We cannot seem to recall crisply deciding this issue.
So, please review the document one last time and raise issues on the
mailing list and please also weigh in on whether you think it should be
Experimental or Proposed Standard.  Also, notes of the form "looks fine
to me" are encouraged.  The WGLC will run through October 24.

Thanks,
Mark & Ted

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

---

From: <[email-masked]>
Date: Wed, 10 Oct 2007 16:22:18 +0100

Generally the UTO draft seems absolutely fine and I would support it
moving to RFC. There seems no obvious reason for it to be experimental
rather than proposed standard. 

I do have one potential concern and some nits:

Concern:

Section 4.1 Middleboxes suggests that "In the future, such [stateful]
firewalls may learn to parse the TCP User Timeout Option and adapt
connection state management accordingly." Would it be worth adding that
in this case this could become a potential security issue as it would
allow cooperative users to cause a stateful firewall to maintain
connection state for over 22 hours?

Nits:

Section 3: 
'LOCAL_UTO' "If unspecified, it default to the default system-wide USER
TIMEOUT." change to "...defaults to the default..."

Para starting 'Before opening a connection...' "The default is to allow
this for connections that do not have a specific user timeout concerns."
delete "a"
"...to prevent UTO options from the other end to override local
application requests." change to "options from the other end overriding
local..."

Next para: "... is a reliable way to initially exchange and potentially
adapt to UTO values." add commas: "... is a reliable way to initially
exchange, and potentially adapt to, UTO values."

Section 3.1 para 1. Delete the first comma in the last sentence so it
reads: "In this case they SHOULD, however, notify the application about
the user timeout value received from the other end."

Para starting "This means that..." change last sentence (remove
nevertheless) "...it can still close or abort..."

Section 4.2 last sentence change to "Therefore, if a connection that
enables keep-alives is also using the TCP User Timeout Option, ..."

Toby

________________________________________________________________________
____
Toby Moncaster, <[email-masked]> Networks Research Centre, BT
Research
B54/70 Adastral Park, Martlesham Heath, Ipswich, IP53RE, UK.  +44 1473
648734 

-----Original Message-----
From: Mark Allman [mailto:[email-masked]] 
Sent: 10 October 2007 14:36
To: [email-masked]
Subject: [tcpm] WGLC for UTO

Folks-

Thanks,
Mark & Ted

---

From: Lars Eggert <[email-masked]>
Date: Wed, 10 Oct 2007 10:59:42 -0500

> connection state for over 22 hours?

Similar to how UTO is not binding for the ends (i.e., they may close  
a connection at any time), it is not binding for middleboxes. So  
these (so far purely hypothetical) middleboxes are free to time out  
the binding at any time, for example, if they become resource- 
constrained. We could make that explicit in the draft, if people feel  
the current text is unclear.

> Nits:

We'll fix these.

Thanks,
Lars

---

From: Pasi Sarolahti <[email-masked]>
Date: Mon, 15 Oct 2007 11:26:59 +0300

> "Experimental".  We cannot seem to recall crisply deciding this issue.

The draft looks fine to me to go forward.

Regarding the Proposed Standard vs. Experimental issue, I think this  
draft, like the other new TCP extensions, should first go to  
Experimental as a rule of thumb. I'm concerned about the increasing  
complexity and size of "the standards track" TCP implementation. It  
would be a good practice to have a careful evaluation in Experimental  
RFC phase before adding up things to standards track TCP that is  
expected to be implemented by most vendors.

- Pasi

---

From: Mark Allman <[email-masked]>
Date: Mon, 15 Oct 2007 07:48:34 -0400

> The draft looks fine to me to go forward.

Many thanks for the note!

I have a couple questions (with my hat off) ...

> expected to be implemented by most vendors.

(1) What 'careful evaluation' do you think should be done during
    Experimental?

    Or, put another way, how would we know that it was OK for UTO to
    later move to PS?

    My own opinion here is that this draft specifies a way to share some
    information and that is pretty benign.  I can't see where it hurts
    anything if stacks want to do it.  It is advisory information if
    stacks want to ignore it.  So, what's the real harm here in putting
    it on the standards track?  Or, what would be the benefit of going
    experimental?  My own answer to both questions is "very little".

(2) While I sympathize with the goal of keeping things simple and
    avoiding needless complexity, I do not believe that just because we
    put something on the standards track we expect it to be implemented
    in every TCP implementation.  Perhaps that is flawed reading of
    these things.

Just my two bits.

allman

---

From: Pasi Sarolahti <[email-masked]>
Date: Mon, 15 Oct 2007 18:31:13 +0300

>> expected to be implemented by most vendors.

First of all, I want to clarify that I am proposing this as a general  
rule of thumb on how to introduce new features to TCP. It has been  
always a bit fuzzy to me when some new feature should go to  
experimental, and when it can go directly to standards track. This is  
not only about UTO (which I think seems like a fine scheme).

> (1) What 'careful evaluation' do you think should be done during

In case of UTO, given
* possibly limited budget of TCP implementation size (in embedded  
devices, for example)
* limited TCP option space
* possibility of resource exhaustion attacks as discussed in security  
considerations

Should I implement UTO and when should I enable it?

>     Or, put another way, how would we know that it was OK for UTO to

If people find UTO useful (I'm sure many will do), they will  
implement UTO even as an Experimental RFC. After a couple of years of  
deployment experience advancing the document to PS should be a  
straight-forward process, if no problems have emerged, right?

One could ask the above question for any other experimental document.  
Having couple of years of kind of a "trial period" for new TCP  
extensions wouldn't do any harm, would it?

>     experimental?  My own answer to both questions is "very little".

I agree that UTO seems quite safe and non-controversial extension  
(like many other experimental RFC).

But one could also ask what's the real harm in putting it to  
experimental first? What would be the benefit of going directly to  
standards track, instead? Very little? Remembering a past tsvarea  
presentation at IETF-68 about Window Vista features, where Window  
scaling (PS) and ECN (PS) were disabled by default, and DSACK (Exp),  
F-RTO (Exp) enabled...

I realize that in the end it is up to the implementors to decide  
which standards track RFCs they choose to use, and we have indeed  
seen that some implementations are pretty liberal in selecting the  
TCP features. Nevertheless, it would be useful to have a meaning to  
the standards track status, indicating that a feature is considered  
to be part of the "recommended TCP", to help the people pondering  
among the number of TCP RFCs out there. The roadmap RFC seems to make  
this assumption, too, having the standards track enhancements listed  
as "recommended".

- Pasi

---

From: Mark Allman <[email-masked]>
Date: Mon, 15 Oct 2007 12:13:55 -0400

[[ Folks, we could use some opinions from additional people on this 
   question. ]]

> not only about UTO (which I think seems like a fine scheme).

Point taken.

> * devices, for example)
> * possibility of resource exhaustion attacks as discussed in
> * security  considerations

The thing that I don't see is how we'll differently answer these
questions in 2 or 3 years than we do today.  I don't mean to claim there
are not considerations.  There are.  But, are embedded devices that
don't want needless TCP mechanisms going to be gone in a few years?  How
is that consideration going to change with experience?  In a few years
will we be able to discount resource attacks?

It seems to me that you (and others) are advocating experience for the
sake of experience, rather than experience for the sake of figuring
something in particular out.

> One could ask the above question for any other experimental

Sure---and I think we should.  But, some documents have good answers and
some don't, IMO.

E.g., we made NCR an experimental RFC because it delays TCP's congestion
response and therefore makes TCP more aggressive.  I think the question
"is this OK?" is clear and would have to be answered with experimental
evidence before we decided that it was OK for standards track (i.e.,
generally applicable for wide spread deployment).  In this case "is it
OK?" is a technical question about the mechanism.  I think this is in
direct contrast to UTO---which is about the exchange of information.  We
can say we're going to ask "is it OK?", but in the UTO case that is not
a technical question.  How do we answer that question with an
experiment?  I don't see any reason why we'd delay putting UTO on the
standards track as a **proposed** standard.

> standards track, instead? Very little?

Point taken.  The benefit may also be small.

In some sense it depends on the default setting you like best.  You want
to add an extra step to all documents and I want to add that extra step
only when it seems like we really need to add that step (and, it doesn't
seem to me that we need the extra step in this case).

> Remembering a past tsvarea

(Nit: DSACK is PS and always has been.  And, IMO this is important
because it is quite close to UTO because they both specify how to share
information and not much else.)

allman

---

From: Joe Touch <[email-masked]>
Date: Tue, 16 Oct 2007 11:39:36 -0700

Pasi Sarolahti wrote:
>>> Experimental as a rule of thumb. 

I don't agree. Whether something goes to experimental is determined by
whether there is an experiment needed. The standards track has phases
for us to gain confidence with extensions - that's why things don't just
go straight to Standard.

There are three choices, BTW:

	- standards track
		should be for things we think are useful to the
		Internet as a whole, and not harmful to the Internet
		as a whole if widely deployed

	- experimental
		things for which an experiment in deployment will help
		either gain confidence in group behavior or parameter
		determination

	- informational
		things which are not harmful to the Internet as a
		whole if widely deployed, but may be useful in
		specific environments

Anything that is harmful to the Internet as a whole should be documented
more as something to avoid, IMO.

>>> I'm concerned about the increasing
>>> complexity and size of "the standards track" TCP implementation. 

That should be a consideration for all items in the standards track, and
is largely - AFAICT - determined by the MUST/SHOULD/MAY designations.

I will note, as others have as well, that there's a problem with the
menu of choices out there. Many choices are intermingled, and the
roadmap should be clear on which current choices are related. The same
relationship can be true for items within a mechanism, as we've discused
on this list as well.

Perhaps it would be useful for us to adopt an informal requirement that
TCP mods come with three clear summaries:

1) whether the proposed mechanism is, as a whole, MUST/SHOULD/MAY

2) which components of the proposed mechanism are MUST/SHOULD/MAY

3) what other dependent choices are MUST/SHOULD/MAY

It'd be useful to have a section that lists these succinctly in summary,
at the beginning of the document, e.g., "Requirements Levels and
Dependencies".

> * possibly limited budget of TCP implementation size (in embedded

MAY and SHOULD allow designers to omit things for space constraints.

> * limited TCP option space

MAY and SHOULD allow designers - and users - to disable things for
header space limitations.

> * possibility of resource exhaustion attacks as discussed in security

That ought to be addressed before being released. Security questions are
not the kinds of things we want to gain experience with via widescale
deployment.

> Should I implement UTO and when should I enable it?

MAY handles that.

Joe

---

From: Pasi Sarolahti <[email-masked]>
Date: Thu, 18 Oct 2007 17:01:29 +0300

> standards track as a **proposed** standard.

Ok, I think you are right that it is hard to come up with well- 
defined experiments that would give some additional technical  
information about the UTO. But I don't understand where this  
requirement for experiments comes from. I also ask, because this  
"what is the experiment?" question has come up quite a few times  
during the past couple of years for Experimental documents in  
different WGs, and RFC 2026 does not say anything about experiments:

    The "Experimental" designation typically denotes a specification  
that
    is part of some research or development effort.  Such a  
specification
    is published for the general information of the Internet technical
    community and as an archival record of the work, subject only to
    editorial considerations and to verification that there has been
    adequate coordination with the standards process (see below)....

(I believe many of the proposed TCP extensions are part of a research  
project.)

> seem to me that we need the extra step in this case).

I didn't mean adding extra step to *all* documents, just that we  
should by default be conservative when extending standards track TCP  
with new features. The idea was that during the Experimental state we  
could, among other things, get better understanding whether there is  
"enough community interest to be considered valuable", as required  
for Proposed Standard. This is sometimes hard to judge based on the  
(lack of) comments during WGLCs. In addition to the comments on the  
mailing list, a good indication of "community interest" would be, if  
someone indicated interest in taking a documented extension into a  
real implementation.

> information and not much else.)

Sorry, by "DSACK" I meant Experimental RFC 3708, i.e. the usage part.  
The UTO document is different that RFC 2883 because it specifies both  
the new option, and recommended response on receiving the option.

- Pasi

---

From: Joe Touch <[email-masked]>
Date: Thu, 18 Oct 2007 07:19:11 -0700

Pasi Sarolahti wrote:
> Ok, I think you are right that it is hard to come up with well-defined
> experiments that would give some additional technical information about
> the UTO. But I don't understand where this requirement for experiments
> comes from. I also ask, because this "what is the experiment?" question
> has come up quite a few times during the past couple of years for
> Experimental documents in different WGs, and RFC 2026 does not say
> anything about experiments:
> 
>    The "Experimental" designation typically denotes a specification that
>    is part of some research or development effort.  Such a specification

That has rarely been the case; more typically, the 'research' is being
conducted by the proposer and the Internet community at large to
determine the efficacy of a spec, and the 'experiment' is part of that
'research or development effort'.

Joe

---

From: "Caitlin Bestler" <[email-masked]>
Date: Thu, 18 Oct 2007 13:36:07 -0400

UTO manages to provide value for those who want it with
no adverse impact on existing implementations. It is also
easy for stacks (and stack offloads) to add support.

So I fully support allowing this to proceed to standard.

---

From: Joe Touch <[email-masked]>
Date: Thu, 18 Oct 2007 16:10:14 -0700

I had a few minor points; I don't think any are showstoppers, but the WG
might consider whether it'd be useful to fix these before this goes out
the door. I think it should, since some are holes in behavior that ought
to be defined.

---

- MUST/MAY/SHOULD on the whole option
	I didn't see this; I'm not sure I care what the decision is,
	but it should be stated in the abstract and intro

- sec 3 at "Before opening..." for two paragraphs
This section uses 2119 language in ways I don't understand. An app that
wishes to do something SHOULD? If it wishes to do something, it "DOES"
it. I don't see a reason for 2119 there, or MAY at the end of that
paragraph, or MAY in the next. In these cases, there are choices
involved that determine what happens. You cannot dictated userland /
application behavior when defining these events in this document, IMO.

- sec 3 "In addition to"
There is no reason in requiring (via SHOULD) a refresh of
SYN-coordinated state. Either that state is coordinated, or it is not.
If not, then the connection is in error.

- sec 3 "A host that supports"
What happens if there is no option space in the next outgoing segment?
What happens if there is no option space at all? Do you tell the app? Do
you do anything special? IMO, this deserves a separate section rather
than just a note at the end of 3.0

- sec 3.1 "When a host"
"In this case, they SHOULD" - they who?

- sec 3.1 "In general"
This is contrary to the default values. CHANGEABLE defaults to true, but
ENABLED defaults to false. That means, IMO, that received UTO options
would be dropped, not acted upon, in the default case.

- sec 6
I thought this section should say a few specific things:

1) There are no new IANA namespaces. (which you say)

2) This doc requires IANA to assign a value from the TCP Option
namespace, to be referred in section 3.3 accordingly. (which you don't
quite ask for!)

-----------------------------------------------------------------------

Very minor points, if an edit occurs:

- intro near "applications can set"
apps typically set/change this param via the OPEN/SEND socket calls, not
the TCP OPEN/SEND API. The two use the same names; it'd be useful to be
clear here.

- intro/throughout
'other end' seems informal; other end of the TCP connection, etc.?

- intro last two paragraphs
these would be useful to move earlier

- sec 3
'per-application basis' -> 'per-connection basis'

- sec 3 at LOCAL_UTO
it should be more clear what the relationship between the system-wide
USER TIMEOUT and local USER_TIMEOUT is; alternately, a list of the
global vars would be useful.

- sec 3.1 "This means that"
This paragraph is part of a discussion on checks and limits; this should
not be the first place you introduce the "max" concept.

- hysteresis?
The doc doesn't describe how quickly the UTO can be changed by the
remote end or application. Does it matter, e.g., for security reasons?

- sec 3.2 "The host requirements rfc"
"seconds is RECOMMENDED" -> append "in that RFC" (you're not doing the
recommending; you're quoting 1122)

- sec 3.2
If you retransmit the option and attach it to a particular byte, and the
byte is ACKd, then why don't you KNOW the option has been received
(i.e., second part of the handshake)? if the other end receives data
over 1 window away from that byte, why doesn't it KNOW the source end
knows it has been recieved (i.e., third part of the handshake)?

About retransmission, IMO, it SHOULD be done - or else what's the point
of this?

- sec 3.4
"TCP implementations" -> "Current TCP implementations"

- sec 4.1
Firewalls may parse this option in unencrypted TCP segments only.

- sec 5
in addition to IPsec, cite RFC2385 for peer authentication

---

From: Lars Eggert <[email-masked]>
Date: Tue, 30 Oct 2007 17:31:21 +0200

> 	but it should be stated in the abstract and intro

I'd like to ask the opinion of the WG here: Should we recommend that  
all stacks implement UTO as a PS? Or only some stacks, and in this  
case, which ones?

(Alternatively, if we're going for Experimental with this document,  
this question is moot, because implicitly only hosts desiring to  
experiment with this option need to implement it.)

> application behavior when defining these events in this document, IMO.

I've rephrased these sentences to not use 211 terms.

> If not, then the connection is in error.

The intent was to make UTO work with SYN cookie implementations that  
can't encode whether a UTO option was present in the cookie, by  
including the option also in the first non-SYN packets. It may also  
help when the option space in the SYN packets was too full to allow  
UTO to be included. So there is some use to doing this. We could  
state that including UTo in the first non-SYN packets is only useful  
if the option was not included in the SYN?

> than just a note at the end of 3.0

I don't know what we can say about this - this is a general issue  
with TCP. What should be done depends a lot on which other options  
are in use for a particular connection. Maybe UTO is considered more  
important than some options, but less important than others. Which  
options do you include and which ones do you not include, generally?  
Hard to say.

> "In this case, they SHOULD" - they who?

s/they/TCP/ - fixed

> would be dropped, not acted upon, in the default case.

When the draft was targeted as Experimental, having ENABLED default  
to false was needed, so that hosts would need to actively enable the  
mechanism to participate to experiment with the option.

If we're going with PS (are we?), ENABLED should default to true, I  
guess.

> namespace, to be referred in section 3.3 accordingly. (which you don't

Right - I made this explicit.

> Very minor points, if an edit occurs:
...

> not be the first place you introduce the "max" concept.

It's not - the formula further up introduces it.

> remote end or application. Does it matter, e.g., for security reasons?

I don't think there are security implications here. The only result  
of changing the value very frequently is that all segments have the  
option attached, so there is some mild increase in bandwidth use. But  
the app can always just send more data anyway :-)

> knows it has been recieved (i.e., third part of the handshake)?

*If* you do this, yes, but there was consensus earlier that the WG  
didn't want the UTO exchange to be reliable, which is why this  
"attaching" the option to a byte is a MAY.

> About retransmission, IMO, it SHOULD be done - or else what's the  

Is this related to your previous comment? If so, there was consensus  
to not make UTO reliable, i.e., retransmit lost options.

Thanks!

Lars

---

From: Joe Touch <[email-masked]>
Date: Tue, 30 Oct 2007 09:07:40 -0700

...
> including the option also in the first non-SYN packets. 

That should be deemed non-compliant. The point of the SYN cookie is to
reestablish the entirety of state that would have been established by
the SYN; if the cookie can't do that, a cookie should not be used.

TCP has no provisions for post-SYN establishment of new connection state
AFAIK. Requiring this of this option would be new, and, IMO, a bit
confusing for designers. What happens if the post-SYN packet lacks the
option? do you declare state mis-synchronization and drop it?

> It may also help
> when the option space in the SYN packets was too full to allow UTO to be
> included.

IMO, if that's a concern, then make sure the UTO MUST NOT be included in
the SYN. I.e., it's in one place or the other; once in place, it
shouldn't be repeated in subsequent segments - only replayed in segments
being retransmitted.

> So there is some use to doing this. We could state that
> including UTo in the first non-SYN packets is only useful if the option
> was not included in the SYN?

I'd prefer that, adjusted to say "if the option was not included in the
SYN due to space limitations".

> I don't know what we can say about this - this is a general issue with
> TCP. What should be done depends a lot on which other options are in use
> for a particular connection. Maybe UTO is considered more important than
> some options, but less important than others. Which options do you
> include and which ones do you not include, generally? Hard to say.

I'm not making an assertion as to what to do, only that the doc ought to
consider the issue. I'll suggest that it ought to send it within 2
segments OR indicate to the application that it has failed; the latter
requires a new API variable, though.

> When the draft was targeted as Experimental, having ENABLED default to
> false was needed, so that hosts would need to actively enable the
> If we're going with PS (are we?), ENABLED should default to true, I guess.

Sure - making the two consistent is the issue.

...
> It's not - the formula further up introduces it.

It might be useful to introduce the issue in prose first. The reason for
using max is the issue, and it's not clear by just stating the formula.

> I don't think there are security implications here. The only result of
> changing the value very frequently is that all segments have the option
> attached, so there is some mild increase in bandwidth use. But the app
> can always just send more data anyway :-)

Can someone on the path do something you don't want to your connection
by tacking this option on?

> "attaching" the option to a byte is a MAY.

Ah - it might be useful to explain that. I thought MAY implied that the
information about reliability was in doubt, rather than that the use of
the attachment was optional but would provide reliable UTO exchange if used.

> Is this related to your previous comment? If so, there was consensus to
> not make UTO reliable, i.e., retransmit lost options.

I have no idea what the point of an unreliable option on a reliable
transport protocol means. IMO, options should be retransmitted when
their associated segments are. The control protocol ought to be at least
as robust as the data. Although I appreciate that UTO isn't as critical
as some other options or flags, introducing nondeterminism at this level
doesn't seem appropriate, IMO.

I.e., I think there are separate questions:

	1) is UTO critical enough to ensure correct exchange via
	an explicitly ack'd handshake
		no - I agree with the WG

	2) should options associated with a segment be retransmitted
	with that segment in general in TCP
		I think the answer to this should be YES, always,
		but I don't think it was asked.

Joe

---

From: "Caitlin Bestler" <[email-masked]>
Date: Tue, 30 Oct 2007 13:07:47 -0400

-----Original Message-----
From: Joe Touch [mailto:[email-masked]] 
Sent: Tuesday, October 30, 2007 9:08 AM
To: Lars Eggert
Cc: [email-masked]
Subject: Re: [tcpm] WGLC for UTO

...

----------End of Original Message
--------------------------------------------------------

The idea here is to recognize that existing stacks establish the TCB at
two different times: on first SYN or on the Ack of the SYN-ACK.

To be very pedantic, the TCB is *always* established when the SYN is
received. It's just that a SYN Cookie encodes the "TCB" in the SYN
cookie value and "stores" the TCB on the network.

Which would be a problem with UTO if the UTO option were only present
in the SYN cookie. Basically there isn't any more room in the SYN
Cookie without stealing information from elsewhere (such as timing
resolution or cryptographic quality).

That won't happen. Instead anyone using SYN Cookies will simply NEVER
support UTO for *any* connection (in which case whether it was in the
SYN is irrelevant, which does encode very efficiently).

The redundant transmission of the UTO option allows a receiver that
uses SYN Cookies to establish connections safely to enable that support
only when it is *actually* creating the full-sized TCB. This same
benefit
actually applies to any strategy where allocation of a full TCB is
deferred
until after the round-trip (which is a generally recommended practice,
although there can be debate about how much the proto-TCB should be
condensed and where it should be stored).

As to Lars comment, the idea of having it both places is to allow 
implementations that create the full TCB on receipt of the SYN to
properly create the TCB. Currently, most software based SYN Cookies
implementations include a "no attack detected" mode where the TCBs
are created immediately.

---

From: Joe Touch <[email-masked]>
Date: Tue, 30 Oct 2007 10:15:12 -0700

> ----------End of Original Message

TCP with SYN cookies must decline connections whose state it cannot
sufficiently encode in a cookie.

> SYN is irrelevant, which does encode very efficiently).

That's inappropriate - the end that ACKs a SYN is responsible for making
sure the appropriate TCB is established. AFAIK, we don't have a signal
for the client to know that cookies are used and to retransmit options
on the next segment, so this would break ALL options established without
ACK in a SYN.

That may require UTO never be sent in a SYN at all. I don't see why that
would be a large problem, and it's cleaner than creating a situation
where a cookie doesn't restore full state.

(i.e., presuming UTO the only option in a SYN that can succeed
unacknowledged?)

> condensed and where it should be stored).

The TCB needs to encode enough information to establish the state that
the SYN-ACK explicitly agrees to. It's not up to the endpoint to decide
not to keep some of that state - once it's ACK'd, it's ACKd.

> implementations include a "no attack detected" mode where the TCBs

If this is the only option that has this property (silent source
assertion of a SYN option), then the appropriate solution is to prohibit
it from SYNs, IMO.

Joe

---

From: "Caitlin Bestler" <[email-masked]>
Date: Tue, 30 Oct 2007 15:05:57 -0400

Joe Touch wrote:

.

> assertion of a SYN option), then the appropriate solution is to
> prohibit it from SYNs, IMO.

> Joe

If you're allocated a "full" TCB based on only an unconfirmed SYN
then you probably would not mind allocating one that is UTO capable.

So I don't really see any harm in prohibiting it from the SYN, unless
it's presence there is needed to keep connection tracking middleboxes
happy or somesuch. The passive endpoint certainly does not need it
to be in the SYN. Any timeouts before the connection is fully
established
are going to have their own logic anyway.

---

From: Lars Eggert <[email-masked]>
Date: Wed, 31 Oct 2007 09:47:37 +0200

> the SYN; if the cookie can't do that, a cookie should not be used.

Well, if the SYN requests (many) options and the receiver cannot  
encode them all in the cookie, it can always reply with a SYN-ACK  
that only echoes those that it can and does encode. That's compliant,  
no?

> option? do you declare state mis-synchronization and drop it?

No - the UTO option is purely advisory and not transmitted reliably.  
We had a long thread a while ago on the list that boiled down to that  
consensus. (I can dig it up if you like me to.) The gist was that it  
should be OK these days to send new options during a connection, even  
if the SYN exchange didn't negotiate their use.

> SYN due to space limitations".

That can certainly be done.

>> with

We can add that TCP should try for a few segments to include a TO  
option if it wants to send one, but I don't think notifying the  
application on failure is necessary, because UTO options are advisory  
and not transmitted reliably. Not being able to include it locally is  
equivalent to having the segment that it was included on being  
dropped in the network.

> Sure - making the two consistent is the issue.

Will do, as soon as the chairs declare consensus on which way they  
see the WG consensus go.

> by tacking this option on?

So that's a different question than your original one, which was  
changing the value very frequently.

An attacker that adds or modifies the content of UTO options may be  
able to affect how long the ends keep the connection alive. Since UTO  
is advisory, an attacker can't really do anything to the connection  
that couldn't happen anyway. And the security properties of UTO are  
similar to other TCP options (window scaling, timestamps), in that  
none of them are authenticated or encrypted.

> the attachment was optional but would provide reliable UTO exchange  

The MAY is about that even though the spec says that an UTO is  
transmitted unreliably, *if* an implementation really wanted to, it  
could try to implement some local mechanisms to make transmission of  
its UTOs to the peer more reliable. (But it can't enforce reliability  
in the other direction.)

> doesn't seem appropriate, IMO.

We had a long discussion on this a year or two ago on this list. The  
outcome was that because UTO is advisory, a simple, unreliable  
transmission is sufficient. We can certainly revisit this decision,  
but I'd personally would like to see strong WG consensus on changing  
this pretty central assumption behind UTO this late in the game.

Lars

---

From: Joe Touch <[email-masked]>
Date: Wed, 31 Oct 2007 08:54:59 -0700

Lars Eggert wrote:
> Well, if the SYN requests (many) options and the receiver cannot encode
> them all in the cookie, it can always reply with a SYN-ACK that only
> echoes those that it can and does encode. That's compliant, no?

It is, but only if current SYN cookie responses for stacks that don't
support UTO could be detected. I'm not sure that's possible.

> No - the UTO option is purely advisory and not transmitted reliably. We
> had a long thread a while ago on the list that boiled down to that
> should be OK these days to send new options during a connection, even if
> the SYN exchange didn't negotiate their use.

Then there's no point in having the SYN cookie encode anything.
Receivers that implement SYN cookies MAY drop the option; senders
sending UTO have no reason to resend, since it's 'advisory and not
transmitted reliably'.

I.e., you can't have it both ways. If this is truly unreliable, then
there is NO reason to ever retransmit it.

...
> We can add that TCP should try for a few segments to include a TO option
> if it wants to send one, but I don't think notifying the application on
> failure is necessary, because UTO options are advisory and not
> transmitted reliably. Not being able to include it locally is equivalent
> to having the segment that it was included on being dropped in the network.

Again, if that's the case, then try to send it ONCE. Never retry -
there's no point.

...
> An attacker that adds or modifies the content of UTO options may be able
> to affect how long the ends keep the connection alive. Since UTO is
> advisory, an attacker can't really do anything to the connection that
> couldn't happen anyway. 

I'm not sure that's true; even though it's advisory, it can cause a
change in behavior - if not, then there's no point in sending it. An
attacker could cause large UTOs for receivers that act on the option,
which could cause a DOS opportunity.

> And the security properties of UTO are similar
> to other TCP options (window scaling, timestamps), in that none of them
> are authenticated or encrypted.

Yes, but the implications of changing these others are different - and
each should be explained in their respective security sections. This
security section should say what happens when an attacker changes THIS
option.

...
> transmission is sufficient. We can certainly revisit this decision, but
> I'd personally would like to see strong WG consensus on changing this
> pretty central assumption behind UTO this late in the game.

Agreed.

Thanks,

Joe

---

From: "Caitlin Bestler" <[email-masked]>
Date: Wed, 31 Oct 2007 12:10:05 -0400

----------- End of Original Message ---------------------

Compliant, yes, but not desirable. It would mean that any system
that had enabled SYN Cookie mode would stop accepting UTOs.
This is not a very intuitive model for application developers, and
would likely just add one more log to the "UTO is not reliable" fire
and discourage it's use.

What I think we want is for any system in the passive role that is
*capable* of doing UTO to refrain from doing any action that would
block enabling UTO on the first non-SYN received.

It is especially important that the passive side not be *obligated*
to remember that there was no UTO option in the SYN packet, as
in *expecting* it to reject later packets for having improper options.
That would essentially mean that the system would have to disable
UTO *permanently* as soon as it enabled SYN Cookies once (unless
it was actually going to track which connections were established
when and check that in real-time).

My understanding of including the UTO in both the SYN as well
as the first non-SYN was that network monitoring equipment (or
software) would expect any negotiated option to have been present
in the SYN and likely would not know that UTO was an exception.

---

From: Lars Eggert <[email-masked]>
Date: Wed, 31 Oct 2007 18:30:47 +0200

On 2007-10-31, at 17:54, ext Joe Touch wrote:
>> encode

Can you rephrase? I don't follow. (Maybe it's too late in the day here.)

> Then there's no point in having the SYN cookie encode anything.

If the SYN cookie could always encode the UTO value, we didn't need  
to also include a UTO with the first non-SYN packet. But I don't know  
of any SYN cookie encoding that can. (And SYN cookies aren't  
standardized anyway.)

All this is a very narrow corner case anyway. The main motivation for  
sending UTO twice (in the SYN and first non-SYN segment) was to make  
sure it takes effect as early as possible in the connection. If this  
is a showstopper, we could remove the recommendation to send it in  
the SYNs and only recommend to send it in the first non-SYN.

> there is NO reason to ever retransmit it.

The reason we special-cased this is that we know of a case (SYN  
cookies) where a UTO on the SYN will be "dropped" (because it can't  
be encoded). As I said above, we can remove this special case, if  
people feel this is cleaner.

>> option

It was YOUR suggestion in an earlier email to try and include a UTO  
in one of a small sequence of a few consecutive segments if option  
space limitation prevented sending it on the next outgoing segment.  
The draft doesn't have this.

> which could cause a DOS opportunity.

Sure, but nothing in TCP is resistant against on-path attackers. We  
can certainly mention that there is a danger, but an on-path attacker  
can do all sorts of other things to a connection.

>> pretty central assumption behind UTO this late in the game.

Noted.

Thanks,
Lars