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 14:57 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 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> <CAA=duU2xRovw34jTWQQdkufrenBq-SHgKh_6hSWLcy0OuSzQTQ@mail.gmail.com> <20190320001751.GS80498@kduck.mit.edu> <CAA=duU1CNcPSZxyeFYveOkBf8jZFsdRCnohJCv_WSmUgf92rdA@mail.gmail.com>
In-Reply-To: <CAA=duU1CNcPSZxyeFYveOkBf8jZFsdRCnohJCv_WSmUgf92rdA@mail.gmail.com>
From: "Andrew G. Malis" <agmalis@gmail.com>
Date: Wed, 20 Mar 2019 10:57:09 -0400
Message-ID: <CAA=duU1204gJN6L88u-EUu2S3tXV5_bF2T_WqagqEDwLUG=JaA@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="000000000000aa8d20058487d614"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/nkB709TUx1G8vBzS49IzL_PTP6E>
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 14:57:28 -0000

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 <agmalis@gmail.com>; 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 <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
>>
>