TLSRoute match ALPN

[dboslee]

👋 Hey everyone, I work at Teleport and have been looking at Gateway API to replace an internal project we built to handle routing many services through a single gateway.

Our specific use case requires TLS inspection to route based on the TLS SNI and ALPN extensions.

It seems the TLSRoute currently only supports routing based on the SNI so I would like to start the discussion of adding something like the following to the TLSRoute spec:

type TLSRouteRule struct {
    Matches []TLSRouteMatch `json:"matches.omitempty"`
    BackendRefs []BackendRef `json:"backendRefs,omitempty"`
}

type TLSRouteMatch struct {
    ALPN []TLSApplicationProtocol `json:"alpn.omitempty"`
}

type TLSApplicationProtocol string

This would allow service owners to specify a list of ALPNs to match and route to a given set of BackendRefs.

If this is something the community is in favor of I would be happy to write up a more exhaustive GEP and get involved in this project.

[howardjohn]

Just curious, can you expand on why you match on ALPN?

[dboslee]

We have multiple protocols wrapped in TLS using a single port and route to different services based on the ALPN. There are some more specifics here.

[howardjohn]

Just curious, why not match on SNI?

[dboslee]

Sorry missed this reply, we do use SNI to handle multi tenancy but use ALPN to route to different services for each tenant.

[youngnick]

On a (very) quick review, this looks reasonable to me:

• ALPN is roughly equivalent to SNI in terms of metadata for routing in that you don't have to terminate TLS to have it available, so it fits the TLSRoute use case there
• This is an additive change, so we don't need an API revision.

I'm low bandwidth at the moment (travelling), so I probably won't make the meeting next week either, but this sounds pretty reasonable to me, especially given that TLSRoute hasn't graduated yet.

[howardjohn]

Isn't ALPN a negotiation? If we are passing through the TLS handshake, we need to pick the destination before we can negotiate. So we are really not routing on the selected ALPN, but the offered ones? Is that accurate?

What happens if I had match for a and b, and I get a request with alpn: [a,b]? Do we prioritize it by order? Is this something supported by proxies?

[dboslee]

Yes this is accurate. And I agree with prioritizing by order as the RFC states:

"ProtocolNameList" contains the list of protocols advertised by the client, in descending order of preference.

So the first application protocol should be the clients preference. However I am not certain if all proxies would enforce this the same way. Would it make sense to leave this up to the implementation?

[howardjohn]

Do we have some info on what proxies support this? I have only found Envoy personally

[dboslee]

I have used nginx and envoy to do alpn based routing. See the nginx ssl_preread_module docs. I've also looked at traefik which seems to support it here although I've never used it personally.

If we're worried to few proxies support this, is there a good way for extending the API for implementation specific features?

[youngnick]

If we're worried to few proxies support this, is there a good way for extending the API for implementation specific features?

For most other areas, the answer is "yes, totally". But because this will require adding some fields to TLSRoute, unfortunately, we're stuck. That said, as I said above, I'm definitely in favor of exploring this more.

[youngnick]

Any chance you could bring this to a community meeting @dboslee? I'll add it to the agenda for tomorrow, but as it's President's Day in the US, I expect a quieter meeting. I think if we can get some more thumbs-up here, then you're clear to go for at least an initial clarification GEP that includes the What and Why, but leaves aside the How.

(Edit: that is, Step 2 on https://gateway-api.sigs.k8s.io/geps/overview/)

[dboslee]

Sound good. I should be able to make the meeting today

[shaneutt]

NGinx and Envoy can do this, but it is still not common across downstream implementations. I'm generally in favor of the next step here being a GEP to suggest adding it as an extended and experimental feature and we can spend some time in that state to see what implementations end up doing with it. 👍