Improve ALPN support

[Tratcher]

ALPN support is present but incomplete in the current implementation:

1. The client needs to be able to provide multiple ALPN values. Today it's restricted to one.
2. The server needs to be able to read multiple values from the client during the handshake (e.g. when selecting which server certificate to use).
3. The server either needs to be able to provide multiple values and have the negotiation resolved internally OR it needs to be documented that the server user is responsible for selecting a single protocol from the client's list (or refusing the connection).
4. The client API uses chars but the server uses bytes. ALPN values are spec'd as opaque bytes and the API should reflect that. Spec: "The precise set of octet values that identifies the protocol."
5. After the connection is established the client and server both need to be able to query what ALPN value was negotiated.

[nibanks]

The current design allows for multiple ALPNs to be used on the server side by creating multiple listeners in different sessions (one for each ALPN). Since each listener only registers for a single ALPN, you know which ALPN is negotiated based on which listener is given the NEW_CONNECTION. The AlpnList here is in TLS format, and does contain the full list.

Besides that, I generally agree with all your other statements. It's been on my TODO list for some time to clean up how we deal with ALPNs at the API layer.

[Tratcher]

The AlpnList here is in TLS format, and does contain the full list.

Great, that just need documentation then.

The current design allows for multiple ALPNs to be used on the server side by creating multiple listeners in different sessions (one for each ALPN). Since each listener only registers for a single ALPN, you know which ALPN is negotiated based on which listener is given the NEW_CONNECTION

Can you have multiple listeners on the same IP+port?

This model precludes allowing the server to make a dynamic decision about ALPNs after receiving the Client Hello, such as using a different ALPN depending on the SNI information.

[nibanks]

Can you have multiple listeners on the same IP+port?

Yes, for the same process you can unlimited listeners (for different/unique ALPNs) on the same IP+port. We don't currently support cross-process sharing of the IP+port though.

This model precludes allowing the server to make a dynamic decision about ALPNs after receiving the Client Hello, such as using a different ALPN depending on the SNI information.

Correct. It is not a goal to be able to pick the ALPN as a result of the requested SNI. The listener is first chosen from the currently registered based on the connection's requested IP, UDP port and ALPN list. Once the listener is chosen, the NEW_CONNECTION event is delivered and then the listener can decide which certificate to provide. To add SNI to the mix would complicate the transport logic considerably.

[Tratcher]

Correct. It is not a goal to be able to pick the ALPN as a result of the requested SNI.

I understand that's the current design and we're not blocked by it, but expect customers to ask for dynamic ALPN at some point, they've already asked for every other setting to be dynamic.

What kind of diagnostics does the app get if a new connection does not match any registered ALPNs?

[nibanks]

What kind of diagnostics does the app get if a new connection does not match any registered ALPNs?

The (server) app is not directly informed of any failed connection attempts due to requests for unregistered ALPNs. This follows the similar pattern of not informing the server of an attempt to connect to a UDP port it wasn't listening to.

I understand that's the current design and we're not blocked by it, but expect customers to ask for dynamic ALPN at some point, they've already asked for every other setting to be dynamic.

As far as supporting dynamic ALPN support, that would greatly complicate the design msquic currently has, and I'd push back hard until a real good reason for supporting this was provided.