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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 13 Mar 2019 19:13:05 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-mpls-sfc-encapsulation-03: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mpls-sfc-encapsulation/

----------------------------------------------------------------------
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.)

----------------------------------------------------------------------
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.

(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.

Section 2.1

nit: s/The TTL For/The TTL for/ (twice)

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."

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?

   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.

   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?

   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).

   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.

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 15 Mar 2019 11:05:59 -0400

Benjamin,

Thanks for your review and comments. See below inline.

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.

If you have any specific suggestions for improvement for the text here,
that would be greatly appreciated! Also, does the IESG have any policy
regarding direct copying of applicable text from one draft to another in
situations like this? Or perhaps we could just add a reference to
particular paragraphs in section 15 of draft-ietf-mpls-sfc? That would
remove the need to copy any text.

I'll await your reply before taking any action.

> COMMENT:

 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.

> 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.

> nit: s/The TTL For/The TTL for/ (twice)

Will fix.

> that "Accordingly, the default behavior for MPLS-encapsulated SFC will

Good suggestion, will add.

> re: "it can be argued" -- is this document attempting to make that

It could be argued that is the case! :-)

> vs. implementation/deployment; I suppose to some extent it is true of

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
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
really does require insider access, and if you have that, there are so many
other bad things you can do that are less expensive or difficult than
trying to use an MPLS-based attack.

> 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.

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.

> 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.

> 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.

Thanks again for your review.

Cheers,
Andy

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 15 Mar 2019 19:25:44 -0000

Andy,

Go ahead and copy text from draft-ietf-mpls-sfc, if you want to. I wrote it and I donate each and every word to you for no fee. You can even use them in the same order if it suits you.

Acknowledgements are also nice.

Adrian

From: mpls <[email-masked]> On Behalf Of Andrew G. Malis
Sent: 15 March 2019 15:06
To: Benjamin Kaduk <[email-masked]>
Cc: mpls-chairs <[email-masked]>; mpls <[email-masked]>; The IESG <[email-masked]>; [email-masked]
Subject: Re: [mpls] Benjamin Kaduk's Discuss on draft-ietf-mpls-sfc-encapsulation-03: (with DISCUSS and COMMENT)

Benjamin,

Thanks for your review and comments. See below inline..

On Wed, Mar 13, 2019 at 10:13 PM Benjamin Kaduk via Datatracker <[email-masked] <mailto:[email-masked]> > wrote:

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.

If you have any specific suggestions for improvement for the text here, that would be greatly appreciated! Also, does the IESG have any policy regarding direct copying of applicable text from one draft to another in situations like this? Or perhaps we could just add a reference to particular paragraphs in section 15 of draft-ietf-mpls-sfc? That would remove the need to copy any text.

 

Section 1

 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.

I take your point, but these are just examples of other uses of MPLS service labels.

Section 2.1

Will fix.

Section 3

Section 6

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 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 really does require insider access, and if you have that, there are so many other bad things you can do that are less expensive or difficult than trying to use an MPLS-based attack.

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. 

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.

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.

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.

Cheers,

Andy

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 15 Mar 2019 15:46:59 -0400

Adrian,

Thank you very much for your kind offer! Of course, anything copied would
be properly acknowledged. But perhaps a reference may do the trick as well
and has less of a carbon footprint - fewer bits all around. :-)

Cheers,
Andy

On Fri, Mar 15, 2019 at 3:25 PM Adrian Farrel <[email-masked]> wrote:

> Andy,
>
>
>
> Go ahead and copy text from draft-ietf-mpls-sfc, if you want to. I wrote
> it and I donate each and every word to you for no fee. You can even use
> them in the same order if it suits you.
>
>
>
> *From:* mpls <[email-masked]> *On Behalf Of *Andrew G. Malis
> *Sent:* 15 March 2019 15:06
> *To:* Benjamin Kaduk <[email-masked]>
> *Cc:* mpls-chairs <[email-masked]>; mpls <[email-masked]>; The IESG <
> [email-masked]>; [email-masked]
> *Subject:* Re: [mpls] Benjamin Kaduk's Discuss on
> draft-ietf-mpls-sfc-encapsulation-03: (with DISCUSS and COMMENT)
>
>
>
> Benjamin,
>
>
>
> 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.
>
>
>
> 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),

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 19 Mar 2019 19:17:51 -0500

> 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.

> 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.)

> situations like this? Or perhaps we could just add a reference to

I don't know of a policy one way or the other...

> remove the need to copy any text.

... but the reference seems like it should be sufficient, at least.

> any changes here up to Deborah.

Okay.  I doubt I'm really the target audience anyway...

> 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.

> 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.)

> 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.

> 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.

> but within a well-defined sub-domain of that provider, such as within a

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.

> 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.)

> 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.

> how hard it is to misconfigure filtering, that's really an implementation

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

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 20 Mar 2019 08:12:28 -0400

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 <[email-masked]> wrote:

> difficult
> in

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 20 Mar 2019 10:57:09 -0400

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