Re: [Masque] Updated proposed charter text

[Martin Thomson <[e-mail]>]

On Sat, Apr 4, 2020, at 00:17, Alex Chernyakhovsky wrote:
> I don't think this is a meaningful distinction. If I understand 
> correctly, you're identifying that CONNECT is actually two actions that 
> have to happen in sequence: establish a tunnel to some destination, 
> then relay bytes to that destination. The first step allows you to 
> connect to arbitrary destinations, unless you have some sort of 
> firewall or ACL system to limit the scope.

I think that this has less to do with the arbitrariness than it has to do with what level of prearrangement.

When I send an IP packet, I might set an arbitrary source and destination address.  The forwarding entity probably needs to have the source address prearranged or bad things happen.  But it might be happy to allow a range of different addresses to be used.  For destination addresses, the level of predetermination is something we could decide is attached to every unit of communication.  Or it might require that every possible destination be prearranged.

An advantage of prearrangement is that you can create a context and compress, reducing or maybe even reversing the overhead of tunneling.  And servers get a clearer channel for expressing their policy constraints.  The disadvantage is that you pay a round trip for the setup, and maybe the tunneling protocol pays in complexity for that ability to be expressive.

What we see with CONNECT is that the destination is prearranged.  The headers on CONNECT are that prearrangement.  That simplifies operation a great deal as the client doesn't have to provide TCP or IP headers on every frame it sends.  The round trip is parallel with the TCP socket establishment from proxy to server, so the latency hit is negligible; more so because clients can send a TLS ClientHello without waiting for the outcome of the CONNECT request.
 
> You can do the same with a VPN, you just need to have connection 
> tracking implemented in the VPN terminator. The only real difference I 
> see here is with a traditional TCP connection, you can't avoid having 
> the connection state, as that's inherent to the protocol, whereas with 
> a VPN one could choose to not implement connection tracking and 
> therefore not have an easy filtering capability. (You could, of course, 
> use stateless firewall rules, even without changing the VPN terminator 
> implementation and relying on the OS native features).

Whatever happens here, we will need to encode some of these assumptions either into limitations of a protocol specification, or as protocol elements that are signaled or negotiated.