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

[Mirja Kuehlewind <[e-mail]>]

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" <[e-mail] on behalf of 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.

    "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