Re: [tcpm] WGLC for UTO

[Joe Touch <[e-mail]>]

Lars Eggert wrote:
> 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?

It is, but only if current SYN cookie responses for stacks that don't
support UTO could be detected. I'm not sure that's possible.

>> 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?
> 
> No - the UTO option is purely advisory and not transmitted reliably. We
> had a long thread a while ago on the list that boiled down to that
> consensus. (I can dig it up if you like me to.) The gist was that it
> should be OK these days to send new options during a connection, even if
> the SYN exchange didn't negotiate their use.

Then there's no point in having the SYN cookie encode anything.
Receivers that implement SYN cookies MAY drop the option; senders
sending UTO have no reason to resend, since it's 'advisory and not
transmitted reliably'.

I.e., you can't have it both ways. If this is truly unreliable, then
there is NO reason to ever retransmit it.

...
> We can add that TCP should try for a few segments to include a TO option
> if it wants to send one, but I don't think notifying the application on
> failure is necessary, because UTO options are advisory and not
> transmitted reliably. Not being able to include it locally is equivalent
> to having the segment that it was included on being dropped in the network.

Again, if that's the case, then try to send it ONCE. Never retry -
there's no point.

...
>> Can someone on the path do something you don't want to your connection
>> by tacking this option on?
> 
> So that's a different question than your original one, which was
> changing the value very frequently.
> 
> An attacker that adds or modifies the content of UTO options may be able
> to affect how long the ends keep the connection alive. Since UTO is
> advisory, an attacker can't really do anything to the connection that
> couldn't happen anyway. 

I'm not sure that's true; even though it's advisory, it can cause a
change in behavior - if not, then there's no point in sending it. An
attacker could cause large UTOs for receivers that act on the option,
which could cause a DOS opportunity.

> And the security properties of UTO are similar
> to other TCP options (window scaling, timestamps), in that none of them
> are authenticated or encrypted.

Yes, but the implications of changing these others are different - and
each should be explained in their respective security sections. This
security section should say what happens when an attacker changes THIS
option.

...
>>>> About retransmission, IMO, it SHOULD be done - or else what's the point
>>>> of this?
>>>
>>> Is this related to your previous comment? If so, there was consensus to
>>> not make UTO reliable, i.e., retransmit lost options.
>>
>> I have no idea what the point of an unreliable option on a reliable
>> transport protocol means. IMO, options should be retransmitted when
>> their associated segments are. The control protocol ought to be at least
>> as robust as the data. Although I appreciate that UTO isn't as critical
>> as some other options or flags, introducing nondeterminism at this level
>> doesn't seem appropriate, IMO.
> 
> We had a long discussion on this a year or two ago on this list. The
> outcome was that because UTO is advisory, a simple, unreliable
> transmission is sufficient. We can certainly revisit this decision, but
> I'd personally would like to see strong WG consensus on changing this
> pretty central assumption behind UTO this late in the game.

Agreed.

Thanks,

Joe

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