Re: [mpls] Benjamin Kaduk's Discuss on draft-ietf-mpls-sfc-encapsulation-03: (with DISCUSS and COMMENT)

["Andrew G. Malis" <[e-mail]>]

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 <[e-mail]> 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 <
> > [e-mail]> 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
>