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

From: "Christopher Wood" <[email-masked]>
Date: Wed, 26 May 2021 07:33:53 -0700

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/

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 31 May 2021 15:35:31 +0000

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