RE: [tcpm] WGLC for UTO

-----Original Message-----
From: Joe Touch [mailto:touch@ISI.EDU] 
Sent: Tuesday, October 30, 2007 9:08 AM
To: Lars Eggert
Cc: tcpm@ietf.org
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).

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

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

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.

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm