Re: [Masque] Proposed MASQUE charter text

[Mirja Kuehlewind <[e-mail]>]

Hi Christian,

please see inline. Please also note that you didn't comment on the latest version we've sent out to the list (I hope this doesn't confuse others).


On 27.01.20, 20:44, "Christian Huitema" <[e-mail]> wrote:

    
    On 1/22/2020 7:26 PM, David Schinazi wrote:
    > [ + Eric & Christian ]
    >
    > Thanks for putting this together!
    
    Sorry for not replying sooner. I have lots of concerns with this
    proposed charter.
    
    >
    > Overall, I really like this charter proposal. There is one main point
    > of discrepancy between the charter and current drafts though that I
    > think we should resolve: QUIC vs HTTP/3. In particular, the proposed
    > charter mentioned:
    >     "a framework that allows concurrently running multiple networking
    > applications inside a QUIC connection"
    > while the latest draft mentions:
    >     "a framework that allows concurrently running multiple networking
    > applications inside an HTTP/3 connection".
    > Some of the use-cases we've discussed require HTTP/3, so I think it's
    > reasonable to use HTTP/3 as our signaling protocol to exchange MASQUE
    > information - it enables obfuscation and gives us many HTTP features
    > for free, such as HTTP-level proxying and caching.
    
    I don't like the proposal all that much. The focus appears to be on
    transport proxying, which is something that Quic deliberately set up to
    eliminate. The whole first paragraph reads like a lamentation that the
    old school performance enhancing proxies cannot be deployed anymore
    because the transport is encrypted. Well, that's very much the point of
    Quic, so it is questionable to start a working group to bring transport
    proxies back in. I will comment further in the text, but there are some
    ground rules that ought to be very clear:
    
    1) Even when proxies are used, the Quic encryption shall be maintained
    end-to-end between client and server, including the encryption of ACK
    frames in the Quic payload.
    
    2) Even when proxies are used, it should be possible for client and
    server to use Quic migration and move the connection to path that does
    not include the proxy.

[MK] Yes, these are two points which we always assumed as precondition (and I don't think the proposed charter text indicates anything other than this). But we can for sure state this more explicitly in the charter. 

[MK] However, I think the confusion might be about the word "proxy". We mean "proxy" mostly in the sense of providing a forwarding and tunneling service (that is not touching the end to end connection). While you seem to map the word "proxy" to what I would maybe call a "transparent proxy" that tries to mangle with the traffic without having the endpoints noticing or agreeing. I thought it would be clear from the charter that that is not what we are talking about and is therefore also completely out of scope. But we can of course make this clearer in the charter text.
    
    
    >
    > Another slight difference is the fact that the charter discusses
    > "proxy services" while the draft discusses "MASQUE applications". I
    > think we mean the same things, but perhaps "MASQUE applications" is
    > more generic and will constrain us less.
    >
    > I also agree with Magnus that we should not focus too much on
    > obfuscation or filtering in the charter, as there are still factions
    > within the IETF that strongly oppose work on such topics.
    >
    > Below is my attempt at incorporating the feedback on this thread, and
    > making the small changes described above:
    >
    > =====
    >
    > Many network topologies lead to situations where transport protocol
    > proxying is
    > beneficial. For example: helping endpoints to communicate when end-to-end
    > connectivity is not possible, applying additional encryption where
    > desirable
    > (such as a VPN), or accommodating differences in network segment
    > characteristics
    > (e.g. long paths such as satellite, or high-loss links). Many existing
    > proxy solutions
    > deployed today rely on transparent intermediation. However, an
    > increasing amount of
    > traffic is using QUIC, and QUIC's improved security model prevents
    > transparent proxies.
    > In order to allow transport protocol proxying when QUIC is in use, we
    > will need a
    > mechanism where one of the QUIC endpoints actively collaborates with
    > the proxy.
    > HTTP/3 and QUIC are good candidate protocols for tunneling or
    > forwarding this kind of
    > traffic, as QUIC provides secure connection establishment, multiplexed
    > streams, and
    > connection migration while HTTP/3 allows HTTP-level proxying and caching.
    
    I think this discussion is based in unproven requirements. For example,
    the text mentions long path and high loss path. 

[MK] Actually that's a good point. I didn't really notice this edit in the final version. I would be more interested in support a mobile network segment with such a proxy. The challenge there is different and  as capacity is varying and it's important to have data available to send why the resources are scheduled for the respective client. However, the idea is not to interfere with the end-to-end traffic but to provide the client more information about the mobile network segment that then can be used by the endpoint to optimize transmission. We are planning to submit a draft on this soon.

    I have running code that
    shows Quic running just fine over such path, with two simple tunings:
    allow the Window to grow sufficiently large; and, use a congestion
    control algorithm like BBR that does not unduly react to small random
    losses.
    
    As I mentioned above, one of the big arguments for Quic is to get rid of
    the ossification caused by the so called "transparent proxies". This
    first paragraph in the proposed charter appears like a paean to these
    proxies. That's a poor motivation for a new working group. 

[MK] Transparent proxies are not what we want to work on and I don't think that's the charter says anything different anywhere.
    
    >
    > This working group will work on MASQUE (Multiplexed Application
    > Substrate over
    > QUIC Encryption) - a framework that allows concurrently running multiple
    > networking applications inside an HTTP/3 connection. MASQUE will allow
    > negotiating support for various MASQUE applications, configuring
    > application
    > parameters, and provide a signaling protocol for these applications.
    > The working
    > group will define specific MASQUE applications that will allow
    > proxying traffic
    > and other services that require communication between endpoints and
    > proxies.
    > These applications may provide simple forwarding with optional address
    > translation only, or more advanced services like name resolution,
    > multipath
    > support, or assistance for congestion control on link segments with
    > challenging
    > characteristics, such as high loss or strongly varying delays.
    
    Are we discussing application proxies or transport proxies, or something
    else? 
    
    Some applications naturally incorporate application relays -- SMTP comes
    to mind. Are we here discussing that, something like SMTP over Quic? Or
    are we discussing HTTP something like HTTP caching proxies? or are we
    discussing MITM attacks that break the encryption in order to inspect
    the traffic?

[MK] Why does this actually matter? If the assumption is that the end-to-end traffic says untouched, any application traffic can be tunneled over QUIC and then forwarded by the proxy. As I said multiple time, MITM is not what we want and I don't understand how you read this in the charter. 
    
    >
    > As use-cases for deploying MASQUE have different security or performance
    > requirements, the working group may define multiple MASQUE
    > applications for
    > proxying to suit these disparate use-cases. In particular, some
    > deployments may
    > prefer to double-encrypt user data to provide stronger privacy
    > guarantees, while
    > others may rather skip the second encryption to reduce computational
    > costs.
    > Such options will need to produce documentation of the resulting
    > security and
    > privacy properties.
    
    I think that's way too vague. There should be a clear statement that as
    long as Quic proxying is concerned, then the end-to-end encryption of
    Quic packets will be preserved. 

[MK] Yes, we should add this if that wasn't clear!

   There should also be a list of specific
    use cases. What applications are we discussing here? HTTP 2? HTTP 1.1?
    SMTP? A generic framework for random applications over proxies?

[MK] There is this draft: https://tools.ietf.org/html/draft-kuehlewind-quic-substrate-00
However, I don't see why we need to list the use cases in the charter. I think it is important to make the scope and requirements clear in the charter. If that is not clear enough, we should make it clearer.
    
    >
    > Alongside the definition of the MASQUE framework, the group will
    > further work on
    > discovery mechanisms for MASQUE servers and which MASQUE applications they
    > support, taking into account deployment across network segments
    > with different
    > operability and end-user relationship characteristics.
    
    The mention of network segments brings to mind the support for
    migration, which is a key attribute of Quic. We want to support
    scenarios like migration from cellular to Wi-Fi. It should be clear that
    whatever proxying is done shall not prevent this migration. For example,
    migrate from a cellular path that includes a proxy to a Wi-Fi path that
    does not.

[MK] I don't see how migration could be hindered by this (given the end-to-end connection stays unmodified) but I'd be fine to explicitly state that in the charter.
    
    >  
    > New MASQUE Applications can be adopted by the group by creating a new
    > milestone with AD review.
    >  
    > If MASQUE requires any extensions to existing protocols, the group will
    > coordinate closely with the respective group responsible for
    > maintaining that
    > protocol, such as the HTTPBIS, QUIC or TLS working groups.
    
    Again, the list of protocol being proxied should be specified in the
    charter, as well as the corresponding design constraints. Proxying HTTP
    is a very different animal than proxying TLS, which smells of "breaking
    the encryption". The IETF should not charter working groups to do that!

[MK] Again, as the end-to-end connection stays untouched, I don't see why the protocols that can use these proxies should be restricted. Again there is NO "breaking the end-to-end encryption" here!

Mirja

    
    -- Christian Huitema