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

[Magnus Westerlund <[e-mail]>]

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]<mailto:[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