Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8595

An MPLS-Based Forwarding Plane for Service Function Chaining

Pages: 32
Proposed Standard
Part 2 of 2 – Pages 22 to 32
First   Prev   None

Top   ToC   RFC8595 - Page 22   prevText

13. Worked Examples

This section reverts to the simplified descriptions of networks that rely wholly on label swapping or label stacking. As described in Section 4, actual deployment scenarios may depend on the use of both mechanisms and utilize a mixed mode as described in Section 8. Consider the simplistic MPLS SFC overlay network shown in Figure 10. A packet is classified for an SFP that will see it pass through two SFs (SFa and SFb) that are accessed through two SFFs (SFFa and SFFb, respectively). The packet is ultimately delivered to the destination, D. +---------------------------------------------------+ | MPLS SFC Network | | | | +---------+ +---------+ | | | SFa | | SFb | | | +----+----+ +----+----+ | | ^ | | ^ | | | | (2)| | |(3) (5)| | |(6) | | (1) | | V (4) | | V (7) | +----------+ ---> +----+----+ ----> +----+----+ ---> +-------+ |Classifier+------+ SFFa +-------+ SFFb +------+ D | +----------+ +---------+ +---------+ +-------+ | | +---------------------------------------------------+ Figure 10: Service Function Chaining in an MPLS Network Let us assume that the SFP is computed and assigned an SPI value of 239. The forwarding details of the SFP are distributed (perhaps using the mechanisms of [BGP-NSH-SFC]) so that the SFFs are programmed with the necessary forwarding instructions. The packet progresses as follows: 1. The classifier assigns the packet to the SFP and imposes two label stack entries comprising a single basic unit of MPLS SFC representation: * The higher label stack entry contains a label carrying the SPI value of 239. * The lower label stack entry contains a label carrying the SI value of 255.
Top   ToC   RFC8595 - Page 23
       Further labels may be imposed to tunnel the packet from the
       classifier to SFFa.

   2.  When the packet arrives at SFFa, SFFa strips any labels
       associated with the tunnel that runs from the classifier to SFFa.
       SFFa examines the top labels and matches the SPI/SI to identify
       that the packet should be forwarded to SFa.  The packet is
       forwarded to SFa unmodified.

   3.  SFa performs its designated function and returns the packet
       to SFFa.

   4.  SFFa modifies the SI in the lower label stack entry (to 254) and
       uses the SPI/SI to look up the forwarding instructions.  It sends
       the packet with two label stack entries:

       *  The higher label stack entry contains a label carrying the SPI
          value of 239.

       *  The lower label stack entry contains a label carrying the SI
          value of 254.

       Further labels may be imposed to tunnel the packet from SFFa
       to SFFb.

   5.  When the packet arrives at SFFb, SFFb strips any labels
       associated with the tunnel from SFFa.  SFFb examines the top
       labels and matches the SPI/SI to identify that the packet should
       be forwarded to SFb.  The packet is forwarded to SFb unmodified.

   6.  SFb performs its designated function and returns the packet
       to SFFb.

   7.  SFFb modifies the SI in the lower label stack entry (to 253) and
       uses the SPI/SI to look up the forwarding instructions.  It
       determines that it is the last SFF in the SFP, so it strips the
       two SFC Label stack entries and forwards the payload toward D
       using the payload protocol.
Top   ToC   RFC8595 - Page 24
   Alternatively, consider the MPLS SFC overlay network shown in
   Figure 11.  A packet is classified for an SFP that will see it pass
   through two SFs (SFx and SFy) that are accessed through two SFFs
   (SFFx and SFFy, respectively).  The packet is ultimately delivered to
   the destination, D.

           +---------------------------------------------------+
           |                   MPLS SFC Network                |
           |                                                   |
           |            +---------+       +---------+          |
           |            |   SFx   |       |   SFy   |          |
           |            +----+----+       +----+----+          |
           |               ^ | |             ^ | |             |
           |            (2)| | |(3)       (5)| | |(6)          |
           |       (1)     | | V     (4)     | | V    (7)      |
      +----------+ ---> +----+----+ ----> +----+----+ ---> +-------+
      |Classifier+------+  SFFx   +-------+  SFFy   +------+   D   |
      +----------+      +---------+       +---------+      +-------+
           |                                                   |
           +---------------------------------------------------+

      Figure 11: Service Function Chaining Using MPLS Label Stacking

   Let us assume that the SFP is computed and assigned an SPI value of
   239.  However, the forwarding state for the SFP is not distributed
   and installed in the network.  Instead, it will be attached to the
   individual packets using the MPLS label stack.

   The packet progresses as follows:

   1.  The classifier assigns the packet to the SFP and imposes two
       basic units of MPLS SFC representation to describe the full SFP:

       *  The top basic unit comprises two label stack entries as
          follows:

          +  The higher label stack entry contains a label carrying the
             SFC context.

          +  The lower label stack entry contains a label carrying the
             SF indicator for SFx.
Top   ToC   RFC8595 - Page 25
       *  The lower basic unit comprises two label stack entries as
          follows:

          +  The higher label stack entry contains a label carrying the
             SFC context.

          +  The lower label stack entry contains a label carrying the
             SF indicator for SFy.

       Further labels may be imposed to tunnel the packet from the
       classifier to SFFx.

   2.  When the packet arrives at SFFx, SFFx strips any labels
       associated with the tunnel from the classifier.  SFFx examines
       the top labels and matches the context/SF values to identify that
       the packet should be forwarded to SFx.  The packet is forwarded
       to SFx unmodified.

   3.  SFx performs its designated function and returns the packet
       to SFFx.

   4.  SFFx strips the top basic unit of MPLS SFC representation,
       revealing the next basic unit.  It then uses the revealed
       context/SF values to determine how to route the packet to the
       next SFF, SFFy.  It sends the packet with just one basic unit of
       MPLS SFC representation comprising two label stack entries:

       *  The higher label stack entry contains a label carrying the SFC
          context.

       *  The lower label stack entry contains a label carrying the SF
          indicator for SFy.

       Further labels may be imposed to tunnel the packet from SFFx
       to SFFy.

   5.  When the packet arrives at SFFy, SFFy strips any labels
       associated with the tunnel from SFFx.  SFFy examines the top
       labels and matches the context/SF values to identify that the
       packet should be forwarded to SFy.  The packet is forwarded to
       SFy unmodified.

   6.  SFy performs its designated function and returns the packet
       to SFFy.

   7.  SFFy strips the top basic unit of MPLS SFC representation,
       revealing the payload packet.  It forwards the payload toward D
       using the payload protocol.
Top   ToC   RFC8595 - Page 26

14. Implementation Notes

It is not the job of an IETF specification to describe the internals of an implementation, except where that directly impacts upon the bits on the wire that change the likelihood of interoperability or where the availability of configuration or security options directly affects the utility of an implementation. However, in view of the objective of this document to acknowledge that there may be a need for an interim deployment of SFC functionality in brownfield MPLS networks, this section provides some observations about how an SFF might utilize MPLS features that are available in existing routers. This section is not intended to be definitive or technically complete; rather, it is indicative. Consider the mechanism used to indicate to which Virtual Routing and Forwarding (VRF) system an incoming MPLS packet should be routed in a Layer 3 Virtual Private Network (L3VPN) [RFC4364]. In this case, the top MPLS label is an indicator of the VRF system that is to be used to route the payload. A similar approach can be taken with the label-swapping SFC technique described in Section 6 such that the SFC Context Label identifies a routing table specific to the SFP. The SF Label can be looked up in the context of this routing table to determine to which SF to direct the packet and how to forward it to the next SFF. Advanced features (such as metadata) are not inspected by SFFs. The packets are passed to SFIs that are MPLS-SFC aware or to SFC proxies, and those components are responsible for handling all metadata issues. Of course, an actual implementation might make considerable optimizations on this approach, but this section should provide hints about how MPLS-based SFC might be achieved with relatively small modifications to deployed MPLS devices.

15. Security Considerations

Discussion of the security properties of SFC networks can be found in [RFC7665]. Further security discussion for the NSH and its use is provided in [RFC8300]. Those documents provide analysis and present a set of requirements and recommendations for security, and the normative security requirements from those documents apply to this specification. However, it should be noted that those documents do not describe any mechanisms for securing NSH systems.
Top   ToC   RFC8595 - Page 27
   It is fundamental to the SFC design that the classifier is a fully
   trusted element.  That is, the classification decision process is not
   visible to the other elements, and its output is treated as accurate.
   As such, the classifier has responsibility for determining the
   processing that the packet will be subject to, including, for
   example, firewall functions.  It is also fundamental to the MPLS
   design that packets are routed through the network using the path
   specified by the node imposing the labels and that the labels are
   swapped or popped correctly.  Where an SF is not encapsulation aware,
   the encapsulation may be stripped by an SFC proxy such that a packet
   may exist as a native packet (perhaps IP) on the path between the SFC
   proxy and the SF; however, this is an intrinsic part of the SFC
   design, which needs to define how a packet is protected in that
   environment.

   SFC components are configured and enabled through a management system
   or a control plane.  This document does not make any assumptions
   about what mechanisms are used.  Deployments should, however, be
   aware that vulnerabilities in the management plane or control plane
   of an SFC system imply vulnerabilities in the whole SFC system.
   Thus, control-plane solutions (such as [BGP-NSH-SFC]) and management-
   plane mechanisms must include security measures that can be enabled
   by operators to protect their SFC systems.

   An analysis of the security of MPLS systems is provided in [RFC5920],
   which also notes that the MPLS forwarding plane has no built-in
   security mechanisms.  Some proposals to add encryption to the MPLS
   forwarding plane have been suggested [MPLS-Opp-Sec], but no
   mechanisms have been agreed upon at the time of publication of this
   document.  Additionally, MPLS does not provide any cryptographic
   integrity protection on the MPLS headers.  That means that procedures
   described in this document rely on three basic principles:

   o  The MPLS network is often considered to be a closed network such
      that insertion, modification, or inspection of packets by an
      outside party is not possible.  MPLS networks are operated with
      closed boundaries so that MPLS-encapsulated packets are not
      admitted to the network, and MPLS headers are stripped before
      packets are forwarded from the network.  This is particularly
      pertinent in the SFC context because [RFC7665] notes that "The
      architecture described herein is assumed to be applicable to a
      single network administrative domain."  Furthermore, [RFC8300]
      states that packets originating outside the SFC-enabled domain
      MUST be dropped if they contain an NSH and packets exiting the
      SFC-enabled domain MUST be dropped if they contain an NSH.  These
      constraints apply equally to the use of MPLS to encode a logical
      representation of the NSH.
Top   ToC   RFC8595 - Page 28
   o  The underlying transport mechanisms (such as Ethernet) between
      adjacent MPLS nodes may offer security mechanisms that can be used
      to defend packets "on the wire".

   o  The SFC-capable devices participating in an SFC system are
      responsible for verifying and protecting payload packets and their
      contents as well as providing other security capabilities that
      might be required in the particular system.

   Additionally, where a tunnel is used to link two non-MPLS domains,
   the tunnel design needs to specify how the tunnel is secured.

   Thus, this design relies on the component underlying technologies to
   address the potential security vulnerabilities, and it documents the
   necessary protections (or risk of their absence) above.  It does not
   include any native security mechanisms in-band with the MPLS encoding
   of the NSH functionality.

   Note that configuration elements of this system (such as the
   programming of the table of metadata; see Section 12) must also be
   adequately secured, although such mechanisms are not in scope for
   this protocol specification.

   No known new security vulnerabilities over the SFC architecture
   [RFC7665] and the NSH specification [RFC8300] are introduced by this
   design, but if issues are discovered in the future, it is expected
   that they will be addressed through modifications to control/
   management components of any solution or through changes to the
   underlying technology.

16. IANA Considerations

IANA has made allocations from the "Extended Special-Purpose MPLS Label Values" subregistry of the "Special-Purpose Multiprotocol Label Switching (MPLS) Label Values" registry as follows: Value | Description | Reference -------+-----------------------------------+-------------- 16 | Metadata Label Indicator (MLI) | RFC 8595 17 | Metadata Present Indicator (MPI) | RFC 8595
Top   ToC   RFC8595 - Page 29

17. References

17.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC 6790, DOI 10.17487/RFC6790, November 2012, <https://www.rfc-editor.org/info/rfc6790>. [RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating and Retiring Special-Purpose MPLS Labels", RFC 7274, DOI 10.17487/RFC7274, June 2014, <https://www.rfc-editor.org/info/rfc7274>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., "Network Service Header (NSH)", RFC 8300, DOI 10.17487/RFC8300, January 2018, <https://www.rfc-editor.org/info/rfc8300>. [RFC8393] Farrel, A. and J. Drake, "Operating the Network Service Header (NSH) with Next Protocol "None"", RFC 8393, DOI 10.17487/RFC8393, May 2018, <https://www.rfc-editor.org/info/rfc8393>.
Top   ToC   RFC8595 - Page 30

17.2. Informative References

[BGP-NSH-SFC] Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L. Jalil, "BGP Control Plane for NSH SFC", Work in Progress, draft-ietf-bess-nsh-bgp-control-plane-11, May 2019. [MPLS-Opp-Sec] Farrel, A. and S. Farrell, "Opportunistic Security in MPLS Networks", Work in Progress, draft-ietf-mpls-opportunistic-encrypt-03, March 2017. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, <https://www.rfc-editor.org/info/rfc3031>. [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <https://www.rfc-editor.org/info/rfc4364>. [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <https://www.rfc-editor.org/info/rfc5920>. [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, <https://www.rfc-editor.org/info/rfc7665>. [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, <https://www.rfc-editor.org/info/rfc8402>. [RFC8459] Dolson, D., Homma, S., Lopez, D., and M. Boucadair, "Hierarchical Service Function Chaining (hSFC)", RFC 8459, DOI 10.17487/RFC8459, September 2018, <https://www.rfc-editor.org/info/rfc8459>. [SR-Srv-Prog] Clad, F., Ed., Xu, X., Ed., Filsfils, C., Bernier, D., Li, C., Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W., and S. Salsano, "Service Programming with Segment Routing", Work in Progress, draft-xuclad-spring-sr-service-programming-02, April 2019.
Top   ToC   RFC8595 - Page 31

Acknowledgements

This document derives ideas and text from [BGP-NSH-SFC]. The authors are grateful to all those who contributed to the discussions that led to that work: Loa Andersson, Andrew G. Malis, Alexander (Sasha) Vainshtein, Joel Halpern, Tony Przygienda, Stuart Mackie, Keyur Patel, and Jim Guichard. Loa Andersson provided helpful review comments. Thanks to Loa Andersson, Lizhong Jin, Matthew Bocci, Joel Halpern, and Mach Chen for reviews of this text. Thanks to Russ Mundy for his Security Directorate review and to S Moonesamy for useful discussions. Thanks also to Benjamin Kaduk, Alissa Cooper, Eric Rescorla, Mirja Kuehlewind, Alvaro Retana, and Martin Vigoureux for comprehensive reviews during IESG evaluation. The authors would like to be able to thank the authors of [SR-Srv-Prog] and [RFC8402] whose original work on service chaining and the identification of services using Segment Identifiers (SIDs), and conversation with whom, helped clarify the application of SR-MPLS to SFC. Particular thanks to Loa Andersson for conversations and advice about working group process.

Contributors

The following individual contributed text to this document: Andrew G. Malis Email: agmalis@gmail.com
Top   ToC   RFC8595 - Page 32

Authors' Addresses

Adrian Farrel Old Dog Consulting Email: adrian@olddog.co.uk Stewart Bryant Futurewei Email: stewart.bryant@gmail.com John Drake Juniper Networks Email: jdrake@juniper.net