RE: [tcpm] WGLC for UTO

"Caitlin Bestler" <> Wed, 31 October 2007 16:10 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1InG9N-00049u-4P; Wed, 31 Oct 2007 12:10:37 -0400
Received: from tcpm by with local (Exim 4.43) id 1InG9L-00044V-Bm for; Wed, 31 Oct 2007 12:10:35 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1InG9L-000419-28 for; Wed, 31 Oct 2007 12:10:35 -0400
Received: from ([] by with esmtp (Exim 4.43) id 1InG97-0005Xi-3d for; Wed, 31 Oct 2007 12:10:27 -0400
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [tcpm] WGLC for UTO
Date: Wed, 31 Oct 2007 12:10:05 -0400
Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD7701F4C10D@nekter>
Thread-Topic: [tcpm] WGLC for UTO
Thread-Index: Acgbk34S8xubRQBjSQOfPDJoLUd+/AAQ+5y/
References: <> <> <78C9135A3D2ECE4B8162EBDCE82CAD77026345DE@nekter> <> <> <> <>
From: Caitlin Bestler <>
To: Lars Eggert <>, ext Joe Touch <touch@ISI.EDU>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8
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="===============0183944556=="

-----Original Message-----
From: Lars Eggert []
Sent: Wed 10/31/2007 12:47 AM
To: ext Joe Touch
Subject: 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,  

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

tcpm mailing list