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

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

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.

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


> (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! :-)


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


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

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.


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


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

Thanks again for your review.

Cheers,
Andy