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

From: "Christopher Wood" <[email-masked]>
Date: Wed, 09 Sep 2020 05:30:36 -0700

One of the goals on our charter is producing a requirements document for IP proxying. draft-cms-masque-ip-proxy-reqs is one attempt at accomplishing this goal. Based on feedback received during the last meeting and the document revision since, we'd like to start an adoption call for this document in its current form as a starting point. 

The document may be found here:

   https://datatracker.ietf.org/doc/draft-cms-masque-ip-proxy-reqs/

And the source may be found here:

   https://github.com/DavidSchinazi/masque-drafts

This call for adoption will conclude on September 23.

Thanks, 
Chris and Eric

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 9 Sep 2020 10:20:33 -0400

I support adoption.  (Per [1], I would suggest using the document state
"Adopted for WG info only".)

I would like to see a requirement for compatibility with existing IETF IP
tunnel layers like PPP (and IPCP/IPV6CP).  Ideally, we could avoid
reinventing these protocols, and just carry them over HTTP.  Failing that,
I'd like to make sure that we can at least expose a PPP-compatible
interface around MASQUE-IP, or provide instructions for chaining PPP and
MASQUE-IP links with a minimum of mismatch.

[1] https://www.ietf.org/about/groups/iesg/statements/support-documents/

On Wed, Sep 9, 2020 at 8:31 AM Christopher Wood <[email-masked]> wrote:

> One of the goals on our charter is producing a requirements document for
> IP proxying. draft-cms-masque-ip-proxy-reqs is one attempt at accomplishing
> this goal. Based on feedback received during the last meeting and the
> document revision since, we'd like to start an adoption call for this
> document in its current form as a starting point.
>
> --
> Masque mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/masque
>

---

From: David Schinazi <[email-masked]>
Date: Wed, 9 Sep 2020 16:29:17 -0700

(To state the obvious: as one of the authors, I support adoption)

I strongly disagree with Ben's suggestion to use the state "Adopted for WG
info only".
I've pasted the definition for that state from RFC 6174 here:

   The "Adopted for WG Info Only" state describes a document that
   contains useful information for the WG that adopted it, but the
   document is not intended to be published as an RFC.  The WG will not
   actively develop the contents of the I-D or progress it for
   publication as an RFC.  The only purpose of the I-D is to provide
   information for internal use by the WG.

Source: https://tools.ietf.org/html/rfc6174#section-4.2.3

I think there is value in publishing this document as RFC,
and our charter specifically states "The working group will first
deliver [...] a requirements document for IP proxying."
My understanding is that, in that sentence, "deliver" a
document means publish an RFC.

David

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 9 Sep 2020 20:03:37 -0700

> document means publish an RFC.

I agree with Ben on status. I do not think that publishing this as an RFC
provides much value. Can you describe what value you think it provides
other than guiding the WG towards a solution document.

As far as the charter goes, the situation seems somewhat confusing in that
the charter lists three documents but only has two milestones:

   The group will focus on a limited set of client-initiated services: (1)
UDP CONNECT and (2) IP proxying.
   Server-initiated services are   out of scope. The working group will
first deliver a protocol solution for UDP
   CONNECT and a requirements document for IP proxying. Once both are
complete, the working group will
   focus on a protocol solution for IP proxying.
..

   Last Submit an informational IP Proxying over MASQUE document
   Next Submit a standards track UDP CONNECT document

I suppose one could argue that the "Last" refers to the requirements
document, but given the sequencing above, it would then not be last, so I
think one could also read this as saying that the IP Proxying protocol
document is to be Information. In any case, I don't think we can consider
the charter dispositive here.

-Ekr

David

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 15 Sep 2020 05:34:32 +0000

Hi all,

I think it’s too early for adoption as we didn’t conclude the discussion on use cases yet. This document lists multiple use cases which impact the requirements but it is not clear to me yet if we want to support all of them or if we initially focus mainly on the direct client to proxy case. I think we should decide this first before we adopt a document to make sure only those cases that we will cover are listed in an (informational) wg document. We started this discussion at the interim but to my understanding didn’t conclude.

Mirja

________________________________
Von: Masque <[email-masked]> im Auftrag von Christopher Wood <[email-masked]>
Gesendet: Mittwoch, September 9, 2020 2:32 PM
An: [email-masked]
Betreff: [Masque] Adoption call for "Requirements for a MASQUE Protocol to Proxy IP Traffic"

   https://protect2.fireeye.com/v1/url?k=83bee503-dd1e059d-83bea598-86ee86bd5107-7486afa5e7992473&q=1&e=352e0e0a-34f3-4463-abcd-d93215fdadc8&u=https%3A%2F%2Fgithub.com%2FDavidSchinazi%2Fmasque-drafts

Thanks,
Chris and Eric

---

From: "Christopher Wood" <[email-masked]>
Date: Tue, 15 Sep 2020 11:59:54 -0700

As pointed out, the charter and milestones are somewhat unclear with respect to IP proxying. After discussion with Martin, we would like to clarify that, at this time, draft-cms-masque-ip-proxy-reqs is under consideration for adoption as a Support Document [1]. If adopted, we will iterate on it and move it through WG last call, but will not progress it to the IESG for publication as an Informational RFC.

The value of this document is in informing any technical solution for IP proxying. Pursuing publication as an RFC increases this value in two important ways: (1) it garners review from the larger IETF community, and (2) makes the requirements stable. The chairs believe that soliciting early review from the Transport and Internet area directorate groups will help us achieve (1), and pushing the document through WG last call will achieve (2). (This also gives us some freedom to change the requirements, should new or otherwise critical information come to light.)

We hope this offers clarity for the adoption call.

Best,
Chris and Eric

On Wed, Sep 9, 2020, at 5:30 AM, Christopher Wood wrote:
> One of the goals on our charter is producing a requirements document 
> for IP proxying. draft-cms-masque-ip-proxy-reqs is one attempt at 
> accomplishing this goal. Based on feedback received during the last 
> meeting and the document revision since, we'd like to start an adoption 
> call for this document in its current form as a starting point. 
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 17 Sep 2020 17:55:25 -0500

Hi, Chris,

>    https://datatracker.ietf.org/doc/draft-cms-masque-ip-proxy-reqs/

I'd like to see this document adopted (as the basis for future work).

I am sympathetic to Mirja's comment that we are still talking about use
cases. My suggestion would be adding tags to each requirement pointing to
the corresponding use case(s) with this requirement so that any use case we
punt that had unique requirements can be easily identified.

I don't have an opinion about whether this is adopted for WG usage or for
publication at this time. I do note that the working group can have that
conversation with the IESG at any time (including during IESG evaluation),
so my suggestion would be to take your best guess and know that your best
guess isn't locking anything in forever.

I do expect that this document will be of use within 3GPP (at least in SA2,
and perhaps other 3GPP working groups), but I don't know if they'll need a
normative dependency on something that gets published in the RFC series, so
don't worry about that as part of the publish/don't publish discussion.

One point that's worth mentioning is that some of our least helpful
documents were written as working group supporting documents, not
maintained while the target protocol was being specified, and then either
publication-requested in a form that was outdated or publication-requested
after a fire drill to do last minute cleanup. If the working group wants to
publish this as an RFC, please keep it updated on along the way!

Best,

Spencer

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 18 Sep 2020 08:27:05 +0000

Hi,
(As individual)

I think this adoption call is a premature. I think the WG need to agree to the
general scope of what IP proxying in MASQUE means before we can adopt a document
on its requirement. Yes, the WG will need a working document, we likely do not
need to publish it as the resulting scope of the solution anyway should be
descirbed in the solution document that I expect the WG to produce eventually.

To make it clear why I think we should agree on a few aspects before adopting a
requirements document I would like to bring up a significant discussion point
for draft-cms-masque-ip-proxy-reqs. In setion 2 the document states:

2.  Use Cases

   There are multiple reasons to deploy an IP proxying protocol.  This
   section discusses some examples of use cases that MUST be supported
   by the protocol.

And the subsections include the following:

2.1.  Consumer VPN
2.2.  Point to Point Connectivity
2.3.  Point to Network Connectivity
2.4.  Network to Network Connectivity

The first three I think have very similar solution space and big overlap in
functionality requried to safely do them. However, the one I really think we
need to discuss more indept before agreeing to do it is: 

2.4 Network to Network Connectivity.

So from my point of view the solution for this can fall into two main
categoriezs. 

A) The MASQUE server is the owner of the network prefix being proxied

B) The MASQUE server proxies any network prefix given by client

The reason for dividing it up like this is to look at what is required to safely
deploy these two differnt versions. 

In A) the MASQUE server gives the MASQUE client and its local network a prefix
that is has been assigned to hand out for this purpose and where the upstream
router has a route for the whole prefix that the MASQUE server uses to hand out.
In this case source address validation for the MASQUE server is easy. By only
forwarding source address from the prefix handed out there are no risks for
source address spoofing through the MASQUE server. Also, from a routing
perspective the route to the prefixes the MASQUE server uses is a primary route
and one which network adimns have a chance of doing attestation of ownership for
the address space. 

In B) if the MASQUE client can inject any network prefix to the MASQUE server we
have just created a tool for avoiding source address validation, or we need to
have a solution where the MASQUE server can verify the source address ownership
to the client. Secondly, this allows then route injection into the routing
system that are likely to go all the way to BGP in the general case. 

I think I understand Google's use case and why they push this, and from their
perspective this is done using internal network resources and networks prefixes
that they will control and they can authorize. However, from a general MASQUE
solution this do require a security solution and discussion of this security
threat realted to source address validation, and impact on routing. Thus, the
scope of the work if B) is included is significant larger and will take longer
time. 

I would propose that B) is not taken on initially and is for future
consideration. With that I requirements 3.4, 3.5, 3.6 can be modified and
simplified. 

I also think that not having a discussion of addressing architecture and
implications on routing by network proxying, which is what Section 4.1 states
will result in a solution that will not be published. So also that needs to be
addressed. 

The below question will also show that I think this document needs to mature a
bit prior to adoption. 

I also have some questions on the draft:

A. In Section 3.4:

   Similarly, to support the network-
   to-network use case, the server will be able to request assignment of
   an IP address range from the client, and the client will either
   assign a range or decline the request.

Can you elaborate why the Server would need an IP address from the Client's
network? The client will need to be a gateway in the client side network to be
able to receive the traffic to forward, but I don't see why the server needs
appear as that gateway?

B. Section 3.6:

I do understand the need for some identify. The server first of all to allow the
client to determine it is communicating with the right MASQUE server. However
for the identification of the client, is that likely at all to be a domain
name?Isn't that a user name, or some other form of authorization to use the
resource. 

C. Section 3.8 in this context I think there are more than the endpoint that
needs authoriztion if network to network proxying would happen. Also, extension
to OAUTH, doesn't that require work in another WG. It looks like more
explanation of what the needs are that prompt the need for extending the
authorization protocol. 

D. Section 3.10

I don't see an issue with a tunnel protocol being used without flow control. If
one overwhelm either of the MASQUE client or server that is equal to congestion
in the network. However, in the meeting I got the impression there was
consideration to disable congestion control also. Is this or not a requ

E. Section 3.11

I think a general VPN use would from a traffic pattern would be distinguishable
from encrypted HTTP Web traffic. Is only wire format the goal here?

F. Section 3.14

Do I interpret this section correctly that it requires a IP session to be split
from a client to two servers? If that is the case that will imply additional
functionality for path selection on a sub IP session flow level to avoid
reordering within such subflows. 

Does this also need some additional concerns if someone deploys the servers
under different networks, resulting in multi-homing scenarios where outgoing and
returning traffic for sub-flows ends up in different paths? In general you will
get some traffic steering concerns to deal with. 

To me this requirement appears to potentially imply quite a bit of more
functionality to work. 

Cheers

Magnus Westerlund 

----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Mobile +46 73 0949079
Torshamnsgatan 23           |
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 18 Sep 2020 10:42:51 -0500

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]> wrote:

Which of these requirements (in
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.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

---

From: David Schinazi <[email-masked]>
Date: Fri, 18 Sep 2020 09:45:02 -0700

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

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 21 Sep 2020 10:00:54 +0000

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:
> > On Fri, Sep 18, 2020 at 3:27 AM Magnus Westerlund <
> > magnus.westerlund=[email-masked]> wrote:
> > 
> > (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

---

From: David Schinazi <[email-masked]>
Date: Mon, 21 Sep 2020 17:35:31 -0700

Hi Magnus,

WG adoption does not imply WG consensus. So yes, if this document is
adopted,
then that does not indicate that the WG has reached consensus on any of its
contents.

David

---

From: "Christopher Wood" <[email-masked]>
Date: Thu, 24 Sep 2020 05:04:56 -0700

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

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 25 Sep 2020 07:32:37 +0000

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

Magnus Westerlund

---

From: Eric Kinnear <[email-masked]>
Date: Sat, 26 Sep 2020 16:54:34 -0700

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]> wrote:
> 
> Hi Chris,
> 
> SE-164 80 Stockholm, Sweden | mailto: [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/masque <https://www.ietf.org/mailman/listinfo/masque>

---

From: Lucas Pardue <[email-masked]>
Date: Sun, 27 Sep 2020 01:15:36 +0100

I don't have much stake in this draft or IP proxying at this stage. And so
reading the discussion so far, the question I have is: if we didn't adopt
the document now would anything really shift if we were to ask the same
question again in N months time?

By that I mean, will the foundational technologies ( QUIC etc) or problem
space change? Will we see someone present completely alternative or
orthogonal requirements?

I suspect neither of those categories to play out. And so IMO having a
single adopted document to focus energy to seems like a sensible choice.

But naturally I've tempted fate with those assertions, so I could well be
proven wrong.

Cheers
Lucas

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 28 Sep 2020 10:05:18 +0000

Hi Lucas,

I think the largest question mark about the doucment is if the WG would even
attempt to tackle the issue of network proxying even on a requirement level.
When that is resolved I think we can answer the question if the document is
suitable or not. 

I also didn't get any feedback on my quesitons from the authors. Answers to
these may help the rest of the WG.

Cheers

Magnus

On Sun, 2020-09-27 at 01:15 +0100, Lucas Pardue wrote:
> reading the discussion so far, the question I have is: if we didn't adopt the
> document now would anything really shift if we were to ask the same question
> again in N months time? 
> 
> space change? Will we see someone present completely alternative or orthogonal
> requirements?
> 
> I suspect neither of those categories to play out. And so IMO having a single
> adopted document to focus energy to seems like a sensible choice.
> 
-- 
Cheers

Magnus Westerlund

---

From: David Schinazi <[email-masked]>
Date: Mon, 28 Sep 2020 09:18:38 -0700

Hi Magnus, responses inline.

David

> When that is resolved I think we can answer the question if the document is

There's no question mark here. The IESG already answered this question
when you approved our charter
<https://datatracker.ietf.org/wg/masque/about/> which states:
    <<The group will focus on a limited set of client-initiated services:
    (1) UDP CONNECT and (2) IP proxying. Server-initiated services are out
    of scope. The working group will first deliver a protocol solution for
UDP
    CONNECT and a requirements document for IP proxying.>>

> these may help the rest of the WG.

I thought I had sent feedback on all of your questions, could you point out
which ones I missed, please?

> orthogonal
> single

On Mon, Sep 28, 2020 at 3:05 AM Magnus Westerlund <magnus.westerlund=
[email-masked]> wrote:

> orthogonal
> single

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 29 Sep 2020 13:12:11 +0000

David,

On Mon, 2020-09-28 at 09:18 -0700, David Schinazi wrote:
> On Mon, Sep 28, 2020 at 3:05 AM Magnus Westerlund <
> when you approved our charter which states:
>     of scope. The working group will first deliver a protocol solution for UDP

So, your drafts discusses different use cases. 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. 

The IP network proxying that you include in the draft as a use case has
implications on the routing system outside of the MASQUE client and server. What
I understand it implies that the MASQUE server is capable of injecting a route
for the proxied network into the upstream router. In addition the MASQUE server
have to consider source address validation. 

> which ones I missed, please?

In https://mailarchive.ietf.org/arch/msg/masque/5k_IUw6-A8jQi3i_q1MOtZt5Hl8 I
included questions A-F. Those I have not seen a response email to those.

Cheers

Magnus Westerlund

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 30 Sep 2020 15:26:32 -0400

On Tue, Sep 29, 2020 at 9:12 AM Magnus Westerlund <magnus.westerlund=
[email-masked]> wrote:
...

> Proxying a whole subnet by the

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.