[Masque] QUIC proxy scenarios

[Christian Huitema <[e-mail]>]

During the first day of the QUIC interop in London, we discussed the
scenarios for a QUIC proxy. This is what I am looking at:


# Scenarios

## Home Server Scenario

Home server establishes QUIC connection with proxy server "in the
cloud", publishes name in DNS with address of cloud server.
Client sends QUIC messages to proxy.
Proxy recognizes the SNI in Initial packets, or the Destination CID in
handhsake and short packets.
Proxy forwards packets to QUIC server as "datagram".
Home server treat packets as if received on UDP socket.
Home server forwards packets to proxy as datagram.
Proxy relays QUIC packets to the client.

Optional: QUIC server may use the "preferred address" mechanism to
suggest migration to a direct connection, bypassing the proxy.
Optional: local clients may discover the local server, without using the
proxy.

## Hidden client scenario

Client establishes connection with proxy. Sends QUIC messages to proxy
as datagrams.
Proxy decapsulates the messages, sends them to destination server.
Destination server replies to proxy.
Proxy examines CID, determines which client it belongs to, forwards QUIC
messages as Datagrams to appropriate destination.

## Onion scenario

Client establishes connection to proxy, then through that to another,
etc. This creates a tree of proxies rooted at the client.
QUIC connections are mapped to a specific branch of the tree.

Hidden server can similarly hide between several layers of proxy. Hidden
servers should not publish their address in the DNS.
May use an Onion DHT service instead (see Tor ".onion"), or in fact any
other mechanism. This is out of scope in this spec.

-- Christian Huitema