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

[Benjamin Kaduk via Datatracker <[e-mail]>]

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.