<?xml version="1.0" encoding="US-ASCII"?> encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?> "rfc2629-xhtml.ent">

<rfc category="std" xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-sfc-serviceid-header-14"
     ipr="trust200902">
number="8979" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" category="std"
consensus="true" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true"
version="3">

  <front>
    <title abbrev="NSH Subscriber/Performance abbrev="Subscriber/Performance Policy TLVs">Service Function
    Chaining: Subscriber Headers">Subscriber and Performance Policy Identification Variable-Length Identifier Context Headers in the Network Service Header (NSH) Context Headers</title> (NSH)</title>
    <seriesInfo name="RFC" value="8979"/>
    <author fullname="Behcet Sarikaya" initials="B.S." initials="B." surname="Sarikaya">
      <organization></organization>
      <organization/>
      <address>
        <postal>
          <street></street>

          <street></street>

          <city></city>

          <region></region>

          <code></code>
          <street/>
          <street/>
          <city/>
          <region/>
          <code/>
        </postal>
        <email>sarikaya@ieee.org</email>
      </address>
    </author>
    <author fullname="Dirk von Hugo" initials="D.H." initials="D." surname="von Hugo">
      <organization abbrev="Deutsche Telekom">Deutsche Telekom</organization>
      <address>
        <postal>
          <street>Deutsche-Telekom-Allee 9</street>

          <city>D-64295 Darmstadt</city>

          <code></code>
          <city>Darmstadt</city>
          <code>D-64295</code>
          <country>Germany</country>
        </postal>

        <phone></phone>
        <phone/>
        <email>Dirk.von-Hugo@telekom.de</email>
      </address>
    </author>
    <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
      <organization>Orange</organization>
      <address>
        <postal>
          <street></street>

          <street></street>

          <city>Rennes 3500</city>

          <region></region>

          <code></code>
          <street/>
          <street/>
          <city>Rennes</city>
          <region/>
          <code>3500</code>
          <country>France</country>
        </postal>

        <phone></phone>
        <phone/>
        <email>mohamed.boucadair@orange.com</email>
      </address>
    </author>
    <date year="2020" year="2021" month="February" />
    <workgroup>SFC</workgroup>
    <keyword>subscriber policy</keyword>
    <keyword>policy enforcement</keyword>
    <keyword>subscriber</keyword>
    <keyword>policy</keyword>
    <keyword>quota</keyword>
    <keyword>identification</keyword>
    <keyword>implicit identification</keyword>
    <keyword>service chain</keyword>
    <keyword>service function chain</keyword>
    <keyword>sfc</keyword>
    <keyword>SFP</keyword>
    <keyword>service function path</keyword>
    <keyword>classification</keyword>
    <keyword>5G</keyword>
    <keyword>traffic steering</keyword>
    <abstract>
      <t>This document defines two the Subscriber and Performance Policy Identifier Context Headers.  These Variable-Length Context Headers that can be
      carried in the Network Service Header: the Subscriber Header (NSH) and Performance
      Policy Identifiers. These Context Headers are used to inform Service
      Functions (SFs) of subscriber- and performance-related information for the
      sake of policy enforcement and appropriate service function chaining Service Function Chaining (SFC)
      operations. The structure of each Context Header, Header and their use and
      processing by NSH-aware nodes, nodes are described.</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>This document discusses how to inform Service Functions (SFs) <xref
      target="RFC7665"></xref> target="RFC7665" format="default"/> about subscriber and service policy
      information,
      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) <xref
      target="RFC8300"></xref> target="RFC8300" format="default"/> Context Header to convey and disseminate such
      information within the boundaries of a single administrative domain. As
      discussed in <xref target="solutions"></xref>, target="solutions" format="default"/>, the use of obfuscated and
      non-persistent identifiers is recommended.</t>
      <t>Also, traffic steering by means of SFC may be driven, for example, by
      QoS (Quality
      Quality of Service) 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
      Service Function Chains and their subsequent SFPs may be conditioned by
      QoS requirements that will affect SF instance(s) the identification,
      location, and sequencing. 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 service requirements. This document also
      specifies a new NSH Context Header (<xref target="sol2"></xref>) target="sol2" format="default"/>) to
      convey such policy identifiers.</t>
      <t>The context information defined in this document can be applicable in
      the context of mobile networks (particularly, (particularly in the 3GPP defined 3GPP-defined (S)Gi
      Interface)
      interface) <xref target="I-D.ietf-sfc-use-case-mobility"></xref>. target="I-D.ietf-sfc-use-case-mobility" format="default"/>.
      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 <xref
      target="TS23401"></xref>. target="TS23401" format="default"/>. For a 5G 3GPP network, it can be the User
      Plane Function (UPF) facing the external Data Network (DN) <xref
      target="TS23501"></xref>. target="TS23501" format="default"/>. As such, a mechanism to pass the internal
      information past the NAT boundary may optimise 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 <xref
      target="RFC8371"></xref>). target="RFC8371" format="default"/>). It is outside the scope of this document to
      include a comprehensive list of deployments which that may make use of the
      Context Headers defined in the document.</t>
      <t>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, Service Function Chain, these
      identifiers are carried in distinct Context Headers rather than
      multiplexing them
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.</t>
      <t>This document does not make any assumption 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 behaviour. behavior. Control plane considerations are
      out of the scope.</t>
      <t>This document adheres to the SFC data plane architecture defined in
      <xref target="RFC7665"></xref>. target="RFC7665" format="default"/>. This document assumes the reader is
      familiar with <xref target="RFC8300"></xref>.</t> target="RFC8300" format="default"/>.</t>
      <t>This document assumes the NSH is used exclusively within a single
      administrative domain. This document follows the recommendations in
      <xref target="RFC8300"></xref> target="RFC8300" format="default"/> 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.</t>
      <t>MTU considerations are discussed in <xref target="MTU"></xref>.</t> target="MTU" format="default"/>.</t>
    </section>
    <section title="Conventions numbered="true" toc="default">
      <name>Conventions and Terminology">
      <t>The Terminology</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and
      "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC2119"></xref><xref target="RFC8174"></xref> target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>

      <t>The reader should be familiar with the terms defined in <xref
      target="RFC7665"></xref>.</t>

      <t>SFC target="RFC7665" format="default"/>.</t>
      <t>"SFC Control Element 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.</t>
    </section>
    <section anchor="solutions"
             title="Subscriber Identification numbered="true" toc="default">
      <name>Subscriber Identifier NSH Variable-Length Context Header"> Header</name>
      <t>Subscriber Identifier is defined as an optional variable-length Variable-Length NSH
      Context Header. Its structure is shown in <xref target="arch7"></xref>. target="arch7" format="default"/>.
      </t>
      <figure anchor="arch7"
          title="Subscriber anchor="arch7">
        <name>Subscriber Identifier Variable-Length Context Header">
          <artwork><![CDATA[ Header</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
    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                    ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure></t>
      </figure>
      <t>The description of the fields is are described as follows:</t>

      <t><list style="symbols">
          <t>Metadata Class: MUST
      <dl spacing="normal">
        <dt>Metadata Class:</dt><dd><bcp14>MUST</bcp14> be set to 0x0 <xref
          target="RFC8300"></xref>.</t>

          <t>Type: TBD1 (See <xref target="IANA"></xref>).</t>

          <t>U bit: Unassigned target="RFC8300" format="default"/>.</dd>
        <dt>Type:</dt><dd>0x00 (see <xref target="IANA" format="default"/>).</dd>
        <dt>U bit:</dt><dd>Unassigned bit (see Section 2.5.1 of <xref
          target="RFC8300"></xref>).</t>

          <t>Length: Indicates target="RFC8300" sectionFormat="of" section="2.5.1"/>).</dd>
        <dt>Length:</dt><dd>Indicates the length of the Subscriber Identifier, in
          bytes (see Section 2.5.1 of <xref target="RFC8300"></xref>).</t>

          <t>Subscriber Identifier: Carries target="RFC8300" sectionFormat="of" section="2.5.1"/>).</dd>

          <dt>Subscriber Identifier:</dt><dd><t>Carries an opaque local identifier that is
          assigned to a subscriber by a network operator.<vspace
          blankLines="1" />While operator.</t>
          <t>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 Section 8.2.2 of <xref target="RFC8300"></xref>, target="RFC8300" sectionFormat="of" section="8.2.2"/>, identifier
          values SHOULD <bcp14>SHOULD</bcp14> be obfuscated.</t>
        </list></t>
        </dd>
      </dl>
      <t>The Subscriber Identifier Context Header is used by service functions 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., Section 3.3 of <xref
      target="I-D.ietf-sfc-use-case-mobility"></xref>). target="I-D.ietf-sfc-use-case-mobility" sectionFormat="of" section="3.3"/>). Alternatively, network
      operators may use identifiers that are associated with customized policy
      profiles that are preconfigured on SFs using an out of band out-of-band mechanism.
      Such a mechanism can be used to rotate the identifiers allowing identifiers, thus allowing for
      better unlinkability (Section 3.2 of <xref target="RFC6973"></xref>). (<xref target="RFC6973" sectionFormat="of" section="3.2"/>).
      Such alternative methods may be suboptimal (e.g., scalability issues
      induced by maintaining and processing finer granular profiles) or
      inadequate to provide 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 to at
      the intended performance level, level is deployment specific.</t>
      <t>The classifier and NSH-aware SFs MAY <bcp14>MAY</bcp14> 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.</t>
      <t>Failures to inject such headers should be logged locally 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.</t>
      <t>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 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.</t>
      <t>NSH-aware SFs MUST <bcp14>MUST</bcp14> ignore Context Headers carrying unknown subscriber
      identifiers.</t>
      <t>Local policies at NSH-aware SFs may require running additional
      validation checks on the content of these Context Headers (e.g., accept 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., remove removing the Context Header from the packet). These additional
      validation checks are deployment-specific. deployment specific. If validation checks fail on
      a Subscriber Identifier Context Header, an NSH-aware SF MUST <bcp14>MUST</bcp14> ignore that
      Context Header. The event should be logged locally 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.</t>
      <t>Multiple Subscriber Identifier Context Headers MAY <bcp14>MAY</bcp14> 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,
      identifiers, while others use non-IP specific non-IP-specific identifiers such as those
      listed in <xref target="RFC8371"></xref> target="RFC8371" format="default"/> and Section 3.3.2 of <xref
      target="I-D.ietf-sfc-use-case-mobility"></xref>. target="I-D.ietf-sfc-use-case-mobility" sectionFormat="of" section="3.3.2"/>. When multiple
      subscriber identifier
      Subscriber Identifier Context Headers are present and an SF is
      instructed to strip the Subscriber Identifier Context Header, that SF
      MUST
      <bcp14>MUST</bcp14> remove all Subscriber Identifier Context Headers.</t>
    </section>
    <section anchor="sol2"
             title="Performance numbered="true" toc="default">
      <name>Performance Policy Identification Identifier NSH Variable-Length Context Headers"> Headers</name>
      <t>Dedicated 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 Service Function Chain within an SFC-enabled domain.
      They are conveyed in the Performance Policy Identifier Context
      Header.</t>

      <t>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 path selection, paths, SF
      instance selection, instances, or applicable policy selection at SFs. Note that the use of the
      Performance Policy Identifier 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).</t>
      <t>The Performance Policy Identifier Context Header allows for the distributed
      enforcement of a per-service policy such as requiring
      a service function path
      an SFP to
      only include specific SFs SF instances (e.g., SFs located within the same
      DC
      Data Center (DC) or those that are exposing the shortest delay from an SFF). Details
      of this process are implementation-specific. 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 stand-by standby
      operation of back-up backup capacity or the presence of SFs deployed in
      multiple instances may be requested.</t>
      <t>In an environment characterised characterized by frequent changes of link and path
      behaviour, for example
      behavior (for example, due to variable load or availability caused by
      propagation conditions on a wireless link, link), the SFP may have to be
      adapted dynamically by on-the-move SFC path and SF instance
      selection.</t>
      <t>Performance Policy Identifier is defined as an optional variable
      length Variable-Length Context Header. Its structure is shown in <xref
      target="arch9"></xref>.</t> target="arch9" format="default"/>.</t>
      <t>The default behavior of intermediary NSH-aware nodes is to preserve
      such Context Headers (i.e., the information can be passed to next hop next-hop
      NSH-aware nodes), but local policy may require an intermediary NSH-aware
      node to strip one Context Header after processing it.</t>
      <t>Multiple Performance Policy Identifier Context Headers MAY <bcp14>MAY</bcp14> be present
      in the NSH, each carrying an opaque value for a distinct policy that
      need
      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.</t>
      <figure anchor="arch9"
              title="Performance anchor="arch9">
        <name>Performance Policy Identifier Variable-Length Context Header">
        <artwork><![CDATA[ Header</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
    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             ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
      </figure>
      <t>The description of the fields is are described as follows:<list style="symbols">
          <t>Metadata Class: MUST follows:</t>
      <dl spacing="normal">
        <dt>Metadata Class:</dt><dd><bcp14>MUST</bcp14> be set to 0x0 <xref
          target="RFC8300"></xref>.</t>

          <t>Type: TBD2 (See <xref target="IANA"></xref>).</t>

          <t>U bit: Unassigned target="RFC8300" format="default"/>.</dd>
        <dt>Type:</dt><dd>0x01 (see <xref target="IANA" format="default"/>).</dd>
        <dt>U bit:</dt><dd>Unassigned bit (see Section 2.5.1 of <xref
          target="RFC8300"></xref>).</t>

          <t>Length: Indicates target="RFC8300" sectionFormat="of" section="2.5.1"/>).</dd>
        <dt>Length:</dt><dd>Indicates the length of the Performance Policy
          Identifier, in bytes (see Section 2.5.1 of <xref
          target="RFC8300"></xref>).</t>

          <t>Performance target="RFC8300" sectionFormat="of" section="2.5.1"/>).</dd>
        <dt>Performance Policy Identifier: Represents Identifier:</dt><dd>Represents an opaque value
          pointing to a specific performance policy to be enforced. The
          structure and semantics of this field are deployment-specific.</t>
        </list></t> deployment specific.</dd>
      </dl>
    </section>
    <section anchor="MTU" title="MTU Considerations"> numbered="true" toc="default">
      <name>MTU Considerations</name>
      <t>As discussed in Section 5.6 of <xref target="RFC7665"></xref>, target="RFC7665" sectionFormat="of" section="5.6"/>, the
      SFC architecture prescribes that additional information be added to
      packets to: <list style="symbols">
          <t>Identify SFPs: this </t>
      <ul spacing="normal">
        <li>Identify SFPs. This is typically the NSH Base Header (Section 2.2
          of <xref target="RFC8300"></xref>) (<xref target="RFC8300" sectionFormat="of" section="2.2"/>) and Service Path Header (Section
          2.3 of <xref target="RFC8300"></xref>).</t>

          <t>Carry (<xref target="RFC8300" sectionFormat="of" section="2.3"/>).</li>
        <li>Carry metadata such those defined in Sections <xref format="counter" target="solutions"></xref> target="solutions"/> and <xref format="counter" target="sol2"></xref>.</t>

          <t>Steer target="sol2"/>.</li>
        <li>Steer the traffic along the SFPs: This is realized by means of transport encapsulation.</t>
        </list></t> encapsulation.</li>
      </ul>
      <t>This added information increases the size of the packet to be carried
      along an SFP.</t>
      <t>Aligned with Section 5 of <xref target="RFC8300"></xref>, target="RFC8300" sectionFormat="of" section="5"/>, it is
      RECOMMENDED
      <bcp14>RECOMMENDED</bcp14> 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.</t>
      <t>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 (Section 5.6 of <xref target="RFC7665"></xref>).</t> (<xref target="RFC7665" sectionFormat="of" section="5.6"/>).</t>
      <t>When dealing with MTU issues, network operators should consider the
      limitations of various transport encapsulations such as those discussed
      in <xref target="I-D.ietf-intarea-tunnels"></xref>.</t> target="I-D.ietf-intarea-tunnels" format="default"/>.</t>
    </section>
    <section anchor="IANA" title="IANA Considerations ">
      <t>This document requests IANA to assign numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>IANA has assigned the following types from the
      "NSH IETF- Assigned IETF-Assigned Optional Variable-Length Metadata Types" subregistry (0x0000
      IETF Base NSH MD Class) registry available at:
      https://www.iana.org/assignments/nsh/nsh.xhtml#optional-variable-length-metadata-types.</t>

      <texttable>
        <ttcol>Value</ttcol>

        <ttcol>Description</ttcol>

        <ttcol>Reference</ttcol>

        <c>TBD1</c>

        <c>Subscriber Identifier</c>

        <c>[ThisDocument]</c>

        <c>TBD2</c>

        <c>Performance
      <eref brackets="angle" target="https://www.iana.org/assignments/nsh"/>.</t>
      <table align="center">
	<name>NSH IETF-Assigned Optional Variable-Length Metadata Types Additions</name>
        <thead>
          <tr>
            <th align="left">Value</th>
            <th align="left">Description</th>
            <th align="left">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">0x00</td>
            <td align="left">Subscriber Identifier</td>
            <td align="left">[RFC8979]</td>
          </tr>
          <tr>
            <td align="left">0x01</td>
            <td align="left">Performance Policy Identifier</c>

        <c>[ThisDocument]</c>
      </texttable> Identifier</td>
            <td align="left">[RFC8979]</td>
          </tr>
        </tbody>
      </table>
    </section>
    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>Data plane SFC-related security considerations, including privacy,
      are discussed in Section 6 of <xref target="RFC7665"></xref> target="RFC7665" sectionFormat="of" section="6"/> and Section
      8 of <xref target="RFC8300"></xref>. target="RFC8300" sectionFormat="of" section="8"/>. In particular, Section 8.2.2 of <xref target="RFC8300"></xref> target="RFC8300" sectionFormat="of" section="8.2.2"/> states that attached metadata (i.e.,
      Context Headers) should be limited to that necessary for correct
      operation of the SFP. That section <xref target="RFC8300" sectionFormat="of" section="8.2.2"/> indicates that metadata
      considerations that operators can take into account when using NSH are
      discussed in <xref target="RFC8165"></xref>.</t> target="RFC8165" format="default"/>.</t>
      <t>As specified in <xref target="RFC8300"></xref>, target="RFC8300" format="default"/>, 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.</t>
      <t>Nodes that are involved in an SFC-enabled domain are assumed to be
      trusted (Section 1.1 of <xref target="RFC8300"> (<xref target="RFC8300" sectionFormat="of" section="1.1"> </xref>). Means Discussion of means to check
      that only authorized nodes are traversed when a packet is crossing an
      SFC-enabled domain are is out of scope of this document.</t>

      <t>Both Subscriber Identifier and Performance Policy Identifier Context Headers
      carry opaque data. This identifier 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.</t>
      <bcp14>RECOMMENDED</bcp14>.</t>

      <t>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 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 Section 3 of [RFC8165]). <xref
target="RFC8165" sectionFormat="of" section="3"/>).
      Such behavior is especially strongly recommended, recommended in case no
      encryption is enabled.</t>
      <t>A misbehaving node from within the SFC-enabled domain may alter the
      content of Subscriber Identifier and Performance Policy Identifier Context Headers 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 <xref target="RFC8300"></xref>
target="RFC8300" sectionFormat="of" section="8"/> are to be followed. A mechanism for
      NSH integrity is specified in <xref
      target="I-D.ietf-sfc-nsh-integrity"></xref>.</t> target="I-D.ietf-sfc-nsh-integrity" format="default"/>.</t>
      <t>If no secure transport encapsulation is enabled, the use of trivial
      subscriber identifier structures structures, together with the presence of specific
      SFs in a service function chain Service Function Chain, may reveal sensitive information to
      every on-path device. Also Also, operational staff in
teams managing these
devices could gain access to such user privacy affecting 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 a Subscriber and Performance Policy
      Identifier Context Headers unless the SF actually uses the content of these headers
      for its operation. As discussed in Section 8.2.2 of <xref
      target="RFC8300"></xref>, target="RFC8300" sectionFormat="of" section="8.2.2"/>, subscriber-identifying information should be
      obfuscated
      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 <xref target="I-D.ietf-sfc-nsh-integrity"></xref>. target="I-D.ietf-sfc-nsh-integrity" format="default"/>. 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).</t>
      <t>Some events are logged locally with notification alerts sent by
      NSH-aware nodes to a Control Element. These events SHOULD <bcp14>SHOULD</bcp14> be rate
      limited.</t>
    </section>
  </middle>
  <back>

<displayreference target="I-D.ietf-intarea-tunnels" to="INTAREA-TUNNELS"/>
<displayreference target="I-D.ietf-sfc-use-case-mobility" to="CASE-MOBILITY"/>
<displayreference target="I-D.ietf-sfc-nsh-integrity" to="NSH-INTEGRITY"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8300.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7665.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8371.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6973.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8165.xml"/>

        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-intarea-tunnels.xml"/>

        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-sfc-use-case-mobility.xml"/>

        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-sfc-nsh-integrity-03.xml"/>

        <reference anchor="TS23401">
          <front>
            <title>General Packet Radio Service (GPRS) enhancements for Evolved
          Universal Terrestrial Radio Access Network (E-UTRAN) access, Release 16</title>
            <author>
              <organization>3GPP</organization>
            </author>
            <date month="December" year="2019"/>
          </front>
<seriesInfo name="Version" value="16.5.0"/>
<seriesInfo name="TS" value="23.401"/>
        </reference>

        <reference anchor="TS23501">
          <front>
            <title>System architecture for the 5G System (5GS), Release 16</title>
            <author>
              <organization>3GPP</organization>
            </author>
            <date month="December" year="2019"/>
          </front>
<seriesInfo name="Version" value="16.3.0"/>
<seriesInfo name="TS" value="23.501"/>
        </reference>
      </references>
    </references>
    <section title="Acknowledgements"> numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>Comments from Joel Halpern <contact fullname="Joel Halpern"/> on a previous draft version and by Carlos
      Bernardos from <contact fullname="Carlos
      Bernardos"/> are appreciated.</t>
      <t>Contributions and review by Christian Jacquenet, Danny Lachos,
      Debashish Purkayastha, Christian <contact fullname="Christian Jacquenet"/>, <contact fullname="Danny Lachos"/>,
      <contact fullname="Debashish Purkayastha"/>, <contact fullname="Christian Esteve Rothenberg, Kyle Larose, Donald
      Eastlake, Qin Wu, Shunsuke Homma, and Greg Mirsky Rothenberg"/>, <contact fullname="Kyle Larose"/>, <contact fullname="Donald
      Eastlake"/>, <contact fullname="Qin Wu"/>, <contact fullname="Shunsuke Homma"/>, and <contact fullname="Greg Mirsky"/> are thankfully
      acknowledged.</t>
      <t>Many thanks to Robert Sparks <contact fullname="Robert Sparks"/> for the secdir review.</t>
      <t>Thanks to Barry Leiba, Erik Kline, Eric Vyncke, Robert Wilton, and
      Magnus Westerlund <contact fullname="Barry Leiba"/>, <contact fullname="Erik Kline"/>, <contact fullname="Éric Vyncke"/>, <contact fullname="Robert Wilton"/>, and
      <contact fullname="Magnus Westerlund"/> for the IESG review.</t>
      <t>Special thanks to Benjamin Kaduk <contact fullname="Benjamin Kaduk"/> for the careful review and
      suggestions that enhanced this specification.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

      <?rfc include='reference.RFC.8300'?>

      <?rfc include='reference.RFC.7665'?>

      <?rfc include='reference.RFC.8174'?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.RFC.8371'?>

      <?rfc include='reference.RFC.6973'?>

      <?rfc include='reference.RFC.8165'?>

      <?rfc include='reference.I-D.ietf-intarea-tunnels'?>

      <?rfc include='reference.I-D.ietf-sfc-use-case-mobility'?>

      <?rfc include='reference.I-D.ietf-sfc-nsh-integrity'?>

      <reference anchor="TS23401">
        <front>
          <title>General Packet Radio Service (GPRS) enhancements for Evolved
          Universal Terrestrial Radio Access Network (E-UTRAN) access,</title>

          <author>
            <organization>3GPP 23.401 16.5.0</organization>
          </author>

          <date month="December" year="2019" />
        </front>
      </reference>

      <reference anchor="TS23501">
        <front>
          <title>System architecture for the 5G System (5GS),</title>

          <author>
            <organization>3GPP 23.501 16.3.0</organization>
          </author>

          <date month="December" year="2019" />
        </front>
      </reference>
    </references>
  </back>
</rfc>