Re: [tcpm] WGLC for UTO

On 2007-10-30, at 18:07, ext Joe Touch wrote:
> Lars Eggert wrote:
>> 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.
>
> 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.

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?

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

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.

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

That can certainly be done.

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

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.

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

> ...
>>> Very minor points, if an edit occurs:
>> ...
>>
>> Most of these are addressed in the next revision. But not these,  
>> so far:
>>
>>> - 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.
>>
>> 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.
>
>>> - 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?
>>
>> 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?

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.

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

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

>>> About retransmission, IMO, it SHOULD be done - or else what's the  
>>> point
>>> of this?
>>
>> 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.

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.

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

Lars

Re: [tcpm] WGLC for UTO

Attachment: smime.p7s