[quicwg/base-drafts] Support for multiplexing middleboxes by requiring SNI (#1456)

[Juha-Matti Tilli <[e-mail]>]

IPv4 address exhaustion is a reality, and the truth is that IPv6 will not be deployed fast enough to be a complete solution. I have an idea where QUIC could be used to solve the IPv4 address exhaustion problem by using multiplexing middleboxes, with minimal modifications to QUIC.

The idea is that the client is forced to provide a server name indication (SNI) if the user provided the client with a DNS name instead of a raw IP address. A NAT middlebox then shares one IPv4 address for multiple servers. The middlebox makes a decision based on the SNI which internal private IPv4 address will be used. The connection will always, reliably, be forwarded to the correct internal private IPv4 address, because the client would be required to always supply an SNI. Nested middleboxes may be supported by configuring SNI matches with wildcards (e.g. server1.department1.company.com will match *.department1.company.com at the company's middlebox and server1.department.company.com at the department's middlebox).

The most common application of QUIC, web browsing, typically uses DNS names and not IP addresses.

The most important of the eventual applications of QUIC will probably be:
* E-mail: SMTP over QUIC
* Remote access: SSH over QUIC, VNC over QUIC, etc.

For SMTP, the MX records already use DNS names instead of IP addresses. SSH and VNC are also typically executed with DNS names.

The only change to QUIC would be to add the following to draft-ietf-quic-tls-12 somewhere:

<blockquote>
A client MUST provide a server name indication, as defined in RFC6066, if the user of the client specified the connection destination as a DNS name instead of an IP address.
</blockquote>

I don't see any mention of SNI in QUIC specifications now, so I assume the proposed requirement is not a requirement now.

TLS 1.3 apparently allows servers to require a client to use SNI (https://tools.ietf.org/html/draft-ietf-tls-tls13-28) but I believe the same should be explicitly specified in the QUIC specifications as well. According to TLS 1.3 draft:

<blockquote>
   Additionally, all implementations MUST support use of the
   "server_name" extension with applications capable of using it.
   Servers MAY require clients to send a valid "server_name" extension.
   Servers requiring this extension SHOULD respond to a ClientHello
   lacking a "server_name" extension by terminating the connection with
   a "missing_extension" alert.
</blockquote>

I hope the same will be true with QUIC's use of TLS. Otherwise QUIC will be a step backwards from TLS+TCP that allows a transparent proxy to operate as a NAT multiplexing device offering access to multiple servers.

If QUIC makes SNI necessary, then QUIC will be much better than TCP+TLS because you don't need a full transparent proxy to do said multiplexing (as the first packet already contains the SNI).

I hope this is the correct venue for this modification proposal (this is my first QUIC related issue). I'm not part of any QUIC mailing list, but if a mailing list is a more appropriate venue for discussing this modification, I could join.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1456