Re: [Masque] Proposed draft charter

[Mirja Kuehlewind <[e-mail]>]

Hi Lars, hi all,

see below.

On 27.01.20, 16:27, "Marcus Ihlar" <[e-mail]> wrote:

    
    -----Original Message-----
    From: Masque <[e-mail]> On Behalf Of Lars Eggert
    Sent: den 27 januari 2020 15:54
    To: Mirja Kuehlewind <[e-mail]>
    Cc: [e-mail]
    Subject: Re: [Masque] Proposed draft charter
    
    Hi,
    
    On 2020-1-27, at 16:34, Mirja Kuehlewind <[e-mail]> wrote:
    > [MK] Only the outer client to proxy connection would be "eliminated".
    
    thanks for clarifying.
    
    So if the concern is for the client-to-proxy part, why does this outer connection need to be QUIC at all? (I think this is also what Marcus described in his reply, i.e., that you could simply run a non-QUIC protocol between the client and proxy on the same five-tuple.)
    
    [MI]  One reason for the client-proxy communication to be QUIC-based is that it would allow for both the double encrypted tunneling and the UDP-forwarding modes. 
    Also, it is probably a good idea from both privacy and deployment perspectives that the client-proxy communication isn't easy to distinguish from standard QUIC traffic. 

[MK] Yes, these are the most important points. The initial use case for MASQUE was obfuscation - so in that case the goal is trying to make MASQUE look as much as possible like any other QUIC traffic on the wire - but there are actually more use cases were the same kind of proxy/tunnel setup would be beneficial so we extended the scope in the proposed charter still including obfuscation as one case. When using QUIC, it is especially nice that different QUIC streams within one connection can be used to forward traffic over the same proxy to different target servers (while e.g. SOCKS would use a separate port for each connection which is then of course visible on the wire), hiding information about the existing of these different connections completely from the respective network segment.

[MK] Further QUC provides build in encryption and authentication. While there are cases were double-encryption of the end-to-end traffic should be avoided, any communication with the proxy directly must be encrypted of course.

[MK] I would say QUIC is simply a nice fit for a transport protocol underneath the proxy protocol we want to work on, providing the features needed for the proxy service like multiplexing, encryption/authentication, and optional datagram support. So why not using it __ Further as the expectation is that in many cases this will especially be used to tunnel quic within quic, you may need to implement only one stack on the client and I think this also open potentials for further optimization in the future.

Mirja