Re: [tcpm] WGLC for UTO

Joe Touch <touch@ISI.EDU> Tue, 30 October 2007 17:15 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1Imugd-0006uJ-Vv; Tue, 30 Oct 2007 13:15:31 -0400
Received: from tcpm by with local (Exim 4.43) id 1Imugc-0006u9-MP for; Tue, 30 Oct 2007 13:15:30 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1Imugc-0006u1-Cs for; Tue, 30 Oct 2007 13:15:30 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1Imugb-000457-3p for; Tue, 30 Oct 2007 13:15:30 -0400
Received: from [] ( []) by (8.13.8/8.13.8) with ESMTP id l9UHFD4e014429; Tue, 30 Oct 2007 10:15:14 -0700 (PDT)
Message-ID: <>
Date: Tue, 30 Oct 2007 10:15:12 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird (Windows/20070728)
MIME-Version: 1.0
To: Caitlin Bestler <>
Subject: Re: [tcpm] WGLC for UTO
References: <> <><78C9135A3D2ECE4B8162EBDCE82CAD77026345DE@nekter><><> <> <78C9135A3D2ECE4B8162EBDCE82CAD77027653E9@nekter>
In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD77027653E9@nekter>
X-Enigmail-Version: 0.95.4
X-ISI-4-43-8-MailScanner: Found to be clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2
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="===============0664191691=="

Caitlin Bestler wrote:
> -----Original Message-----
> From: Joe Touch [mailto:touch@ISI.EDU] 
> Sent: Tuesday, October 30, 2007 9:08 AM
> To: Lars Eggert
> Cc:
> Subject: Re: [tcpm] WGLC for UTO
> Lars Eggert wrote:
>> On 2007-10-19, at 2:10, ext Joe Touch wrote:
> ...
>>> - 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.
>> 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.
> 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?
> ----------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).

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

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

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

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

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.

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

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.


tcpm mailing list