--- 1/draft-ietf-mpls-sfc-04.txt 2019-02-12 04:14:16.190805086 -0800 +++ 2/draft-ietf-mpls-sfc-05.txt 2019-02-12 04:14:16.250806539 -0800 @@ -1,21 +1,21 @@ MPLS Working Group A. Farrel Internet-Draft Old Dog Consulting Intended status: Standards Track S. Bryant -Expires: May 24, 2019 Huawei +Expires: August 16, 2019 Huawei J. Drake Juniper Networks - November 20, 2018 + February 12, 2019 An MPLS-Based Forwarding Plane for Service Function Chaining - draft-ietf-mpls-sfc-04 + draft-ietf-mpls-sfc-05 Abstract Service Function Chaining (SFC) is the process of directing packets through a network so that they can be acted on by an ordered set of abstract service functions before being delivered to the intended destination. An architecture for SFC is defined in RFC7665. The Network Service Header (NSH) can be inserted into packets to steer them along a specific path to realize a Service Function Chain. @@ -23,87 +23,89 @@ Multiprotocol Label Switching (MPLS) is a widely deployed forwarding technology that uses labels placed in a packet in a label stack to identify the forwarding actions to be taken at each hop through a network. Actions may include swapping or popping the labels as well, as using the labels to determine the next hop for forwarding the packet. Labels may also be used to establish the context under which the packet is forwarded. This document describes how Service Function Chaining can be achieved in an MPLS network by means of a logical representation of the NSH in - an MPLS label stack. It does not deprecate or replace the NSH, but - acknowledges that there may be a need for an interim deployment of - SFC functionality in brownfield networks. + an MPLS label stack. That is, the NSH is not used, but the fields of + the NSH are mapped to fields in the MPLS label stack. It does not + deprecate or replace the NSH, but acknowledges that there may be a + need for an interim deployment of SFC functionality in brownfield + networks. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on May 24, 2019. + This Internet-Draft will expire on August 16, 2019. Copyright Notice - Copyright (c) 2018 IETF Trust and the persons identified as the + Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 3. Choice of Data Plane SPI/SI Representation . . . . . . . . . 4 4. Use Case Scenarios . . . . . . . . . . . . . . . . . . . . . 5 4.1. Label Swapping for Logical NSH . . . . . . . . . . . . . 5 4.2. Hierarchical Encapsulation . . . . . . . . . . . . . . . 5 - 4.3. Fine Control of Service Function Instances . . . . . . . 5 + 4.3. Fine Control of Service Function Instances . . . . . . . 6 4.4. Micro Chains and Label Stacking . . . . . . . . . . . . . 6 4.5. SFC and Segment Routing . . . . . . . . . . . . . . . . . 6 5. Basic Unit of Representation . . . . . . . . . . . . . . . . 6 - 6. MPLS Label Swapping . . . . . . . . . . . . . . . . . . . . . 7 + 6. MPLS Label Swapping . . . . . . . . . . . . . . . . . . . . . 8 7. MPLS Label Stacking . . . . . . . . . . . . . . . . . . . . . 10 8. Mixed Mode Forwarding . . . . . . . . . . . . . . . . . . . . 12 9. A Note on Service Function Capabilities and SFC Proxies . . . 13 10. Control Plane Considerations . . . . . . . . . . . . . . . . 13 11. Use of the Entropy Label . . . . . . . . . . . . . . . . . . 14 12. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . 15 12.1. Indicating Metadata in User Data Packets . . . . . . . . 15 12.2. Inband Programming of Metadata . . . . . . . . . . . . . 17 13. Worked Examples . . . . . . . . . . . . . . . . . . . . . . . 20 14. Implementation Notes . . . . . . . . . . . . . . . . . . . . 24 15. Security Considerations . . . . . . . . . . . . . . . . . . . 25 - 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 + 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 - 18. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26 - 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 - 19.1. Normative References . . . . . . . . . . . . . . . . . . 26 - 19.2. Informative References . . . . . . . . . . . . . . . . . 27 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 + 18. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27 + 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 + 19.1. Normative References . . . . . . . . . . . . . . . . . . 27 + 19.2. Informative References . . . . . . . . . . . . . . . . . 28 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 1. Introduction Service Function Chaining (SFC) is the process of directing packets through a network so that they can be acted on by an ordered set of abstract service functions before being delivered to the intended destination. An architecture for SFC is defined in [RFC7665]. When applying a particular Service Function Chain to the traffic selected by a service classifier, the traffic needs to be steered @@ -545,22 +547,22 @@ Section 4.3. When an SFF receives a packet containing an MPLS label stack, it checks whether it is processing an {SFP, SI} label pair for label swapping or a {context label, SFI index} label pair for label stacking. It then selects the appropriate SFI to which to send the packet. When it receives the packet back from the SFI, it has four cases to consider. o If the current hop requires an {SFP, SI} and the next hop requires - an {SFP, SI}, it sets the SI label to the SI value of the current - hop, selects an instance of the SF to be executed at the next hop, + an {SFP, SI}, it selects an instance of the SF to be executed at + the next hop, sets the SI label to the SI value of the next hop, and tunnels the packet to the SFF for that SFI. o If the current hop requires an {SFP, SI} and the next hop requires a {context label, SFI label}, it pops the {SFP, SI} from the top of the MPLS label stack and tunnels the packet to the SFF indicated by the context label. o If the current hop requires a {context label, SFI label}, it pops the {context label, SFI label} from the top of the MPLS label stack. @@ -1100,40 +1102,80 @@ 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 - present in [RFC8300]. + present in [RFC8300]. Those documents provide analysis and present a + set of requirements and recommendations for security, but they do not + describe any mechanisms for securing NSH systems. It is fundamental to the SFC design that the classifier is a trusted resource which determines the processing that the packet will be subject to, including for example the firewall. 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 labels are swapped or popped correctly. Where an SF is not encapsulation aware the encapsulation may be stripped by an SFC proxy such that packet may exist as a native packet (perhaps IP) on the path between SFC proxy and 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 + [I-D.ietf-bess-nsh-bgp-control-plane]) and management plane + mechanisms must include security measures that can be enable by + operators to protect their SFC systems. + + An analysis of the security of MPLS systems is provided in [RFC5920]. + That document notes the MPLS forwarding plane has no built-in + security mechanisms. Some proposals to add encryption to the MPLS + forwarding plane have been suggested + ([I-D.ietf-mpls-opportunistic-encrypt]), but no mechanisms have been + agreed at the time of publication of this document. 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. 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." + + 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 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 the security vulnerabilities are addressed (or should be - addressed) in all the underlying technologies used by this design, - which itself does not introduce any new security vulnerabilities. + Thus, the security vulnerabilities are addressed (or should be + addressed) in all the underlying technologies used by this design. + No known new security vulnerabilities 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 This document requests IANA to make 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 | -------+-----------------------------------+-------------- @@ -1145,21 +1187,23 @@ This document derives ideas and text from [I-D.ietf-bess-nsh-bgp-control-plane]. The authors are grateful to all those who contributed to the discussions that led to this work: Loa Andersson, Andrew G. Malis, Alexander Vainshtein, Joel M. 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. + and Mach Chen for reviews of this text. Thanks to Russ Mundy for his + Security Directorate review and to S Moonesamy for useful + discussions. The authors would like to be able to thank the authors of [I-D.xuclad-spring-sr-service-chaining] and [RFC8402] whose original work on service chaining and the identification of services using SIDs, and conversation with whom helped clarify the application of MPLS-SR to SFC. Particular thanks to Loa Andersson for conversations and advice about working group process. @@ -1196,44 +1240,53 @@ [RFC8393] Farrel, A. and J. Drake, "Operating the Network Service Header (NSH) with Next Protocol "None"", RFC 8393, DOI 10.17487/RFC8393, May 2018, . 19.2. Informative References [I-D.ietf-bess-nsh-bgp-control-plane] Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L. Jalil, "BGP Control Plane for NSH SFC", draft-ietf-bess- - nsh-bgp-control-plane-04 (work in progress), July 2018. + nsh-bgp-control-plane-05 (work in progress), January 2019. + + [I-D.ietf-mpls-opportunistic-encrypt] + Farrel, A. and S. Farrell, "Opportunistic Security in MPLS + Networks", draft-ietf-mpls-opportunistic-encrypt-03 (work + in progress), March 2017. [I-D.ietf-spring-segment-routing-mpls] Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing with MPLS - data plane", draft-ietf-spring-segment-routing-mpls-15 - (work in progress), October 2018. + data plane", draft-ietf-spring-segment-routing-mpls-18 + (work in progress), December 2018. [I-D.xuclad-spring-sr-service-chaining] Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W., and S. Salsano, "Segment Routing for Service Chaining", draft-xuclad-spring-sr-service- chaining-01 (work in progress), March 2018. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, . [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, . + [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS + Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, + . + [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, . [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, .