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

SFC                                                          B. Sarikaya
Internet-Draft                                       Denpel Informatique
Intended status: Standards Track                             D. von Hugo
Expires: April 11, 2021                                 Deutsche Telekom
                                                            M. Boucadair
                                                                  Orange
                                                         October 8, 2020

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

Abstract

   This document defines Subscriber and Performance Policy Identifiers
   Network Service Header Variable-Length Context Headers to inform
   Service Functions about subscriber- and service-related information
   for the sake of policy enforcement and appropriate service function
   chaining operations.  The structure of each Context Header, 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 April 11, 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
   (https://trustee.ietf.org/license-info) in effect on the date of

Sarikaya, et al.         Expires April 11, 2021                 [Page 1]
Internet-Draft   NSH Subscriber/Performance Policy TLVs     October 2020

   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.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   This document discusses how to inform Service Functions (SFs)
   [RFC7665] about subscriber and service-related information, when
   required, for the sake of policy enforcement within a single
   administrative domain.  Particularly, 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.

   Also, the enforcement of SFC-based differentiated traffic policies
   may be inferred, 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 enforcement may be conditioned by QoS
   requirements that will affect SF instance(s) identification,
   location, and sequencing.  Hence, the need to supply a performance
   policy identifier to downstream SFs to appropriately meet the service
   requirements arises.

   SFs and SF Forwarders (SFFs) involved in a service chain have to
   contribute to the respective service policy (QoS, for example)

Sarikaya, et al.         Expires April 11, 2021                 [Page 2]
Internet-Draft   NSH Subscriber/Performance Policy TLVs     October 2020

   requirements characterized by low transmission delay between each
   other, by exposing a high availability of resources to process
   function tasks, or by redundancy provided by stand-by machines for
   seamless execution continuation in case of failures.  These
   requirements may be satisfied by means of control plane protocols,
   but in some contexts, e.g., in networks where resources are very much
   constrained, carrying QoS-related information directly in packets may
   improve the overall SFC operation instead of relying upon the
   potential complexity or adding overhead introduced by some SFC
   control plane features.  This information is proposed to be included
   as a Context Header in the NSH.

   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 addressing in those
   networks, if SFs to be invoked are located after a NAT function, the
   identification based on the internal IP address is not possible once
   the NAT has been crossed.  NAT functionality can reside in a distinct
   node which for 3GPP network can be the Packet Data Network (PDN)
   Gateway (PGW) as specified in [TS23401] in case of 4G or the User
   Plane Function (UPF) facing the external Data Network (DN) [TS23501]
   in case of 5G, respectively.  As such, means to allow passing the
   internal information 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.  As such identifier one of already specified 3GPP
   identifiers may serve (see, for example, those listed in [RFC8371]),
   but it is out of scope of this document to include a comprehensive
   list of deployment contexts which may make use of the Context Headers
   defined in the document.

   Since identifiers for subscribers are distinct from those for
   performance policy and multiple policies (e.g., as per multiple
   services) may be associated to a single subscriber within one service
   chain both identifiers are defined separately thus avoiding to
   require additional internal structures of the Context Headers to
   decide unambiguously 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 an SFC-enabled domain.  This
   document focuses on the data plane behaviour.  Control plane
   considerations are out of the scope.

Sarikaya, et al.         Expires April 11, 2021                 [Page 3]
Internet-Draft   NSH Subscriber/Performance Policy TLVs     October 2020

   The reader may refer to Section 3 of [RFC8300] for MTU
   considerations.  Such considerations are not reiterated here.

   This document assumes the NSH is used exclusively within a single
   administrative domain.

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

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

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

Sarikaya, et al.         Expires April 11, 2021                 [Page 4]
Internet-Draft   NSH Subscriber/Performance Policy TLVs     October 2020

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

   o  Subscriber Identifier: Carries an opaque subscriber identifier.

   The Subscriber Identifier Context Header is used to convey an
   identifier assigned by the service provider to uniquely identify a
   subscriber.  This subscriber identifier can be used by service
   functions to enforce per-subscriber policies (e.g., apply resource
   quota).

   The classifier and NSH-aware SFs MAY inject or strip a subscriber
   identifier Context Header as a function of a local policy.  In order
   to prevent interoperability issues, the data and their format to be
   injected in such header SHOULD be configured to nodes authorized to
   inject such headers.  Typically, 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 depend on the information in
   the Context Header such as frequency, thresholds, and content of the
   alarm (full header, timestamp, etc.)) SHOULD be configurable.

   This document adheres to the recommendations in [RFC8300] for
   handling the Context Headers at both ingress and egress SFC boundary
   nodes.  That is, to strip such Context Headers.  Revealing any
   personal and subscriber-related information to third parties is
   avoided by design to prevent privacy breaches in terms of user
   tracking.

   Depending on the local policy, proxies MAY strip a Subscriber
   Identifier Context Header from the packet or pass the data to the
   next SF in the service chain after processing the content of the
   Context Headers.  If no instruction is provided, an intermediary NSH-
   aware node MUST maintain such Context Headers so that the information
   can be passed to next hop NSH-aware nodes.

   NSH-aware SFs MUST ignore Context Headers carrying unknown subscriber
   identifiers.

   NSH-aware SFs MUST be capable to run additional validation checks on
   the content of these Context Headers (e.g., accept only some lengths,
   types) and the behavior to adopt; the exact set of validation checks
   is provided as a local policy.  Such policy may include to, e.g.,
   ignore the Context Header or to remove it from the packet.  However,

Sarikaya, et al.         Expires April 11, 2021                 [Page 5]
Internet-Draft   NSH Subscriber/Performance Policy TLVs     October 2020

   this specification does not require nor preclude such NSH-aware SFs
   may be instructed to ignore the Context Header, to remove the Context
   Header from the packet, etc.  These 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 that expects an internal IP address as subscriber
   identifier will discard Subscriber Identifier Context Headers
   conveying Mobile Subscriber ISDN Number (MSISDN), International
   Mobile Subscriber Identity (IMSI), or malformed IP addresses.

   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 identifier is defined to
   differentiate between services requiring specific treatment 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
   the Performance Policy Identifier is not helpful if the path
   computation is centralized and a strict SFP is presented as local
   policy to SFFs.

   The Performance Policy Identifier allows for the distributed
   enforcement of a per-service policy such as 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

Sarikaya, et al.         Expires April 11, 2021                 [Page 6]
Internet-Draft   NSH Subscriber/Performance Policy TLVs     October 2020

   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
   deployment of multiple SF instances may be requested.

   In an environment characterised by frequent changes of link and path
   behaviour, for example due to variable load or availablility 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 optional variable length
   Context Header.  Its structure is shown in Figure 2.

   Depending on the local policy, proxies MAY strip a Performance Policy
   Identifier Context Header from the packet or pass the data to the
   next SF in the service chain after processing the content of the
   Context Headers.  If no instruction is provided, an intermediary NSH-
   aware node MUST maintain such Context Headers so that the information
   can be passed to next hop NSH-aware nodes.

   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.

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

Sarikaya, et al.         Expires April 11, 2021                 [Page 7]
Internet-Draft   NSH Subscriber/Performance Policy TLVs     October 2020

   o  Type: TBD2 (See Section 5).

   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
      semantic of this field is deployment-specific.

5.  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] |
        +-------+-------------------------------+----------------+

6.  Security Considerations

   Data plane SFC-related security considerations, including privacy,
   are discussed in [RFC7665] and [RFC8300].

   Nodes that are involved in an SFC-enabled domain are assumed to be
   trusted ([RFC8300]).  Means to check that only authorized nodes are
   solicited when a packet is crossing an SFC-enabled domain are out of
   scope of this document.

   A misbehaving node within from 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 [RFC8300] are to be followed.  Also, integrity checks
   offered by the transport encapsulation can be used to detect
   anomalies.  A mechanism for SFC Integrity is specified in
   [I-D.ietf-sfc-nsh-integrity].

   An SF maintaining logs for operational reasons MUST NOT log the
   content of Subscriber and Performance Policy Context Headers received

Sarikaya, et al.         Expires April 11, 2021                 [Page 8]
Internet-Draft   NSH Subscriber/Performance Policy TLVs     October 2020

   in NSH packets if the SF does not use the content of that header for
   its operation.

7.  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 Martin Vigoureux for the AD review.

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

   [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-00 (work in progress), June 2020.

Sarikaya, et al.         Expires April 11, 2021                 [Page 9]
Internet-Draft   NSH Subscriber/Performance Policy TLVs     October 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.

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

   [RFC8459]  Dolson, D., Homma, S., Lopez, D., and M. Boucadair,
              "Hierarchical Service Function Chaining (hSFC)", RFC 8459,
              DOI 10.17487/RFC8459, September 2018,
              <https://www.rfc-editor.org/info/rfc8459>.

   [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
   Denpel Informatique

   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
   Rennes 3500
   France

   Email: mohamed.boucadair@orange.com

Sarikaya, et al.         Expires April 11, 2021                [Page 10]