Subject: Re: [Masque] Adoption call for "Requirements for a MASQUE Protocol to Proxy IP Traffic"

From: Magnus Westerlund <[email-masked]>
Date: Thu, 1 Oct 2020 15:33:38 +0000

On Wed, 2020-09-30 at 15:26 -0400, Ben Schwartz wrote:
> 
> 
> On Tue, Sep 29, 2020 at 9:12 AM Magnus Westerlund <
> magnus.westerlund=[email-masked]> wrote:
> ...
> > Proxying a whole subnet by the
> > client may or may not be in scope for what is meant with IP proxying. From
> > my
> > personal perspective that scope was not clear. I was only thinking
> > "borrowing" a
> > single IP from the MASQUE server and using the QUIC as a tunnel to the
> > MASQUE
> > server to reach the gateway for that IP address. 
> 
> With IPv6, having a single IP address would be considered poor form, would it
> not?  Perhaps supporting large subnets is a requirement even in the simple
> single-client use-case.

If you are proxying rather than tunneling I do expect that you will have to
establish state for each individual address that is rooted in the MASQUE server
for the external side. But, maybe we have different definitions of proxying?

The other important distinction between use cases is if the MASQUE client will
borrow a IPv6 address or even a whole  /64 prefix from MASQUE server, or if the
MASQUE client can request from the MASQUE server that it establish a route for
the subnet that the MASQUE client already have. It is primarily the late that I
have issues with as I think that enlarges the potential issues the MASQUE
solution need to handle to be published.   

Cheers

Magnus Westerlund

---

From: Alex Chernyakhovsky <[email-masked]>
Date: Thu, 1 Oct 2020 12:43:13 -0400

Hi Magnus,

> The other important distinction between use cases is if the MASQUE client
will
borrow a IPv6 address or even a whole  /64 prefix from MASQUE server, or if
the
MASQUE client can request from the MASQUE server that it establish a route
for
the subnet that the MASQUE client already have.

I think there's an important distinction to be made here: the changes at
the protocol level, and the changes in the other considerations a
successful client/server implementation would have to face. Our goal is to
ensure the protocol can accommodate these use cases, which is why they were
included in the draft. I'm working on an update to the draft's wording to
clarify that it is not required for every client/server to implement all of
these use cases.

Sincerely,
-Alex

On Thu, Oct 1, 2020 at 11:34 AM Magnus Westerlund <magnus.westerlund=
[email-masked]> wrote:

> --
> Masque mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/masque
>

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 07 Oct 2020 12:13:44 -0700

Looking through the document, I believe that it is a good starting place for the milestone and ought to be adopted.

Like some of the others on this list, I personally have more interest in seeing the CONNECT-UDP work get solidified soon, but I think that IP proxying is an essential part of MASQUE, and good to keep discussing in parallel.

I’d like to the working group hash out of some of the requirements in detail—it seems like we’ll be reinventing a lot of the work of IKEv2 traffic selectors based on the current description. This can be complex, and we should avoid duplicating work where possible. I’m also curious if we see ways forward that allow IP proxying without some of that complexity. These can all be discussed after adoption, though.

Best,
Tommy

> On Sep 26, 2020, at 4:54 PM, Eric Kinnear <ekinnear=[email-masked]> wrote:
> 
> Hi all, 
> 
> Thanks to everyone who has responded to this call for adoption as a support document. We have both positive and negative viewpoints being expressed — thanks for the valuable discussion so far. 
> Ideally, we’d like to see a few more people chime in with their views and the discussion to continue towards a position from which we can move forwards.
> 
> To aid in that, we are extending the adoption call for an additional two weeks, ending October 7.
> We’re especially interested in focus on what should be covered by the requirements document and if this document can be used as a starting point to get there.
> 
> Thanks, 
> Eric and Chris
> 
> 
>> On Sep 25, 2020, at 12:32 AM, Magnus Westerlund <magnus.westerlund=[email-masked] <mailto:magnus.westerlund=[email-masked]>> wrote:
>> 
>> Hi Chris,
>> 
>> Understood. My personal view is that this adoption call was unnecessary rushing
>> things and that we don't know if the document is a suitable starting point until
>> we have had some more discussion. 
>> 
>> But lets get on discussing its content rather than the formalia. 
>> 
>> Cheers
>> 
>> Magnus
>> 
>> On Thu, 2020-09-24 at 05:04 -0700, Christopher Wood wrote:
>>> Magnus,
>>> 
>>> As noted in the kickoff email, the purpose was to "start an adoption call for
>>> this document in its current form as a starting point." We expect the document
>>> contents may change as we work towards consensus, and that's fine! We're just
>>> getting started.
>>> 
>>> Best,
>>> Chris
>>> 
>>> On Mon, Sep 21, 2020, at 3:00 AM, Magnus Westerlund wrote:
>>>> David,
>>>> 
>>>> I hope that we can agee on that if adopting this document at this stage
>>>> there
>>>> will be no implication on any of the content in document having WG
>>>> consensus. I
>>>> rather see that the WG would discuss the use cases and we have a document
>>>> where
>>>> the general content would have WG consensus when adopting it. 
>>>> I think adopting a document just becasue we know we are going to need it is
>>>> rushing thing for the wrong reasons. I rather adopt a document in 3 months
>>>> time
>>>> where we are agreeing more on the content. 
>>>> 
>>>> 
>>>> Cheers
>>>> 
>>>> Magnus
>>>> 
>>>> 
>>>> 
>>>> On Fri, 2020-09-18 at 09:45 -0700, David Schinazi wrote:
>>>>> Thank you for comments, Mirja, Spencer, and Magnus!
>>>>> 
>>>>> If I may summarize them in the following bullet points:
>>>>> - we should reach WG consensus on use-cases
>>>>> - we should clarify the last use-case
>>>>> - we should clarify which requirement relates to which use-case
>>>>> 
>>>>> (There were also detailed comments on individual requirements that
>>>>> would be better discussed on individual threads, or GitHub issues)
>>>>> 
>>>>> I absolutely agree with these bullet points. As per our charter, the
>>>>> goal of this entire draft is for us to reach WG consensus on
>>>>> use-cases and requirements for IP proxying, before the WG starts
>>>>> work on a solution. However, none of those comments justify
>>>>> delaying adoption of the document. The call for adoption is there
>>>>> to ensure there is WG interest in the draft, and that folks are willing
>>>>> to review and comment - which your messages indicate! Adopting
>>>>> the draft will actually facilitate answering the three points above,
>>>>> since WG consensus is better reached on parts of WG documents,
>>>>> as opposed to individual submissions.
>>>>> 
>>>>> Thanks,
>>>>> David
>>>>> 
>>>>> 
>>>>> On Fri, Sep 18, 2020 at 8:43 AM Spencer Dawkins at IETF <
>>>>> [email-masked] <mailto:[email-masked]>> wrote:
>>>>>> So, just to start the discussion Magnus said we need to have (and I
>>>>>> agree
>>>>>> that we need to have it, whether before, or after, adoption), 
>>>>>> 
>>>>>> On Fri, Sep 18, 2020 at 3:27 AM Magnus Westerlund <
>>>>>> magnus.westerlund=[email-masked] <mailto:magnus.westerlund=[email-masked]>> wrote:
>>>>>> 
>>>>>> Which of these requirements (in 
>>>>>> https://www.ietf.org/id/draft-cms-masque-ip-proxy-reqs-01.txt <https://www.ietf.org/id/draft-cms-masque-ip-proxy-reqs-01.txt>)
>>>>>> 
>>>>>> 3.1.  IP Session Establishment
>>>>>> 3.2.  Proxying of IP packets
>>>>>> 3.3.  Maximum Transmission Unit
>>>>>> 3.4.  IP Assignment
>>>>>> 3.5.  Route Negotiation
>>>>>> 3.6.  Identity
>>>>>> 3.7.  Transport Security
>>>>>> 3.8.  Authentication
>>>>>> 3.9.  Reliable Transmission of IP Packets
>>>>>> 3.10.  Flow Control
>>>>>> 3.11.  Indistinguishability
>>>>>> 3.12.  Support HTTP/2 and HTTP/3
>>>>>> 3.13.  Multiplexing
>>>>>> 3.14.  Load balancing
>>>>>> 3.15.  Extensibility
>>>>>> 
>>>>>> belongs to each use case?
>>>>>> 
>>>>>>> 2.1.  Consumer VPN
>>>>>>> 2.2.  Point to Point Connectivity
>>>>>>> 2.3.  Point to Network Connectivity
>>>>>>> 2.4.  Network to Network Connectivity
>>>>>> 
>>>>>> (I'm happy to have this conversation in Github, but Magnus said we
>>>>>> needed to
>>>>>> have it here, so I'm following his excellent leadership)
>>>>>> 
>>>>>> Best,
>>>>>> 
>>>>>> Spencer 
>>>> 
>>>> -- 
>>>> Cheers
>>>> 
>>>> Magnus Westerlund 
>>>> 
>>>> 
>>>> ----------------------------------------------------------------------
>>>> Networks, Ericsson Research
>>>> ----------------------------------------------------------------------
>>>> Ericsson AB                 | Mobile +46 73 0949079
>>>> Torshamnsgatan 23           |
>>>> SE-164 80 Stockholm, Sweden | mailto: [email-masked] <mailto:[email-masked]>
>>>> ----------------------------------------------------------------------
>>>> 
>>>> 
>>>> 
>> -- 
>> Cheers
>> 
>> Magnus Westerlund 
>> 
>> 
>> ----------------------------------------------------------------------
>> Networks, Ericsson Research
>> ----------------------------------------------------------------------
>> Ericsson AB                 | Mobile +46 73 0949079
>> Torshamnsgatan 23           |
>> SE-164 80 Stockholm, Sweden | mailto: [email-masked] <mailto:[email-masked]>
>> ----------------------------------------------------------------------
>> 
>> 
>> -- 
>> Masque mailing list
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/masque <https://www.ietf.org/mailman/listinfo/masque>
> -- 
> Masque mailing list
> [email-masked]

---

From: "Christopher Wood" <[email-masked]>
Date: Wed, 14 Oct 2020 10:39:45 -0700

The adoption call is now complete. It looks like we have consensus to adopt this draft and continue its development as a WG Support Document [1]. Authors, can you please submit draft-ietf-masque-ip-proxy-reqs-00 at your earliest convenience?

Thanks to everyone who chimed in and provided feedback! We look forward to continued discussions on the use cases and requirements. 

Best,
Chris and Eric

[1] https://mailarchive.ietf.org/arch/msg/masque/eLjdyqM_z-Gs4dmXuOFfvBSMyt8/

On Sat, Sep 26, 2020, at 4:54 PM, Eric Kinnear wrote:
> Hi all, 
> 
> Thanks to everyone who has responded to this call for adoption as a 
> support document. We have both positive and negative viewpoints being 
> expressed — thanks for the valuable discussion so far. 
> Ideally, we’d like to see a few more people chime in with their views 
> and the discussion to continue towards a position from which we can 
> move forwards.
> 
> We’re especially interested in focus on what should be covered by the 
> requirements document and if this document can be used as a starting 
> point to get there.
> 
> Thanks, 
> Eric and Chris
> 
> 
> > On Sep 25, 2020, at 12:32 AM, Magnus Westerlund <magnus.westerlund=[email-masked]> wrote:
> > 
> > Hi Chris,
> > 
> >>>> [email-masked]> wrote:
> >>>>> https://www.ietf.org/id/draft-cms-masque-ip-proxy-reqs-01.txt)
> >>>>> 
> >>> SE-164 80 Stockholm, Sweden | mailto: [email-masked]
> > SE-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: David Schinazi <[email-masked]>
Date: Wed, 14 Oct 2020 14:08:11 -0700

Thanks Chris!

We've now uploaded draft-ietf-masque-ip-proxy-reqs-00
<https://tools.ietf.org/html/draft-ietf-masque-ip-proxy-reqs-00>.

It contains the same contents as draft-cms-masque-ip-proxy-reqs-01,
except for changes in the draft creation tools and the correction of
one spelling mistake (see diff here
<https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=draft-cms-masque-ip-proxy-reqs-01&url2=draft-ietf-masque-ip-proxy-reqs-00>
).

We also have a GitHub repository
<https://github.com/ietf-wg-masque/draft-ietf-masque-ip-proxy-reqs> set up.
We encourage folks who
brought up concerns during the adoption call to please open GitHub
issues on the repository to ensure their voices are heard.

Cheers,
David

On Wed, Oct 14, 2020 at 10:40 AM Christopher Wood <[email-masked]>
wrote:

> The adoption call is now complete. It looks like we have consensus to
> adopt this draft and continue its development as a WG Support Document [1].
> Authors, can you please submit draft-ietf-masque-ip-proxy-reqs-00 at your
> earliest convenience?
>
> Thanks to everyone who chimed in and provided feedback! We look forward to
> continued discussions on the use cases and requirements.
>
> Best,
> Chris and Eric
>
> [1]
> https://mailarchive.ietf.org/arch/msg/masque/eLjdyqM_z-Gs4dmXuOFfvBSMyt8/
>