Re: [tcpm] WGLC for UTO

[Joe Touch <[e-mail]>]

Caitlin Bestler wrote:
> 
> -----Original Message-----
> From: Joe Touch [mailto:[e-mail]] 
> Sent: Tuesday, October 30, 2007 9:08 AM
> To: Lars Eggert
> Cc: [e-mail]
> 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
unacknowledged?)

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

Joe

_______________________________________________
tcpm mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tcpm