[Masque] comments on draft-schinazi-masque [was:Re: Splitting MASQUE Obfuscation out of MASQUE]

[Mirja Kuehlewind <[e-mail]>]

Hi David,

thanks for splitting the document up!

I guess the last paragraph in section 4, as well as section 6 and the IANA considerations in draft-schinazi-masque-obfuscation-00 could/should have also been moved to/left in draft-schinazi-masque-02…?

A couple of comments/questions on draft-schinazi-masque-02:

1) The draft say at the beginning of section 3

“As soon as the server has accepted the client's MASQUE initial
   request, it can advertise support for MASQUE Applications, which will
   be multiplexed over this HTTP/3 connection.“

I wondering what you actually mean by “multiplexed over HTTP/3”. I believe the idea here is that you would always send a HTTP connect first, however, I would assume that you then leverage multiplexing on the QUIC layer, especially when you proxy (non-http) QUIC traffic or other UDP traffic…? Can you further explain?!

2) And also regarding the proxying of QUIC/UDP traffic: As far as I understand you propose to only use QUIC datagrams for this (+ potentially one QUIC stream as control channel?)? My thinking was that you can also instruct a MASQUE server to forward all data on one QUIC stream to a specific server. Yes, this would make the MASQUE proxying reliable but e.g. in case of a high loss link between the client and the MASQUE server this could actually be beneficial. Further I understand that more work is needed on the mapping of datagram-ID to target server but just mapping a certain stream ID to a target server would also be easier. In our work at Ericsson, we assume the first stream opened to be some control stream that then can be used to indicate forwarding requests/mappings for other streams as well as any additional data that the client and MASQUE server may want to exchange at any other time during the connection life time.

3) There is also work in draft-piraux-quic-tunnel-00 (adding authors in cc’ed in case there are not on this list) which I think is related. They also use QUIC as tunneling protocol to an immediate proxy. On each stream they first negotiate the forwarding capabilities based on a TLV-based protocol and then, after an end TLV message, switch over to the actual payload data that is supposed to be forwarded. I think this is align with the TCP converter working in tcpm, however, given QUIC supports multiplexing I think it is actually not necessary to prepend the negotiation part on the same stream, rather than using a separate control stream for that. In any case I think both proposals are indented to support similar functionality and therefore the signaling protocols should probably be aligned. Any thoughts here?

Mirja






From: Masque <[e-mail]> on behalf of David Schinazi <[e-mail]>
Date: Wednesday, 8. January 2020 at 23:01
To: MASQUE <[e-mail]>
Subject: [Masque] Splitting MASQUE Obfuscation out of MASQUE

Hi MASQUE enthusiasts,

One piece of feedback I've gotten about MASQUE was that there is more community interest in working on the "how do we make better proxies running over QUIC?" question than on the "how can I hide a VPN behind an HTTPS server?" question.

Therefore I've split out the hidden VPN use-case into its own draft, named MASQUE Obfuscation:
https://tools.ietf.org/html/draft-schinazi-masque-obfuscation

The core MASQUE draft is now more focused on laying out a generic mechanism for multiplexing applications over QUIC:
https://tools.ietf.org/html/draft-schinazi-masque

Conceptually, MASQUE Obfuscation is now just a single use-case for MASQUE among others.

In terms of next steps, I'll be working on fleshing out the specific protocol bits of MASQUE, and on a draft charter to discuss the potential creation of a MASQUE working group. More details to follow.

Thanks,
David