Re: [Masque] QUIC proxy scenarios

[David Schinazi <[e-mail]>]

Hi Christian,

Apologies for the delayed response, it's been a busy few weeks.

I've taken a lot of text from your PR
<https://github.com/DavidSchinazi/masque-drafts/pull/2/files> and added it
to the document.
I think we can have MASQUE be a framework where both proxy and VPN can be
negotiated and co-exist.

Please let me know what you think of the latest text
<https://davidschinazi.github.io/masque-drafts/draft-schinazi-masque.html>.

I'm thinking as a next step we may want to flesh out the details of the QUIC
proxy
<https://davidschinazi.github.io/masque-drafts/draft-schinazi-masque.html#rfc.section.5.4>?
(e.g., how to negotiate its use and to compress QUIC connection IDs)

Thanks,
David


On Tue, May 21, 2019 at 3:59 AM David Schinazi <[e-mail]>
wrote:

> Hi Christian,
>
> These are definitely interesting use-cases, and I think the draft could
> use more text to that extent.
>
> A pull request would be most welcome!
> https://github.com/DavidSchinazi/masque-drafts
>
> In the Home Server Scenario, can you elaborate on who the
> client/server/proxy is? Is the goal to access home services from anywhere
> in the Internet?
>
> David
>
> On Tue, May 21, 2019 at 10:04 AM Christian Huitema <[e-mail]>
> wrote:
>
>> 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
>>
>> --
>> Masque mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/masque
>>
>