Return-Path: 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 A95F4129A4B; Wed, 20 Mar 2019 07:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 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, HTTPS_HTTP_MISMATCH=1.989, 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 qtzkuNK-sVuk; Wed, 20 Mar 2019 07:57:22 -0700 (PDT) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (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 921771310AB; Wed, 20 Mar 2019 07:57:21 -0700 (PDT) Received: by mail-qt1-x829.google.com with SMTP id x12so2834006qts.7; Wed, 20 Mar 2019 07:57:21 -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=P4d6J+UPPOrwoW2ZqDCOqXyWMbjF+fo8t6W/R6RACts=; b=jxz0YQHVCGX9QRX90YokZi9ZCrrRl4VrtbYVqhqRfghv3KH/7fE+9o810PnX996TcY +sml5eTKlWM+kSBMA6q1HqkBZVJVguqL5ZSFBO7eU5+vyrQGSAkA7DG4zGl0U4g6MjZY RblpAnHnQm5x77z/nsDIyBnI8NjbzmSmVa2q5YYdppLdaR+yrOpKO/hJY8FQSxfCdCA7 hmsaMWD1hTLq7A6O2OYaEFPnKQqe7mYTC+NDfthDyW6YN467Xs9pqgX4Y/R/74FOgq+/ k03aOl7MLCtH/bgC+7HD49Vnb+l4O6b2t3VUZVpML/XMmx92Fzoevf2ZgvEKnKXMwDC2 qiXg== 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=P4d6J+UPPOrwoW2ZqDCOqXyWMbjF+fo8t6W/R6RACts=; b=td+BHM3WIdATRrw1yW/qHRd2jDQaxqyO2L0mkxNbR1kEiLIp1liABzDn6FOcVOeLue OtwurMr6QDryrtk9RQUYvLydR5howuOpMvskkz41P2eML6QZRKfiJtTjS4oBJulEKCZv 6rPWRw2ZAC42U8jgZvH9ds0xmsPITfD4QTN5Qa+laCv1cI3P+JV5//5+xQH76+UjYfOr 4jwxatVUn8e1M+7zjc4np2rpKwuJX8qJpTDIQ5jVVoqkj5/mU+W4MTo1B36/2wxWnc1N 2jH/KaL1vuJD9KxJSLB080CIreXdYTwLh71I05DW4GvpEdkE2GkwATSIMpf5MTuREtmD bzyQ== X-Gm-Message-State: APjAAAVqF6LPE3hSp4xqr8oEXff08IOxInInq1GBELYtzznLJrchoUK3 EZjavu5AjkletosuHEESJZXMo1olcAoCl0KLRMPURUeahRg= X-Google-Smtp-Source: APXvYqwyn9dARQocRk6/VPg0vjPmvT/j9Cp//nsASllWBk2wkqnP7QnHd3/zp4Fls7BVz0em9S1rmW3XYORok3JAoVY= X-Received: by 2002:a0c:9319:: with SMTP id d25mr6775795qvd.99.1553093840504; Wed, 20 Mar 2019 07:57:20 -0700 (PDT) MIME-Version: 1.0 References: <155252958505.24865.4180223375091950120.idtracker@ietfa.amsl.com> <20190320001751.GS80498@kduck.mit.edu> In-Reply-To: From: "Andrew G. Malis" Date: Wed, 20 Mar 2019 10:57:09 -0400 Message-ID: To: Benjamin Kaduk Cc: The IESG , draft-ietf-mpls-sfc-encapsulation@ietf.org, Loa Andersson , mpls-chairs , mpls Content-Type: multipart/alternative; boundary="000000000000aa8d20058487d614" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2019 14:57:28 -0000 --000000000000aa8d20058487d614 Content-Type: text/plain; charset="UTF-8" It turns out that the BBF recently reorganized their website. The new URL is https://www.broadband-forum.org/wp-content/uploads/2018/12/IPMPLSForum19.0.0.pdf . Cheers, Andy On Wed, Mar 20, 2019 at 8:12 AM Andrew G. Malis wrote: > 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 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 >> > --000000000000aa8d20058487d614 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It turns out that the BBF recently reorga= nized their website. The new URL is=C2=A0https://www.broa= dband-forum.org/wp-content/uploads/2018/12/IPMPLSForum19.0.0.pdf .

Cheers,
Andy




On Wed, Mar 20, 2019= at 8:12 AM Andrew G. Malis <agmali= s@gmail.com> wrote:
Benjamin,

T= hanks again. I'm not sure why that BBF URL stopped working, but you can= find the document here:


I'll check w= ith them regarding fixing the link going forward.

= Regarding option a of=C2=A0RFC 4364, see section 10 on p. 32. We've alw= ays 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> wr= ote:
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!=C2=A0 I just have one= concern,
> > which will hopefully be easy to resolve (since there is a good ch= ance
> > 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<= br> > > draft-ietf-mpls-sfc-04 about circular references between that doc= ument
> > and RFCs 7665 and 8300 regarding security properties, is also som= ewhat
> > applicable to this document.=C2=A0 I do recognize the validity of= first
> > paragraph of the security considerations here (the NSH is an opaq= ue
> > payload for MPLS), but that in and of itself does not present a s= ecurity
> > analysis of the NSH in the MPLS environment.=C2=A0 The last parag= raph of the
> > security considerations of this document attempts to provide some=
> > analysis, but it seems to be incomplete and perhaps overly optimi= stic,
> > particularly with respect to the use of MPLS with Inter-Carrier > > Interconnect and the processing of MPLS traffic from external
> > interfaces.=C2=A0 Is there any reason not to fully harmonize (i.e= .,
> > synchronize) the security considerations of draft-ietf-mpls-sfc a= nd
> > draft-ietf-mpls-sfc-encapsulation?=C2=A0 (I guess the first parag= raph of this
> > document's security considerations doesn't apply to the o= ther document,
> > that allocates extended-special-purpose label values, but that= 9;s the
> > only thing I saw.)
> >
>
> Trying to keep this document in sync with draft-ietf-mpls-sfc was diff= icult
> because it was a moving target while this draft was being developed, a= nd 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 th= e
> 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.=C2=A0 Did you have in mind text in specifically the sec= urity
considerations of the other draft that doesn't apply to this one?=C2=A0= I made
a quick skim and didn't see anything that stuck out, but it was pretty<= br> 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 import= ant 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
> >
> >=C2=A0 =C2=A0 This encapsulation is equivalent from an SFC perspec= tive to other
> >=C2=A0 =C2=A0 transport encapsulations of packets using the NSH.= =C2=A0 This can be
> >=C2=A0 =C2=A0 illustrated by adding an additional line to the exam= ple of a next-hop
> >=C2=A0 =C2=A0 SPI/SI-to-network overlay network locator mapping in= Table 1 of
> >=C2=A0 =C2=A0 [RFC8300]:
> >
> > We probably should expand SPI and SI, since we haven't yet hi= t 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 Exampl= e"; it's not
> > really clear that specifically that table is the best way to illu= strate
> > how the MPLS encapsulation would work.
> >
>
>=C2=A0 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.=C2=A0 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.=C2=A0 A= s a general
> > matter, not necessarily involving changes to this document, it ma= y be
> > good to try to reserve these terms for cases where the confidenti= ality
> > is in fact provided, to help disambiguate the cases for the reade= r.
> >
>
> 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
> >
> >=C2=A0 =C2=A0 For SFC, ECMP may or may not be desirable.=C2=A0 To = prevent ECMP when it
> >=C2=A0 =C2=A0 is not desired, the NSH Base Header was carefully co= nstructed so that
> >=C2=A0 =C2=A0 the NSH could not look like IPv4 or IPv6 based on it= s first nibble.
> >=C2=A0 =C2=A0 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-encapsulate= d SFC will
> > not use ECMP."
> >
>
> Good suggestion, will add.
>
>
> >
> > Section 6
> >
> >=C2=A0 =C2=A0 However, it can be argued that carrying the NSH over= MPLS is more
> >
> > re: "it can be argued" -- is this document attempting t= o make that
> > argument?
> >
>
> It could be argued that is the case! :-)

I think that "arguably is more secure" would more directly repres= ent such
a claim, but it is of course your call.

>
> >=C2=A0 =C2=A0 secure than using other encapsulations, as it is ext= remely difficult,
> >=C2=A0 =C2=A0 due to the MPLS architecture, for an attempted attac= ker to inject
> >
> > It's not entirely clear to me how much of this is the MPLS ar= chitecture
> > vs. implementation/deployment; I suppose to some extent it is tru= e of
> > both.
> >
>
> IMHO, it really is a result of the architecture, and as a result, any<= br> > implementation that properly follows the architecture. MPLS packets mu= st be
> created by a PE router, and downstream P routers will drop any incomin= g

(I think the crux of what I'm "not clear" about is the source= of this
"must".=C2=A0 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-m= ost label
> that's in the router's LIB. So successfully injecting MPLS att= ack 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<= br> directly connected to that router) it's hard for us, in our mental mode= l,
to be confident that it will remain secret and unguessable.=C2=A0 (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<= br> "requires insider access", given my present understanding.

> other bad things you can do that are less expensive or difficult than<= br> > 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.

>
> >
> >=C2=A0 =C2=A0 unexpected MPLS packets into a network, as MPLS netw= orks do not by
> >=C2=A0 =C2=A0 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 us= ed 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.=C2=A0 The argument, as sta= ted,
does not seem to hold up, given the ability of MPLS networks to use ICI to<= br> accept external traffic (i.e., it is "within the design").=C2=A0 = 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 do= n't
> do MPLS across carrier boundaries, there's too much trust that wou= ld be
> required. That said, there are some examples of inter-carrier MPLS, mo= st
> commonly using RFC 4364 option A, which really isn't an MPLS inter= face.
> There is an MPLS Forum document,
> https://www.broa= dband-forum.org/technical/download/ipmpls/IPMPLSForum19.0.0.pdf
> , which discusses the various ways one can implement an MPLS ICI and t= he
> security implications of doing so, in section 13.

(I couldn't find "option A" in RFC 4364, and the broadband-fo= rum link gives
a 404 over here.)

>
> >
> >=C2=A0 =C2=A0 would need knowledge of the specific labels allocate= d by control and/
> >=C2=A0 =C2=A0 or management plane protocols.=C2=A0 Thus, an attack= er attempting to spoof
> >=C2=A0 =C2=A0 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 lab= el
> > values (if not necessarily the mapping from label to behavior). > >
>
> Absolutely, As I said above, if you've got that much insider acces= s, 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 th= at meets
the preconditions from the first part of the sentence.

>
> >
> >=C2=A0 =C2=A0 network's control and management planes and a wa= y to inject packets
> >=C2=A0 =C2=A0 into internal interfaces.=C2=A0 This is compared to,= for example, NSH over
> >=C2=A0 =C2=A0 UDP over IP, which could be injected into any extern= al interface in a
> >=C2=A0 =C2=A0 network that was not properly configured to filter o= ut such packets
> >=C2=A0 =C2=A0 at the ingress.
> >
> > The NSH security considerations already (essentially) require thi= s
> > filtering at ingress behavior; the practical question relevant he= re
> > seems to just be a matter of scale -- how hard it is to misconfig= ure
> > 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 te= rms of
> how hard it is to misconfigure filtering, that's really an impleme= ntation
> and deployment question.

I guess I'm trying to say that the comparison doesn't feel particul= arly
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.=C2=A0 The expected MPLS deployment setup (or architecture, as yo= u put
it) makes this happen essentially by default, but anything using the NSH is=
supposed to do it.=C2=A0 So, the comparison is not really about the encodin= g
per se, but rather around the risk/likelihood of noncompliant deployment, but the current wording gives the impression that it's supposed to aris= e as
a natural consequence of the encoding (as opposed to the deployment
details).

> Thanks again for your review.

And thanks for your responses!=C2=A0 Sorry for the slow reply.

Benjamin
--000000000000aa8d20058487d614--