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

From: Juha-Matti Tilli <[email-masked]>
Date: Mon, 18 Jun 2018 04:40:25 -0700

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

---

From: MikkelFJ <[email-masked]>
Date: Mon, 18 Jun 2018 04:57:03 -0700

This probably should be discussed on the mailing list rather than as an issue.

Aren't there privacy concerns here? One could imagine a DNS like mapping from SNI to connection ID similar to a stateless retry, but where a SNI drives the retry. This could be a sort-of separate service external to QUIC.

-- 
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#issuecomment-398029983

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 18 Jun 2018 12:45:08 +0000 (UTC)

Would a forward proxy approach help alleviate your concerns?

@bemasc and I are putting together some ideas on how a User Agent could explicitly opt-in to passing non-TCP traffic via a proxy, in a similar way to how HTTP proxies work now. This takes place after secure session establishment.

-- 
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#issuecomment-398041749

---

From: MikkelFJ <[email-masked]>
Date: Mon, 18 Jun 2018 06:00:00 -0700

A forward proxy is useful but it cannot safely operate at the cloud provider level load balancer because privacy is compromised.

-- 
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#issuecomment-398045612

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 18 Jun 2018 06:27:08 -0700

I guess it depends where the exhaustion concerns are. 

A reverse proxy for the cloud case, i.e. a request router, is something I'm familiar with. Some have scalability concerns with these.

-- 
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#issuecomment-398053344

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 18 Jun 2018 06:47:25 -0700

FWIW, the QUIC-HTTP draft mandates the use of SNI. Quoting from [section 2.3](https://quicwg.org/base-drafts/draft-ietf-quic-http.html#rfc.section.2.3), "The Server Name Indication (SNI) extension [RFC6066] MUST be included in the TLS handshake."

Though I wonder if we might want to relax the wording in possibility of having SNI encryption, to something like what we see in [RFC 7540 section 9.2](https://tools.ietf.org/html/rfc7540#section-9.2).

-- 
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#issuecomment-398059647

---

From: Martin Thomson <[email-masked]>
Date: Mon, 18 Jun 2018 22:31:57 -0700

As observed, we mandate use of SNI already (though we might want to soften this to allow encrypted SNI as @kazuho points out).  TLS doesn't mandate use of SNI, which is entirely appropriate for QUIC-the-transport.

-- 
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#issuecomment-398279115

---

From: janaiyengar <[email-masked]>
Date: Tue, 19 Jun 2018 18:46:07 +0000 (UTC)

As noted already, QUIC inherits TLS's requirements of SNI (the SNI field is still part of TLS), and QUIC-HTTP inherits HTTP/2's requirements of SNI. @jmtilli : If you're concerned about encrypted SNI, that conversation ought to apply to HTTP over TCP as well, so I would take that to the httpbis working group. If you are concerned about other applications using QUIC without SNI, that'll probably be relevant when considering other applications mapped on QUIC, which we haven't done yet as a wg.

-- 
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#issuecomment-398504617

---

From: Juha-Matti Tilli <[email-masked]>
Date: Wed, 20 Jun 2018 06:20:15 -0700

Ok, perhaps this issue can be closed then, if QUIC inherits the requirement of TLS. I was fearing that QUIC might not adopt all of TLS, as QUIC is very different from TCP and not all of TLS might necessarily apply.

-- 
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#issuecomment-398745630

---

From: Mike Bishop <[email-masked]>
Date: Wed, 20 Jun 2018 18:03:32 +0000 (UTC)

Closed #1456.

-- 
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#event-1691862761