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

David Schinazi <dschinazi.ietf@gmail.com> Fri, 04 June 2021 15:38 UTC

Return-Path: <dschinazi.ietf@gmail.com>
X-Original-To: masque@ietfa.amsl.com
Delivered-To: masque@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC583A1705 for <masque@ietfa.amsl.com>; Fri, 4 Jun 2021 08:38:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lsfg9eQuJHgF for <masque@ietfa.amsl.com>; Fri, 4 Jun 2021 08:38:07 -0700 (PDT)
Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC7D13A16EC for <masque@ietf.org>; Fri, 4 Jun 2021 08:38:07 -0700 (PDT)
Received: by mail-pg1-x535.google.com with SMTP id q15so8154523pgg.12 for <masque@ietf.org>; Fri, 04 Jun 2021 08:38:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Kbl6vmei9iWIepjJHKWTUCW2OuyfPUoC7KbZYgJ5G7g=; b=W320qCdJYbFuJoKum5vKeUn5lyLbGrm9Bv1hvYrfN+aZwfmSWhxFpaHaazuV0b2alx JSlTCTyEnfgqZbW5imDSEdm2RwNI5JvGPmWUlcswKWvS34KpUOpiIk/DaPb8IUBAor3L IB8Cm139g18C3HwCW/7lQS8PpyqNBkI7j4lyiB+XPPqyySoFMTD3ez5RSahzBRe6+nkj oLFe0qIrJkApHnVa0vhtw4pqNJ5GnaAnxBIkoUDUO0NF7DuuKja0On/JPRhaZrc1DC1C h57+Oe35f6d8+R7evG65Jkd5L8UcMGyoBmG2ECJ3j6e5gxoy2rkt4pI2pHJGr2IE/sTV enig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Kbl6vmei9iWIepjJHKWTUCW2OuyfPUoC7KbZYgJ5G7g=; b=CAgG95toIcziRRlzGZr6aX6Qu/8HyFUdgxP4NTlDbboEikOSgiK/+AJxJqL/SljxGD 4X5zR6iJaZigg4RxS6ooBAgm114H3v9E3kap7/7EUsOp3Xebi3mw6DRMJDatY/pjZf6W 1Ov3JG7yAIfklU6ObVjTOMOXvLAro1jARTEoE3RaHK99XA0Jo3J0hzarli4RM6Zt7II6 ICoYBBygpwGmfMm/xxaqoa4BayQwjOippRX0mA5R2p9ce26jFffEx/ONXV9mUlmuV4qR zc+v79i7GPgJZ1UemvuYgrSAi5CJ3xQ7lewGSJkuMMTxAUC3NT7SaBPI9CjrIpdySxVl bkEw==
X-Gm-Message-State: AOAM533Td+YWt0j/Gcpcd/uADDtqrlsziTsInkVAcbCCuL/LNj/gMxUa pALTaoi0kMew1hOYIM27eUSgq3Hu2tUAmg7qU8g=
X-Google-Smtp-Source: ABdhPJwm7TLwFMxhzwnsAzyHSMmFSmWoZNdv2BFz45gXctDD6w5AmuXsO0nCV3aK+6rZQlPn7ZeNtJ/1ItNTMEAuAVA=
X-Received: by 2002:a63:58e:: with SMTP id 136mr1061315pgf.206.1622821085508; Fri, 04 Jun 2021 08:38:05 -0700 (PDT)
MIME-Version: 1.0
References: <d314198b-6c01-4b15-84d8-9896b5fdee80@www.fastmail.com> <HE1PR0702MB3772355483E2771650C6D679953F9@HE1PR0702MB3772.eurprd07.prod.outlook.com> <746F7E16-37BD-49EF-896A-649D394CCB05@ericsson.com> <CAPDSy+6PjZk0Kea6154V3=GF-8bs+0Mr+FtFfi-girGh3uAVrQ@mail.gmail.com> <3deea8212d66731de5c81abae353f3e9322f2d57.camel@ericsson.com>
In-Reply-To: <3deea8212d66731de5c81abae353f3e9322f2d57.camel@ericsson.com>
From: David Schinazi <dschinazi.ietf@gmail.com>
Date: Fri, 04 Jun 2021 08:37:54 -0700
Message-ID: <CAPDSy+68DoVrRiC7uEn1-Ze_5LDn9mt7-f+ZeovTTYAUh=w2Og@mail.gmail.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Cc: Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>, "masque@ietf.org" <masque@ietf.org>, "caw@heapingbits.net" <caw@heapingbits.net>
Content-Type: multipart/alternative; boundary="00000000000055f6fc05c3f27afd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/masque/Hzd9JW1v5xLu8gndc-VdnFf2uws>
Subject: Re: [Masque] WGLC for "Requirements for a MASQUE Protocol to Proxy IP Traffic"
X-BeenThere: masque@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiplexed Application Substrate over QUIC Encryption <masque.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/masque>, <mailto:masque-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/masque/>
List-Post: <mailto:masque@ietf.org>
List-Help: <mailto:masque-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/masque>, <mailto:masque-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Jun 2021 15:38:15 -0000

On Fri, Jun 4, 2021 at 8:16 AM Magnus Westerlund <
magnus.westerlund@ericsson.com> wrote:

> On Wed, 2021-06-02 at 15:19 -0700, David Schinazi wrote:
>
> Hi Magnus and Mirja, thanks for your comments.
>
> I strongly disagree with you. There is great value in establishing WG
> consensus on the requirements document, as it allows us to avoid
> litigating the same points over and over again. I'm very excited to start
> working on a protocol solution here, but we should leverage the work we've
> done on the requirements document, not ignore it. Looking more closely at
> your objections, they all seem to stem from the fact that you would rather
> not support the network-to-network use-case. You've repeated this objection
> many times without providing justification for it, and that does not make
> it true. If you look at draft-cms-masque-connect-ip which is a possible
> protocol solution for this space, you'll find that supporting this use-case
> does not increase the complexity of the protocol. And we have strong
> precedent at the IETF for this: RFC 4303 supports network-to-network with
> any added complexity, because it's a fundamentally natural use of IP
> proxying.
>
>
> To be as clear as possible. I don't want the WG be required to have
> finished the network to network use case functionality prior to publication
> of the core solution that covers the other use cases. You say I have no
> justification, I brought up several aspects that I think will need to have
> description and security considerations and potentially additional protocol
> functionalities that I fear will delay the work.
>

That's a pretty circular argument. You're adding scope to the problem and
then saying that such added scope is causing delays. IP proxying is about
encapsulating IP packets and some negotiation. Policy isn't and shouldn't
be in scope. If I configure a home router to use a given DHCP address pool,
the DHCP RFC doesn't need to tell me how to validate that I'm allowed to
use that address pool.

For example source address validation, something that IETF didn't have
> specifications for in the same way as we do now when RFC 4303 was published.
>

RFC 4303 didn't discuss source address validation because it was out of
scope for an encapsulation format, not because the IETF lacked security at
the time. Policy is important, but it's just not in scope here.

I also have my experience on the IESG to know that the bar is ticking ever
> up to ensure that protocols are safe to deploy and that security issues are
> mitigated.
>

Luckily the IESG doesn't have a monopoly on knowing how to build safe
protocols.

I also hope this discussion do result in people forming their own opinion
> and actually speaking up if they think the requirements document says what
> they want.
>

Yes, I'm hoping this discussion is helping folks form opinions. But the
burden of speaking up isn't exclusively on folks in favor.

I will note that I am convinced that this effort has been severly hampered
> by the lack of physical meetings with a chance to follow up on points and
> have clarifying discussions.
>

I agree that things could have progressed more efficiently, but we're still
doing pretty well.

Cheers
>
> Magnus
>
>
>
>
> Thanks,
> David
>
> On Wed, Jun 2, 2021 at 1:13 AM Mirja Kuehlewind <mirja.kuehlewind=
> 40ericsson.com@dmarc.ietf.org> wrote:
>
> 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" <
> masque-bounces@ietf.org on behalf of magnus.westerlund=
> 40ericsson.com@dmarc.ietf.org> 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
>
>
On Fri, Jun 4, 2021 at 8:25 AM Magnus Westerlund <
magnus.westerlund@ericsson.com> wrote:

> Hi David,
>
>
>
> If it is a minor detail, then lets address that “detail” then and create a
> WG consensus.
>

Let's *discuss* that detail. As individual contributors to this working
group, you and I are not in a position to decide what forms consensus or
what needs to be addressed.

David


> Cheers
>
>  Magnus Westerlund
>