Re: [Masque] Updated proposed charter text

[Alex Chernyakhovsky <[e-mail]>]

On Thu, Apr 2, 2020 at 4:26 PM Eric Rescorla <[e-mail]> wrote:

>
>
> On Thu, Apr 2, 2020 at 12:40 PM Alex Chernyakhovsky <[e-mail]>
> wrote:
>
>>
>>
>> On Thu, Apr 2, 2020 at 11:36 AM Spencer Dawkins at IETF <
>> [e-mail]> wrote:
>>
>>> Replying to Chris via Ekr's reply to me :-)
>>>
>>> On Thu, Apr 2, 2020 at 9:09 AM Eric Rescorla <[e-mail]> wrote:
>>>
>>>> I don't think the diversity of naming here is that useful as a guide to
>>>> the diversity of the use cases. For instance, 2817, which defines CONNECT
>>>> uses the term both "proxy" and "tunnel" in the same sentence.
>>>>
>>>> "A CONNECT method requests that a proxy establish a tunnel connection
>>>> on its behalf."
>>>>
>>>> And yet TURN, which provides a similar service, calls itself "Traversal
>>>> Using Relays around NAT".
>>>>
>>>> As a practical matter, the TCP and UDP use cases focus on establishing
>>>> an association with the server in which packets are forwarded to and from a
>>>> given destination and the IP use case seems to focus on forwarding IP
>>>> datagrams from the client to and from arbitrary destinations (this last
>>>> might use some fleshing out, I suppose).
>>>>
>>>
>>> This is the kind of thing I was also thinking about - not that we
>>> weren't using the right terms, but that we were vague enough that people
>>> during the BOF were guessing at what MASQUE would be most like (
>>> https://en.wikipedia.org/wiki/Blind_men_and_an_elephant). So, yes,
>>> fleshing out what we expect to happen, and not to happen, makes sense to
>>> me.
>>>
>>> Just to start where Ekr started, do people think we're forwarding to
>>> arbitrary destinations, or only to destinations that were explicitly set up?
>>>
>>> What does "arbitrary destinations" mean here? For QBONE, we have built
>> the ability to route between networks, including setting a default that can
>> be for reaching the public internet. Is that arbitrary, or is that a
>> destination that was explicitly set up because a route was configured? I'm
>> not sure I understand the implication of the distinction.
>>
>
> So, you have a tunnel between point A and point B.
>
> In TCP CONNECT (and hypothetically UDP CONNECT) you set up an association
> to a given destination. You then inject datagrams labelled with the
> association ID and it gets routed to that destination and packets in the
> return direction get labelled with the same association ID on the way to
> the client. Incoming messages not coming from any association are discarded.
>
> In a pure IP VPN, there aren't any destination associations and packets
> just get routed based on the IP header in both directions, regardless of
> what state has been created. Note that a TURN relay occupies a sort of
> intermediate state where associations are implicitly created and destroyed.
>
> -Ekr
>
> 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.

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).

Sincerely,
-Alex


>> Sincerely,
>> -Alex
>>
>> Best,
>>>
>>> Spencer
>>>
>>>
>>>> -Ekr
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Apr 2, 2020 at 7:03 AM Christopher Wood <[e-mail]>
>>>> wrote:
>>>>
>>>>> On Tue, Mar 31, 2020, at 4:34 PM, Spencer Dawkins at IETF wrote:
>>>>> > Hi, Christopher,
>>>>> >
>>>>> > Thanks for getting this update out so quickly.
>>>>> >
>>>>> > I have thoughts, but wanted to start with the first couple of
>>>>> paragraphs.
>>>>> >
>>>>> > On Tue, Mar 31, 2020 at 11:43 AM Christopher Wood <
>>>>> [e-mail]> wrote:
>>>>> > > Based on last week's meeting, it seems folks are generally
>>>>> enthusiastic about some form of MASQUE moving forward. To help scope that
>>>>> particular form, here's an update to the proposed charter.
>>>>> > >
>>>>> > >  ~~~
>>>>> > >  Many network topologies lead to situations where transport
>>>>> protocol proxying is beneficial. For example, proxying enables endpoints to
>>>>> communicate when end-to-end connectivity is not possible and can apply
>>>>> additional encryption where desirable (such as a VPN). Proxying can also
>>>>> improve client privacy, e.g., by hiding a client's IP address from a target
>>>>> server.
>>>>> > >
>>>>> > >  Proxying technologies such as SOCKS and HTTP(S) CONNECT exist,
>>>>> albeit with their own shortcomings. For example, SOCKS signalling is not
>>>>> encrypted and HTTP CONNECT is currently limited to TCP. In contrast, HTTP/3
>>>>> is a viable candidate protocol for proxying arbitrary traffic, as it
>>>>> provides secure connectivity, multiplexed streams, and migration for a
>>>>> single connection while taking advantage of a unified congestion
>>>>> controller. HTTP/3 datagrams provide for unreliable data transmission,
>>>>> which enables transporting UDP and other unreliable flows via a proxy
>>>>> without introducing potentially redundant or unnecessary recovery
>>>>> mechanisms. Further, HTTP/3 supports an established request/response
>>>>> semantic that can set up and configure flows for different services.
>>>>> >
>>>>> > If I remember correctly, somewhere between the audio conference and
>>>>> the
>>>>> > active jabber conversation, there were people who mentioned
>>>>> >  * proxies
>>>>> >  * relays
>>>>> >  * tunnels
>>>>> >  * VPNs
>>>>> >  * NATs, and
>>>>> >  * now that I look at the second paragraph, maybe even firewalls
>>>>> > Is it possible to agree on the functionalities that this community
>>>>> of
>>>>> > interest is thinking of, as part of the charter discussion?
>>>>> >
>>>>> > ISTM that if we're talking about "connect for IP", we're closer to a
>>>>> > tunnel than a proxy, and I don't think that's what most of the
>>>>> MASQUE
>>>>> > folk were thinking of.
>>>>> >
>>>>> > Perhaps this will fall out of the use cases people have been
>>>>> collecting?
>>>>>
>>>>> Yep, I expect that to be the case! While the use cases in the charter
>>>>> are not meant to be exhaustive, more specificity would probably help frame
>>>>> the rest of the content.
>>>>>
>>>>> Meta question: are you looking for a specific change in the text, and
>>>>> if so, what might that be?
>>>>>
>>>>> Best,
>>>>> Chris
>>>>>
>>>>> --
>>>>> Masque mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/masque
>>>>>
>>>> --
>>> Masque mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/masque
>>>
>>