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

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

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 <[e-mail]> 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.
>
>
>
> Acknowledgements are also nice.
>
>
>
> Adrian
>
>
>
> *From:* mpls <[e-mail]> *On Behalf Of *Andrew G. Malis
> *Sent:* 15 March 2019 15:06
> *To:* Benjamin Kaduk <[e-mail]>
> *Cc:* mpls-chairs <[e-mail]>; mpls <[e-mail]>; The IESG <
> [e-mail]>; [e-mail]
> *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 <
> [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
>
>
>