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
>