Re: [tcpinc] TCP's treatment of data in SYN packets

[Joe Touch <[e-mail]>]

On 7/30/2016 4:26 PM, David Mazieres expires 2016-10-28 PDT wrote:
> Joe Touch <[e-mail]> writes:
>
>>> On Jul 30, 2016, at 10:20 AM, David Mazieres <[e-mail]> wrote:
>>>
>>> And mandating no
>>> buffering of discarded SYN data is a good way to do that...
>> You can do that for ENO, but you cannot assert requirements for legacy
>> stacks.
>>
>> The problem is that you keep saying you "know" when the other end
>> supports ENO based on previous state, but if that were really true you
>> wouldn't need to negotiate ENO in the 3WHS.
> No, I'm saying *if* the application knows the other end of a connection
> supports ENO,
It doesn't until the SYN-ACK.

Let me put it this way - if you know the other end supports ENO, then
you clearly don't need to negotiate it in the SYN. Is that what you do?

>  and in particular *if* the application intends to abort an
> unencrypted connection anyway, 
TCP needs to be the one making that decision, because an "app" that
doesn't make that decision could be experiencing TCP semantics that are
incorrect.

> *then* it probably makes sense for the
> application to send data in a SYN segment.
An app doesn't make that decision - it can do things to prevent it from
happening (i.e., waiting for the connection to be open before writing
data), but it can't force this behavior. It's not in the user interface
defined in RFC793, so you can't assume it (unless you're creating this
definition solely for ENO, which seems far out of scope to me).

> You are right that if we could have an internet flag day, we wouldn't
> need TCP-ENO at all.  But getting from the status quo to our goal of
> ~100% encrypted TCP traffic requires multiple stages--first
> opportunistic encryption, then shimming in some sort of endpoint
> authentication, finally having applications or middleware drop
> unauthenticated connections. 

That's one possible future. Another is one where TCPINC dies off and is
replaced by something else, either at the TCP layer or IP.

>  If TCPINC succeeds, people may, for
> example, configure NFS servers not to talk to workstations over
> unencrypted TCP.  By that point it makes to discuss TEPs supporting SYN
> data, but not now.  Now the question before the working group is how ENO
> should avoid preempting/complicating those future discussions.
It also needs to avoid adverse interactions with not using ENO at all.

> So far I haven't heard any objections to anything before the last
> paragraph of section 4.7, which means the discussion needs to focus on
> that last paragraph, namely:
First, just because I say the food is salty, doesn't mean it's great if
you fix the salt level. But yes, this part needs fixing.

>    Using data in SYN segments deviates from TCP semantics and can cause
>    problems with middleboxes or non-compliant TCP hosts.  Hence, all
>    TEPs SHOULD support a normal mode of operation that does not make use
>    of data in SYN segments.  Moreover, implementations SHOULD employ SYN
>    data only if explicitly requested by the application or in cases
>    where such use is highly unlikely to pose problems.
>
> I think you've objected to the word "using" as too vague, and maybe
Yes..

> would prefer "standard TCP semantics" to make clear we aren't talking
> about TFO.  
Yes.

Then there's the part about middleboxes (it's useless to make "laws for
the lawless", i.e., if your goal is to modify TCP in ways that are
compliant with all middleboxes, you can stop now).

Then there's the part about non-compliant hosts - actually, "using" data
in the SYN violates the semantics of TCP for *compliant* hosts.

> You did not answer my question about whether the word
> "consuming" is better than "using". 
It's needlessly anthropomorphic.

The answer is simple - if the receiver (ENO or otherwise) uses the
information in the SYN data (i.e., it changes its behavior in any way
based on that content), then it MUST happen after TFO only (at this
point) or a true equivalent. There is *no* aspect of ENO that currently
supports that level of equivalence - i.e., *validated* by a SYN cookie.
You don't get to make that assumption based on any "belief" of the other
end's state

>  You also did not answer my question
> about whether you would support a sentence saying active openers SHOULD
> abort non-ENO connections if they have sent SYN data (though at this
> point I think such a sentence would be good). 
MUST, and it MUST occur inside TCP. You can't assume that happens at the
application (user) layer.

Note that I already said this when I gave you two choices:
a) never send anything you can't retract in the SYN-ACK
or
b) always abort - inside TCP - a connection where you would have needed
to do that retraction

> Your arguments seem
> primarily directed at some hypothetical future straw-man TEP sending
> encrypted SYN data to non-ENO aware hosts, but no existing TEP proposal
> does that and more importantly that is not the question at hand.
You seem to be operating under the mistaken belief that sending data to
the same IP address twice always reaches the same TCP context. I.e.,
when you send TCP-encrypted SYN data to a host, you have NO WAY OF
KNOWING whether that host is ENO-capable until AFTER the SYN-ACK.

Otherwise, if you did COULD already know that, you clearly wouldn't need
the ENO flag at all. Since you need that flag, then you need to consider
the case where it is wrong.

> So on the topic of TCP-ENO, do you have specific suggestions for
> improving the last paragraph of section 4.7 of the draft?
>
>

See above. Note that this does not imply that I consider the entire
draft otherwise correct.

Joe