Re: [tcpm] WGLC for UTO

On 2007-10-31, at 17:54, ext Joe Touch wrote:
> Lars Eggert wrote:
>> 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?
>
> 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.

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

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

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

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.

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

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.

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

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.

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

Noted.

Thanks,
Lars

Re: [tcpm] WGLC for UTO

Attachment: smime.p7s