Re: [Masque] Updated proposed charter text

[Eric Rescorla <[e-mail]>]

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


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