RFC 9263

Network Service Header (NSH) Metadata Type 2 Variable-Length Context Headers

📅 published August 2022, from ietf

RFC 9263 is a Standards Track doc from August 2022 (ISSN 2070-1721) called Network Service Header (NSH) Metadata Type 2 Variable-Length Context Headers. Y. Wei (Ed., ZTE Corporation), U. Elzur (Intel), S. Majee (Individual Contributor), C. Pignataro (Cisco), and D. Eastlake 3rd (Futurewei Technologies) wrote it. Its header doesn't list anything it obsoletes or updates, so it's standing on its own 💅

Abstract ✨

Okay so, Service Function Chaining (SFC) uses the Network Service Header (NSH) (RFC 8300) to steer packets and attach context metadata (MD) to each one 🎀 That metadata comes in different types, and MD Type 2 is the flexible one made of Variable-Length Context Headers. This doc defines several of those Context Headers that can be used inside a Service Function Path (SFP). Main character energy, honestly 👑

Status of This Memo

This is an Internet Standards Track document 🌸

It's a product of the Internet Engineering Task Force (IETF), and it reflects consensus from the IETF community. It went through public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 7841 🧚

For the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9263 💖

Copyright (c) 2022 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), as in effect on the publication date. Read those carefully, because they spell out your rights and restrictions for this document. Any Code Components pulled out of this document have to include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Revised BSD License 📜

Table of Contents

   1.  Introduction
   2.  Conventions Used in This Document
     2.1.  Terminology
     2.2.  Requirements Language
   3.  NSH MD Type 2 Format
   4.  NSH MD Type 2 Context Headers
     4.1.  Forwarding Context
     4.2.  Tenant ID
     4.3.  Ingress Network Node Information
     4.4.  Ingress Network Source Interface
     4.5.  Flow ID
     4.6.  Source and/or Destination Groups
     4.7.  Policy ID
   5.  Security Considerations
     5.1.  Forwarding Context
     5.2.  Tenant ID
     5.3.  Ingress Network Node Information
     5.4.  Ingress Node Source Interface
     5.5.  Flow ID
     5.6.  Source and/or Destination Groups
     5.7.  Policy ID
   6.  IANA Considerations
     6.1.  MD Type 2 Context Types
     6.2.  Forwarding Context Types
     6.3.  Flow ID Context Types
   7.  References
     7.1.  Normative References
     7.2.  Informative References
   Acknowledgments
   Authors' Addresses

1. Introduction ✨

So the Network Service Header (NSH) [RFC8300] is the encapsulation for the Service Function Chaining (SFC) architecture [RFC7665]. It gives you three key things:

  1. Service Function Path (SFP) identification
  2. indication of location within an SFP
  3. optional, per-packet metadata (fixed-length or variable-length)

[RFC8300] defines two metadata formats (MD Types), 1 and 2 🦋 MD Type 1 is fixed-length, 16 octets. MD Type 2 is the variable-length context format. This doc defines several common metadata Context Headers for NSH MD Type 2, and they add to the Subscriber Identifier and Performance Policy MD Type 2 Context Headers from [RFC8979] 💜

Not covered here: metadata usage, updating or chaining metadata, and other SFP functions. Those live in [RFC8300] 🙈

2. Conventions Used in This Document ✨

2.1. Terminology

This document uses the terminology from the SFC architecture [RFC7665] and the NSH [RFC8300] 🍓

2.2. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 🔥

3. NSH MD Type 2 Format ✨

An NSH is made of a 4-octet Base Header, a 4-octet Service Path Header, and optional Context Headers. The Base Header tells you which MD Type is in use 🎀

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Ver|O|U|    TTL    |   Length  |U|U|U|U|MD Type| Next Protocol |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: NSH Base Header

For a detailed header description, go check the NSH [RFC8300] 📖

When the Base Header specifies MD Type = 0x2, zero or more Variable-Length Context Headers MAY be added, right after the Service Path Header. Figure 2 shows the format of the Context Header, as defined in Section 2.5.1 of [RFC8300] 🦋

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Metadata Class       |      Type     |U|    Length   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   Variable-Length Metadata                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: NSH Variable-Length Context Headers

4. NSH MD Type 2 Context Headers ✨

[RFC8300] gives Metadata Class 0x0000 the name IETF Base NSH MD Class. In this doc, metadata types are defined for the IETF Base NSH MD Class 💅 The Context Headers in the subsections below are:

  1. Forwarding Context
  2. Tenant ID
  3. Ingress Network Node Information
  4. Ingress Node Source Interface
  5. Flow ID
  6. Source and/or Destination Groups
  7. Policy ID

4.1. Forwarding Context 🌈

This metadata context carries a network forwarding context, which is used for segregation and forwarding scope. The forwarding context can take a few forms depending on the network, like a Virtual eXtensible Local Area Network (VXLAN) / Generic Protocol Extension for VXLAN (VXLAN-GPE) Virtual Network Identifier (VNID), VPN Routing and Forwarding (VRF) identification, or a VLAN 🧚

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Metadata Class = 0x0000    |  Type = 0x04  |U|  Length = 4 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |CT=0x0 |             Reserved          |        VLAN ID        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: VLAN Forwarding Context

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Metadata Class = 0x0000    |  Type = 0x04  |U|  Length = 4 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |CT=0x1 |Resv   |     Service VLAN ID   |    Customer VLAN ID   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 4: QinQ Forwarding Context

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Metadata Class = 0x0000    |  Type = 0x04  |U|  Length = 4 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |CT=0x2 |   Reserved    |              MPLS VPN Label           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 5: MPLS VPN Forwarding Context

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Metadata Class = 0x0000    |  Type = 0x04  |U|  Length = 4 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |CT=0x3 | Resv  |            Virtual Network Identifier         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 6: VNI Forwarding Context

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Metadata Class = 0x0000    |  Type = 0x04  |U|  Length = 8 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |CT=0x4 |             Reserved                                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Session ID                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 7: Session ID Forwarding Context

Here's what each field means 🫶

Context Type (CT): This is a 4-bit field that defines how the Forwarding Context field gets interpreted. Check the IANA considerations in Section 6.2. This document defines these CT values:

  • 0x0: 12-bit VLAN identifier [IEEE.802.1Q_2018]. See Figure 3.
  • 0x1: 24-bit double tagging identifiers. A service VLAN tag followed by a customer VLAN tag [IEEE.802.1Q_2018]. The two VLAN IDs are concatenated and appear in the same order they had in the payload. See Figure 4.
  • 0x2: 20-bit MPLS VPN label [RFC3032] [RFC4364]. See Figure 5.
  • 0x3: 24-bit virtual network identifier (VNI) [RFC8926]. See Figure 6.
  • 0x4: 32-bit Session ID [RFC3931]. This is called Key in GRE [RFC2890]. See Figure 7.
Reserved (Resv): These bits in the context fields MUST be sent as zero and ignored on receipt. 💀

4.2. Tenant ID 🎀

Okay bestie, tenant identification is basically the VIP rope in a multi-tenant environment 🧚 It's how you keep everyone's stuff separated and organized! Orchestration system-generated Tenant IDs are the classic example. This Context Header carries the value of the Tenant ID. Virtual Tenant Network (VTN) [OpenDaylight-VTN] is an application that provides multi-tenant virtual networks on a Software-Defined Networking (SDN) controller, and it's giving main character energy 💅

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Metadata Class = 0x0000    |  Type = 0x05  |U|    Length   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                         Tenant ID                             ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          Figure 8: Tenant ID List

The fields work like this:

  • Length: Indicates the length of the Tenant ID in octets (see Section 2.5.1 of [RFC8300]).
  • Tenant ID: Represents an opaque value pointing to orchestration system-generated Tenant ID. The structure and semantics of this field are specific to the operator's deployment across its operational domain and are specified and assigned by an orchestration function. The specifics of that orchestration-based assignment are outside the scope of this document.

4.3. Ingress Network Node Information ✨

Here's the tea 🫖 This Context Header carries a Node ID of the network node at which the packet entered the SFC-enabled domain. This node will necessarily be a classifier [RFC7665]. In cases where the Service Path Identifier (SPI) identifies the ingress node, this Context Header is superfluous, so you can literally skip it 🙈

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Metadata Class = 0x0000    |  Type = 0x06  |U|   Length    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                        Node ID                                ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 9: Ingress Network Node ID

The fields work like this:

  • Length: Indicates the length of the Node ID in octets (see Section 2.5.1 of [RFC8300]).
  • Node ID: Represents an opaque value of the ingress network Node ID. The structure and semantics of this field are deployment specific. For example, Node ID may be a 4-octet IPv4 address Node ID, a 16-octet IPv6 address Node ID, a 6-octet MAC address, an 8-octet MAC address (64-bit Extended Unique Identifier (EUI-64)), etc.

4.4. Ingress Network Source Interface 🦋

This context identifies the ingress interface of the ingress network node. The l2vlan (135), l3ipvlan (136), ipForward (142), and mpls (166) in [IANAifType] are examples of source interfaces, so you've got options 🌈

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Metadata Class = 0x0000    |  Type = 0x07  |U|    Length   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                     Source Interface                          ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 10: Ingress Network Source Interface

The fields work like this:

  • Length: Indicates the length of the Source Interface in octets (see Section 2.5.1 of [RFC8300]).
  • Source Interface: Represents an opaque value of the identifier of the ingress interface of the ingress network node.

4.5. Flow ID 💜

Flow ID gives you a field in NSH MD Type 2 to label packets belonging to the same flow, so they stick together like best friends 👯‍♀️ For example, [RFC8200] defines the IPv6 Flow Label as Flow ID. Another example is how [RFC6790] defines an entropy label that is generated based on flow information in the MPLS network. Absence of this field or a value of zero denotes that packets have not been labeled with a Flow ID.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Metadata Class = 0x0000    |  Type = 0x08  |U| Length = 4  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |CT=0x0 |   Reserved    |           IPv6 Flow ID                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          Figure 11: IPv6 Flow ID
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Metadata Class = 0x0000    |  Type = 0x08  |U| Length = 4  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |CT=0x1 |   Reserved    |        MPLS entropy label             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 12: MPLS Entropy Label

The fields work like this:

  • Length: Indicates the length of the Flow ID in octets (see Section 2.5.1 of [RFC8300]). For example, the IPv6 Flow Label in [RFC8200] is 20 bits long. An entropy label in the MPLS network in [RFC6790] is also 20 bits long.
  • Context Type (CT): This 4-bit field defines the interpretation of the Flow ID field. Please see the IANA considerations in Section 6.3. This document defines these CT values:
    • 0x0: 20-bit IPv6 Flow Label in [RFC8200]. See Figure 11.
    • 0x1: 20-bit entropy label in the MPLS network in [RFC6790]. See Figure 12.
  • Reserved: These bits in the context fields MUST be sent as zero and ignored on receipt.

4.6. Source and/or Destination Groups 🍓

Intent-based systems can use this data to express the logical grouping of source and/or destination objects. [OpenStack] and [OpenDaylight] provide examples of such a system. Each is expressed as a 32-bit opaque object, so it's all neatly boxed up 🎁

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Metadata Class = 0x0000    |  Type = 0x09  |U|  Length=8   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Source Group                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Destination Group                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 13: Source/Destination Groups

If there is no group information specified for the Source Group or Destination Group field, the field MUST be sent as zero and ignored on receipt.

4.7. Policy ID ✨

Traffic handling policies are often referred to by a system-generated identifier, which the devices then use to look up the policy's content locally. For example, this identifier could be an index to an array, a lookup key, or a database ID. The identifier lets enforcement agents or services look up the content of their part of the policy, so everyone's on the same page 📖

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Metadata Class = 0x0000    |  Type = 0x0A  |U|    Length   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                           Policy ID                           ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                            Figure 14: Policy ID

The fields work like this:

  • Length: Indicates the length of the Policy ID in octets (see Section 2.5.1 of [RFC8300]).
  • Policy ID: Represents an opaque value of the Policy ID.

This Policy ID is a general Policy ID, essentially a key that lets Service Functions (SFs) know which policies to apply to packets. Those policies generally won't have much to do with performance and are more about what specific treatment to apply. It may, for example, select a URL filter data set for a URL filter or select a video transcoding policy in a transcoding SF. The Performance Policy ID in [RFC8979] is described there as having very specific use and, for example, says that fully controlled SFPs would not use it. The Policy ID in this document is for cases not covered by [RFC8979] 💅

5. Security Considerations 🔐

⚠️ Bestie, this part is serious! A misbehaving node from within the SFC-enabled domain may alter the content of the Context Headers, which may lead to service disruption. Such an attack is not unique to the Context Headers defined in this document. Measures discussed in Section 8 of [RFC8300] describe the general security considerations for protecting the NSH. [RFC9145] specifies methods of protecting the integrity of the NSH metadata. If the NSH includes the Message Authentication Code (MAC) and Encrypted Metadata Context Header [RFC9145], the authentication of the packet MUST be verified before using any data. If the verification fails, the receiver MUST stop processing the Variable-Length Context Headers and notify an operator.

The security and privacy considerations for the 7 types of Context Headers specified above are discussed below. Since NSH-ignorant SFs will never see the NSH, even if they are malign, they cannot compromise security or privacy based on the NSH or any of these Context Headers. They could, however, cause compromise based on the rest of the packet. To the extent that any of these headers are included when they would be unneeded or have no effect, they provide a covert channel for the entity adding the Context Header to communicate a limited amount of arbitrary information to downstream entities within the SFC-enabled domain 🕵️‍♀️

5.1. Forwarding Context 🌸

All of the Forwarding Context variants specified in this document (those with CT values between 0 and 4) merely repeat a field that is available in the packet encapsulated by the NSH. These variants repeat that field in the NSH for convenience. Thus, there are no special security or privacy considerations in these cases. Any future new values of CT for the Forwarding Context must specify the security and privacy considerations for those extensions.

5.2. Tenant ID 🦋

The Tenant ID indicates the tenant to which traffic belongs and might be used to tie together and correlate packets for a tenant that some monitoring function could not otherwise group, especially if other possible identifiers were being randomized. As such, it may reduce security by facilitating traffic analysis, but only within the SFC-enabled domain where this Context Header is present in packets. Stay alert, and don't let the tea spill 🫢

5.3. Ingress Network Node Information 🛬

okay so the SFC-enabled domain manager usually runs the initial ingress/classifier node, which means it's potentially aware of whatever this Context Header is carrying 👀. Plus, a lot of the time the SPI in the NSH already identifies the ingress node or narrows it way down 🔍. And honestly? Most of the time, tons of different entities are sending packets into the SFC-enabled domain through that same ingress node 🫶. So in most situations this Context Header is expected to weaken security and privacy only to a minor extent, and only within the SFC-enabled domain 💅.

5.4. Ingress Node Source Interface 🔌

this one is kinda meaningless on its own 🙈 unless the Ingress Network Node Information Context Header is also there. When the node info header shows up, this source interface header gets extra specific: it tells you not just the initial ingress/classifier node but also the port on that node where the data arrived 🎯. So it's more likely to pin down a specific source entity, or at least tighten up the list of possible sources way more than the node header alone can. Which means putting it alongside the node info is potentially a bigger threat to security and privacy than the node header by itself. The lowkey good news? That threat is still constrained to the SFC-enabled domain 🌈.

5.5. Flow ID 🌊

the versions of this Context Header defined in this document just repeat fields that are already available in the packet, so they have no special security or privacy considerations ✨. BUT any future new values of CT for the Flow ID have to specify the security and privacy considerations for those extensions 📝. Future you, please don't forget 😭.

5.6. Source and/or Destination Groups 🧑‍🤝‍🧑

this Context Header gives you extra info that might help identify the source and/or destination of packets 👀. Depending on how granular the groups are, it could either (1) distinguish packets as part of flows from and/or to objects where those flows couldn't otherwise be easily distinguished but look like they're part of one or fewer flows, or (2) group packet flows that are from and/or to an object where those flows couldn't otherwise be easily grouped for analysis or another purpose 🗂️. So the presence of this Context Header with non-zero source and/or destination groups can, within the SFC-enabled domain, erode security and privacy to an extent that depends on the details of the grouping 💀.

5.7. Policy ID 📜

this Context Header carries an identifier that nodes in the SFC-enabled domain can use to look up policy and potentially influence what they do with the packet carrying it ✨. If there are no such decisions about their actions, then the header should not be included 🙅‍♀️. If there ARE such decisions, the information they're based on needs to be included somewhere in the packet. There's no reason for this Context Header to have any security or privacy considerations that wouldn't apply to any other plaintext way of including that same information 🔐. It may also provide additional info to help identify a flow of data for analysis 🦋.

6. IANA Considerations 🎀

6.1. MD Type 2 Context Types 🏷️

IANA has assigned the following types (Table 1) from the "NSH IETF-Assigned Optional Variable-Length Metadata Types" registry available at [IANA-NSH-MD2] 💖.

         +=======+==================================+===========+
         | Value |           Description            | Reference |
         +=======+==================================+===========+
         | 0x04  |        Forwarding Context        | RFC 9263  |
         +-------+----------------------------------+-----------+
         | 0x05  |            Tenant ID             | RFC 9263  |
         +-------+----------------------------------+-----------+
         | 0x06  |     Ingress Network Node ID      | RFC 9263  |
         +-------+----------------------------------+-----------+
         | 0x07  |    Ingress Network Interface     | RFC 9263  |
         +-------+----------------------------------+-----------+
         | 0x08  |             Flow ID              | RFC 9263  |
         +-------+----------------------------------+-----------+
         | 0x09  | Source and/or Destination Groups | RFC 9263  |
         +-------+----------------------------------+-----------+
         | 0x0A  |            Policy ID             | RFC 9263  |
         +-------+----------------------------------+-----------+

                           Table 1: Type Values

6.2. Forwarding Context Types 🧚

IANA has created a new subregistry for "Forwarding Context Types" at [IANA-NSH-MD2] as follows 🌸.

The registration policy is IETF Review.

     +=========+=========================================+===========+
     | Value   |               Description               | Reference |
     +=========+=========================================+===========+
     | 0x0     |          12-bit VLAN identifier         | RFC 9263  |
     +---------+-----------------------------------------+-----------+
     | 0x1     |    24-bit double tagging identifiers    | RFC 9263  |
     +---------+-----------------------------------------+-----------+
     | 0x2     |          20-bit MPLS VPN label          | RFC 9263  |
     +---------+-----------------------------------------+-----------+
     | 0x3     | 24-bit virtual network identifier (VNI) | RFC 9263  |
     +---------+-----------------------------------------+-----------+
     | 0x4     |            32-bit Session ID            | RFC 9263  |
     +---------+-----------------------------------------+-----------+
     | 0x5-0xE |                Unassigned               |           |
     +---------+-----------------------------------------+-----------+
     | 0xF     |                 Reserved                | RFC 9263  |
     +---------+-----------------------------------------+-----------+

                     Table 2: Forwarding Context Types

6.3. Flow ID Context Types 🦋

IANA has created a new subregistry for "Flow ID Context Types" at [IANA-NSH-MD2] as follows 💜.

The registration policy is IETF Review.

    +=========+==========================================+===========+
    | Value   |               Description                | Reference |
    +=========+==========================================+===========+
    | 0x0     |          20-bit IPv6 Flow Label          | RFC 9263  |
    +---------+------------------------------------------+-----------+
    | 0x1     | 20-bit entropy label in the MPLS network | RFC 9263  |
    +---------+------------------------------------------+-----------+
    | 0x2-0xE |                Unassigned                |           |
    +---------+------------------------------------------+-----------+
    | 0xF     |                 Reserved                 | RFC 9263  |
    +---------+------------------------------------------+-----------+

                      Table 3: Flow ID Context Types

7. References 📚

7.1. Normative References 🔗

7.2. Informative References 🌈

Acknowledgments 🫶

the authors would like to thank Paul Quinn, Behcet Sarikaya, Dirk von Hugo, Mohamed Boucadair, Gregory Mirsky, and Joel Halpern for providing invaluable concepts and content for this document 💖✨

Authors' Addresses ✨

okay bestie, time for the squad roll call 💖 these are the humans who wrote this, and here's how to reach each of them 🫶

Yuehua Wei (editor) 🎀 is the editor, so she's the one holding the pen 💅

Yuehua Wei (editor)
ZTE Corporation
No.50, Software Avenue
Nanjing
210012
China
Email: wei.yuehua@zte.com.cn

Uri Elzur 🦋 from Intel 💜

Uri Elzur
Intel
Email: uri.elzur@intel.com

Sumandra Majee 🌸 is listed as an Individual Contributor, which is so iconic, no cap 👑

Sumandra Majee
Individual Contributor
Email: Sum.majee@gmail.com

Carlos Pignataro 🧚 from Cisco 🔥

Carlos Pignataro
Cisco
Email: cpignata@cisco.com

Donald E. Eastlake, 3rd 🌈 from Futurewei Technologies, and yes, the "3rd" is part of the official name 😭

Donald E. Eastlake, 3rd
Futurewei Technologies
2386 Panoramic Circle
Apopka, FL 32703
United States of America
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
📦 where this page comes from