Re: [Masque] Updated proposed charter text

[Eric Rescorla <[e-mail]>]

On Thu, Apr 2, 2020 at 8:34 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?
>

I think it depends on the protocol.

- For TCP you can only really forward to destinations that were explicitly
set up
- For UDP you could in principle forward to arbitrary destinations but the
return path is problematic (you need the server to be a stateful NAT) so
explicitly set up seems better
- For IP I understand that what people want is arbitrary destinations in
both directions, which is the source of the additional complexity

-Ekr


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