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

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 2 Jun 2021 08:12:42 +0000

Hi all,

I think I already made my points a couple of times but for the record: I agree with the points raised by Magnus below. I don't think the drafts is clear about all requirements and especially about the question which things are part of the core document and which things might only be needed by one potential use case. I think the document served its purpose by creating discussion but I don't feel we have reached consensus on all points. However, I also don't think spending more time on the requirements is a useful exercise and I would prefer to move on to work on the protocol (even without final consensus on the requirements).

Mirja

On 31.05.21, 17:35, "Masque on behalf of Magnus Westerlund" <[email-masked] on behalf of magnus.westerlund=[email-masked]> wrote:

    Hi,

    I have reviewed the document -02). I have some detailed comments below but 
    first I have a very high level comment about this document.

    I think it is a mistake to attempt to declare a WG consensus on this 
    requirement document. I do believe this document contains valuable things to 
    consider. However, I do not agree on how it is formulated or what requirements 
    level it puts on things or what it means. An example where I see a significant 
    issue with how we interpret things would be this from Section 2.

    "This
       section discusses some examples of use cases that MUST be supported
       by the protocol.  Note that while the protocol needs to support these
       use cases, the protocol elements that allow them may be optional."

    I think this MUST is quite meaningless in the context of the next sentence. 
    For example I am of the opinion that the protocol should not be required to 
    support use case 2.4, however I have no issue with the proponents for that use 
    case develop an extension. The reason I think it should be an extension in an 
    individual document is that in this use case one can assume much less about 
    routing, source address validation, and the trust issues for that information 
    looks different. So what does it mean that the protocol MUST support 2.4 if 
    that is in an extension? Then it is not necessary for it to support and thus 
    not a MUST.

    This is just one example and I point out more things where I am not agreeing 
    on how the requirement is formulated below. I think it is better for the WG 
    that we avoid declaring consensus on the requirement document (which we anyway 
    not intended to published) and instead use it as a reminder of use cases and 
    functionality and then dive into solution that covers these. We can discuss in 
    the context of the solution if it is necessary or not to have a particular 
    feature that enables a particular use cases in the core spec or in a 
    extension.

    Section 2.4:

    I think this use cases is quite special as it is the one that requires the 
    MASQUE Server to trust the MASQUE client statements of what networks and 
    routes it has. In 2.1-2.3 the MASQUE client will be a node in a network 
    provisioned by the MASQUE server. For information purpose the MASQUE server 
    can inform the client what routes exists from this network. In most cases this 
    network will have a default route to the rest. In some cases, like 2.3 it 
    might be specifically intended to reach a particular network(s). Also when the 
    masque server deals with that the client presents an address range that isn't 
    borrowed from the MASQUE server, then also there are questions about routing 
    loops, return routability and ownership of that address space. Thus the 
    considerations for this use case are significantly more complex and this is 
    the reasons I argue that this should be a separate document so that it can be 
    progressed as it matures and the core don't need to wait for these issues to 
    be sorted out.

    Section 3.9: I think this requirements more advanced parts really are 
    associated primarily with use case 2.4. So providing a single IP address or a 
    part of a prefix for a network that is treated as one across is this really 
    route information, or reachability from this network?

    Section 3.9: I am not certain I understand what it actually referred to with
      "Both
       endpoints can also request a route to a given prefix, and the peer
       can choose to provide that route or not."

    Is it a request to add a route to the specified prefix via the requesting 
    MASQUE endpoint or the reverse of please provide a route to the given prefix?

    Section 3.6: "Note that this requirement does not cover
       authenticating the identifier."

    Do I understand this text to say that the protocol should be able to carry the 
    ID, but not need to enable a trust structure to verify the ownership of that 
    identifier? But, I would guess that it is assumed that the transport of said 
    identifier will be done so no third party can modify it per Section 3.7.

    Isn't this requirement in contradiction of IETF general desire to mandate at 
    least one secure method for operating the protocol? Thus, it would be fine to 
    have a general mechanism for providing identifier or the remote endpoints 
    identity, however one mandatory to implement solution for this should be 
    provided. The reason I am asking here is that in many usage of a secured 
    tunnel require the endpoint to identify itself.

    Section 3.8: Is this really a requirement, or a desired capability from the 
    underlying transport to reduce the overhead? When using QUIC with datagram one 
    have the possibility to move the bottleneck from the forwarding on the sending 
    side not keeping up and having to drop packets to have the receiving endpoint 
    not keep up in its forwarding and therefore drop packets. But, clearly it will 
    reduce the overhead for operation when datagram is available. But, clearly the 
    MASQUE implementation need to work also when HTTP/3 is not available. Thus, an 
    implementation needs to have support for flow controlled traffic, and I guess 
    this requirement intended to say that it also needs to support when flow 
    control is not available.

    Section 5.1:

       This document only describes the requirements for a protocol that
       allows IP proxying.  It does not discuss how the IPs assigned are
       determined, managed, or translated.  While these details are
       important for producing a functional system, they do not need to be
       handled by the protocol beyond the ability to convey those
       assignments.

    I would claim that the use case implies that certain address architecture 
    needs to be supported. I think not being specific about that actually makes it 
    harder to validate that the protocol actually supports the intended use cases. 
    I think the discussion we have had so far would have benefitted from actually 
    drawing examples of cases that people desire to support. I don't think they 
    are particular many. However, especially the network to network use case 
    discussion would have benefitted from some examples of intended deployments.

    To conclude I don't think this document is ready declare any form of WG 
    consensus on.

    Cheers

    Magnus Westerlund

---

From: David Schinazi <[email-masked]>
Date: Wed, 2 Jun 2021 15:19:32 -0700

Hi Magnus and Mirja, thanks for your comments.

I strongly disagree with you. There is great value in establishing WG
consensus on the requirements document, as it allows us to avoid
litigating the same points over and over again. I'm very excited to start
working on a protocol solution here, but we should leverage the work we've
done on the requirements document, not ignore it. Looking more closely at
your objections, they all seem to stem from the fact that you would rather
not support the network-to-network use-case. You've repeated this objection
many times without providing justification for it, and that does not make
it true. If you look at draft-cms-masque-connect-ip which is a possible
protocol solution for this space, you'll find that supporting this use-case
does not increase the complexity of the protocol. And we have strong
precedent at the IETF for this: RFC 4303 supports network-to-network with
any added complexity, because it's a fundamentally natural use of IP
proxying.

Thanks,
David

On Wed, Jun 2, 2021 at 1:13 AM Mirja Kuehlewind <mirja.kuehlewind=
[email-masked]> wrote:

> Hi all,
>
> I think I already made my points a couple of times but for the record: I
> agree with the points raised by Magnus below. I don't think the drafts is
> clear about all requirements and especially about the question which things
> are part of the core document and which things might only be needed by one
> potential use case. I think the document served its purpose by creating
> discussion but I don't feel we have reached consensus on all points.
> However, I also don't think spending more time on the requirements is a
> useful exercise and I would prefer to move on to work on the protocol (even
> without final consensus on the requirements).
>
> Mirja
>
> On 31.05.21, 17:35, "Masque on behalf of Magnus Westerlund" <
> [email-masked] on behalf of magnus.westerlund=
> [email-masked]> wrote:
>
>     Hi,
>
> --
> Masque mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/masque
>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 2 Jun 2021 15:32:11 -0700

> issue with how we interpret things would be this from Section 2.

Can you elaborate a bit on what you are asking for here?

The charter says:
   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.

IOW, this requirements document is prior to working on IP proxying
technically. So, what would you have us to do be able to work on that?

> that is in an extension? Then it is not necessary for it to support and

I don't think this is meaningless. For instance, suppose that I was writing
a requirements document for TLS, I might say "TLS must support
certificate-based client authentication", but any given client or server
might not support that. The first is a requirement on the protocol design,
the second on the implementations.

This is just one example and I point out more things where I am not
> agreeing

With the caveat that I am not a huge fan of requirements documents, this
seems like it's just punting all requirements discussions to the protocol
document. If we really don't have consensus on 2.4 (and without taking a
position either way on that), then I would rather bracket that requirement
and declare consensus on what we have.

I don't personally strongly desire 2.4 but it's clear to me that 2.4 is an
essential part of operating a large class of corporate VPNs, so if we want
to have a generic VPN protocol, we need it, no? To the extent to which it
is complicated, I would suggest we try to solve it (borrowing from IPsec as
appropriate) and if we discover we cannot within a reasonable period of
time, then we can consider punting it.

-Ekr

---

From: Töma Gavrichenkov <[email-masked]>
Date: Thu, 3 Jun 2021 06:17:43 +0300

Peace,

> without final consensus on the requirements).

Frankly, if brought out of context, that would be the scariest thing to
hear on a software project, or really on a project of any kind, especially
on those involving more than one developer.

"Let's just start the development without clear understanding of what we
do, and we'll declare success once we're too tired to continue together".
Has this ever worked well, other than by accident?

--
Töma

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 2 Jun 2021 21:55:35 -0700

I've read this document, and at a high level, I find it useful as a list of
items to work on. That is clearly the intent of the document, it is in line
with what we planned to do (per charter), and as such, I am fine with
having the document.

The list of use cases seems natural with an IP VPN, and the list of
requirements seems reasonable (some of them are very desirable) to me. All
in all, this is a fine starting list to try and solve for.

About 2.4: (Like EKR, I don't have a strong desire for it but) It seems
natural to support this, and there are folks who want it. Magnus, Mirja, is
the concern that this is too complicated, or that this shouldn't consume wg
time when the other cases are more important? If it's the forner, we can
simply prioritize. If it's the latter, we can discuss ways of deciding how
to punt it later if it cannot be solved.

- jana

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 03 Jun 2021 15:59:52 +1000

The network-network case could result in adding a bunch of complexity to a design [1].  But Jana and Ekr are right here.  We can build the complex parts of the protocol last (or even not at all).  And implementations will be free to decide not to support those more complex features.

As the *requirement* is not that complex, I see little harm in it.  Let's talk about the protocols instead.

[1] ...some of it unnecessary, in my opinion; Alex and David will know that I don't particularly like the stateful design they have proposed.

On Thu, Jun 3, 2021, at 14:55, Jana Iyengar wrote:
> I've read this document, and at a high level, I find it useful as a 
> list of items to work on. That is clearly the intent of the document, 
> it is in line with what we planned to do (per charter), and as such, I 
> am fine with having the document.
> 
> requirements seems reasonable (some of them are very desirable) to me. 
> All in all, this is a fine starting list to try and solve for. 
> 
> natural to support this, and there are folks who want it. Magnus, 
> Mirja, is the concern that this is too complicated, or that this 
> shouldn't consume wg time when the other cases are more important? If 
> it's the forner, we can simply prioritize. If it's the latter, we can 
> discuss ways of deciding how to punt it later if it cannot be solved.
> 
> - jana
> 
> > On Wed, Jun 2, 2021, 11:13 AM Mirja Kuehlewind <mirja.kuehlewind=[email-masked]> wrote:
> >> However, I also don't think spending more time on the requirements is a useful exercise and I would prefer to move on to work on the protocol (even without final consensus on the requirements).
> > 
> > Frankly, if brought out of context, that would be the scariest thing to hear on a software project, or really on a project of any kind, especially on those involving more than one developer.
> > 
> > "Let's just start the development without clear understanding of what we do, and we'll declare success once we're too tired to continue together".  Has this ever worked well, other than by accident?
> > 
> > --
> > Töma
> > -- 
> > Masque mailing list
> > [email-masked]
> [email-masked] <mailto:Masque%40ietf.org>

---

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 3 Jun 2021 07:24:13 +0000

Inline.

From: Jana Iyengar <[email-masked]>
Date: Thursday, 3. June 2021 at 06:56
To: Töma Gavrichenkov <[email-masked]>
Cc: Mirja Kuehlewind <[email-masked]>, Magnus Westerlund <[email-masked]>, Christopher Wood <[email-masked]>, MASQUE <[email-masked]>
Subject: Re: [Masque] WGLC for "Requirements for a MASQUE Protocol to Proxy IP Traffic"

I've read this document, and at a high level, I find it useful as a list of items to work on. That is clearly the intent of the document, it is in line with what we planned to do (per charter), and as such, I am fine with having the document.

The list of use cases seems natural with an IP VPN, and the list of requirements seems reasonable (some of them are very desirable) to me. All in all, this is a fine starting list to try and solve for.

About 2.4: (Like EKR, I don't have a strong desire for it but) It seems natural to support this, and there are folks who want it. Magnus, Mirja, is the concern that this is too complicated, or that this shouldn't consume wg time when the other cases are more important? If it's the forner, we can simply prioritize. If it's the latter, we can discuss ways of deciding how to punt it later if it cannot be solved.

[MK] As the network-to-network use case is only one use among at least three and the more complex one, the concern is about adding functions that are only relevant to this use case to the base spec. As such I would also prefer to prioritize the other, hopefully more simply use cases first.

Mirja

- jana

On Wed, Jun 2, 2021 at 8:18 PM Töma Gavrichenkov <[email-masked]<mailto:[email-masked]>> wrote:
Peace,
On Wed, Jun 2, 2021, 11:13 AM Mirja Kuehlewind <mirja.kuehlewind=[email-masked]<mailto:[email-masked]>> wrote:
However, I also don't think spending more time on the requirements is a useful exercise and I would prefer to move on to work on the protocol (even without final consensus on the requirements).

--
Töma
--
Masque mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/masque

---

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 3 Jun 2021 07:29:08 +0000

Hi Töma, hi all,

I explicitly said that I think the work on the requirement was useful (and required by the charter), however, I think we did not reach consensus on all of the requirements and their priority in the draft. It’s still a good list to work from this list but I don’t see value in spending more time in trying to agree on the final set of requirement when decisions might come more easily when talking about concrete realizations. I don’t say we should at all ignore the requirement document but I don’t want this group to declare consensus on something where I think there is no consensus.

Mirja

From: Töma Gavrichenkov <[email-masked]>
Date: Thursday, 3. June 2021 at 05:18
To: Mirja Kuehlewind <[email-masked]>
Cc: Magnus Westerlund <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Masque] WGLC for "Requirements for a MASQUE Protocol to Proxy IP Traffic"

Peace,

--
Töma

---

From: Töma Gavrichenkov <[email-masked]>
Date: Thu, 3 Jun 2021 11:26:13 +0300

Peace,

On Thu, Jun 3, 2021 at 10:29 AM Mirja Kuehlewind
<[email-masked]> wrote:
> I don’t say we should at all ignore the requirement document
> but I don’t want this group to declare consensus on something
> where I think there is no consensus.

I don't really see the reason behind opposing 2.4.  If someone doesn't
want to develop this use case in the spec, someone else would, and
we've already got volunteers.  The protocol spec is a collaborative
work, isn't it?

The use case itself is totally useful and would certainly have an
impact on adoption, within corporate IT infrastructures as well as in
general.  The *protocol* MUST support it before it sees the light of
the day; the implementations, probably, SHOULD.

--
Töma

---

From: Alex Chernyakhovsky <[email-masked]>
Date: Thu, 3 Jun 2021 15:34:48 -0400

Hi folks,

My view is that this requirements document is a set of requirements for the
protocol to support, not the implementations. The protocol must be able to
support these use cases, but it's not necessarily the case that all
implementations will. As I've mentioned previously, I expect we will have
to have additional documents describing mandatory-to-implement extensions
for certain operating profiles which will define what implementations need
to support for specific instantiations of the use cases.

Sincerely,
-Alex

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 4 Jun 2021 14:57:55 +0000

Hi,

On Wed, 2021-06-02 at 15:32 -0700, Eric Rescorla wrote:

On Mon, May 31, 2021 at 8:35 AM Magnus Westerlund <magnus.westerlund=[email-masked]<mailto:[email-masked]>> wrote:
Hi,

The charter says:
   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.

IOW, this requirements document is prior to working on IP proxying technically. So, what would you have us to do be able to work on that?

I think one way to deal with this is to recharter. But, maybe we can adjust the document or have additional discussion to create a consensus here. I think clarifying what is actual common core and what is needed for specific use cases could be vastly useful.

And with more voices involved in this we likely can have a rough consensus that actually is a consensus.

"This

I don't think this is meaningless. For instance, suppose that I was writing a requirements document for TLS, I might say "TLS must support certificate-based client authentication", but any given client or server might not support that. The first is a requirement on the protocol design, the second on the implementations.

The issue I have I think is that this do require the protocol to have all these features in place before we can progress the core of the protocol for approval. Which means that we need to solve all the issues with all the use cases before the WG can progress.

With the caveat that I am not a huge fan of requirements documents, this seems like it's just punting all requirements discussions to the protocol document. If we really don't have consensus on 2.4 (and without taking a position either way on that), then I would rather bracket that requirement and declare consensus on what we have.

If with "bracketing" means clarify that these are potentially optional parts then I think that is a reasonable direction.

I don't personally strongly desire 2.4 but it's clear to me that 2.4 is an essential part of operating a large class of corporate VPNs, so if we want to have a generic VPN protocol, we need it, no? To the extent to which it is complicated, I would suggest we try to solve it (borrowing from IPsec as appropriate) and if we discover we cannot within a reasonable period of time, then we can consider punting it.

So I am not objecting to the WG working on 2.4, and as you say it will be necessary. However, I would strongly prefer to have that functionality being an extension of a basic core.

Cheers

Magnus

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 4 Jun 2021 14:59:59 +0000

Hi Alex,

Thanks for this clarification. The formulations in the requriements document very much make me interpret this as a desire for a monolith from a protocol functionality perspective.

So maybe we should try to figure out what needs to be done to address that aspect.

Cheers

Magnus

On Thu, 2021-06-03 at 15:34 -0400, Alex Chernyakhovsky wrote:
Hi folks,

My view is that this requirements document is a set of requirements for the protocol to support, not the implementations. The protocol must be able to support these use cases, but it's not necessarily the case that all implementations will. As I've mentioned previously, I expect we will have to have additional documents describing mandatory-to-implement extensions for certain operating profiles which will define what implementations need to support for specific instantiations of the use cases.

---

From: David Schinazi <[email-masked]>
Date: Fri, 4 Jun 2021 08:14:44 -0700

Hi Magnus,

What exactly are you trying to achieve here? It sounds like your only point
of disagreement with the WGLC is that you would prefer to have
network-to-network be an extension instead of an optional-to-implement part
of the core. Because of this very minor detail, you're suggesting large
amounts of process like a recharter. We all know that that takes many weeks
to accomplish. Can you explain why such a small detail warrants delaying
this whole effort?

Thanks,
David

On Fri, Jun 4, 2021 at 7:58 AM Magnus Westerlund <magnus.westerlund=
[email-masked]> wrote:

>   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.
>
>
>
> I think one way to deal with this is to recharter. But, maybe we can
> adjust the document or have additional discussion to create a consensus
> here. I think clarifying what is actual common core and what is needed for
> specific use cases could be vastly useful.
>
> I don't think this is meaningless. For instance, suppose that I was
> writing a requirements document for TLS, I might say "TLS must support
> The issue I have I think is that this do require the protocol to have all
> these features in place before we can progress the core of the protocol for
> approval. Which means that we need to solve all the issues with all the use
> cases before the WG can progress.
>
>
>
>
> If with "bracketing" means clarify that these are potentially optional
> parts then I think that is a reasonable direction.
>
>
> So I am not objecting to the WG working on 2.4, and as you say it will be
> necessary. However, I would strongly prefer to have that functionality
> being an extension of a basic core.
>
> Cheers
>
> Magnus
> --
> Masque mailing list
> [email-masked]

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 4 Jun 2021 15:16:18 +0000

On Wed, 2021-06-02 at 15:19 -0700, David Schinazi wrote:
Hi Magnus and Mirja, thanks for your comments.

I strongly disagree with you. There is great value in establishing WG consensus on the requirements document, as it allows us to avoid litigating the same points over and over again. I'm very excited to start working on a protocol solution here, but we should leverage the work we've done on the requirements document, not ignore it. Looking more closely at your objections, they all seem to stem from the fact that you would rather not support the network-to-network use-case. You've repeated this objection many times without providing justification for it, and that does not make it true. If you look at draft-cms-masque-connect-ip which is a possible protocol solution for this space, you'll find that supporting this use-case does not increase the complexity of the protocol. And we have strong precedent at the IETF for this: RFC 4303 supports network-to-network with any added complexity, because it's a fundamentally natural use of IP proxying.

To be as clear as possible. I don't want the WG be required to have finished the network to network use case functionality prior to publication of the core solution that covers the other use cases. You say I have no justification, I brought up several aspects that I think will need to have description and security considerations and potentially additional protocol functionalities that I fear will delay the work. For example source address validation, something that IETF didn't have specifications for in the same way as we do now when RFC 4303 was published. I also have my experience on the IESG to know that the bar is ticking ever up to ensure that protocols are safe to deploy and that security issues are mitigated.

I also hope this discussion do result in people forming their own opinion and actually speaking up if they think the requirements document says what they want.

I will note that I am convinced that this effort has been severly hampered by the lack of physical meetings with a chance to follow up on points and have clarifying discussions.

Cheers

Magnus

Thanks,
David

On Wed, Jun 2, 2021 at 1:13 AM Mirja Kuehlewind <mirja.kuehlewind=[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

Mirja

On 31.05.21, 17:35, "Masque on behalf of Magnus Westerlund" <[email-masked]<mailto:[email-masked]> on behalf of magnus.westerlund=[email-masked]<mailto:[email-masked]>> wrote:

    Hi,

    "This

    Section 2.4:

    Section 5.1:

    Cheers

    Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 4 Jun 2021 15:25:45 +0000

Hi David,

If it is a minor detail, then lets address that “detail” then and create a WG consensus. 

Cheers

Magnus Westerlund

From: David Schinazi <[email-masked]> 
Sent: den 4 juni 2021 17:15
To: Magnus Westerlund <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Masque] WGLC for "Requirements for a MASQUE Protocol to Proxy IP Traffic"

Hi Magnus,

What exactly are you trying to achieve here? It sounds like your only point of disagreement with the WGLC is that you would prefer to have network-to-network be an extension instead of an optional-to-implement part of the core. Because of this very minor detail, you're suggesting large amounts of process like a recharter. We all know that that takes many weeks to accomplish. Can you explain why such a small detail warrants delaying this whole effort?

Thanks,

David

On Fri, Jun 4, 2021 at 7:58 AM Magnus Westerlund <magnus.westerlund=[email-masked] <mailto:[email-masked]> > wrote:

Hi,

 

On Mon, May 31, 2021 at 8:35 AM Magnus Westerlund <magnus.westerlund=[email-masked] <mailto:[email-masked]> > wrote:

Hi,

The charter says:

 

 

"This

 

 

Cheers

Magnus

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

---

From: "Christopher Wood" <[email-masked]>
Date: Fri, 04 Jun 2021 08:30:08 -0700

> If it is a minor detail, then lets address that “detail” then and 

The purpose of this WGLC is to try and establish such consensus. To that end, it would be useful if folks could chime in on any points of contention, especially this particular section, so we can assess consensus upon completion.

Thanks,
Chris, for the chairs

---

From: David Schinazi <[email-masked]>
Date: Fri, 4 Jun 2021 08:37:54 -0700

On Fri, Jun 4, 2021 at 8:16 AM Magnus Westerlund <
[email-masked]> wrote:

> To be as clear as possible. I don't want the WG be required to have
> finished the network to network use case functionality prior to publication
> of the core solution that covers the other use cases. You say I have no
> justification, I brought up several aspects that I think will need to have
> description and security considerations and potentially additional protocol
> functionalities that I fear will delay the work.
>

That's a pretty circular argument. You're adding scope to the problem and
then saying that such added scope is causing delays. IP proxying is about
encapsulating IP packets and some negotiation. Policy isn't and shouldn't
be in scope. If I configure a home router to use a given DHCP address pool,
the DHCP RFC doesn't need to tell me how to validate that I'm allowed to
use that address pool.

For example source address validation, something that IETF didn't have
> specifications for in the same way as we do now when RFC 4303 was published.
>

RFC 4303 didn't discuss source address validation because it was out of
scope for an encapsulation format, not because the IETF lacked security at
the time. Policy is important, but it's just not in scope here.

I also have my experience on the IESG to know that the bar is ticking ever
> up to ensure that protocols are safe to deploy and that security issues are
> mitigated.
>

Luckily the IESG doesn't have a monopoly on knowing how to build safe
protocols.

I also hope this discussion do result in people forming their own opinion
> and actually speaking up if they think the requirements document says what
> they want.
>

Yes, I'm hoping this discussion is helping folks form opinions. But the
burden of speaking up isn't exclusively on folks in favor.

I will note that I am convinced that this effort has been severly hampered
> by the lack of physical meetings with a chance to follow up on points and
> have clarifying discussions.
>

I agree that things could have progressed more efficiently, but we're still
doing pretty well.

Cheers
>     To conclude I don't think this document is ready declare any form of
On Fri, Jun 4, 2021 at 8:25 AM Magnus Westerlund <

> If it is a minor detail, then lets address that “detail” then and create a

Let's *discuss* that detail. As individual contributors to this working
group, you and I are not in a position to decide what forms consensus or
what needs to be addressed.

David

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 4 Jun 2021 08:52:48 -0700

On Fri, Jun 4, 2021 at 7:57 AM Magnus Westerlund <
[email-masked]> wrote:

> Hi,
>
> On Wed, 2021-06-02 at 15:32 -0700, Eric Rescorla wrote
>

> parts then I think that is a reasonable direction.

This is what I am suggesting.

> being an extension of a basic core.

What I am proposing here is that we:

- Mark this requirement as not having consensus in the reqts doc
- Try to develop it contemporaneously, and if it is done in time, put it in
the core document and if not, consider an extension.

-Ekr

---

From: Alex Chernyakhovsky <[email-masked]>
Date: Fri, 4 Jun 2021 12:30:10 -0400

Hi folks,

I do not agree with the premise of making any of the protocol requirements
optional in the way being suggested here. While I am fine
with implementations not supporting every profile, I think it is imperative
that the core protocol be sufficiently flexible to be able to support the
enumerated use cases. I do not believe the complexities being discussed
here will slow down iteration on the protocol, because for the most part,
are restrictions on what the protocol prohibits (or in the case of source
address validation, out-of-scope policy issues that are not relevant to
this specific protocol design question).

Sincerely,
-Alex

On Fri, Jun 4, 2021 at 11:53 AM Eric Rescorla <[email-masked]> wrote:

>> I don't personally strongly desire 2.4 but it's clear to me that 2.4 is
>> an essential part of operating a large class of corporate VPNs, so if we
>> want to have a generic VPN protocol, we need it, no? To the extent to which
>> it is complicated, I would suggest we try to solve it (borrowing from IPsec
>> as appropriate) and if we discover we cannot within a reasonable period of
> - Try to develop it contemporaneously, and if it is done in time, put it
> in the core document and if not, consider an extension.
>
> -Ekr
>
> --
> Masque mailing list
> [email-masked]

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 7 Jun 2021 08:15:26 +0000

Hi David and WG,

Let me attempt to clarify a bit why I have made the comments I have made. I think they do stem from interepreting the network to network use cases as a very general technology and from the perspective of deploying this with clients which the server has limited trust in. I realize that you are likely comming from another perspective that you only intended to use this in cases where you have fairly high mutual trust in the client and the server. I think that is actually the major difference here and why you below think I am making a circular arguments. I think it all stem from lack of discussion of this use cases and what operational limitations we intended to have on the protocol.

So if the goal here is to have high mutual trust between client and server then I think a protocol solution may be able to be defined with such an applicability statement and less mandate on necessary protocol mechanisms to protect against malicous peers. I think that is in stark contrast against some of the other use cases where the trust in the client could be rather minimal. Like the client and server relationship is only this is a paying customer that gets a VPN access and the server has no idea what type of client or implementation that are the peer. This basic use cases will deploy with an addressing architecture that makes it much less vulnerable to malicous intent on the routing level.

So, can we please discuss what assumption we have on the client and server trust?

I also think your attempt to sweep the addressing schemes to be used by the servers under the rug and not disucss them have hurt the understanding. I at least have been guessing on possible deployment scenarios rather than that we have openly discussed them in the WG. Yes, they maybe not need to be detailed in the protocol solution or an arhcitecture document, however they would have made sense to have some addressing deployment scenarios in this requirement documents use case section to make clear what would have been intended. Because they do influence what is needed for the solution.

Cheers

Magnus

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 7 Jun 2021 07:06:01 -0500

On Mon, Jun 7, 2021, 03:15 Magnus Westerlund <magnus.westerlund=
[email-masked]> wrote:

> Hi David and WG,
>
> Let me attempt to clarify a bit why I have made the comments I have made.
> I think they do stem from interepreting the network to network use cases as
> a very general technology and from the perspective of deploying this with
> clients which the server has limited trust in. I realize that you are
> likely comming from another perspective that you only intended to use this
> in cases where you have fairly high mutual trust in the client and the
> server. I think that is actually the major difference here and why you
> below think I am making a circular arguments. I think it all stem from lack
> of discussion of this use cases and what operational limitations we
> intended to have on the protocol.
>

I don't know if this would have helped, but I do wish we could tell
(explicitly, in the requirements draft) which requirements arose from
various use cases.

I'm pretty sure that most participants think they know that (likely), but
also think that other participants have the same understanding (perhaps
less likely). I think that's what Magnus is saying here, if I'm reading the
thread correctly.

Do The Right Thing, of course.

Best,

Spencer

So if the goal here is to have high mutual trust between client and server
> then I think a protocol solution may be able to be defined with such an
> applicability statement and less mandate on necessary protocol mechanisms
> to protect against malicous peers. I think that is in stark contrast
> against some of the other use cases where the trust in the client could be
> rather minimal. Like the client and server relationship is only this is a
> paying customer that gets a VPN access and the server has no idea what type
> of client or implementation that are the peer. This basic use cases will
> deploy with an addressing architecture that makes it much less vulnerable
> to malicous intent on the routing level.
>
> I also think your attempt to sweep the addressing schemes to be used by
> the servers under the rug and not disucss them have hurt the understanding.
> I at least have been guessing on possible deployment scenarios rather than
> that we have openly discussed them in the WG. Yes, they maybe not need to
> be detailed in the protocol solution or an arhcitecture document, however
> they would have made sense to have some addressing deployment scenarios in
> this requirement documents use case section to make clear what would have
> been intended. Because they do influence what is needed for the solution.
>
> Cheers
>
> Magnus
>
> --
> Masque mailing list
> [email-masked]

---

From: Martin Duke <[email-masked]>
Date: Mon, 7 Jun 2021 12:25:23 -0700

I'd like to step in here as AD and make sure we are not talking past each
other here. IIUC:

(1) Magnus and Mirja do not want to implement 2.4.
(2) The authors want to make sure the design is extensible to support 2.4,
but are OK with some endpoints not supporting it.

It does not appear that there is tension between these points. However, I
understand that Magnus is concerned that 2.4 will hold up the core proxy-ip
draft unnecessarily.

As AD, if we come to that point, I see no requirement in the charter that
this be one or two documents; if the option is holding everything up, it
can go to the IESG while 2.4 has further refinement in the WG. I don't see
that we have to make this decision now.

Regarding the document at hand, the existing Sec 2 offers the possibility
that all of the use cases are optional. It does not preclude the path that
appears to have consensus.

Is that consistent with others' understanding?

Martin

---

From: Martin Duke <[email-masked]>
Date: Mon, 7 Jun 2021 12:38:59 -0700

To clarify what I meant, I'm suggesting the the future IP proxy document
can split out the network-network use case specification if that proves to
be problematic.

I am not saying we should have two requirements documents.

On Mon, Jun 7, 2021 at 12:25 PM Martin Duke <[email-masked]> wrote:

>>> Let me attempt to clarify a bit why I have made the comments I have
>>> made. I think they do stem from interepreting the network to network use
>>> cases as a very general technology and from the perspective of deploying
>>> this with clients which the server has limited trust in. I realize that you
>>> are likely comming from another perspective that you only intended to use
>>> this in cases where you have fairly high mutual trust in the client and the
>> So if the goal here is to have high mutual trust between client and
>>> server then I think a protocol solution may be able to be defined with such
>>> an applicability statement and less mandate on necessary protocol
>>> mechanisms to protect against malicous peers. I think that is in stark
>>> contrast against some of the other use cases where the trust in the client
>>> could be rather minimal. Like the client and server relationship is only
>>> this is a paying customer that gets a VPN access and the server has no idea
>>> what type of client or implementation that are the peer. This basic use
>>> cases will deploy with an addressing architecture that makes it much less
>>> vulnerable to malicous intent on the routing level.
>>>

---

From: Alex Chernyakhovsky <[email-masked]>
Date: Mon, 7 Jun 2021 15:54:55 -0400

Hi Martin,

Thanks for weighing in, and I agree with your interpretation that there is
no tension between these two points.

I agree that should we run into timeline issues with the implementation
drafts, it is possible to split out the section 2.4 implementation into its
own document. We should cross that bridge if/when we get there.

Sincerely,
-Alex

On Mon, Jun 7, 2021 at 3:39 PM Martin Duke <[email-masked]> wrote:

>> (2) The authors want to make sure the design is extensible to support
>> 2.4, but are OK with some endpoints not supporting it.
>>
>>> I'm pretty sure that most participants think they know that (likely),
>>> but also think that other participants have the same understanding (perhaps

---

From: "Christopher Wood" <[email-masked]>
Date: Mon, 07 Jun 2021 13:07:28 -0700

As Martin points out, the solution for the network-to-network use case in Section 2.4 can be split out into a separate document should we run into timeline issues down the road. 

To that end, we'd like to reiterate that the purpose of this WGLC is to determine if we can we move forward with this understanding and consensus on this document in its current state, plus or minus maybe some editorial cleanup. If not, what specific requirements in the document are problematic, and why?

Thanks,
Chris and Eric

On Mon, Jun 7, 2021, at 12:54 PM, Alex Chernyakhovsky wrote:
> Hi Martin,
> 
> Thanks for weighing in, and I agree with your interpretation that there 
> is no tension between these two points.
> 
> drafts, it is possible to split out the section 2.4 implementation into 
> its own document. We should cross that bridge if/when we get there.
> 
> Sincerely,
> -Alex
> 
> > To clarify what I meant, I'm suggesting the the future IP proxy document can split out the network-network use case specification if that proves to be problematic.
> > 
> >> I'd like to step in here as AD and make sure we are not talking past each other here. IIUC:
> >> 
> >> (2) The authors want to make sure the design is extensible to support 2.4, but are OK with some endpoints not supporting it.
> >> 
> >> It does not appear that there is tension between these points. However, I understand that Magnus is concerned that 2.4 will hold up the core proxy-ip draft unnecessarily.
> >> 
> >> As AD, if we come to that point, I see no requirement in the charter that this be one or two documents; if the option is holding everything up, it can go to the IESG while 2.4 has further refinement in the WG. I don't see that we have to make this decision now.
> >> 
> >> Regarding the document at hand, the existing Sec 2 offers the possibility that all of the use cases are optional. It does not preclude the path that appears to have consensus.
> >> 
> >> On Mon, Jun 7, 2021 at 5:06 AM Spencer Dawkins at IETF <[email-masked]> wrote:
> >>> 
> >>> 
> >>> On Mon, Jun 7, 2021, 03:15 Magnus Westerlund <magnus.westerlund=[email-masked]> wrote:
> >>>> Hi David and WG,
> >>>> 
> >>> I don't know if this would have helped, but I do wish we could tell (explicitly, in the requirements draft) which requirements arose from various use cases. 
> >>> 
> >>> I'm pretty sure that most participants think they know that (likely), but also think that other participants have the same understanding (perhaps less likely). I think that's what Magnus is saying here, if I'm reading the thread correctly.
> >>>

---

From: David Schinazi <[email-masked]>
Date: Mon, 7 Jun 2021 15:41:05 -0700

That makes sense to me. The requirements document states that the
network-to-network use-case will be optional to implement, so it won't be a
burden. As we make progress on building the actual protocol, we'll find out
whether the network-to-network use-case adds delays or not. If it does,
then we'll split it off to its own document. Alternatively, I think Magnus
has offered a great suggestion in his latest message: a separate
architecture document. This way we can keep the protocol document shorter
and tackle the policy/address-validation/trust/addressing questions in the
architecture document. Either way, it does sound like we have a good path
forward to wrap up the requirements document.

David

On Mon, Jun 7, 2021 at 1:07 PM Christopher Wood <[email-masked]> wrote:

> As Martin points out, the solution for the network-to-network use case in
> Section 2.4 can be split out into a separate document should we run into
> timeline issues down the road.
>
> To that end, we'd like to reiterate that the purpose of this WGLC is to
> determine if we can we move forward with this understanding and consensus
> on this document in its current state, plus or minus maybe some editorial
> cleanup. If not, what specific requirements in the document are
> problematic, and why?
>
> Thanks,
> Chris and Eric
>
> > > To clarify what I meant, I'm suggesting the the future IP proxy
> document can split out the network-network use case specification if that
> proves to be problematic.
> > >
> > >> It does not appear that there is tension between these points.
> However, I understand that Magnus is concerned that 2.4 will hold up the
> core proxy-ip draft unnecessarily.
> > >>
> > >> As AD, if we come to that point, I see no requirement in the charter
> that this be one or two documents; if the option is holding everything up,
> it can go to the IESG while 2.4 has further refinement in the WG. I don't
> see that we have to make this decision now.
> > >>
> > >> Regarding the document at hand, the existing Sec 2 offers the
> possibility that all of the use cases are optional. It does not preclude
> the path that appears to have consensus.
> > >>
> > >>> I'm pretty sure that most participants think they know that
> (likely), but also think that other participants have the same
> understanding (perhaps less likely). I think that's what Magnus is saying
> here, if I'm reading the thread correctly.
> > >>>
> > >>>> I also think your attempt to sweep the addressing schemes to be
> used by the servers under the rug and not disucss them have hurt the
> understanding. I at least have been guessing on possible deployment
> scenarios rather than that we have openly discussed them in the WG. Yes,
> they maybe not need to be detailed in the protocol solution or an
> arhcitecture document, however they would have made sense to have some
> addressing deployment scenarios in this requirement documents use case
> section to make clear what would have been intended. Because they do
> influence what is needed for the solution.
> > >>>>
> > >>>> Cheers
> > >>>>
> > >>>> Magnus
> > >>>> --
> > >>>> Masque mailing list
> > >>>> [email-masked]

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 7 Jun 2021 20:29:50 -0500

To the upthread posters - that sounds good to me.

Thanks, Martin, for helping clarify the expectations.

Best,

Spencer

On Mon, Jun 7, 2021 at 5:41 PM David Schinazi <[email-masked]>
wrote:

>> > >> (2) The authors want to make sure the design is extensible to
>> support 2.4, but are OK with some endpoints not supporting it.
>> > >>
>> > >>>> Let me attempt to clarify a bit why I have made the comments I
>> have made. I think they do stem from interepreting the network to network
>> use cases as a very general technology and from the perspective of
>> deploying this with clients which the server has limited trust in. I
>> realize that you are likely comming from another perspective that you only
>> intended to use this in cases where you have fairly high mutual trust in
>> the client and the server. I think that is actually the major difference
>> here and why you below think I am making a circular arguments. I think it
>> all stem from lack of discussion of this use cases and what operational
>> limitations we intended to have on the protocol.
>> > >>>
>> > >>>> So if the goal here is to have high mutual trust between client
>> and server then I think a protocol solution may be able to be defined with
>> such an applicability statement and less mandate on necessary protocol

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 8 Jun 2021 17:29:29 +1000

Hello,

This document seems to be asking for one or more HTTP extensions, but is expressed almost entirely in terms of IP. That's not terribly helpful to readers; what's needed is a mapping between IP and HTTP (in the direction opposite to that defined by RFC7230 and RFC7540!) to guide expectations. Some suggested edits:

OLD:
'There is interest among MASQUE working group participants in designing a protocol that can proxy IP traffic over HTTP. This document describes the set of requirements for such a protocol.'
NEW:
'MASQUE working group participants are interested in extending HTTP to allow it to tunnel IP traffic. This document describes the relevant requirements.'

OLD:
'This document describes the set of requirements for a protocol that can proxy IP traffic over HTTP.'
NEW:
'This document describes the set of requirements for extending HTTP to tunnel IP traffic.'

QUESTION:
'The server will have the ability to accept or deny the client's request.'  <-- which server? Any server along the request chain, or the origin server? next hop?

QUESTION:
'The Data Transports MUST be able to take IP datagrams input on one side and egress them unmodified in their entirety on the other side,' <-- are these sides the user agent and the origin server, or something else? Similar questions about 'client' and 'server' in subsequent text.

OLD:
'The IP proxying protocol discussed in this document will run over HTTP.'
NEW:
'The requirements discussed in this document will be met by the definition of HTTP/2 extension(s), HTTP/3 extension(s), and possibly one or more HTTP semantic extensions.'

Along those lines, it'd probably be helpful to add a note that if HTTP semantic extensions are defined, they are by nature usable in all versions of HTTP, although the WG might choose not to define their operation in a given protocol version.

Additionally, wherever 'protocol' is used, 'HTTP extension(s)' should be substituted. Likewise, wherever 'proxy' is used, 'tunnel' should be substituted (see <https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#intermediaries>).

Finally, I don't see anywhere where it's explicitly said that after these extensions are used, the connection still needs to be usable for HTTP traffic. That seems like something that's important to establish one way or another (I have my preferences here, of course).

Cheers,

> On 27 May 2021, at 12:33 am, Christopher Wood <[email-masked]> wrote:
> 
> This email starts the working group last call for "Requirements for a MASQUE Protocol to Proxy IP Traffic", located here:
> 
>    https://datatracker.ietf.org/doc/draft-ietf-masque-ip-proxy-reqs/
> 
> This last call serves to solidify requirements for subsequent work on CONNECT-IP solutions, as discussed in [1].
> 
> Please review the document and send your comments to the list by June 11.
> 
> Note the the GitHub repository for this draft can be found here: 
> 
>    https://github.com/ietf-wg-masque/draft-ietf-masque-ip-proxy-reqs
> 
> Thanks,
> Chris and Eric
> 
> [1] https://mailarchive.ietf.org/arch/msg/masque/LXObvy1DDuxLs-3dndyNKY0W4Gs/
> 
> -- 
> Masque mailing list
> [email-masked]

--
Mark Nottingham   https://www.mnot.net/

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 8 Jun 2021 07:46:01 +0000

Hi,

I agree that one can split later, with some additional delay. How
problematic waiting with splitting is depends on what the network to
network use cases is supposed to cover. I think we need to figure out
what type of threat model and mutual trust the two MASQUE endpoint is
expected to have in this use case. 

So, can we please figure this out becasue I think that will clarify if
there is low risk for extra delay or significant risk for extra delay?
This is a request for better clarification in the requirements document
on 2.4. 

Cheers

Magnus

On Mon, 2021-06-07 at 13:07 -0700, Christopher Wood wrote:
> As Martin points out, the solution for the network-to-network use
> case in Section 2.4 can be split out into a separate document should
> we run into timeline issues down the road. 
> 
> To that end, we'd like to reiterate that the purpose of this WGLC is
> to determine if we can we move forward with this understanding and
> consensus on this document in its current state, plus or minus maybe
> some editorial cleanup. If not, what specific requirements in the
> document are problematic, and why?
> 
> Thanks,
> Chris and Eric
> 
> > On Mon, Jun 7, 2021 at 3:39 PM Martin Duke <[email-masked]
> > > wrote:
> > > document can split out the network-network use case specification
> > > if that proves to be problematic.
> > > 
> > > > However, I understand that Magnus is concerned that 2.4 will
> > > > hold up the core proxy-ip draft unnecessarily.
> > > > 
> > > > As AD, if we come to that point, I see no requirement in the
> > > > charter that this be one or two documents; if the option is
> > > > holding everything up, it can go to the IESG while 2.4 has
> > > > further refinement in the WG. I don't see that we have to make
> > > > this decision now.
> > > > 
> > > > possibility that all of the use cases are optional. It does not
> > > > preclude the path that appears to have consensus.
> > > > 
> > > > > On Mon, Jun 7, 2021, 03:15 Magnus Westerlund <
> > > > > magnus.westerlund=[email-masked]> wrote:
> > > > > > Hi David and WG,
> > > > > > 
> > > > > > Let me attempt to clarify a bit why I have made the
> > > > > > comments I have made. I think they do stem from
> > > > > > interepreting the network to network use cases as a very
> > > > > > general technology and from the perspective of deploying
> > > > > > this with clients which the server has limited trust in. I
> > > > > > realize that you are likely comming from another
> > > > > > perspective that you only intended to use this in cases
> > > > > > where you have fairly high mutual trust in the client and
> > > > > > the server. I think that is actually the major difference
> > > > > > here and why you below think I am making a circular
> > > > > > arguments. I think it all stem from lack of discussion of
> > > > > > this use cases and what operational limitations we intended
> > > > > > to have on the protocol.
> > > > > 
> > > > > I don't know if this would have helped, but I do wish we
> > > > > could tell (explicitly, in the requirements draft) which
> > > > > requirements arose from various use cases. 
> > > > > 
> > > > > (likely), but also think that other participants have the
> > > > > same understanding (perhaps less likely). I think that's what
> > > > > Magnus is saying here, if I'm reading the thread correctly.
> > > > > 
> > > > > > So if the goal here is to have high mutual trust between
> > > > > > client and server then I think a protocol solution may be
> > > > > > able to be defined with such an applicability statement and
> > > > > > less mandate on necessary protocol mechanisms to protect
> > > > > > against malicous peers. I think that is in stark contrast
> > > > > > against some of the other use cases where the trust in the
> > > > > > client could be rather minimal. Like the client and server
> > > > > > relationship is only this is a paying customer that gets a
> > > > > > VPN access and the server has no idea what type of client
> > > > > > or implementation that are the peer. This basic use cases
> > > > > > will deploy with an addressing architecture that makes it
> > > > > > much less vulnerable to malicous intent on the routing
> > > > > > level.
> > > > > > 
> > > > > > I also think your attempt to sweep the addressing schemes
> > > > > > to be used by the servers under the rug and not disucss
> > > > > > them have hurt the understanding. I at least have been
> > > > > > guessing on possible deployment scenarios rather than that
> > > > > > we have openly discussed them in the WG. Yes, they maybe
> > > > > > not need to be detailed in the protocol solution or an
> > > > > > arhcitecture document, however they would have made sense
> > > > > > to have some addressing deployment scenarios in this
> > > > > > requirement documents use case section to make clear what
> > > > > > would have been intended. Because they do influence what is
> > > > > > needed for the solution. 
> > > > > > 
> > > > > > Cheers
> > > > > > 
> > > > > > Magnus
> > > > > > -- 
> > > > > > Masque mailing list
> > > > > > [email-masked]

---

From: David Schinazi <[email-masked]>
Date: Wed, 9 Jun 2021 18:17:33 -0700

Hi Magnus,

You're correct that this isn't currently explicit in the document. The
intention of the authors was to declare trust out of scope for the IP
proxying protocol. Similar to IP, DHCP, ESP, etc, the protocol itself
does not need to worry about trust as that is better handled at a policy
layer that lives outside of the protocol. Since the IP Proxying
Requirements document only applies requirements to the IP proxying
protocol, trust is also out of scope for the requirements document. I can
add a subsection to Section 5 (Non-Requirements) if you'd like.

If we agree that trust is out of scope, then the risk for added delay is
low.

David

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 10 Jun 2021 09:00:05 -0500

Hi, Davis,

> add a subsection to Section 5 (Non-Requirements) if you'd like.

I'm not Magnus (my loss and his gain), but that seems like a good thing to
write down.

> low.

I know that IETF working groups don't have a lot of experience with
requirements drafts that are developed in WG Github repos and not forwarded
for publication, but ISTM that unless someone is actually planning to
delete https://github.com/ietf-wg-masque/draft-ietf-masque-ip-proxy-reqs,
which would surprise me a lot, it's just going to be sitting there in the
WG repo, and people who aren't involved in MASQUE now would reasonably
consult it.

So adding assumptions like this one, as we recognize them, would actually
take MASQUE requirements work closer to a living document that continues to
be useful, and that's certainly something new IETF participants would find
helpful.

Best,

Spencer

David

---

From: Chris Box <[email-masked]>
Date: Thu, 10 Jun 2021 18:43:34 +0100

I have what is possibly a stupid question. It's regarding this section:

3.3 <https://datatracker.ietf.org/doc/html/draft-ietf-masque-ip-proxy-reqs-02#section-3.3>.
Maximum Transmission Unit

   The protocol will allow endpoints to inform each other of the Maximum
   Transmission Unit (MTU) they are willing to forward.  This will allow
   avoiding IP fragmentation, especially as IPv6 does not allow IP
   fragmentation by nodes along the path.

In the case where at least one end of the tunnel is a network, what is the
definition of endpoint here? I'm confused because in my head this protocol
can only convey information between each end of the tunnel, whereas in
order to influence MTU, this information needs to go to the actual sender
located somewhere within the network of section 2.3 or 2.4. That sender is
a different definition of endpoint.

Presumably only the ends of the tunnel exchange MTU information directly,
and then they rely on influencing PMTU Discovery to adjust the actions of
the sender?

Chris

On Wed, 26 May 2021 at 15:34, Christopher Wood <[email-masked]> wrote:

> This email starts the working group last call for "Requirements for a
> MASQUE Protocol to Proxy IP Traffic", located here:
>
> This last call serves to solidify requirements for subsequent work on
> CONNECT-IP solutions, as discussed in [1].
>
> [1]
> https://mailarchive.ietf.org/arch/msg/masque/LXObvy1DDuxLs-3dndyNKY0W4Gs/
>
> --
> Masque mailing list
> [email-masked]

---

From: David Schinazi <[email-masked]>
Date: Thu, 10 Jun 2021 11:13:52 -0700

Hi Chris B,

The endpoints in this document are the endpoints of the tunnel.
The goal of the MTU requirement is to mention that these endpoints
can share what they view as the max MTU. That would be the MTU
of the tunnel itself. You're right that connections that go through the
tunnel but don't terminate on the tunnel endpoints would need to
also take into account MTUs for the IP hops on either side of the
tunnel. One way to accomplish that is PMTUD between the ends of
that connection.

David

On Thu, Jun 10, 2021 at 10:44 AM Chris Box <[email-masked]> wrote:

> 3.3 <https://datatracker.ietf.org/doc/html/draft-ietf-masque-ip-proxy-reqs-02#section-3.3>.  Maximum Transmission Unit
>

---

From: Chris Box <[email-masked]>
Date: Fri, 11 Jun 2021 15:19:18 +0100

> tunnel. One way to accomplish that is PMTUD between the ends of

That makes sense. In that case, can we clarify the wording? Something like
this perhaps?

   The protocol will allow tunnel endpoints to inform each other of the Maximum
   Transmission Unit (MTU) they are willing to forward.  This will allow
   avoiding some IP fragmentation, especially as IPv6 does not allow IP
   fragmentation by nodes along the path. In cases where the tunnel endpoint

   is not the same as the communication endpoint, tunnel endpoints are

   expected to apply the guidance on UDP tunnels in [BCP145].

Chris

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 11 Jun 2021 10:06:37 -0500

Chris,

>    expected to apply the guidance on UDP tunnels in [BCP145].

Your question was a good one. I think your proposal is also helpful,
especially with the pointer to  BCP 145.

Thank you for that.

Best,

Spencer

---

From: David Schinazi <[email-masked]>
Date: Fri, 11 Jun 2021 18:59:37 -0700

Thanks Chris B,

I've created a PR that incorporates your MTU text, and also should answer
Magnus' question about trust:
https://github.com/ietf-wg-masque/draft-ietf-masque-ip-proxy-reqs/pull/33/files

Thanks,
David

On Fri, Jun 11, 2021 at 8:07 AM Spencer Dawkins at IETF <
[email-masked]> wrote:

>> That makes sense. In that case, can we clarify the wording? Something
>> like this perhaps?
>>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 11 Jun 2021 21:57:27 -0500

Thank you, David

Best,

Spencer

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 28 Jun 2021 16:04:12 +0000

Hi,

Sorry for the delayed response. 

From my perspective you can't just state that trust is out of scope. For a
solution document I would see the need to discuss the security implications for
a MASQUE endpoint between the authorization that can be derived from the
protocol mechanisms for endpoint identity versus the MASQUE protocol requests
impact on external state such as routing tables and their potential
implications. 

From my perspective if the IP proxying protocol expresses information about
routes we will end up having to discuss the purpose and security implications of
those routes and the endpoints trust in what is stated. 

Cheers

Magnus

On Wed, 2021-06-09 at 18:17 -0700, David Schinazi wrote:
> If we agree that trust is out of scope, then the risk for added delay is low.
> 
> David
>

---

From: David Schinazi <[email-masked]>
Date: Mon, 28 Jun 2021 09:36:37 -0700

Hi Magnus,

Thank you for clarifying *what* you would prefer to see in scope.
Can you explain *why* you are advocating for those topics?
In particular, you seem to be treating the routing table as
something unique that needs to be handled differently, and I
don't understand that. Many HTTP methods involve changing
local state - if I click the Like button on a website, a database
gets updated somewhere, for example. The routing table is a
database, and it's unclear to me why it needs to be treated
differently. It seems absolutely reasonable to have text in the
security considerations section that states that servers shouldn't
let unauthenticated clients modify any server databases without
checks, but it sounds like you're suggesting that the protocol
solution document be opinionated about trust, and that would
severely limit the applicability of the protocol - various use-cases
will have different means of authenticating clients and picking
policies for what a client is allowed to do, and we cannot preclude
those.

David

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 29 Jun 2021 10:02:02 +0000

Hi David,

> Can you explain *why* you are advocating for those topics?

So the reason I am advocating for additional care in relation to routing
information is the fact that a malicous and successful injection of a route into
a network can be used as an tool to attack third parties. You could potentially
divert traffic to perform other attacks or monitoring for survailence or
information gathering. 

And I think the main difference between the network to network VPN case compared
to the customer VPN, is that the later only forwards traffic with a destination
of the address/network the MASQUE Server lent to the MASQUE client. That makes
the threat model match the leaf node, not a transit or multihomed network which
network to network VPN easily create.  

And with that change to the threat model the mitigations and security
considerations are impacted. Which in terms is what I fear will delay the
specification additionally. Do you think you can write a specification without
bringing up the security considerations for the protocol field that carries
route prefix information? 

The requirements document is very clear in Section 3.5 that a protocol mechanism
is needed for route negotiation. That negotiation will be used to affect the
MASQUE endpoints routing state. Which in its tern requires the implementation to
consider which traffic it should accept. Yes, there is a trust question here in
regards to authenticy and identity of who makes a statement about that
authenticity in the request. But it is also a question of what threats are
inherent in this mechanism and what each endpoint needs to consider when using
this mechanism to safely use it to forwards traffic through the tunnel. 

> policies for what a client is allowed to do, and we cannot preclude

The routing information carried in a MASQUE specific mechanism that directly
impact what traffic that MASQUE endpoint will forward and what mechanisms will
be needed to mitigate threats is the same as any HTTP application. So this is
not the same as a general HTTP using applicaiton. The HTTP using application
will have to evaluate the risks with the implemented function in that
application, just like I asking us to carefully consider the impact of the
application MASQUE. 

And when it comes to authentication mechanism I think for interoperability it
will be necessary for the MASQUE application to require something to be
mandatory to implement, even if that is the Mandatory to implement by the
targeted HTTP versions. However, MASQUE service clearly have similar
considerations to TURN servers where the failure to early on consider if one had
mechanisms that was suited to the use cases. The issue with TURN was that for
example WebRTC services wanted to provision its users with user individual
credentials where the TURN services could be a contracted thrid party service
that supported many WebRTC services concurrently.

But to conclude all I am really expecting is that the security considerations
and the mitigations in the MASQUE protocol specification consider the MASQUE
application in all its use cases listed in the requirements. 

Cheers

Magnus Westerlund

---

From: Alex Chernyakhovsky <[email-masked]>
Date: Tue, 29 Jun 2021 14:07:39 -0400

Hi Magnus,

Inline.

Sincerely,
-Alex

> divert traffic to perform other attacks or monitoring for survailence or

These concerns are valid, but they apply to a system implementation, not
the protocol. As we've discussed numerous times, these sorts of things can
be accomplished with IPSec, yet the IPSec RFCs do not go into the details
that you are requesting. I am not saying that we shouldn't have such
guidance, but we have no requirement that it appear in the same document
nor be published at the same time as the rest of the work we are currently
discussing. I believe we're all in agreement there --- but I don't
understand what concretely you're concerned about delaying if we are going
to be able to break things up into separate documents, if/when that becomes
necessary.

> network to network VPN easily create.

Again, this is a system concern, not a protocol one. A sufficiently
extensible protocol, as we are aiming to design, can handle both of these
cases regardless of what policy and considerations we end up having in
place. Our goal is to design this sufficiently extensible protocol.

> route prefix information?

Yes, I explicitly believe we can do so, and this is evidenced by the IPSec
RFCs. For example, RFC4301, which talks about the IPSec security
architecture, makes no mention of this.

We cannot operate without some abstractions, or else we will end up caught
up in discussions that can make no progress. It is sufficient for us to
begin implementation work and note that security considerations exist and
operators are responsible for validating these routes per their own policy.

> application in all its use cases listed in the requirements.

Again, we have to operate at a reasonable level of abstraction. What you're
suggesting amounts to turning these documents into a massive compendium, to
which I see limited benefit.

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 30 Jun 2021 12:15:11 +0000

Hi,
I think you stated your view. I have stated my view. I think the best
is to progress, I just hope that there will not be an extensive
discussion against splitting the document if we get caught in a
situation where my fears are realized and we are getting feedback that
is directly related to the network to network use case and will take
some work to finish. 
Cheers
Magnus

On Tue, 2021-06-29 at 14:07 -0400, Alex Chernyakhovsky wrote:
> These concerns are valid, but they apply to a system implementation,
> not the protocol. As we've discussed numerous times, these sorts of
> things can be accomplished with IPSec, yet the IPSec RFCs do not go
> into the details that you are requesting. I am not saying that we
> shouldn't have such guidance, but we have no requirement that it
> appear in the same document nor be published at the same time as the
> rest of the work we are currently discussing. I believe we're all in
> agreement there --- but I don't understand what concretely you're
> concerned about delaying if we are going to be able to break things
> up into separate documents, if/when that becomes necessary. 
> >  
> > 
> > 
> > 
> extensible protocol, as we are aiming to design, can handle both of
> these cases regardless of what policy and considerations we end up
> having in place. Our goal is to design this sufficiently extensible
> protocol. 
> >  
> > 
> > 
> > 
> Yes, I explicitly believe we can do so, and this is evidenced by the
> IPSec RFCs. For example, RFC4301, which talks about the IPSec
> security architecture, makes no mention of this.
> We cannot operate without some abstractions, or else we will end up
> caught up in discussions that can make no progress. It is sufficient
> for us to begin implementation work and note that security
> considerations exist and operators are responsible for validating
> these routes per their own policy. 
> >  
> > 
> > 
> > 
> Again, we have to operate at a reasonable level of abstraction. What
> you're suggesting amounts to turning these documents into a massive
> compendium, to which I see limited benefit. 
> >  
> > 
> > 
> > 
> > Cheers
> > 
> > 
> > 
> > Magnus Westerlund
> >