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

[Eric Rescorla <[e-mail]>]

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?



> "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.


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.

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






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