RE: [tcpm] WGLC for UTO

"Caitlin Bestler" <Caitlin.Bestler@neterion.com> Wed, 31 October 2007 16:10 UTC

Return-path: <tcpm-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InG9N-00049u-4P; Wed, 31 Oct 2007 12:10:37 -0400
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1InG9L-00044V-Bm for tcpm-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 12:10:35 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InG9L-000419-28 for tcpm@ietf.org; Wed, 31 Oct 2007 12:10:35 -0400
Received: from mx.neterion.com ([72.1.205.142] helo=owa.neterion.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InG97-0005Xi-3d for tcpm@ietf.org; 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>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [tcpm] WGLC for UTO
Thread-Index: Acgbk34S8xubRQBjSQOfPDJoLUd+/AAQ+5y/
References: <20071015161355.CDC992CA32C@lawyers.icir.org> <44C4AF94-CC5D-4702-914E-764583E2AADA@nokia.com> <78C9135A3D2ECE4B8162EBDCE82CAD77026345DE@nekter> <4717E7D6.7000407@isi.edu> <14C200C0-73DE-4550-A1E2-5B43BEE29BAF@nokia.com> <472756CC.8070809@isi.edu> <582A6F13-12CC-4B5C-8415-CBDAD73116AA@nokia.com>
From: "Caitlin Bestler" <Caitlin.Bestler@neterion.com>
To: "Lars Eggert" <lars.eggert@nokia.com>, "ext Joe Touch" <touch@ISI.EDU>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8
Cc: tcpm@ietf.org
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0183944556=="
Errors-To: tcpm-bounces@ietf.org



-----Original Message-----
From: Lars Eggert [mailto:lars.eggert@nokia.com]
Sent: Wed 10/31/2007 12:47 AM
To: ext Joe Touch
Cc: tcpm@ietf.org
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,  
no?

----------- 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
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm