MPLS Network Actions (MNA) Framework

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 7 October 2024.¶

Copyright Notice

Copyright (c) 2024 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

This document specifies an architectural framework for the MPLS Network Actions (MNA) technologies. MNA technologies are used to indicate actions for Label Switched Paths (LSPs) and/or MPLS packets and to transfer data needed for these actions.¶

The document provides the foundation for the development of a common set of network actions and information elements supporting additional operational models and capabilities of MPLS networks. Some of these actions are defined in existing MPLS specifications, while others require extensions to existing specifications to meet the requirements found in [I-D.ietf-mpls-mna-requirements].¶

MPLS forwarding actions are instructions to MPLS routers to apply additional actions when forwarding a packet. These might include load-balancing a packet given its entropy, whether or not to perform fast-reroute on a failure, and whether or not a packet has metadata relevant to the forwarding actions along the path.¶

This document generalizes the concept of MPLS "forwarding actions" into "network actions" to include any action that an MPLS router is requested to take on the packet. That includes any MPLS forwarding action, but may include other operations (such as security functions, OAM procedures, etc.) that are not directly related to forwarding of the packet.¶

MNA technologies may redefine the semantics of the Label, Traffic Class (TC), and Time to Live (TTL) fields in an MPLS Label Stack Entry (LSE) within a NAS.¶

2. Structure

An MNA solution specifies one or more network actions to apply to an MPLS packet. These network actions and their ancillary data may be carried in sub-stacks within the MPLS label stack and/or post-stack data. A solution must specify where in the label stack the network actions sub-stacks occur, if and how frequently they should be replicated within the label stack, and how the network action sub-stack and post-stack data are encoded.¶

Processing of the label stack past the top of stack LSE was first introduced with the Entropy Label. [RFC6790]¶

A network action sub-stack contains:¶

• Network Action Sub-Stack Indicator (NSI): The first LSE in the NAS contains a special purpose label, called the MNA label, which is used to indicate the start of a network action sub-stack.¶

• Network Action Indicators (NAI): Optionally, a set of indicators that describes the set of network actions. If the set of indicators is not in the sub-stack, a solution could encode them in post-stack data. A network action is said to be present if there is an indicator in the packet that invokes the action.¶

• In-Stack Data (ISD): A set of zero or more LSEs that carry ancillary data for the network actions that are present. Network action indicators are not considered ancillary data.¶

Each network action present in the network action sub-stack may have zero or more LSEs of in-stack data. The ordering of the in-stack data LSEs corresponds to the ordering of the network action indicators. The encoding of the in-stack data, if any, for a network action must be specified in the document that defines the network action.¶

Certain network actions may also specify that data is carried after the label stack. This is called post-stack data. The encoding of the post-stack data, if any, for a network action must be specified in the document that defines the network action. If multiple network actions are present and have post-stack data, the ordering of their post-stack data corresponds to the ordering of the network action indicators.¶

A solution must specify the order that network actions are to be applied to the packet.¶

3. Encoding

Several possible ways to encode NAIs have been proposed. In this section, we enumerate the possibilities and some considerations for the various alternatives.¶

When network actions are carried in the MPLS label stack, then regardless of their type, they are represented by a set of LSEs termed a network action sub-stack (NAS). An NAS consists of a special label, optionally followed by LSEs that specify which network actions are to be performed on the packet and the in-stack ancillary data for each indicated network action. Different network actions may be placed together in one NAS or may be carried in different sub-stacks.¶

[I-D.ietf-mpls-mna-requirements] requires that a solution not add unnecessary LSEs to the sub-stack (Section 3.1, requirement 9). Accordingly, solutions should also make efficient use of the bits within the sub-stack (except the S-bit), as inefficient use of the bits could result in the addition of unnecessary LSEs.¶

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |               Label                   | TC  |S|      TTL      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                Label:  Label value, 20 bits
                TC:     Traffic Class, 3 bits
                S:      Bottom of Stack, 1 bit
                TTL:    Time To Live

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                Label                  |x x x|S|x x x x x x x x|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                Label:  Label value, 20 bits
                x:      Bit available for use in solution definition
                S:      Bottom of Stack, 1 bit

4. Semantics

For MNA to be consistent across implementations and predictable in operational environments, its semantics need to be entirely predictable. An MNA solution MUST specify a deterministic order for processing each of the Network Actions in a packet. Each network action must specify how it interacts with all other previously defined network actions. Private network actions are network actions that are not publicly documented. Private network actions MUST be included in the ordering of network actions, but the interactions of private actions with other actions are outside of the scope of this document.¶

5. Definition of a Network Action

Network actions should be defined in a document and must contain:¶

• Name: The name of the network action.¶

• Network Action Indicator: The bit position or opcode that indicates that the network action is active.¶

• Scope: The document should specify which nodes should perform the network action as described in Section 2.1.¶

• State: The document should specify if the network action can modify state in the network, and if so, the state that may be modified and its side effects.¶

• Required/Optional: The document should specify whether a node is required to perform the network action.¶

• In-Stack Data: The number of LSEs of in-stack data, if any, and its encoding. If this is of a variable length, then the solution must specify how an implementation can determine this length without implementing the network action.¶

• Post-Stack Data: The encoding of post-stack data, if any. If this is of a variable length, then the solution must specify how an implementation can determine this length without implementing the network action.¶

A solution should create an IANA registry for network actions.¶

6. Management Considerations

Network operators will need to be cognizant of which network actions are supported by which nodes and will need to ensure that this is signaled. Some solutions may require network-wide configuration to synchronize the use of the labels that indicate the start of an NAS. Solution documents must make clear what management considerations apply to the solutions they are describing. Solutions documents must describe mechanisms for performing network diagnostics in the presence of MNAs.¶

7. Security Considerations

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.¶

Central to the security of MPLS networks is operational security of the network; something that operators of MPLS networks are well versed in. The deployment of link-level security (e.g., [MACsec]) prevents the covert acquisition of the label stack for an attack. This is particularly important in the case of a network deploying MNA, because the MNA information may be sensitive. Thus the confidentiality and authentication achieved through the use of link-level security is particularly advantageous.¶

Some additional proposals to add encryption to the MPLS forwarding plane have been suggested [I-D.ietf-mpls-opportunistic-encrypt], but no mechanisms have been agreed upon at the time of publication of this document. [I-D.ietf-mpls-opportunistic-encrypt] offers hop-by- hop security that encrypts the label stack and is functionally equivalent to that provided by [MACsec]. Alternatively, it also offers end-to-end encryption of the MPLS payload with no cryptographic integrity protection of the MPLS headers.¶

Particular care would be needed when introducing any end-to-end security mechanism to allow an in-stack MNA solution that needed to employ on-path modification of the MNA data, or where post-stack MNA data needed to be examined on-path.¶

A cornerstone of MPLS security is to protect the network from processing MPLS labels originated outside the network.¶

Operators have considerable experience in excluding MPLS-encoded packets at the network boundaries for example, by excluding all MPLS packets and all packets that are revealed to be carrying an MPLS packet as the payload of IP tunnels. Where such packets are accepted into an MPLS network from an untrusted third party, non-MPLS packets are immediately encapsulated in an MPLS label stack specified by the MPLS network operator and MPLS packets have additional label stack entries imported as specified by the MPLS network operator. Thus, it is difficult for an attacker to pass a MPLS-encoded packet into a network or to present any instructions to the network forwarding system.¶

Within a single well-managed domain, an adjacent domain may be considered to be trusted provided that it is sufficiently shielded from third-party traffic ingress and third-party traffic observation. In such a situation, no new security vulnerabilities are introduced by MNA.¶

In some inter-domain applications (including carrier's carrier) where a first network's MPLS traffic is encapsulated directly over a second MPLS network by simply pushing additional MPLS LSEs, the contents of the first network's payload and label stack may be visible to the forwarders in the second network. Historically this has been benign, and indeed useful for ECMP. However, if the first network's traffic has MNA information this may be exposed to MNA-capable forwarders causing unpredictable behavior or modification of the customer MPLS label stack or MPLS payload. This is an increased vulnerability introduced by MNA that SHOULD be addressed in any MNA solution.¶

Several mitigations are available to an operator:¶

a) Reject all incoming packets containing MNA information that do not come from a trusted network. Note that it may be acceptable to accept and process MNA information from a trusted network.¶

b) Fully encapsulate the inbound packet in a new additional MPLS label stack such that the forwarder finds a Bottom of Stack (BoS) bit imposed by the carrier network and only finds MNA information added by the carrier network.¶

A mitigation that we reject as unsafe is having the ingress LSR push sufficient additional labels such that any MNA information received in packets entering the network from a third-party network is made inaccessible due to it being below the RLD. This is unsafe in the presence of an overly conservative RLD value which can result in the third-party MNA information becoming visible to and acted on by an MNA forwarder in the carrier network.¶

8. IANA Considerations

This document requests that IANA allocate a code point from the "IGP MSD-Types" registry in the "Interior Gateway Protocol (IGP) Parameters" namespace for "Readable Label Depth", referencing this document.¶

9. Acknowledgements

This document is the result of work started in MPLS Open Design Team, with participation by the MPLS, PALS, and DETNET working groups.¶

The authors would like to thank Adrian Farrel for his contributions and to John Drake, Toerless Eckert, and Jie Dong for their comments.¶

Authors' Addresses