On Thu, Jul 28, 2016 at 6:07 PM, Joe Touch <[email protected]> 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
_______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
