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

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

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