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>; mpls <mpls@ietf.org>; The IESG < > iesg@ietf.org>; 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 > > >
- [mpls] Benjamin Kaduk's Discuss on draft-ietf-mpl… Benjamin Kaduk via Datatracker
- Re: [mpls] Benjamin Kaduk's Discuss on draft-ietf… Andrew G. Malis
- Re: [mpls] Benjamin Kaduk's Discuss on draft-ietf… Adrian Farrel
- Re: [mpls] Benjamin Kaduk's Discuss on draft-ietf… Andrew G. Malis
- Re: [mpls] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk
- Re: [mpls] Benjamin Kaduk's Discuss on draft-ietf… Andrew G. Malis
- Re: [mpls] Benjamin Kaduk's Discuss on draft-ietf… Andrew G. Malis