--- 1/draft-ietf-mpls-sfc-06.txt 2019-03-07 15:13:35.642224276 -0800 +++ 2/draft-ietf-mpls-sfc-07.txt 2019-03-07 15:13:35.750226924 -0800 @@ -1,21 +1,21 @@ MPLS Working Group A. Farrel Internet-Draft Old Dog Consulting Intended status: Standards Track S. Bryant Expires: September 8, 2019 Huawei J. Drake Juniper Networks March 7, 2019 An MPLS-Based Forwarding Plane for Service Function Chaining - draft-ietf-mpls-sfc-06 + draft-ietf-mpls-sfc-07 Abstract This document describes how Service Function Chaining (SFC) can be achieved in an MPLS network by means of a logical representation of the Network Service Header (NSH) in 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. @@ -66,30 +66,31 @@ 5. Basic Unit of Representation . . . . . . . . . . . . . . . . 6 6. MPLS Label Swapping . . . . . . . . . . . . . . . . . . . . . 7 7. MPLS Label Stacking . . . . . . . . . . . . . . . . . . . . . 10 8. Mixed Mode Forwarding . . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 14 12.1. Indicating Metadata in User Data Packets . . . . . . . . 15 12.2. Inband Programming of Metadata . . . . . . . . . . . . . 17 - 13. Worked Examples . . . . . . . . . . . . . . . . . . . . . . . 20 + 12.2.1. Loss of Inband Metadata . . . . . . . . . . . . . . 20 + 13. Worked Examples . . . . . . . . . . . . . . . . . . . . . . . 21 14. Implementation Notes . . . . . . . . . . . . . . . . . . . . 24 15. Security Considerations . . . . . . . . . . . . . . . . . . . 25 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 - 18. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27 + 18. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 19.1. Normative References . . . . . . . . . . . . . . . . . . 28 - 19.2. Informative References . . . . . . . . . . . . . . . . . 28 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 + 19.2. Informative References . . . . . . . . . . . . . . . . . 29 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 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 @@ -317,21 +317,21 @@ The use case scenario for this approach is introduced in Section 4.1. As can be seen from Figure 2, the top of the label stack comprises the labels necessary to deliver the packet over the MPLS tunnel between SFFs. Any MPLS encapsulation may be used (i.e., MPLS, MPLS in UDP, MPLS in GRE, and MPLS in VXLAN or GPE), thus the tunnel technology does not need to be MPLS, but that is shown here for simplicity. An entropy label ([RFC6790]) may also be present as described in - Section 11 + Section 11. Under these labels (or other encapsulation) comes a single instance of the basic unit of MPLS label stack for SFC. In addition to the interpretation of the fields of these label stack entries provided in Section 5 the following meanings are applied: SPI Label: The Label field of the SFC Context label stack entry contains the value of the SPI encoded as a 20 bit integer. The semantics of the SPI is exactly as defined in [RFC8300]. Note that an SPI as defined by [RFC8300] can be encoded in 3 octets @@ -427,21 +427,21 @@ This section describes how the basic unit of MPLS label stack for SFC introduced in Section 5 is used when MPLS label stacking is used to carry information about the SFP and SFs to be executed. The use case scenarios for this approach is introduced in Section 4. As can be seen in Figure 3, the top of the label stack comprises the labels necessary to deliver the packet over the MPLS tunnel between SFFs. Any MPLS encapsulation may be used. An entropy label ([RFC6790]) may also be present as described in - Section 11 + Section 11. Under these labels comes one of more instances of the basic unit of MPLS label stack for SFC. In addition to the interpretation of the fields of these label stack entries provided in Section 5 the following meanings are applied: SFC Context Label: The Label field of the SFC Context label stack entry contains a label that delivers SFC context. This label may be used to indicate the SPI encoded as a 20 bit integer using the semantics of the SPI is exactly as defined in [RFC8300] and noting @@ -456,24 +456,24 @@ SF Label: The Label field of the SF label stack entry contains a value that identifies the next SFI to be actioned for the packet. This label may be scoped globally or within the context of the preceding SFC Context Label and comes from the range 16 ... 2^20 - 1. TC: The TC fields are as described in Section 5. S: The S bits are as described in Section 5. - TTL: The TTL fields in the SFC Context label stack entry SF label - stack entry SHOULD be set to 1 as stated in Section 5, but MAY be - set to larger values if the label indicated a forwarding operation - towards the node that hosts the SF. + TTL: The TTL fields in the SFC Context label stack entry and in the + SF label stack entry SHOULD be set to 1 as stated in Section 5, + but MAY be set to larger values if the label indicated a + forwarding operation towards the node that hosts the SF. ------------------- ~ Tunnel Labels ~ +-------------------+ ~ Optional ~ ~ Entropy Label ~ +-------------------+ - - - | SFC Context Label | +-------------------+ Basic unit of MPLS label stack for SFC | SF Label | @@ -863,26 +863,58 @@ Figure 9: The Metadata TLV The fields of this TLV are interpreted as follows: Length: The length of the metadata carried in the Metadata field in octets not including any padding. Metadata Type: The type of the metadata present. Values for this field are taken from the "MD Types" registry maintained by IANA - and defined in [RFC8300]. + and defined in [RFC8300] and encoded with the most significant bit + first. Metadata: The actual metadata formatted as described in whatever document defines the metadata. This field is end-padded with zero to three octets of zeroes to take it up to a four octet boundary. +12.2.1. Loss of Inband Metadata + + Note that inband exchange of metadata is vulnerable to packet loss. + This is both a risk arising from network faults and an attack + vulnerability. + + If packets that arrive at an SFF use an MLI that does not have an + entry in the metadata table, an alarm can be raised and the packet + can be discarded or processed without the metadata according to local + configuration. This provides some long-term mitigation, but is not + an ideal solution. + + Further mitigation to loss of metadata packets can be achieved by + retransmitting them at a configurable interval. This is a relatively + cheap, but only partial solution because there may still be a window + during which the metadata has not been received. + + The concern of lost metadata may be particularly important when the + metadata applicable to a specific MPI is being changed. This could + result in out-of-date metadata being applied to a packet. If this is + a concern, it is RECOMMENDED that a new MPI is used to install a new + entry in the metadata table, and the packets in the flow should be + marked with the equivalent new MLI. + + Finally, if an application that requires metadata is sensitive to + this potential loss or attack, it SHOULD NOT use inband metadata + distribution, but SHOULD rely on control plane or management plane + mechanisms because these approaches can use a more sophisticated + protocol that includes confirmation of delivery, and can perform + verification or inspection of entries in the metadata table. + 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 Service Functions, SFa and SFb, that are accessed through Service @@ -1092,31 +1124,33 @@ 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]. 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. - 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. + 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 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.