SFC                                                          B. Sarikaya
Internet-Draft
Intended status: Standards Track                             D. von Hugo
Expires: June 14, 2021                                  Deutsche Telekom
                                                            M. Boucadair
                                                                  Orange
                                                       December 11, 2020


      Service Function Chaining: Subscriber and Performance Policy
  Identification Variable-Length Network Service Header (NSH) Context
                                Headers
                   draft-ietf-sfc-serviceid-header-14

Abstract

   This document defines two Variable-Length Context Headers that can be
   carried in the Network Service Header: the Subscriber and Performance
   Policy Identifiers.  These Context Headers are used to inform Service
   Functions of subscriber- and performance-related information for the
   sake of policy enforcement and appropriate service function chaining
   operations.  The structure of each Context Header, and their use and
   processing by NSH-aware nodes, are described.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on June 14, 2021.

Copyright Notice

   Copyright (c) 2020 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



Sarikaya, et al.          Expires June 14, 2021                 [Page 1]


Internet-Draft   NSH Subscriber/Performance Policy TLVs    December 2020


   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Terminology . . . . . . . . . . . . . . . . .   4
   3.  Subscriber Identification NSH Variable-Length Context Header    4
   4.  Performance Policy Identification NSH Variable-Length Context
       Headers . . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   5.  MTU Considerations  . . . . . . . . . . . . . . . . . . . . .   8
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   This document discusses how to inform Service Functions (SFs)
   [RFC7665] 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)
   [RFC8300] Context Header to convey and disseminate such information
   within the boundaries of a single administrative domain.  As
   discussed in Section 3, the use of obfuscated and non-persistent
   identifiers is recommended.

   Also, traffic steering by means of SFC may be driven, for example, by
   QoS (Quality of Service) 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 SF
   instance(s) identification, location, and sequencing.  Hence, the
   need arises to provide downstream SFs with a performance policy
   identifier in order for them to appropriately meet the QoS service



Sarikaya, et al.          Expires June 14, 2021                 [Page 2]


Internet-Draft   NSH Subscriber/Performance Policy TLVs    December 2020


   requirements.  This document also specifies a new NSH Context Header
   (Section 4) 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) [I-D.ietf-sfc-use-case-mobility].  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 [TS23401].  For a 5G
   3GPP network, it can be the User Plane Function (UPF) facing the
   external Data Network (DN) [TS23501].  As such, a mechanism to pass
   the internal information past the NAT boundary may optimise 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
   [RFC8371]).  It is outside the scope of this document to include a
   comprehensive list of deployments which 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
   multiplexing them 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 assumption 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.  Control plane
   considerations are out of the scope.

   This document adheres to the SFC data plane architecture defined in
   [RFC7665].  This document assumes the reader is familiar with
   [RFC8300].

   This document assumes the NSH is used exclusively within a single
   administrative domain.  This document follows the recommendations in
   [RFC8300] 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,



Sarikaya, et al.          Expires June 14, 2021                 [Page 3]


Internet-Draft   NSH Subscriber/Performance Policy TLVs    December 2020


   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 Section 5.

2.  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 [RFC2119][RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   The reader should be familiar with the terms defined in [RFC7665].

   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.

3.  Subscriber Identification NSH Variable-Length Context Header

   Subscriber Identifier is defined as an optional variable-length NSH
   Context Header.  Its structure is shown 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

   The description of the fields is as follows:

   o  Metadata Class: MUST be set to 0x0 [RFC8300].

   o  Type: TBD1 (See Section 6).

   o  U bit: Unassigned bit (see Section 2.5.1 of [RFC8300]).

   o  Length: Indicates the length of the Subscriber Identifier, in
      bytes (see Section 2.5.1 of [RFC8300]).




Sarikaya, et al.          Expires June 14, 2021                 [Page 4]


Internet-Draft   NSH Subscriber/Performance Policy TLVs    December 2020


   o  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
      Section 8.2.2 of [RFC8300], identifier values SHOULD be
      obfuscated.

   The Subscriber Identifier Context Header is used by service functions
   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 [I-D.ietf-sfc-use-case-mobility]).
   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 mechanism can be used to
   rotate the identifiers allowing thus for better unlinkability
   (Section 3.2 of [RFC6973]).  Such alternative methods may be
   suboptimal (e.g., scalability issues induced by maintaining and
   processing finer granular profiles) or inadequate to provide 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 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.





Sarikaya, et al.          Expires June 14, 2021                 [Page 5]


Internet-Draft   NSH Subscriber/Performance Policy TLVs    December 2020


   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.,
   accept 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 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 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 [RFC8371] and Section 3.3.2 of
   [I-D.ietf-sfc-use-case-mobility].  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.

4.  Performance Policy Identification NSH Variable-Length Context
    Headers

   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 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 distributed SFC path selection, SF
   instance selection, or policy selection at SFs.  Note that the use of



Sarikaya, et al.          Expires June 14, 2021                 [Page 6]


Internet-Draft   NSH Subscriber/Performance Policy TLVs    December 2020


   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 allows for the distributed
   enforcement of a per-service policy such as requiring a service
   function path to only include specific SFs instances (e.g., SFs
   located within the same 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 stand-by operation of back-up
   capacity or the presence of SFs deployed in multiple instances may be
   requested.

   In an environment characterised by frequent changes of link and path
   behaviour, 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 Figure 2.

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











Sarikaya, et al.          Expires June 14, 2021                 [Page 7]


Internet-Draft   NSH Subscriber/Performance Policy TLVs    December 2020


       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 description of the fields is as follows:

   o  Metadata Class: MUST be set to 0x0 [RFC8300].

   o  Type: TBD2 (See Section 6).

   o  U bit: Unassigned bit (see Section 2.5.1 of [RFC8300]).

   o  Length: Indicates the length of the Performance Policy Identifier,
      in bytes (see Section 2.5.1 of [RFC8300]).

   o  Performance Policy Identifier: Represents an opaque value pointing
      to specific performance policy to be enforced.  The structure and
      semantics of this field are deployment-specific.

5.  MTU Considerations

   As discussed in Section 5.6 of [RFC7665], the SFC architecture
   prescribes that additional information be added to packets to:

   o  Identify SFPs: this is typically the NSH Base Header (Section 2.2
      of [RFC8300]) and Service Path Header (Section 2.3 of [RFC8300]).

   o  Carry metadata such those defined in Sections 3 and 4.

   o  Steer the traffic along the SFPs: transport encapsulation.

   This added information increases the size of the packet to be carried
   along an SFP.

   Aligned with Section 5 of [RFC8300], 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




Sarikaya, et al.          Expires June 14, 2021                 [Page 8]


Internet-Draft   NSH Subscriber/Performance Policy TLVs    December 2020


   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 (Section 5.6 of [RFC7665]).

   When dealing with MTU issues, network operators should consider the
   limitations of various transport encapsulations such as those
   discussed in [I-D.ietf-intarea-tunnels].

6.  IANA Considerations

   This document requests IANA to assign the following types from the
   "NSH IETF- Assigned Optional Variable-Length Metadata Types" (0x0000
   IETF Base NSH MD Class) registry available at:
   https://www.iana.org/assignments/nsh/nsh.xhtml#optional-variable-
   length-metadata-types.

        +-------+-------------------------------+----------------+
        | Value | Description                   | Reference      |
        +-------+-------------------------------+----------------+
        | TBD1  | Subscriber Identifier         | [ThisDocument] |
        | TBD2  | Performance Policy Identifier | [ThisDocument] |
        +-------+-------------------------------+----------------+

7.  Security Considerations

   Data plane SFC-related security considerations, including privacy,
   are discussed in Section 6 of [RFC7665] and Section 8 of [RFC8300].
   In particular, Section 8.2.2 of [RFC8300] states that attached
   metadata (i.e., Context Headers) should be limited to that necessary
   for correct operation of the SFP.  That section indicates that
   metadata considerations that operators can take into account when
   using NSH are discussed in [RFC8165].

   As specified in [RFC8300], 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 (Section 1.1 of [RFC8300]).  Means to check that only
   authorized nodes are traversed when a packet is crossing an SFC-
   enabled domain are out of scope of this document.



Sarikaya, et al.          Expires June 14, 2021                 [Page 9]


Internet-Draft   NSH Subscriber/Performance Policy TLVs    December 2020


   Both Subscriber Identifier and Performance Policy Context Headers
   carry opaque data.  This identifier 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 Section 3 of [RFC8165]).  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 Context
   Headers which may lead to service disruption.  Such attack is not
   unique to the Context Headers defined in this document; measures
   discussed in Section 8 of [RFC8300] are to be followed.  A mechanism
   for NSH integrity is specified in [I-D.ietf-sfc-nsh-integrity].

   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 a Subscriber and Performance Policy Context Headers unless the SF
   actually uses the content of these headers for its operation.  As
   discussed in Section 8.2.2 of [RFC8300], subscriber-identifying
   information should be obfuscated and, if an operator deems
   cryptographic integrity protection needed, security features in the
   transport encapsulation protocol (such as IPsec) must be used.  A
   mechanism for encrypting sensitive NSH data is specified in



Sarikaya, et al.          Expires June 14, 2021                [Page 10]


Internet-Draft   NSH Subscriber/Performance Policy TLVs    December 2020


   [I-D.ietf-sfc-nsh-integrity].  This mechanism can be considered by
   network operators when enhanced SF-to-SF security protection of NSH
   metadata is required (e.g., 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.

8.  Acknowledgements

   Comments from Joel Halpern on a previous version and by Carlos
   Bernardos are appreciated.

   Contributions and review by Christian Jacquenet, Danny Lachos,
   Debashish Purkayastha, Christian Esteve Rothenberg, Kyle Larose,
   Donald Eastlake, Qin Wu, Shunsuke Homma, and Greg Mirsky are
   thankfully acknowledged.

   Many thanks to Robert Sparks for the secdir review.

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

   Special thanks to Benjamin Kaduk for the careful review and
   suggestions that enhanced this specification.

9.  References

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



Sarikaya, et al.          Expires June 14, 2021                [Page 11]


Internet-Draft   NSH Subscriber/Performance Policy TLVs    December 2020


9.2.  Informative References

   [I-D.ietf-intarea-tunnels]
              Touch, J. and M. Townsley, "IP Tunnels in the Internet
              Architecture", draft-ietf-intarea-tunnels-10 (work in
              progress), September 2019.

   [I-D.ietf-sfc-nsh-integrity]
              Boucadair, M., Reddy.K, T., and D. Wing, "Integrity
              Protection for the Network Service Header (NSH) and
              Encryption of Sensitive Context Headers", draft-ietf-sfc-
              nsh-integrity-01 (work in progress), November 2020.

   [I-D.ietf-sfc-use-case-mobility]
              Haeffner, W., Napper, J., Stiemerling, M., Lopez, D., and
              J. Uttaro, "Service Function Chaining Use Cases in Mobile
              Networks", draft-ietf-sfc-use-case-mobility-09 (work in
              progress), January 2019.

   [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 23.401 16.5.0, "General Packet Radio Service (GPRS)
              enhancements for Evolved Universal Terrestrial Radio
              Access Network (E-UTRAN) access,", December 2019.

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

Authors' Addresses

   Behcet Sarikaya

   Email: sarikaya@ieee.org






Sarikaya, et al.          Expires June 14, 2021                [Page 12]


Internet-Draft   NSH Subscriber/Performance Policy TLVs    December 2020


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

   Email: Dirk.von-Hugo@telekom.de


   Mohamed Boucadair
   Orange
   Rennes 3500
   France

   Email: mohamed.boucadair@orange.com




































Sarikaya, et al.          Expires June 14, 2021                [Page 13]