Re: [mpls] Benjamin Kaduk's Discuss on draft-ietf-mpls-sfc-encapsulation-03: (with DISCUSS and COMMENT)
"Andrew G. Malis" <agmalis@gmail.com> Wed, 20 March 2019 12:12 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 C6E9D12865E; Wed, 20 Mar 2019 05:12:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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] 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 M3deG6rY2FHA; Wed, 20 Mar 2019 05:12:41 -0700 (PDT)
Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 2965B127918; Wed, 20 Mar 2019 05:12:41 -0700 (PDT)
Received: by mail-qt1-x831.google.com with SMTP id t28so2127533qte.6; Wed, 20 Mar 2019 05:12:41 -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=jNn31cuLEQVzK6vn8sYCXrlF2j0TdvFdJ2y89h0TqUI=; b=JkL/74couHHmoihQWWq0tgbvWWhJH/NnCBtzQEkx/BhlfSR3epqJ8EP254Rzn1r/Cs kJBz4jXFfAWLwYzm0ptjYWwI9bpYs7+pJhfAGlQ9ssQKENnNk92az3vaQVVYaj6T8SRD LOT67OSHK6Xkh7I4OUKO1JcrCgweUpwon/toszNBWZNSPZGMwnKRtyiiGpi1xGPJsanD TE3LxCxInrd/+MOf5shcHKfaKr1OpNuB+XklhtPgXw98AiexB7PBzUTl5L9KM2yAAGt8 r7y+Gf62s2Jx3LX9cVz8UFBZLiPwmhl+WjcbNNVhOIM0sW8az315NLKkBrkoOfxfDO/V ghYg==
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=jNn31cuLEQVzK6vn8sYCXrlF2j0TdvFdJ2y89h0TqUI=; b=c917AdqjpAxExRQJoI1raNZrBAVx5wtWwsEj7qrGiq2HZnIB9L4BnMGbJmeipwvpZA pNT52gQU7XBX8QEGS8K9n2D6xd9kG5GkW/dGQm1LDVjXLmkLjWGCtaNXp8B6QG5IqkHN bKj/3+U2BqCu2m0pG5ntXzATGofmzqXvHYCIDWCSoN/Wc5gtn9iz54FyKZfPXGsqkoPB DBIjjQIhEuC54uySbeY85XRNx5RXgZzQWm9bhBB5aa8vPM9dNrYEmVx0IKZneJvzhQVa qTxLRn3ZCBTqAlT+m+7Y6rmsOVehynxVSppJey7WzEIdTx0hyoptrZy2XFExy5rB++Yd uCUQ==
X-Gm-Message-State: APjAAAWCRn/pZfNCt/YyLCnrOsrDSNg1XSuNT1nCxdKY9MjtxK3yH1JZ O57+cdKWsOF68f7KW0hKki/+6UaS0vbWXEbn4qQ=
X-Google-Smtp-Source: APXvYqxvCxzjPrIvJTepN0OIaLnKOmCeSs9eriXCxBnpR3Tt8VS4hlSE96HKp/gs02uVuo75AzvMusHmqpX4/LUakeA=
X-Received: by 2002:ac8:2eec:: with SMTP id i41mr2975841qta.81.1553083960020; Wed, 20 Mar 2019 05:12:40 -0700 (PDT)
MIME-Version: 1.0
References: <155252958505.24865.4180223375091950120.idtracker@ietfa.amsl.com> <CAA=duU2xRovw34jTWQQdkufrenBq-SHgKh_6hSWLcy0OuSzQTQ@mail.gmail.com> <20190320001751.GS80498@kduck.mit.edu>
In-Reply-To: <20190320001751.GS80498@kduck.mit.edu>
From: "Andrew G. Malis" <agmalis@gmail.com>
Date: Wed, 20 Mar 2019 08:12:28 -0400
Message-ID: <CAA=duU1CNcPSZxyeFYveOkBf8jZFsdRCnohJCv_WSmUgf92rdA@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: The IESG <iesg@ietf.org>, draft-ietf-mpls-sfc-encapsulation@ietf.org, Loa Andersson <loa@pi.nu>, mpls-chairs <mpls-chairs@ietf.org>, mpls <mpls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000be54d305848589d9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/xDDH8llQbOn_r11_YiIilT8CvNM>
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: Wed, 20 Mar 2019 12:12:45 -0000
Benjamin, Thanks again. I'm not sure why that BBF URL stopped working, but you can find the document here: https://web.archive.org/web/20160426184514/https://www.broadband-forum.org/technical/download/ipmpls/IPMPLSForum19.0.0.pdf I'll check with them regarding fixing the link going forward. Regarding option a of RFC 4364, see section 10 on p. 32. We've always referred to those as options a, b, and c. Once I get the go-ahead from Deborah, I'll do an update on the draft. Cheers, Andy On Tue, Mar 19, 2019 at 8:17 PM Benjamin Kaduk <kaduk@mit.edu> wrote: > On Fri, Mar 15, 2019 at 11:05:59AM -0400, Andrew G. Malis wrote: > > 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. > > Other than things purely related to the specific encoding of the semantic > content of the NSH, though, it seems that the security and privacy > considerations to conveying the information content of the NSH over MPLS > transit should be essentially identical, regardless of how that semantic > content is encoded. Did you have in mind text in specifically the security > considerations of the other draft that doesn't apply to this one? I made > a quick skim and didn't see anything that stuck out, but it was pretty > quick. > > > If you have any specific suggestions for improvement for the text here, > > that would be greatly appreciated! Also, does the IESG have any policy > > I suppose this may change given the response to my question above, but > given my comments in the COMMENT section on this document's security > considerations, my initial specific suggestion would be to take the first > paragraph from this document, strike the other three paragraphs, and > incorporate (whether inline or by reference) the full security > considerations from the other document. > > (And to be clear, "initial" and "suggestion" are important words here; I > don't intend to say this is the final word.) > > > regarding direct copying of applicable text from one draft to another in > > situations like this? Or perhaps we could just add a reference to > > I don't know of a policy one way or the other... > > > particular paragraphs in section 15 of draft-ietf-mpls-sfc? That would > > remove the need to copy any text. > > ... but the reference seems like it should be sufficient, at least. > > > 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. > > Okay. I doubt I'm really the target audience anyway... > > > > > > (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! :-) > > I think that "arguably is more secure" would more directly represent such > a claim, but it is of course your call. > > > > > > 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 > > (I think the crux of what I'm "not clear" about is the source of this > "must". But it seems unlikely to be relevant to the present discussion, so > perhaps we should just drop this topic.) > > > 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 > > Just needing to know the label allocations that are valid for that router > is unlikely to inspire much confidence from security-area folks; given that > this is necessarily shared with several parties (i.e., at least everything > directly connected to that router) it's hard for us, in our mental model, > to be confident that it will remain secret and unguessable. (Also, > depending on their goal, an attacker may not need to know what a specific > label does, so if they just need to be able to guess *any* valid label, > their job gets easier.) > > > really does require insider access, and if you have that, there are so > many > > An N of 2**20 chance of success (per packet!) doesn't really mesh with > "requires insider access", given my present understanding. > > > other bad things you can do that are less expensive or difficult than > > trying to use an MPLS-based attack. > > Sure, but that doesn't always mean that we should completely ignore the > risk; the situation may not always be that way. > > > > > > > > > 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. > > The specific text I quoted was supposedly talking about generic MPLS > networks, not restricted to sites using the NSH. The argument, as stated, > does not seem to hold up, given the ability of MPLS networks to use ICI to > accept external traffic (i.e., it is "within the design"). The specific > environments in which the NSH is intended to be used may well have a > different situation, but the current text does not reflect that different > situation, just from a purely rhetorical point of view. > > > 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. > > (I couldn't find "option A" in RFC 4364, and the broadband-forum link gives > a 404 over here.) > > > > > > > > > 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. > > My point is that from a rhetorical point of view, this is a facile argument > -- the "requirement" would essentially always be met by anyone that meets > the preconditions from the first part of the sentence. > > > > > > > > > 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. > > I guess I'm trying to say that the comparison doesn't feel particularly > compelling to me (given my (low) level of background knowledge) -- 8300 > requires this sort of filtering in all cases, whether MPLS or UDP or > otherwise. The expected MPLS deployment setup (or architecture, as you put > it) makes this happen essentially by default, but anything using the NSH is > supposed to do it. So, the comparison is not really about the encoding > per se, but rather around the risk/likelihood of noncompliant deployment, > but the current wording gives the impression that it's supposed to arise as > a natural consequence of the encoding (as opposed to the deployment > details). > > > Thanks again for your review. > > And thanks for your responses! Sorry for the slow reply. > > Benjamin >
- [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