RFC 8979

Subscriber and Performance Policy Identifier Context Headers in the Network Service Header (NSH)

📅 published February 2021, from ietf

Subscriber and Performance Policy Identifier Context Headers in the Network Service Header (NSH) ✨

Okay bestie, welcome to RFC 8979!! 🎀 This one is all about how we can tell Service Functions (SFs) who a subscriber is and what performance policy applies, without the packet itself giving the game away. It's giving "carry the info along for the ride" energy 🦋

Here's the title block tea ☕:

  • Authors: B. Sarikaya (Huawei is not listed here, that's not the vibe, lol), D. von Hugo (Deutsche Telekom), and M. Boucadair (Orange). Iconic trio 💜
  • Category: Standards Track, so this is an official Internet Standard-track document 👑
  • Date: February 2021 📅
  • Obsoletes / Updates: This one is not listed as obsoleting or updating anything, so it's a fresh start 🌸

Also, the document's ISSN is 2070-1721, which is just the official ID for the RFC series 🧚

Let's get into it 💅

Abstract ✨

Okay so the big idea: this doc defines the Subscriber and Performance Policy Identifier Context Headers. These are Variable-Length Context Headers that ride inside the Network Service Header (NSH) 🎀 They tell Service Functions (SFs) about subscriber info and performance info, so SFs can enforce policy and do the right Service Function Chaining (SFC) operations. The doc also explains the structure of each Context Header and how NSH-aware nodes use and process them 🫶

Status of This Memo ✨

Quick legal-ish bit but still important 💖 This is an Internet Standards Track document. It's a product of the Internet Engineering Task Force (IETF), it reflects the consensus of the IETF community, got public review, and was approved by the Internet Engineering Steering Group (IESG) 🔥

If you want the deeper scoop on Internet Standards, check Section 2 of RFC 7841 📖

For the current status, any errata, or to send feedback, head to https://www.rfc-editor.org/info/rfc8979 🌈

Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. 💜

This doc 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, bestie, they spell out your rights and restrictions 🙈

Also, any Code Components pulled out of this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty as described in that license 💅

Table of Contents 🎀

  • 1. Introduction
  • 2. Conventions and Terminology
  • 3. Subscriber Identifier NSH Variable-Length Context Header
  • 4. Performance Policy Identifier NSH Variable-Length Context Headers
  • 5. MTU Considerations
  • 6. IANA Considerations
  • 7. Security Considerations
  • 8. References
    • 8.1. Normative References
    • 8.2. Informative References
  • Acknowledgements
  • Authors' Addresses

1. Introduction 🦋

Okay this section sets the scene 🌸 The doc talks about how to tell Service Functions (SFs) [RFC7665] about subscriber and service policy info, but only when it's actually needed for policy enforcement inside a single administrative domain 💅

Subscriber info might be required to enforce subscriber-specific SFC-based traffic policies. The catch? The info in the packets may not be enough to uniquely identify a subscriber 😭 So this doc fills that gap by specifying a new Network Service Header (NSH) [RFC8300] Context Header to carry and spread that info, but only within one administrative domain 🫶 Also, we recommend using obfuscated and non-persistent identifiers, more on that in Section 3 ✨

Traffic steering with SFC can also be driven by Quality of Service (QoS) considerations 🌈 QoS info can feed into computing, setting up, and picking the Service Function Path (SFP). Plus, how Service Function Chains and their SFPs get structured can depend on QoS needs, which affects the identification, location, and sequencing of SF instances 🔥 So downstream SFs need a performance policy identifier to meet those QoS needs properly. This doc also defines a new NSH Context Header (Section 4) to carry those policy identifiers 💖

This info can be useful in mobile networks, especially the 3GPP-defined (S)Gi interface [CASE-MOBILITY] 📱 Mobile networks use lots of private IPv4 addresses, so if the SFs you want are placed after a NAT function, you can't identify things by the internal IPv4 address anymore once the NAT has been crossed 😭 The NAT can live in a separate node. In a 4G 3GPP network, that node can be the Packet Data Network (PDN) Gateway (PGW) specified in [TS23401]. In a 5G 3GPP network, it can be the User Plane Function (UPF) facing the external Data Network (DN) [TS23501] 🦋 So a way to pass the internal info across the NAT boundary can help packets traverse the SFC-enabled mobile network domain more efficiently ✨ Also, some SFs that aren't enabled on the PGW/UPF may need a subscriber identifier to work properly (examples are listed in [RFC8371]) 💜 The doc doesn't try to list every deployment that could use these Context Headers, because that's out of scope 🙈

Here's a key design choice 🎀 Subscriber identifiers are different from performance policy identifiers, and one subscriber can have multiple policies in a Service Function Chain. So the two identifiers go in separate Context Headers instead of being mashed into one. That way you don't need extra internal structure to say whether an identifier is for a subscriber or a policy 🫶

The doc doesn't assume anything about how subscriber or performance policy identifiers are structured. Each one is treated as an opaque value 🔐 What they mean and how they're validated are policies local to each SFC-enabled domain. This doc only focuses on the data plane behavior. Control plane stuff is out of scope 🌸

This doc follows the SFC data plane architecture from [RFC7665], and it assumes you already know [RFC8300] 💅

It also assumes NSH is used exclusively within a single administrative domain ✨ Following the [RFC8300] recommendations, ingress and egress SFC boundary nodes strip the entire NSH, Context Headers included 🧚 Subscriber info is never revealed to parties outside the SFC-enabled domain, by design 💖 So the risk of privacy breaches and user tracking stays inside the SFC-enabled domain where NSH is used. The doc assumes there are mechanisms in place to monitor and audit that domain, to catch misbehavior and deter misuse 🔥

MTU considerations are covered in Section 5 🦋

2. Conventions and Terminology 🎀

Okay, the key words: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this doc are interpreted as described in BCP 14 [RFC2119] [RFC8174], but only when they appear in ALL CAPS like shown here 💅

You should be familiar with the terms defined in [RFC7665] 🌸

SFC Control Element means a logical entity that tells one or more SFC data plane functional elements how to process packets inside an SFC-enabled domain ✨

That's the end of part 1, bestie! 💜 More parts are coming, so stay tuned 🧚

3. Subscriber Identifier NSH Variable-Length Context Header 🎀

okay so the Subscriber Identifier is an optional Variable-Length NSH Context Header 💖 bestie, here's what it looks like, the layout is in Figure 1 🦋

    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   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                      Subscriber Identifier                    ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 1: Subscriber Identifier Variable-Length Context Header

so here's the breakdown 🌸

  • Metadata Class: MUST be set to 0x0 [RFC8300] 💅
  • Type: 0x00 (see Section 6) ✨
  • U bit: the Unassigned bit (see Section 2.5.1 of [RFC8300]) 🫶
  • Length: how long the Subscriber Identifier is, in bytes (see Section 2.5.1 of [RFC8300]) 🍓
  • Subscriber Identifier: an opaque local identifier that a network operator assigns to a subscriber 🧚
⚠️ okay this part is serious, bestie 😭 The spec doesn't define an internal structure for these identifiers, and it also doesn't give them any cryptographic protection 💀 So whatever structure you pick is visible on the wire if no secure transport encapsulation is used. That's why, in line with Section 8.2.2 of [RFC8300], identifier values SHOULD be obfuscated 🙈

the Subscriber Identifier Context Header is how SFs enforce per-subscriber policies (think resource quota, a customized filtering profile, or accounting) 💜 operators can reuse identifiers generated from legacy deployments (e.g., Section 3.3 of [CASE-MOBILITY]) 🌈 or they can use identifiers tied to customized policy profiles that are preconfigured on SFs out-of-band ✨ rotating those identifiers gives you better unlinkability (Section 3.2 of [RFC6973]) 🔥 the alternatives can be suboptimal though (scalability issues from maintaining and processing finer-grained profiles 😩) or inadequate for some per-subscriber policies 🥺 whether a method works and fits the SFs at the intended performance level is deployment specific, so it's up to you 🦋

the classifier and NSH-aware SFs MAY inject a Subscriber Identifier Context Header based on a local policy 💖 that local policy SHOULD say which SFP(s) get the header ✨ to avoid interoperability issues, the type and format of the identifiers should be configured on the nodes that are authorized to inject and consume them 🎀 for example, node X could be told to inject subscriber ID type Y (a type/set scheme) 🌸 other schemes may be envisaged too 🧚

if injecting a header fails, it SHOULD be logged locally, and a notification alarm may be sent to a Control Element 😬 the details of those alarms might depend on what the Context Header carries 💅 things like frequency, thresholds, and alarm content SHOULD be configurable 🍓

by default, intermediary NSH-aware nodes preserve Subscriber Identifier Context Headers (so the info can go on to the next-hop NSH-aware nodes) 💜 but local policy may tell an intermediary to strip one after processing it 🫶

NSH-aware SFs MUST ignore Context Headers carrying unknown subscriber identifiers 🙅‍♀️

local policies at NSH-aware SFs may require extra validation checks on these headers (e.g., only accepting some lengths or types) 🔍 they may also say what the SF does when validation fails (e.g., removing the header from the packet) 🗑️ these extra checks are deployment specific 🌈 if validation fails on a Subscriber Identifier Context Header, an NSH-aware SF MUST ignore that Context Header 🛑 the event SHOULD be logged locally, and a notification alarm may be sent to a Control Element if the SF is told to do that 📣 for example, an SF will discard Subscriber Identifier Context Headers in any format other than the one it's instructed to expect 💀

multiple Subscriber Identifier Context Headers MAY be present in the NSH, each with a distinct opaque value but all pointing to the same subscriber 👑 this can be needed, e.g., by policy enforcement in a mobile network where some SFs use IP addresses as subscriber identifiers while others use non-IP-specific identifiers like those in [RFC8371] and Section 3.3.2 of [CASE-MOBILITY] 🌸 when multiple headers are present and an SF is told to strip them, that SF MUST remove all Subscriber Identifier Context Headers 🧹

4. Performance Policy Identifier NSH Variable-Length Context Headers ⭐

okay so there are dedicated service-specific performance identifiers 🚀 they tell apart services that need special treatment to perform a certain way, like ultra-low latency (ULL) or ultra-high reliability (UHR) 💖 other policies can also be considered when you set up a Service Function Chain in an SFC-enabled domain ✨ these are carried in the Performance Policy Identifier Context Header 🎀

downstream NSH-aware nodes can use the Performance Policy Identifier Context Header in an NSH packet to pick suitably distributed SFC paths, SF instances, or policy at SFs 🦋 note that it's not helpful if path computation is centralized and a strict SFP is handed to SF Forwarders (SFFs) as local policy 🙈

this header lets you enforce a per-service policy in a distributed way 🌈 like requiring an SFP to include only specific SF instances (e.g., SFs in the same Data Center (DC) or the ones with the shortest delay from an SFF) 🍓 how that works is implementation specific 🧚 for illustration, an SFF might look up the usable SFs based on the performance policy identifier 🔍 typical criteria for picking SFs are location, performance, or proximity 📍 for UHR services, standby backup capacity or SFs deployed in multiple instances may be requested 🛟

in an environment where link and path behavior changes often (say, variable load or availability from propagation conditions on a wireless link) 📡 the SFP may need to adapt dynamically through on-the-move SFC path and SF instance selection 🏃‍♀️

Performance Policy Identifier is an optional Variable-Length Context Header 💅 its structure is in Figure 2 ✨

by default, intermediary NSH-aware nodes preserve these Context Headers (the info can be passed to next-hop NSH-aware nodes) 🫶 but local policy may require an intermediary NSH-aware node to strip one Context Header after processing it 🗑️

multiple Performance Policy Identifier Context Headers MAY be present in the NSH, each carrying an opaque value for a distinct policy that needs enforcing for a flow 💜 supplying conflicting policies may complicate SFP computation and SF instance location 😵 rules to detect conflicting policies may be given as local policy to NSH-aware nodes 📜 when a node detects such a conflict, its default behavior is to discard the packet and send a notification alarm to a Control Element 🚨

    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   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                     Performance Policy Identifier             ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 2: Performance Policy Identifier Variable-Length Context
                                Header

the breakdown 🌸

  • Metadata Class: MUST be set to 0x0 [RFC8300] 💖
  • Type: 0x01 (see Section 6) ✨
  • U bit: the Unassigned bit (see Section 2.5.1 of [RFC8300]) 🎀
  • Length: how long the Performance Policy Identifier is, in bytes (see Section 2.5.1 of [RFC8300]) 🦋
  • Performance Policy Identifier: an opaque value pointing to a specific performance policy to be enforced 🌈 its structure and semantics are deployment specific 🧚

5. MTU Considerations 🌊

okay so as discussed in Section 5.6 of [RFC7665], the SFC architecture says extra info gets added to packets to 🫧

  • Identify SFPs: typically the NSH Base Header (Section 2.2 of [RFC8300]) and Service Path Header (Section 2.3 of [RFC8300]) 🗺️
  • Carry metadata such as those defined in Sections 3 and 4 🍓
  • Steer the traffic along the SFPs: done with transport encapsulation 🚂

all that extra info makes packets bigger as they travel along an SFP 📦

aligned with Section 5 of [RFC8300], network operators are RECOMMENDED to increase the underlying MTU so NSH traffic gets forwarded within an SFC-enabled domain without fragmentation 🙌 operators should also keep the available underlying MTU in mind when they give SFs the Context Headers to inject per SFP and how big the data in those headers is 📏

if the underlying MTU can't be increased to fit the NSH overhead, operators may rely on a transport encapsulation protocol with the required fragmentation handling 🧩 operators should carefully assess how turning that on affects SFFs (Section 5.6 of [RFC7665]) 🔎

when dealing with MTU issues, operators should consider the limitations of various transport encapsulations, like the ones discussed in [INTAREA-TUNNELS] 🫶✨

6. IANA Considerations ✨

IANA has assigned the following types from the "NSH IETF-Assigned Optional Variable-Length Metadata Types" subregistry (0x0000 IETF Base NSH MD Class) available at: https://www.iana.org/assignments/nsh. 📋

        +=======+===============================+===========+
        | Value | Description                   | Reference |
        +=======+===============================+===========+
        | 0x00  | Subscriber Identifier         | [RFC8979] |
        +-------+-------------------------------+-----------+
        | 0x01  | Performance Policy Identifier | [RFC8979] |
        +-------+-------------------------------+-----------+

            Table 1: NSH IETF-Assigned Optional Variable-
                   Length Metadata Types Additions

7. Security Considerations 🔐

okay bestie, this section is the serious one, so let's go 🫶

Data plane SFC-related security considerations, including privacy, are covered in Section 6 of [RFC7665] and Section 8 of [RFC8300]. Section 8.2.2 of [RFC8300] says attached metadata (aka Context Headers) should be limited to what's necessary for the SFP to operate correctly 💅. That same section also points to [RFC8165] for the metadata considerations operators can think about when they use NSH.

As [RFC8300] specifies, the NSH already natively supports ways to stop privacy-related info from leaking outside an SFC-enabled domain 🦋. The last SFF of an SFP always removes the NSH (and therefore the identifiers defined in this spec) before a packet leaves the SFP, so it's gone before it exits.

Nodes involved in an SFC-enabled domain are assumed to be trusted (Section 1.1 of [RFC8300]) 🌸. How to check that only authorized nodes get traversed when a packet crosses an SFC-enabled domain is out of scope for this document, so that one's a different story 🙈.

Both Subscriber Identifier and Performance Policy Identifier Context Headers carry opaque data 🎀. The Subscriber Identifier Context Header is assigned locally by a network provider, and it can be built from stuff that's already in the original packets from a host (like an internal IP address), or from other info collected from various places in an SFC-enabled domain (like a line identifier) 💜. The structure of these identifiers is only shared with entitled NSH-aware nodes. BUT, some structures can be super easy to infer from the headers if they're trivial (IP addresses, I'm looking at you 👀). Since persistent identifiers make tracking over time way easier, indirect and non-persistent identification is RECOMMENDED 🍓.

Also, having multiple Subscriber Identifier Context Headers in the same NSH lets a misbehaving node inside the SFC-enabled domain link those identifiers to the same subscriber 😭. That makes tracking that subscriber way more effective, which is so not it. Using non-persistent identifiers (like ones that get randomized regularly), and removing the Subscriber Identifier Context Headers from the NSH by the last SF that uses them, helps soften this issue (see "data minimization" in Section 3 of [RFC8165]) ✨. This behavior is especially strongly recommended when no encryption is enabled.

A misbehaving node inside the SFC-enabled domain can also change the content of Subscriber Identifier and Performance Policy Identifier Context Headers, which could cause service disruption 💀. This kind of attack isn't unique to the Context Headers defined here, so the measures in Section 8 of [RFC8300] are to be followed. A mechanism for NSH integrity is specified in [NSH-INTEGRITY] 🔥.

If no secure transport encapsulation is enabled, using trivial subscriber identifier structures together with specific SFs in a Service Function Chain can reveal sensitive info to every on-path device 🚨. Operational staff on the teams managing those devices could also get access to user privacy-affecting data. That kind of disclosure can break legal requirements, because this info should only be available to a very small number of network operator personnel 🙅‍♀️. Access to subscriber data also usually needs specific access privilege levels. To keep that protection in place, an SF that keeps operational logs should not log the content of Subscriber and Performance Policy Identifier Context Headers unless the SF actually uses that content for its operation 🫣. As discussed in Section 8.2.2 of [RFC8300], subscriber-identifying info should be obfuscated, and if an operator decides cryptographic integrity protection is needed, security features in the transport encapsulation protocol (such as IPsec) must be used 🔒. A mechanism for encrypting sensitive NSH data is specified in [NSH-INTEGRITY]. Network operators can consider it when they need enhanced SF-to-SF security protection of NSH metadata (for example, to protect against compromised SFFs) 🛡️.

Some events get logged locally, with notification alerts sent by NSH-aware nodes to a Control Element. These events SHOULD be rate limited ⏱️.

8. References 📚

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

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

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

8.2. Informative References

[CASE-MOBILITY]
           Haeffner, W., Napper, J., Stiemerling, M., Lopez, D. R.,
           and J. Uttaro, "Service Function Chaining Use Cases in
           Mobile Networks", Work in Progress, Internet-Draft, draft-
           ietf-sfc-use-case-mobility-09, 1 January 2019,
           <https://tools.ietf.org/html/draft-ietf-sfc-use-case-
           mobility-09>.

[INTAREA-TUNNELS]
           Touch, J. and M. Townsley, "IP Tunnels in the Internet
           Architecture", Work in Progress, Internet-Draft, draft-
           ietf-intarea-tunnels-10, 12 September 2019,
           <https://tools.ietf.org/html/draft-ietf-intarea-tunnels-
           10>.

[NSH-INTEGRITY]
           Boucadair, M., Reddy.K, T., and D. Wing, "Integrity
           Protection for the Network Service Header (NSH) and
           Encryption of Sensitive Context Headers", Work in
           Progress, Internet-Draft, draft-ietf-sfc-nsh-integrity-03,
           22 January 2021, <https://tools.ietf.org/html/draft-ietf-
           sfc-nsh-integrity-03>.

[RFC6973]  Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
           Morris, J., Hansen, M., and R. Smith, "Privacy
           Considerations for Internet Protocols", RFC 6973,
           DOI 10.17487/RFC6973, July 2013,
           <https://www.rfc-editor.org/info/rfc6973>.

[RFC8165]  Hardie, T., "Design Considerations for Metadata
           Insertion", RFC 8165, DOI 10.17487/RFC8165, May 2017,
           <https://www.rfc-editor.org/info/rfc8165>.

[RFC8371]  Perkins, C. and V. Devarapalli, "Mobile Node Identifier
           Types for MIPv6", RFC 8371, DOI 10.17487/RFC8371, July
           2018, <https://www.rfc-editor.org/info/rfc8371>.

[TS23401]  3GPP, "General Packet Radio Service (GPRS) enhancements
           for Evolved Universal Terrestrial Radio Access Network
           (E-UTRAN) access, Release 16", Version 16.5.0, TS 23.401,
           December 2019.

[TS23501]  3GPP, "System architecture for the 5G System (5GS),
           Release 16", Version 16.3.0, TS 23.501, December 2019.

Acknowledgements 💖

Huge thanks to Joel Halpern for the comments on a previous draft version, and to Carlos Bernardos too 🥰.

Big shoutout to Christian Jacquenet, Danny Lachos, Debashish Purkayastha, Christian Esteve Rothenberg, Kyle Larose, Donald Eastlake, Qin Wu, Shunsuke Homma, and Greg Mirsky for their contributions and review 🙌.

Many thanks to Robert Sparks for the secdir review 🧚.

Thanks to Barry Leiba, Erik Kline, Éric Vyncke, Robert Wilton, and Magnus Westerlund for the IESG review ⭐.

Special thanks to Benjamin Kaduk for the careful review and suggestions that made this spec even better 👑✨.

Authors' Addresses 🦋

Behcet Sarikaya

Email: sarikaya@ieee.org


Dirk von Hugo
Deutsche Telekom
Deutsche-Telekom-Allee 9
D-64295 Darmstadt
Germany

Email: Dirk.von-Hugo@telekom.de


Mohamed Boucadair
Orange
3500 Rennes
France

Email: mohamed.boucadair@orange.com
📦 where this page comes from