Subscriber and Performance Policy Identifier Context Headers in the Network Service Header (NSH)sarikaya@ieee.orgDeutsche TelekomDeutsche-Telekom-Allee 9DarmstadtD-64295GermanyDirk.von-Hugo@telekom.deOrangeRennes3500Francemohamed.boucadair@orange.comSFCsubscriber policypolicy enforcementsubscriberpolicyquotaidentificationimplicit identificationservice chainservice function chainsfcSFPservice function pathclassification5Gtraffic steeringThis document defines the Subscriber and Performance Policy Identifier Context Headers. These Variable-Length Context Headers can be
carried in the Network Service Header (NSH) and are used to inform Service
Functions (SFs) of subscriber- and performance-related information for the
sake of policy enforcement and appropriate Service Function Chaining (SFC)
operations. The structure of each Context Header and their use and
processing by NSH-aware nodes are described.IntroductionThis document discusses how to inform Service Functions (SFs) about subscriber and service policy
information when required for the sake of policy enforcement within a
single administrative domain. In particular, subscriber-related
information may be required to enforce subscriber-specific SFC-based
traffic policies. However, the information carried in packets may not be
sufficient to unambiguously identify a subscriber.
This document fills
this void by specifying a new Network Service Header (NSH) Context Header to convey and disseminate such
information within the boundaries of a single administrative domain. As
discussed in , the use of obfuscated and
non-persistent identifiers is recommended.Also, traffic steering by means of SFC may be driven, for example, by
Quality of Service (QoS) considerations. Typically, QoS information may
serve as an input for the computation, establishment, and selection of
the Service Function Path (SFP). Furthermore, the dynamic structuring of
Service Function Chains and their subsequent SFPs may be conditioned by
QoS requirements that will affect the identification,
location, and sequencing of SF instances.
Hence, the need arises to provide downstream
SFs with a performance policy identifier in order for them to
appropriately meet the QoS requirements. This document also
specifies a new NSH Context Header () to
convey such policy identifiers.The context information defined in this document can be applicable in
the context of mobile networks (particularly in the 3GPP-defined (S)Gi
interface) .
Typically, because of the widespread use of private IPv4 addresses in
those networks, if the SFs to be invoked are located after a NAT
function, the identification based on the internal IPv4 address is not
possible once the NAT has been crossed. NAT functionality can reside in
a distinct node. For a 4G 3GPP network, that node can be the Packet Data
Network (PDN) Gateway (PGW) as specified in . For a 5G 3GPP network, it can be the User
Plane Function (UPF) facing the external Data Network (DN) . As such, a mechanism to pass the internal
information past the NAT boundary may optimize packet traversal within
an SFC-enabled mobile network domain. Furthermore, some SFs that are not
enabled on the PGW/UPF may require a subscriber identifier to properly
operate (see, for example, those listed in ). It is outside the scope of this document to
include a comprehensive list of deployments that may make use of the
Context Headers defined in the document.Since subscriber identifiers are distinct from those used to identify
a performance policy and given that multiple policies may be associated
with a single subscriber within a Service Function Chain, these
identifiers are carried in distinct Context Headers rather than
being multiplexed in one single Context Header. This approach avoids a
requirement for additional internal structure in the Context Headers to
specify whether an identifier refers to a subscriber or to a policy.This document does not make any assumptions about the structure of
subscriber or performance policy identifiers; each such identifier is
treated as an opaque value. The semantics and validation of these
identifiers are policies local to each SFC-enabled domain. This document
focuses on the data plane behavior. Control plane considerations are
out of the scope.This document adheres to the SFC data plane architecture defined in
. This document assumes the reader is
familiar with .This document assumes the NSH is used exclusively within a single
administrative domain. This document follows the recommendations in
for handling the Context Headers at both
ingress and egress SFC boundary nodes (i.e., to strip the entire NSH,
including Context Headers). Revealing any subscriber-related information
to parties outside the SFC-enabled domain is avoided by design.
Accordingly, the scope for privacy breaches and user tracking is limited
to within the SFC-enabled domain where the NSH is used. It is assumed
that appropriate mechanisms to monitor and audit an SFC-enabled domain
to detect misbehavior and to deter misuse are in place.MTU considerations are discussed in .Conventions and Terminology
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
when, and only when, they appear in all capitals, as shown here.
The reader should be familiar with the terms defined in ."SFC Control Element" refers to a logical entity that instructs one or
more SFC data plane functional elements on how to process packets within
an SFC-enabled domain.Subscriber Identifier NSH Variable-Length Context HeaderSubscriber Identifier is defined as an optional Variable-Length NSH
Context Header. Its structure is shown in .
The fields are described as follows:
Metadata Class:
MUST be set to 0x0 .
Type:
0x00 (see ).
U bit:
Unassigned bit (see ).
Length:
Indicates the length of the Subscriber Identifier, in
bytes (see ).
Subscriber Identifier:
Carries an opaque local identifier that is
assigned to a subscriber by a network operator.While this document does not specify an internal
structure for these identifiers, it also does not provide any
cryptographic protection for them; any internal structure to the
identifier values chosen will thus be visible on the wire if no
secure transport encapsulation is used. Accordingly, in alignment
with , identifier
values SHOULD be obfuscated.
The Subscriber Identifier Context Header is used by SFs
to enforce per-subscriber policies (e.g., resource quota, customized
filtering profile, accounting). To that aim, network operators may rely
on identifiers that are generated from those used in legacy deployments
(e.g., ). Alternatively, network
operators may use identifiers that are associated with customized policy
profiles that are preconfigured on SFs using an out-of-band mechanism.
Such a mechanism can be used to rotate the identifiers, thus allowing for
better unlinkability ().
Such alternative methods may be suboptimal (e.g., scalability issues
induced by maintaining and processing finer granular profiles) or
inadequate for providing some per-subscriber policies. The assessment of
whether a method for defining a subscriber identifier provides the
required functionality and whether
it is compatible with the capabilities of the SFs at
the intended performance level is deployment specific.The classifier and NSH-aware SFs MAY inject a Subscriber Identifier
Context Header as a function of a local policy. This local policy should
indicate the SFP(s) for which the Subscriber Identifier Context Header
will be added. In order to prevent interoperability issues, the type and
format of the identifiers to be injected in a Subscriber Identifier
Context Header should be configured to nodes authorized to inject and
consume such headers. For example, a node can be instructed to insert
such data following a type/set scheme (e.g., node X should inject
subscriber ID type Y). Other schemes may be envisaged.Failures to inject such headers should be logged locally, while a
notification alarm may be sent to a Control Element. The details of
sending notification alarms (i.e., the parameters affecting the
transmission of the notification alarms) might depend on the nature of
the information in the Context Header. Parameters for sending alarms,
such as frequency, thresholds, and content of the alarm, should be
configurable.The default behavior of intermediary NSH-aware nodes is to preserve
Subscriber Identifier Context Headers (i.e., the information can be
passed to next-hop NSH-aware nodes), but local policy may require an
intermediary NSH-aware node to strip a Subscriber Identifier Context
Header after processing it.NSH-aware SFs MUST ignore Context Headers carrying unknown subscriber
identifiers.Local policies at NSH-aware SFs may require running additional
validation checks on the content of these Context Headers (e.g., accepting
only some lengths or types). These policies may also indicate the
behavior to be followed by an NSH-aware SF if the validation checks fail
(e.g., removing the Context Header from the packet). These additional
validation checks are deployment specific. If validation checks fail on
a Subscriber Identifier Context Header, an NSH-aware SF MUST ignore that
Context Header. The event should be logged locally, while a notification
alarm may be sent to a Control Element if the NSH-aware SF is instructed
to do so. For example, an SF will discard Subscriber Identifier
Context Headers conveying identifiers in all formats that are different from the
one the SF is instructed to expect.Multiple Subscriber Identifier Context Headers MAY be present in the
NSH, each carrying a distinct opaque value but all pointing to the same
subscriber. This may be required, e.g., by policy enforcement mechanisms
in a mobile network where some SFs rely on IP addresses as subscriber
identifiers, while others use non-IP-specific identifiers such as those
listed in and . When multiple
Subscriber Identifier Context Headers are present and an SF is
instructed to strip the Subscriber Identifier Context Header, that SF
MUST remove all Subscriber Identifier Context Headers.Performance Policy Identifier NSH Variable-Length Context HeadersDedicated service-specific performance identifiers are defined to
differentiate between services that require specific treatment in order
to exhibit a performance characterized by, e.g., ultra-low latency (ULL)
or ultra-high reliability (UHR). Other policies can be considered when
instantiating a Service Function Chain within an SFC-enabled domain.
They are conveyed in the Performance Policy Identifier Context
Header.The Performance Policy Identifier Context Header is inserted in an NSH packet so that downstream NSH-aware nodes can make use of the performance information for proper selection of suitably distributed SFC paths, SF instances, or applicable policy at SFs. Note that the use of the performance policy identifier is not helpful if the path computation is
centralized and a strict SFP is presented as local policy to SF
Forwarders (SFFs).The Performance Policy Identifier Context Header allows for the distributed
enforcement of a per-service policy such as requiring
an SFP to
only include specific SF instances (e.g., SFs located within the same
Data Center (DC) or those that are exposing the shortest delay from an SFF). Details
of this process are implementation specific. For illustration purposes,
an SFF may retrieve the details of usable SFs based upon the
corresponding performance policy identifier. Typical criteria for
instantiating specific SFs include location, performance, or proximity
considerations. For the particular case of UHR services, the standby
operation of backup capacity or the presence of SFs deployed in
multiple instances may be requested.In an environment characterized by frequent changes of link and path
behavior (for example, due to variable load or availability caused by
propagation conditions on a wireless link), the SFP may have to be
adapted dynamically by on-the-move SFC path and SF instance
selection.Performance Policy Identifier is defined as an optional Variable-Length Context Header. Its structure is shown in .The default behavior of intermediary NSH-aware nodes is to preserve
such Context Headers (i.e., the information 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 to be enforced for a flow. Supplying conflicting policies may
complicate the SFP computation and SF instance location. Corresponding
rules to detect conflicting policies may be provided as a local policy
to the NSH-aware nodes. When such conflict is detected by an NSH-aware
node, the default behavior of the node is to discard the packet and send
a notification alarm to a Control Element.The fields are described as follows:
Metadata Class:
MUST be set to 0x0 .
Type:
0x01 (see ).
U bit:
Unassigned bit (see ).
Length:
Indicates the length of the Performance Policy
Identifier, in bytes (see ).
Performance Policy Identifier:
Represents an opaque value
pointing to a specific performance policy to be enforced. The
structure and semantics of this field are deployment specific.
MTU ConsiderationsAs discussed in , the
SFC architecture prescribes that additional information be added to
packets to:
Identify SFPs. This is typically the NSH Base Header () and Service Path Header ().
Carry metadata such those defined in Sections and .
Steer the traffic along the SFPs: This is realized by means of transport encapsulation.
This added information increases the size of the packet to be carried
along an SFP.Aligned with , it is
RECOMMENDED for network operators to increase the underlying MTU so that
NSH traffic is forwarded within an SFC-enabled domain without
fragmentation. The available underlying MTU should be taken into account
by network operators when providing SFs with the required Context
Headers to be injected per SFP and the size of the data to be carried in
these Context Headers.If the underlying MTU cannot be increased to accommodate the NSH
overhead, network operators may rely upon a transport encapsulation
protocol with the required fragmentation handling. The impact of
activating such feature on SFFs should be carefully assessed by network
operators ().When dealing with MTU issues, network operators should consider the
limitations of various transport encapsulations such as those discussed
in .IANA ConsiderationsIANA has assigned the following types from the
"NSH IETF-Assigned Optional Variable-Length Metadata Types" subregistry (0x0000
IETF Base NSH MD Class) available at:
.
Security ConsiderationsData plane SFC-related security considerations, including privacy,
are discussed in and . In particular, states that attached metadata (i.e.,
Context Headers) should be limited to that necessary for correct
operation of the SFP. indicates that metadata
considerations that operators can take into account when using NSH are
discussed in .As specified in , means to prevent
leaking privacy-related information outside an SFC-enabled domain are
natively supported by the NSH given that the last SFF of an SFP will
systematically remove the NSH (and therefore the identifiers defined in
this specification) before forwarding a packet exiting the SFP.Nodes that are involved in an SFC-enabled domain are assumed to be
trusted (). Discussion of means to check
that only authorized nodes are traversed when a packet is crossing an
SFC-enabled domain is out of scope of this document.Both Subscriber Identifier and Performance Policy Identifier Context Headers
carry opaque data. In particular, the Subscriber Identifier Context Header is locally assigned by a network
provider and can be generated from some of the information that is
already conveyed in the original packets from a host (e.g., internal IP
address) or other information that is collected from various sources
within an SFC-enabled domain (e.g., line identifier). The structure of
the identifiers conveyed in these Context Headers is communicated only
to entitled NSH-aware nodes. Nevertheless, some structures may be easily
inferred from the headers if trivial structures are used (e.g., IP
addresses). As persistent identifiers facilitate tracking over time, the
use of indirect and non-persistent identification is thus
RECOMMENDED.Moreover, the presence of multiple Subscriber Identifier Context
Headers in the same NSH allows a misbehaving node from within the
SFC-enabled domain to bind these identifiers to the same subscriber.
This can be used to track that subscriber more effectively.
The use of non-persistent (e.g., regularly randomized) identifiers as
well as the removal of the Subscriber Identifier Context Headers from
the NSH by the last SF making use of such headers soften this issue
(see "data minimization" discussed in ).
Such behavior is especially strongly recommended in case no
encryption is enabled.A misbehaving node from within the SFC-enabled domain may alter the
content of Subscriber Identifier and Performance Policy Identifier 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 are to be followed. A mechanism for
NSH integrity is specified in .If no secure transport encapsulation is enabled, the use of trivial
subscriber identifier structures, together with the presence of specific
SFs in a Service Function Chain, may reveal sensitive information to
every on-path device. Also, operational staff in
teams managing these
devices could gain access to such user privacy-affecting data.
Such
disclosure can be a violation of legal requirements because such
information should be available to very few network operator personnel.
Furthermore, access to subscriber data usually requires specific access
privilege levels. To maintain that protection, an SF keeping operational
logs should not log the content of Subscriber and Performance Policy
Identifier Context Headers unless the SF actually uses the content of these headers
for its operation. As discussed in , subscriber-identifying information should be
obfuscated, and, if an operator deems 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 . This
mechanism can be considered by network operators when enhanced SF-to-SF
security protection of NSH metadata is required (e.g., to protect against
compromised SFFs).Some events are logged locally with notification alerts sent by
NSH-aware nodes to a Control Element. These events SHOULD be rate
limited.ReferencesNormative ReferencesInformative ReferencesGeneral Packet Radio Service (GPRS) enhancements for Evolved
Universal Terrestrial Radio Access Network (E-UTRAN) access, Release 163GPPSystem architecture for the 5G System (5GS), Release 163GPPAcknowledgementsComments from on a previous draft version and from are appreciated.Contributions and review by , ,
, , , , , , and are thankfully
acknowledged.Many thanks to for the secdir review.Thanks to , , , , and
for the IESG review.Special thanks to for the careful review and
suggestions that enhanced this specification.