Re: [mpls] Benjamin Kaduk's Discuss on draft-ietf-mpls-sfc-encapsulation-03: (with DISCUSS and COMMENT)

"Andrew G. Malis" <agmalis@gmail.com> Fri, 15 March 2019 19:47 UTC

Return-Path: <agmalis@gmail.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA8EB13126E; Fri, 15 Mar 2019 12:47:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 FlaKVnp76EQT; Fri, 15 Mar 2019 12:47:11 -0700 (PDT)
Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 63DC7130E16; Fri, 15 Mar 2019 12:47:11 -0700 (PDT)
Received: by mail-qt1-x832.google.com with SMTP id y36so1672145qtb.3; Fri, 15 Mar 2019 12:47:11 -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=0ESNN6jMQczayHrYsAJ3iSmPkHFVybzZIJYXOSFc4BQ=; b=sqmPMojjMwyt2FakxEB4AOd6/F59SgPJLjyEvays0GDV51TSiWhI+NH1puYMl8zceb 0qaibyo3DWtLxyMEcC/+HJPeiCA8H/kFyaFSUTarJdzayNNf8RrwC0uWtBsUh/4oZdds +UUtA/s62avNW511hLV1k0vKuh/6vzZh9gJTbjSh/m7Cri3h0eETOMCWScR0I3FVsDI2 HjDn8uT8pBAck+cq9OSTCguaDF11Bovk4qwV/pyRy3VYSdnmZtgHSXaYGSRRvttzFre6 WMm+XAmmVwDTxnjysbfTziSGTqctgJ8Uqj7w525wljDdh55M7QyRsv7t633bShyjyMzb ngtg==
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=0ESNN6jMQczayHrYsAJ3iSmPkHFVybzZIJYXOSFc4BQ=; b=fCeoB6WyBrkPtBpIggSQ99FksNXdsGM0jbETkSnuwYPc3ZzPjAdxo5lQiU8w/8UtKa mYNAmUjaW95TZx5V1N6HFM34n1AOYlPe/39nzryDxYTFr8/7ZUt7J/gQ9cqB0PAEz2Ks KSAmU89c0DXnHXnv4h3QKSQh5gI/o31lvphqNwIbO3PRTkIga6hl2NrbuvZ1dd+ebtOc tNBoVG0qZmgI8Y4FIcZz6/Do3FuDUa9WfjACjByqjdFgZgX2xCQo9wmDHGwUlWuvrdn7 GGIMkiPA1Pj54S5ewJd5OrzUZj9qPA6gI6Y4CPGuEwZJcnz7u5UwfH2kEL7qDzykasNW q0yA==
X-Gm-Message-State: APjAAAUqWh8WKC+JEADtTqHuH5Cb0Uxs1S8czx+TXyOlr1NvnJEmb62z X/Gb5xdwzmDQbMd15RZedBm257WlBc/y3R8InLE=
X-Google-Smtp-Source: APXvYqwFgH2rH038uUznUKiMOYU+wqEdKazhjiMWPVzaZpcB8IrhTPhzqkkzJLi7bLk0IAHqPRXRG8K/3hD2Hww0+n8=
X-Received: by 2002:ac8:d49:: with SMTP id r9mr1375433qti.192.1552679230221; Fri, 15 Mar 2019 12:47:10 -0700 (PDT)
MIME-Version: 1.0
References: <155252958505.24865.4180223375091950120.idtracker@ietfa.amsl.com> <CAA=duU2xRovw34jTWQQdkufrenBq-SHgKh_6hSWLcy0OuSzQTQ@mail.gmail.com> <059f01d4db64$e35136b0$a9f3a410$@olddog.co.uk>
In-Reply-To: <059f01d4db64$e35136b0$a9f3a410$@olddog.co.uk>
From: "Andrew G. Malis" <agmalis@gmail.com>
Date: Fri, 15 Mar 2019 15:46:59 -0400
Message-ID: <CAA=duU1ez=14acEz9WvpkycC3kZ5xQuBU-O8=kmFAPi6CUeg6A@mail.gmail.com>
To: Adrian Farrel <adrian@olddog.co.uk>
Cc: Benjamin Kaduk <kaduk@mit.edu>, mpls-chairs <mpls-chairs@ietf.org>, mpls <mpls@ietf.org>, The IESG <iesg@ietf.org>, draft-ietf-mpls-sfc-encapsulation@ietf.org
Content-Type: multipart/alternative; boundary="000000000000f7b8c30584274d6d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/Yn6_5Xj7q6nQUcByEsGM0J2mahk>
Subject: Re: [mpls] Benjamin Kaduk's Discuss on draft-ietf-mpls-sfc-encapsulation-03: (with DISCUSS and COMMENT)
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Mar 2019 19:47:15 -0000

Adrian,

Thank you very much for your kind offer! Of course, anything copied would
be properly acknowledged. But perhaps a reference may do the trick as well
and has less of a carbon footprint - fewer bits all around. :-)

Cheers,
Andy


On Fri, Mar 15, 2019 at 3:25 PM Adrian Farrel <adrian@olddog.co.uk> wrote:

> Andy,
>
>
>
> Go ahead and copy text from draft-ietf-mpls-sfc, if you want to. I wrote
> it and I donate each and every word to you for no fee. You can even use
> them in the same order if it suits you.
>
>
>
> Acknowledgements are also nice.
>
>
>
> Adrian
>
>
>
> *From:* mpls <mpls-bounces@ietf.org> *On Behalf Of *Andrew G. Malis
> *Sent:* 15 March 2019 15:06
> *To:* Benjamin Kaduk <kaduk@mit.edu>
> *Cc:* mpls-chairs <mpls-chairs@ietf.org>rg>; mpls <mpls@ietf.org>rg>; The IESG <
> iesg@ietf.org>gt;; draft-ietf-mpls-sfc-encapsulation@ietf.org
> *Subject:* Re: [mpls] Benjamin Kaduk's Discuss on
> draft-ietf-mpls-sfc-encapsulation-03: (with DISCUSS and COMMENT)
>
>
>
> Benjamin,
>
>
>
> Thanks for your review and comments. See below inline..
>
>
>
> On Wed, Mar 13, 2019 at 10:13 PM Benjamin Kaduk via Datatracker <
> noreply@ietf.org> wrote:
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Thanks for this clear and concise document!  I just have one concern,
> which will hopefully be easy to resolve (since there is a good chance
> that all the text necessary to do so is already written).
>
> As far as I can tell, the comment made by the secdir reviewer of
> draft-ietf-mpls-sfc-04 about circular references between that document
> and RFCs 7665 and 8300 regarding security properties, is also somewhat
> applicable to this document.  I do recognize the validity of first
> paragraph of the security considerations here (the NSH is an opaque
> payload for MPLS), but that in and of itself does not present a security
> analysis of the NSH in the MPLS environment.  The last paragraph of the
> security considerations of this document attempts to provide some
> analysis, but it seems to be incomplete and perhaps overly optimistic,
> particularly with respect to the use of MPLS with Inter-Carrier
> Interconnect and the processing of MPLS traffic from external
> interfaces.  Is there any reason not to fully harmonize (i.e.,
> synchronize) the security considerations of draft-ietf-mpls-sfc and
> draft-ietf-mpls-sfc-encapsulation?  (I guess the first paragraph of this
> document's security considerations doesn't apply to the other document,
> that allocates extended-special-purpose label values, but that's the
> only thing I saw.)
>
>
>
> Trying to keep this document in sync with draft-ietf-mpls-sfc was
> difficult because it was a moving target while this draft was being
> developed, and of course, it was updated during IETF last call and IESG
> review following the completion of this draft. And as you noted, there are
> some fundamental differences between the two drafts. Because the other
> draft makes some additions and changes to the MPLS label stack while this
> draft uses the MPLS label stack as designed and in wide practice, there's
> text in the other draft that doesn't apply to this one, such as regarding the
> use of MPLS to encode a logical representation of the NSH.
>
>
>
> If you have any specific suggestions for improvement for the text here,
> that would be greatly appreciated! Also, does the IESG have any policy
> regarding direct copying of applicable text from one draft to another in
> situations like this? Or perhaps we could just add a reference to
> particular paragraphs in section 15 of draft-ietf-mpls-sfc? That would
> remove the need to copy any text.
>
>
>
> I'll await your reply before taking any action.
>
>
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Section 1
>
>    This encapsulation is equivalent from an SFC perspective to other
>    transport encapsulations of packets using the NSH.  This can be
>    illustrated by adding an additional line to the example of a next-hop
>    SPI/SI-to-network overlay network locator mapping in Table 1 of
>    [RFC8300]:
>
> We probably should expand SPI and SI, since we haven't yet hit a
> terminiology section or a note that (implies that) readers should be
> familiar with the standard SFC terminology.
> Also, Table 1 of RFC 8300 is labeled "SFF NSH Mapping Example"; it's not
> really clear that specifically that table is the best way to illustrate
> how the MPLS encapsulation would work.
>
>
>
>  That table 1 extension was added to the draft as a result of the Routing
> Directorate review. Other than expanding the acronyms, I'll leave making
> any changes here up to Deborah.
>
>
>
>
> (side note) We use the strings "VPN" and "virtual private" here, which
> in some contexts will cause an (uninformed) reader to assume that data
> privacy (confidentiality) is involved; our uses do not seem to be for
> cases that would involve such a confidentiality property.  As a general
> matter, not necessarily involving changes to this document, it may be
> good to try to reserve these terms for cases where the confidentiality
> is in fact provided, to help disambiguate the cases for the reader.
>
>
>
> I take your point, but these are just examples of other uses of MPLS
> service labels.
>
>
>
> Section 2.1
>
> nit: s/The TTL For/The TTL for/ (twice)
>
>
>
> Will fix.
>
>
>
>
> Section 3
>
>    For SFC, ECMP may or may not be desirable.  To prevent ECMP when it
>    is not desired, the NSH Base Header was carefully constructed so that
>    the NSH could not look like IPv4 or IPv6 based on its first nibble.
>    See Section 2.2 of [RFC8300] for further details.
>
> nit: this paragraph might flow better into the next one if we add a note
> that "Accordingly, the default behavior for MPLS-encapsulated SFC will
> not use ECMP."
>
>
>
> Good suggestion, will add.
>
>
>
>
> Section 6
>
>    However, it can be argued that carrying the NSH over MPLS is more
>
> re: "it can be argued" -- is this document attempting to make that
> argument?
>
>
>
> It could be argued that is the case! :-)
>
>
>
>    secure than using other encapsulations, as it is extremely difficult,
>    due to the MPLS architecture, for an attempted attacker to inject
>
> It's not entirely clear to me how much of this is the MPLS architecture
> vs. implementation/deployment; I suppose to some extent it is true of
> both.
>
>
>
> IMHO, it really is a result of the architecture, and as a result, any
> implementation that properly follows the architecture. MPLS packets must be
> created by a PE router, and downstream P routers will drop any incoming
> MPLS packets from upstream P or PE routers that don't have a top-most label
> that's in the router's LIB. So successfully injecting MPLS attack packets
> really does require insider access, and if you have that, there are so many
> other bad things you can do that are less expensive or difficult than
> trying to use an MPLS-based attack.
>
>
>
>
>    unexpected MPLS packets into a network, as MPLS networks do not by
>    design accept MPLS packets from external interfaces, and an attacker
>
> What about Inter-Carrier Interconnect?
>
>
>
> MPLS ICI is really off-topic for this draft because the NSH is only used
> in limited SFC domains that not only within a single domain (see RFC 8300),
> but within a well-defined sub-domain of that provider, such as within a
> data center.
>
>
>
> That said, just to answer your question, carriers for the most part don't
> do MPLS across carrier boundaries, there's too much trust that would be
> required. That said, there are some examples of inter-carrier MPLS, most
> commonly using RFC 4364 option A, which really isn't an MPLS interface.
> There is an MPLS Forum document,
> https://www.broadband-forum.org/technical/download/ipmpls/IPMPLSForum19.0.0.pdf
> , which discusses the various ways one can implement an MPLS ICI and the
> security implications of doing so, in section 13.
>
>
>
>
>    would need knowledge of the specific labels allocated by control and/
>    or management plane protocols.  Thus, an attacker attempting to spoof
>    MPLS-encapsulated NSH packets would require insider knowledge of the
>
> An attacker in a position to inject traffic seems likely to also be able
> to observe legitimate traffic and correspondingly their valid label
> values (if not necessarily the mapping from label to behavior).
>
>
>
> Absolutely, As I said above, if you've got that much insider access, there
> are much easier ways to screw up a network than play with MPLS packets.
>
>
>
>
>    network's control and management planes and a way to inject packets
>    into internal interfaces.  This is compared to, for example, NSH over
>    UDP over IP, which could be injected into any external interface in a
>    network that was not properly configured to filter out such packets
>    at the ingress.
>
> The NSH security considerations already (essentially) require this
> filtering at ingress behavior; the practical question relevant here
> seems to just be a matter of scale -- how hard it is to misconfigure
> this filtering or how likely it is that the relevant filtering is
> present as a consequence of factors external to SFC.
>
>
>
> I think that's a question more for RFC 8300 than this draft. In terms of
> how hard it is to misconfigure filtering, that's really an implementation
> and deployment question.
>
>
>
> Thanks again for your review.
>
>
>
> Cheers,
>
> Andy
>
>
>