mirjak/draft-kuehlewind-quic-substrate

This IETF Internet-draft discusses use cases for use of QUIC as a substrate protocol.

Building the Draft

Formatted text and HTML versions of the draft can be built using make.

$ make

This requires that you have the necessary software installed. See the instructions.

Contributing

See the guidelines for contributions.

draft-kuehlewind-quic-substrate's Issues

Frontend support section has a bit of duplication

The final paragraph includes some text that duplicates things that were already said. e.g.

para 1:

the client communicates with a reverse proxy that may
or may not be under the authority of the service provider

para 3:

the client interact with a proxy that is located close to the
server and potentially even under the same administrative domain or at least has some
trust relationship with the application service provider

Either: these are different cases (but that seems odd if they are in the same section), or we can rationalise the text.

Frontend Support for Load Balancing and Migration/Mobility

Frontend Support for Load Balancing and Migration/Mobility section includes statement:

Terminating not only the transport connection but also the
security association is especially problematic if the proxy provider under the direct
authority of the services provided but a contracted third party.

I can't parse this, so I think a "is not under" is required somewhere. Or a restructure of the sentence to better highlight the problem.

Transparent proxying clarity

The 4th paragraph of the introduction says:

Existing proxies that are not based on QUIC are often transparent. That is, they do not
require the cooperation of the ultimate connection endpoints, and are often not
visible to one or both of the endpoints. If QUIC provides the basis for future tunneling
and proxying solutions, it is expected that this relationship will change.

It is not totally clear what we think the challenges are for transparent proxying with QUIC. Perhaps explaining them will make the the assertion 'it is expected this relationship will change' more understandable.

Trust and Authentication

Add requirements on trust and authentication beyond what is provided by QUIC/TLS

Web fronting / HTTPS tunnels

Maybe add a reference to draft-ietf-tls-sni-encryption section 4.1. on HTTPS Tunnels, or a separate use case?

Discovery requirements

Do we want to add any text about how clients discover proxies. There are a few ways this works today, HTTP often uses WPAD that I finally found an IETF contribution for (!) https://tools.ietf.org/html/draft-ietf-wrec-wpad-01. Although that document didn't get adopted, it led me to find RFC 3040 which has some nice descriptions of Web-oriented proxies.