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

[Kyle Rose <[e-mail]>]

On Thu, Jul 28, 2016 at 6:07 PM, Joe Touch <[e-mail]> wrote:

> On 7/28/2016 3:01 PM, Kyle Rose wrote:
> > I still don't have a good feel for what folks like Joe are
> > recommending re: dealing with a B that doesn't understand ENO. If B is
> > suddenly not ENO-aware,
> Not suddenly. During the SYN exchange.
>

Sorry, by "suddenly" I mean that an IP that formerly negotiated ENO gets
swapped out for one that doesn't understand ENO: this could for example be
the result of a load balancer sending the request to a machine with an
older kernel.

Note that it must be the case that the stack in question doesn't understand
ENO, not just that it is now unwilling to negotiate ENO. If it knows about
ENO but just doesn't want to negotiate it, it knows enough to throw away
the SYN data.


> Or are you not dealing with legacy endpoints that don't speak ENO? The
> goal there is to fail gracefully - either fail to support ENO and
> proceed, kill the connection, etc. But you should never start delivering
> data to the application by accident - that's something you can't roll back.
>
> BTW, you DO need to deal with an endpoint that spoke ENO before but does
> not now (for two different connections). That could happen because of an
> OS revision or because the connection configured differently anyway.
>

Again, I would put the "machine understands but does not want to negotiate
ENO" case into the supportable category, because we can completely define
the behavior of endpoints that understand ENO. I'm worried about the
interoperability case with legacy kernels that don't even know what ENO is.

These two paragraphs do get to what I was asking. I agree we do need to
deal with them, but what is the space of reasonable solutions? When an
endpoint *could* deliver garbage to an application, as any legacy TCP stack
could according to the spec, we can never send encrypted data in the SYN if
we are unwilling to retain and/or assume some state about peers. I see four
main options:

(1) Don't ever send data in the SYN. This is easiest, but sacrifices ENO
support for SYN data forever for the sake of full interoperability with
legacy TCP stacks, even with hosts a user knows a priori support ENO. This
is not my preference.

(2) Retain knowledge of ENO support for an IP and assume it on resumption
attempts, throwing that state away if ENO is not negotiated. This case
means accepting that we'll have to retry the connection in cases when a
server supporting ENO and one knowing nothing about ENO share an IP.

(3) Require signaling from the server on a previous connection. This case
is a more explicit form of (2), and carries the same dangers, but puts the
configuration burden on the server administrator to assert that, yes, all
servers responding for this IP support ENO.

(4) Require signaling from the client application. This allows a client to
decide whether to support SYN data based on a priori knowledge of the
server's support for ENO.

Kyle