Re: [tcpm] WGLC for UTO

Lars Eggert <> Wed, 31 October 2007 16:31 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1InGTV-0004co-0H; Wed, 31 Oct 2007 12:31:25 -0400
Received: from tcpm by with local (Exim 4.43) id 1InGTT-0004Z2-DX for; Wed, 31 Oct 2007 12:31:23 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1InGTT-0004Yu-3e for; Wed, 31 Oct 2007 12:31:23 -0400
Received: from ([] by with esmtp (Exim 4.43) id 1InGTL-0006Y1-Ee for; Wed, 31 Oct 2007 12:31:23 -0400
Received: from ( []) by (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9VGUfEk001896; Wed, 31 Oct 2007 18:31:10 +0200
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 18:30:50 +0200
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 18:30:50 +0200
Received: from ([]) by over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 18:30:49 +0200
Received: from [] ( []) by (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9VGUldL022854; Wed, 31 Oct 2007 18:30:48 +0200
In-Reply-To: <>
References: <> <> <78C9135A3D2ECE4B8162EBDCE82CAD77026345DE@nekter> <> <> <> <> <>
Mime-Version: 1.0 (Apple Message framework v752.3)
Message-Id: <>
From: Lars Eggert <>
Subject: Re: [tcpm] WGLC for UTO
Date: Wed, 31 Oct 2007 18:30:47 +0200
To: ext Joe Touch <touch@ISI.EDU>
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 31 Oct 2007 16:30:49.0230 (UTC) FILETIME=[655ADAE0:01C81BDB]
X-Nokia-AV: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: multipart/mixed; boundary="===============1920564859=="

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.


tcpm mailing list