Ideas for TCP, TLS, and UDP Routing

[robscott]

At present TCP, TLS, and UDP Routes are all almost identical, with the only meaningful difference being that TLSRoute allows for a second layer of SNI matching (intersecting with Gateway Listeners when attaching to Gateways).

As we want to move this area of the API forward and avoid these concepts getting stuck in experimental channel forever, I thought it would be useful to collect potential features that we could add to these Routes in the future. If all of these potential features could apply equally to each Route type, it may be worth consolidating these APIs to avoid unnecessary duplication. If on the other hand, there are protocol specific capabilities that we may want to add in the future, it would be useful to at least write those down here so we had a clear reason for keeping these resources separate.

For the record, I'm increasingly skeptical that the additional layer of SNI matching enabled by TLSRoute is actually helpful. It was meant to mirror host matching in HTTPRoute, but SNI matching has fundamentally different characteristics that may not make sense to split across two levels. If we did end up removing that capability from TLSRoute, it would mean all three route types were identical.

I'd be particularly interested in hearing perspective from the mesh side (cc @howardjohn @keithmattix @kflynn @mikemorris) as there's not really a clear parallel for some of the constructs we're relying on Gateway for here (port + protocol matching).

[shaneutt]

Relates/overlaps with #2612.

[pleshakov]

I think this is also related #1958

[pleshakov]

Some possible TCP-specifics features

• Timeouts
• TLS between proxy and the backend

[candita]

TLSRoute is the only route that implements Passthrough, and there were some specific design decisions made in the past that required a separate route.

Personally, I think it would be ok to get rid of TLSRoute if we could then implement Passthrough routing in HTTPRoute.

[youngnick]

I think I agree here - I don't understand if we removed the SNI routing functionality from TLSRoute, where would that functionality go? Using SNI for matching without terminating the TLS connection is a very useful feature, and the only way I can see to replace it is to move this to some sort of implied matching when you're using a Listener with a hostname, and TCPRoutes attached or something. But that seems very indirect and not-explicit, unlike the current TLSRoute.

I guess I'd like to hear more on TLSRoute at least, @robscott.