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

[David Schinazi <[e-mail]>]

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=
[e-mail]> wrote:

> 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=
> [e-mail]> 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.
>
>
> 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?
>
>
> 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
>    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.
>
>
> 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.
>
>
>
>
> 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.
>
>
> 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
> --
> Masque mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/masque
>