Tech-invite   World Map
3GPPspecs     Glossaries     T+       IETF     RFCs     Groups     SIP     ABNFs

RFC 8300

 
 
 

Network Service Header (NSH)

Part 2 of 2, p. 22 to 40
Prev Section

 


prevText      Top      ToC       Page 22 
7.  Policy Enforcement with NSH

7.1.  NSH Metadata and Policy Enforcement

   As described in Section 2, NSH provides the ability to carry metadata
   along a service path.  This metadata may be derived from several
   sources.  Common examples include:

      Network nodes/devices: Information provided by network nodes can
      indicate network-centric information (such as VPN Routing and
      Forwarding (VRF) or tenant) that may be used by Service Functions
      or conveyed to another network node post service path egress.

      External (to the network) systems: External systems, such as
      orchestration systems, often contain information that is valuable
      for Service Function policy decisions.  In most cases, this
      information cannot be deduced by network nodes.  For example, a
      cloud orchestration platform placing workloads "knows" what
      application is being instantiated and can communicate this
      information to all NSH nodes via metadata carried in the Context
      Header(s).

      Service Functions: A Classifier co-resident with Service Functions
      often performs very detailed and valuable classification.

   Regardless of the source, metadata reflects the "result" of
   classification.  The granularity of classification may vary.  For
   example, a network switch, acting as a Classifier, might only be able
   to classify based on a 2-tuple, or based on a 5-tuple, while a
   Service Function may be able to inspect application information.
   Regardless of granularity, the classification information can be
   represented in the NSH.

Top      Up      ToC       Page 23 
   Once the data is added to the NSH, it is carried along the service
   path.  NSH-aware SFs receive the metadata, and can use that metadata
   for local decisions and policy enforcement.  Figures 9 and 10
   highlight the relationship between metadata and policy.

                +-------+        +-------+        +-------+
                |  SFF  )------->(  SFF  |------->|  SFF  |
                +---+---+        +---+---+        +---+---+
                    ^                |                |
                  ,-|-.            ,-|-.            ,-|-.
                 /     \          /     \          /     \
                ( Class )        (  SF1  )        (  SF2  )
                 \ ify /          \     /          \     /
                  `---'            `---'            `---'
                 5-tuple:        Permit             Inspect
                 Tenant A        Tenant A           AppY
                 AppY

                       Figure 9: Metadata and Policy

               +-----+           +-----+            +-----+
               | SFF |---------> | SFF |----------> | SFF |
               +--+--+           +--+--+            +--+--+
                  ^                 |                  |
                ,-+-.             ,-+-.              ,-+-.
               /     \           /     \            /     \
              ( Class )         (  SF1  )          (  SF2  )
               \ ify /           \     /            \     /
                `-+-'             `---'              `---'
                  |              Permit            Deny AppZ
              +---+---+          employees
              |       |
              +-------+
              External
              system:
              Employee
              AppZ

                  Figure 10: External Metadata and Policy

   In both of the examples above, the Service Functions perform policy
   decisions based on the result of the initial classification: the SFs
   did not need to perform re-classification; instead, they rely on an
   antecedent classification for local policy enforcement.

   Depending on the information carried in the metadata, data privacy
   impact needs to be considered.  For example, if the metadata conveys
   tenant information, that information may need to be authenticated

Top      Up      ToC       Page 24 
   and/or encrypted between the originator and the intended recipients
   (which may include intended SFs only); one approach to an optional
   capability to do this is explored in [NSH-ENCRYPT].  The NSH itself
   does not provide privacy functions, rather it relies on the transport
   encapsulation/overlay.  An operator can select the appropriate set of
   transport encapsulation protocols to ensure confidentiality (and
   other security) considerations are met.  Metadata privacy and
   security considerations are a matter for the documents that define
   metadata format.

7.2.  Updating/Augmenting Metadata

   Post-initial metadata imposition (typically, performed during initial
   service path determination), the metadata may be augmented or
   updated:

   1.  Metadata Augmentation: Information may be added to the NSH's
       existing metadata, as depicted in Figure 11.  For example, if the
       initial classification returns the tenant information, a
       secondary classification (perhaps co-resident with deep packet
       inspection (DPI) or server load balancing (SLB)) may augment the
       tenant classification with application information, and impose
       that new information in NSH metadata.  The tenant classification
       is still valid and present, but additional information has been
       added to it.

   2.  Metadata Update: Subsequent Classifiers may update the initial
       classification if it is determined to be incorrect or not
       descriptive enough.  For example, the initial Classifier adds
       metadata that describes the traffic as "Internet", but a security
       Service Function determines that the traffic is really "attack".
       Figure 12 illustrates an example of updating metadata.

Top      Up      ToC       Page 25 
               +-----+           +-----+            +-----+
               | SFF |---------> | SFF |----------> | SFF |
               +--+--+           +--+--+            +--+--+
                  ^                 |                  |
                ,---.             ,---.              ,---.
               /     \           /     \            /     \
              ( Class )         (  SF1  )          (  SF2  )
               \     /           \     /            \     /
                `-+-'             `---'              `---'
                  |              Inspect           Deny
              +---+---+          employees         employee+
              |       |          Class=AppZ        appZ
              +-------+
              External
              system:
              Employee

                     Figure 11: Metadata Augmentation

                +-----+           +-----+            +-----+
                | SFF |---------> | SFF |----------> | SFF |
                +--+--+           +--+--+            +--+--+
                   ^                 |                  |
                 ,---.             ,---.              ,---.
                /     \           /     \            /     \
               ( Class )         (  SF1  )          (  SF2  )
                \     /           \     /            \     /
                 `---'             `---'              `---'
              5-tuple:            Inspect             Deny
              Tenant A            Tenant A            attack
                                   --> attack

                        Figure 12: Metadata Update

7.3.  Service Path Identifier and Metadata

   Metadata information may influence the service path selection since
   the Service Path Identifier values can represent the result of
   classification.  A given SPI can be defined based on classification
   results (including metadata classification).  The imposition of the
   SPI and SI results in the packet being placed on the newly specified
   SFP at the position indicated by the imposed SPI and SI.

   This relationship provides the ability to create a dynamic service
   plane based on complex classification, without requiring each node to
   be capable of such classification or requiring a coupling to the
   network topology.  This yields Service Graph functionality as

Top      Up      ToC       Page 26 
   described in Section 6.4.  Figure 13 illustrates an example of this
   behavior.

               +-----+           +-----+            +-----+
               | SFF |---------> | SFF |------+---> | SFF |
               +--+--+           +--+--+      |     +--+--+
                  |                 |         |        |
                ,---.             ,---.       |      ,---.
               /     \           / SF1 \      |     /     \
              (  SCL  )         (   +   )     |    (  SF2  )
               \     /           \SCL2 /      |     \     /
                `---'             `---'    +-----+   `---'
             5-tuple:            Inspect   | SFF |    Original
             Tenant A            Tenant A  +--+--+    next SF
                                  --> DoS     |
                                              V
                                            ,-+-.
                                           /     \
                                          (  SF10 )
                                           \     /
                                            `---'
                                             DoS
                                          "Scrubber"

             Legend:
             SCL = Service Classifier

                      Figure 13: Path ID and Metadata

   Specific algorithms for mapping metadata to an SPI are outside the
   scope of this document.

8.  Security Considerations

   NSH security must be considered in the contexts of the SFC
   architecture and operators' environments.  One important
   characteristic of NSH is that it is not an end-to-end protocol.  As
   opposed to a protocol that "starts" on a host and "ends" on a server
   or another host, NSH is typically imposed by a network device on
   ingress to the SFC domain and removed at the egress of the SFC
   domain.  As such, and as with any other network-centric protocols
   (e.g., IP Tunneling, Traffic Engineering, MPLS, or Provider-
   Provisioned Virtual Private Networks), there is an underlying trust
   in the network devices responsible for imposing, removing, and acting
   on NSH information.

   The following sections detail an analysis and present a set of
   requirements and recommendations in those two areas.

Top      Up      ToC       Page 27 
8.1.  NSH Security Considerations from Operators' Environments

   Trusted Devices

      All Classifiers, SFFs and SFs (hereinafter referred to as "SFC
      devices") within an operator's environment are assumed to have
      been selected, vetted, and actively maintained; therefore, they
      are trusted by that operator.  This assumption differs from the
      oft held view that devices are untrusted, often referred to as the
      "zero-trust model".  Operators SHOULD regularly monitor (i.e.,
      continuously audit) these devices to help ensure compliant
      behavior.  This trust, therefore, extends into NSH operations: SFC
      devices are not, themselves, considered to be attack vectors.
      This assumption, and the resultant conclusion is reasonable since
      this is the very basis of an operator posture; the operator
      depends on this reality to function.  If these devices are not
      trusted, and indeed are compromised, almost the entirety of the
      operator's standard-based IP and MPLS protocol suites are
      vulnerable; therefore, the operation of the entire network is
      compromised.  Although there are well-documented monitoring-based
      methods for detecting compromise (such as included continuous
      monitoring and audit and log review), these may not be sufficient
      to contain damage by a completely compromised element.

      Methods and best practices to secure devices are also widely
      documented and outside the scope of this document.

   Single Domain Boundary

      As per [RFC7665], NSH is designed for use within a single
      administrative domain.  This scoping provides two important
      characteristics:

      i) Clear NSH boundaries

      NSH egress devices MUST strip the NSH headers before they send the
      users' packets or frames out of the NSH domain.

      Means to prevent leaking privacy-related information outside an
      administrative domain are natively supported by the NSH given that
      the last SFF of a service path will systematically remove the NSH
      encapsulation before forwarding a packet exiting the service path.

      The second step in such prevention is to filter the transport
      encapsulation protocol used by NSH at the domain edge.  The
      transport encapsulation protocol MUST be filtered and MUST NOT
      leave the domain edge.

Top      Up      ToC       Page 28 
      Depending upon the transport encapsulation protocol used for NSH,
      this can be done either by completely blocking the transport
      encapsulation (e.g., if MPLS is the chosen NSH transport
      encapsulation protocol, it is therefore never allowed to leave the
      domain) or by examining the carried protocol with the transport
      encapsulation (e.g., if VXLAN-gpe is used as the NSH transport
      encapsulation protocol, all domain edges need to filter based on
      the carried protocol in the VXLAN-gpe.)

      The other consequence of this bounding is that ingress packets
      MUST also be filtered to prevent attackers from sending in NSH
      packets with service path identification and metadata of their own
      selection.  The same filters as described above for both the NSH
      at SFC devices and for the transport encapsulation protocol as
      general edge protections MUST be applied on ingress.

      In summary, packets originating outside the SFC-enabled domain
      MUST be dropped if they contain an NSH.  Similarly, packets
      exiting the SFC-enabled domain MUST be dropped if they contain an
      NSH.

      ii) Mitigation of external threats

      As per the trusted SFC device points raised above, given that NSH
      is scoped within an operator's domain, that operator can ensure
      that the environment and its transitive properties comply with
      that operator's required security posture.  Continuous audits for
      assurance are recommended with this reliance on a fully trusted
      environment.  The term "continuous audits" describes a method
      (automated or manual) of checking security-control compliance on a
      regular basis, at some set period of time.

8.2.  NSH Security Considerations from the SFC Architecture

   The SFC architecture defines functional roles (e.g., SFF), as well as
   protocol elements (e.g., Metadata).  This section considers each role
   and element in the context of threats posed in the areas of integrity
   and confidentiality.  As with routing, the distributed computation
   model assumes a distributed trust model.

   An important consideration is that NSH contains mandatory-to-mute
   fields, and further, the SFC architecture describes cases where other
   fields in NSH change, all on a possible SFP hop-by-hop basis.  This
   means that any cryptographic solution requires complex key
   distribution and life-cycle operations.

Top      Up      ToC       Page 29 
8.2.1.  Integrity

   SFC devices

      SFC devices MAY perform various forms of verification on received
      NSH packets such as only accepting NSH packets from expected
      devices, checking that NSH SPI and SI values received from
      expected devices conform to expected values and so on.
      Implementation of these additional checks are a local matter and,
      thus, out of scope of this document.

   NSH Base and Service Path Headers

      Attackers who can modify packets within the operator's network may
      be able to modify the SFP, path position, and/or the metadata
      associated with a packet.

      One specific concern is an attack in which a malicious
      modification of the SPI/SI results in an alteration of the path to
      avoid security devices.  The options discussed in this section
      help thwart that attack, and so does the use of the optional
      "Proof of Transit" method [PROOF-OF-TRANSIT].

      As stated above, SFC devices are trusted; in the case where an SFC
      device is compromised, NSH integrity protection would be subject
      to forging (in many cases) as well.

      NSH itself does not mandate protocol-specific integrity
      protection.  However, if an operator deems protection is required,
      several options are viable:

      1.  SFF/SF NSH verification

          Although, strictly speaking, not integrity protection, some of
          the techniques mentioned above, such as checking expected NSH
          values are received from expected SFC device(s), can provide a
          form of verification without incurring the burden of a full-
          fledged integrity-protection deployment.

      2.  Transport Security

          NSH is always encapsulated by an outer transport encapsulation
          as detailed in Section 4 of this specification, and as
          depicted in Figure 1.  If an operator deems cryptographic
          integrity protection necessary due to their risk analysis,
          then an outer transport encapsulation that provides such
          protection [RFC6071], such as IPsec, MUST be used.

Top      Up      ToC       Page 30 
          Although the threat model and recommendations of Section 5 of
          BCP 72 [RFC3552] would normally require cryptographic data
          origin authentication for the header, this document does not
          mandate such mechanisms in order to reflect the operational
          and technical realities of deployment.

          Given that NSH is transport independent, as mentioned above, a
          secure transport, such as IPsec can be used for carry NSH.
          IPsec can be used either alone or in conjunction with other
          transport encapsulation protocols, in turn, encapsulating NSH.

          Operators MUST ensure the selected transport encapsulation
          protocol can be supported by the transport encapsulation/
          underlay of all relevant network segments as well as SFFs,
          SFs, and SFC Proxies in the service path.

          If connectivity between SFC-enabled devices traverses the
          public Internet, then such connectivity MUST be secured at the
          transport encapsulation layer.  IPsec is an example of such a
          transport.

      3.  NSH Variable Header-Based Integrity

          Lastly, NSH MD Type 2 provides, via variable-length headers,
          the ability to append cryptographic integrity protection to
          the NSH packet.  The implementation of such a scheme is
          outside the scope of this document.

   NSH metadata

      As with the Base and Service Path Headers, if an operator deems
      cryptographic integrity protection needed, then an existing,
      standard transport protocol MUST be used since the integrity
      protection applies to entire encapsulated NSH packets.  As
      mentioned above, a risk assessment that deems data-plane traffic
      subject to tampering will apply not only to NSH but to the
      transport information; therefore, the use of a secure transport is
      likely needed already to protect the entire stack.

      If an MD Type 2 variable header integrity scheme is in place, then
      the integrity of the metadata can be ensured via that mechanism as
      well.

Top      Up      ToC       Page 31 
8.2.2.  Confidentiality

   SFC devices

      SFC devices can "see" (and need to use) NSH information.

   NSH Base and Service Path Headers

      SPI and other base / service path information does not typically
      require confidentiality; however, if an operator does deem
      confidentiality to be required, then, as with integrity, an
      existing transport encapsulation that provides encryption MUST be
      utilized.

   NSH metadata

      An attacker with access to the traffic in an operator's network
      can potentially observe the metadata NSH carries with packets,
      potentially discovering privacy-sensitive information.

      Much of the metadata carried by NSH is not sensitive.  It often
      reflects information that can be derived from the underlying
      packet or frame.  Direct protection of such information is not
      necessary, as the risks are simply those of carrying the
      underlying packet or frame.

      Implementers and operators MUST be aware that metadata can have
      privacy implications, and those implications are sometimes hard to
      predict.  Therefore, attached metadata should be limited to that
      necessary for correct operation of the SFP.  Further, [RFC8165]
      defines metadata considerations that operators can take into
      account when using NSH.

      Protecting NSH metadata information between SFC components can be
      done using transport encapsulation protocols with suitable
      security capabilities, along the lines discussed above.  If a
      security analysis deems these protections necessary, then security
      features in the transport encapsulation protocol (such as IPsec)
      MUST be used.

      One useful element of providing privacy protection for sensitive
      metadata is described under the "SFC Encapsulation" area of the
      Security Considerations of [RFC7665].  Operators can and should
      use indirect identification for metadata deemed to be sensitive
      (such as personally identifying information), significantly
      mitigating the risk of a privacy violation.  In particular,
      subscriber-identifying information should be handled carefully,
      and, in general, SHOULD be obfuscated.

Top      Up      ToC       Page 32 
      For those situations where obfuscation is either inapplicable or
      judged to be insufficient, an operator can also encrypt the
      metadata.  An approach to an optional capability to do this was
      explored in [NSH-ENCRYPT].  For other situations where greater
      assurance is desired, optional mechanisms such as
      [PROOF-OF-TRANSIT] can be used.

9.  IANA Considerations

9.1.  NSH Parameters

   IANA has created a new "Network Service Header (NSH) Parameters"
   registry.  The following subsections detail new registries within the
   "Network Service Header (NSH) Parameters" registry.

9.1.1.  NSH Base Header Bits

   There are five unassigned bits (U bits) in the NSH Base Header, and
   one assigned bit (O bit).  New bits are assigned via Standards Action
   [RFC8126].

   Bit 2 - O (OAM) bit
   Bit 3 - Unassigned
   Bits 16-19 - Unassigned

9.1.2.  NSH Version

   IANA has set up the "NSH Version" registry.  New values are assigned
   via Standards Action [RFC8126].

       +-------------+---------------------------------+-----------+
       | Version     | Description                     | Reference |
       +-------------+---------------------------------+-----------+
       | Version 00b | Protocol as defined by RFC 8300 | RFC 8300  |
       | Version 01b | Reserved                        | RFC 8300  |
       | Version 10b | Unassigned                      |           |
       | Version 11b | Unassigned                      |           |
       +-------------+---------------------------------+-----------+

                           Table 5: NSH Version

Top      Up      ToC       Page 33 
9.1.3.  NSH MD Types

   IANA has set up the "NSH MD Types" registry, which contains 4-bit
   values.  MD Type values 0x0, 0x1, 0x2, and 0xF are specified in this
   document; see Table 6.  Registry entries are assigned via the "IETF
   Review" policy defined in RFC 8126 [RFC8126].

                +-----------+-----------------+-----------+
                | MD Type   | Description     | Reference |
                +-----------+-----------------+-----------+
                | 0x0       | Reserved        | RFC 8300  |
                |           |                 |           |
                | 0x1       | NSH MD Type 1   | RFC 8300  |
                |           |                 |           |
                | 0x2       | NSH MD Type 2   | RFC 8300  |
                |           |                 |           |
                | 0x3 - 0xE | Unassigned      |           |
                |           |                 |           |
                | 0xF       | Experimentation | RFC 8300  |
                +-----------+-----------------+-----------+

                          Table 6: MD Type Values

9.1.4.  NSH MD Class

   IANA has set up the "NSH MD Class" registry, which contains 16-bit
   values.  New allocations are to be made according to the following
   policies:

   0x0000 to 0x01ff: IETF Review
   0x0200 to 0xfff5: Expert Review

   IANA has assigned the values as follows:

        +------------------+------------------------+------------+
        | Value            | Meaning                | Reference  |
        +------------------+------------------------+------------+
        | 0x0000           | IETF Base NSH MD Class | RFC 8300   |
        |                  |                        |            |
        | 0xfff6 to 0xfffe | Experimental           | RFC 8300   |
        |                  |                        |            |
        | 0xffff           | Reserved               | RFC 8300   |
        +------------------+------------------------+------------+

                           Table 7: NSH MD Class

   A registry for Types for the MD Class of 0x0000 is defined in
   Section 9.1.5.

Top      Up      ToC       Page 34 
   Designated Experts evaluating new allocation requests from the
   "Expert Review" range should principally consider whether a new MD
   class is needed compared to adding MD Types to an existing class.
   The Designated Experts should also encourage the existence of an
   associated and publicly visible registry of MD Types although this
   registry need not be maintained by IANA.

   When evaluating a request for an allocation, the Expert should verify
   that the allocation plan includes considerations to handle privacy
   and security issues associated with the anticipated individual MD
   Types allocated within this class.  These plans should consider, when
   appropriate, alternatives such as indirection, encryption, and
   limited-deployment scenarios.  Information that can't be directly
   derived from viewing the packet contents should be examined for
   privacy and security implications.

9.1.5.  NSH IETF-Assigned Optional Variable-Length Metadata Types

   The Type values within the IETF Base NSH MD Class, i.e., when the MD
   Class is set to 0x0000 (see Section 9.1.4), are the Types owned by
   the IETF.  Per this document, IANA has created a registry for the
   Type values for the IETF Base NSH MD Class called the "NSH IETF-
   Assigned Optional Variable-Length Metadata Types" registry, as
   specified in Section 2.5.1.

   The type values are assigned via Standards Action [RFC8126].

   No initial values are assigned at the creation of the registry.

Top      Up      ToC       Page 35 
9.1.6.  NSH Next Protocol

   IANA has set up the "NSH Next Protocol" registry, which contains
   8-bit values.  Next Protocol values 0, 1, 2, 3, 4, and 5 are defined
   in this document (see Table 8).  New values are assigned via "Expert
   Review" as per [RFC8126].

               +---------------+--------------+-----------+
               | Next Protocol | Description  | Reference |
               +---------------+--------------+-----------+
               | 0x00          | Unassigned   |           |
               |               |              |           |
               | 0x01          | IPv4         | RFC 8300  |
               |               |              |           |
               | 0x02          | IPv6         | RFC 8300  |
               |               |              |           |
               | 0x03          | Ethernet     | RFC 8300  |
               |               |              |           |
               | 0x04          | NSH          | RFC 8300  |
               |               |              |           |
               | 0x05          | MPLS         | RFC 8300  |
               |               |              |           |
               | 0x06 - 0xFD   | Unassigned   |           |
               |               |              |           |
               | 0xFE          | Experiment 1 | RFC 8300  |
               |               |              |           |
               | 0xFF          | Experiment 2 | RFC 8300  |
               +---------------+--------------+-----------+

               Table 8: NSH Base Header Next Protocol Values

   Expert Review requests MUST include a single codepoint per request.
   Designated Experts evaluating new allocation requests from this
   registry should consider the potential scarcity of codepoints for an
   8-bit value, and check both for duplications and availability of
   documentation.  If the actual assignment of the Next Protocol field
   allocation reaches half of the range (that is, when there are 128
   unassigned values), IANA needs to alert the IESG.  At that point, a
   new more strict allocation policy SHOULD be considered.

10.  NSH-Related Codepoints

10.1.  NSH Ethertype

   An IEEE Ethertype, 0x894F, has been allocated for NSH.

Top      Up      ToC       Page 36 
11.  References

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

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

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

11.2.  Informative References

   [NSH-BROADBAND-ALLOCATION]
              Napper, J., Kumar, S., Muley, P., Henderickx, W., and M.
              Boucadair, "NSH Context Header Allocation -- Broadband",
              Work in Progress, draft-napper-sfc-nsh-broadband-
              allocation-04, November 2017.

   [NSH-DC-ALLOCATION]
              Guichard, J., Smith, M., Kumar, S., Majee, S., Agarwal,
              P., Glavin, K., Laribi, Y., and T. Mizrahi, "Network
              Service Header (NSH) MD Type 1: Context Header Allocation
              (Data Center)", Work in Progress,
              draft-guichard-sfc-nsh-dc-allocation-07, August 2017.

   [NSH-ENCRYPT]
              Reddy, T., Patil, P., Fluhrer, S., and P. Quinn,
              "Authenticated and encrypted NSH service chains", Work in
              Progress, draft-reddy-sfc-nsh-encrypt-00, April 2015.

Top      Up      ToC       Page 37 
   [PROOF-OF-TRANSIT]
              Brockners, F., Bhandari, S., Dara, S., Pignataro, C.,
              Leddy, J., Youell, S., Mozes, D., and T. Mizrahi, "Proof
              of Transit", Work in Progress, draft-brockners-proof-
              of-transit-04, October 2017.

   [RFC2784]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
              Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
              DOI 10.17487/RFC2784, March 2000,
              <https://www.rfc-editor.org/info/rfc2784>.

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,
              DOI 10.17487/RFC3552, July 2003,
              <https://www.rfc-editor.org/info/rfc3552>.

   [RFC3692]  Narten, T., "Assigning Experimental and Testing Numbers
              Considered Useful", BCP 82, RFC 3692,
              DOI 10.17487/RFC3692, January 2004,
              <https://www.rfc-editor.org/info/rfc3692>.

   [RFC6071]  Frankel, S. and S. Krishnan, "IP Security (IPsec) and
              Internet Key Exchange (IKE) Document Roadmap", RFC 6071,
              DOI 10.17487/RFC6071, February 2011,
              <https://www.rfc-editor.org/info/rfc6071>.

   [RFC6291]  Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
              D., and S. Mansfield, "Guidelines for the Use of the "OAM"
              Acronym in the IETF", BCP 161, RFC 6291,
              DOI 10.17487/RFC6291, June 2011,
              <https://www.rfc-editor.org/info/rfc6291>.

   [RFC7325]  Villamizar, C., Ed., Kompella, K., Amante, S., Malis, A.,
              and C. Pignataro, "MPLS Forwarding Compliance and
              Performance Requirements", RFC 7325, DOI 10.17487/RFC7325,
              August 2014, <https://www.rfc-editor.org/info/rfc7325>.

   [RFC7498]  Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for
              Service Function Chaining", RFC 7498,
              DOI 10.17487/RFC7498, April 2015,
              <https://www.rfc-editor.org/info/rfc7498>.

   [RFC7676]  Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support
              for Generic Routing Encapsulation (GRE)", RFC 7676,
              DOI 10.17487/RFC7676, October 2015,
              <https://www.rfc-editor.org/info/rfc7676>.

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

   [RFC8201]  McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
              "Path MTU Discovery for IP version 6", STD 87, RFC 8201,
              DOI 10.17487/RFC8201, July 2017,
              <https://www.rfc-editor.org/info/rfc8201>.

   [RTG-ENCAP]
              Nordmark, E., Tian, A., Gross, J., Hudson, J., Kreeger,
              L., Garg, P., Thaler, P., and T. Herbert, "Encapsulation
              Considerations", Work in Progress,
              draft-ietf-rtgwg-dt-encap-02, October 2016.

   [SFC-CONTROL-PLANE]
              Boucadair, M., "Service Function Chaining (SFC) Control
              Plane Components & Requirements", Work in Progress,
              draft-ietf-sfc-control-plane-08, October 2016.

   [SFC-OAM-FRAMEWORK]
              Aldrin, S., Pignataro, C., Kumar, N., Akiya, N., Krishnan,
              R., and A. Ghanwani, "Service Function Chaining (SFC)
              Operation, Administration and Maintenance (OAM)
              Framework", Work in Progress,
              draft-ietf-sfc-oam-framework-03, September 2017.

   [VXLAN-GPE]
              Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol
              Extension for VXLAN", Work in Progress,
              draft-ietf-nvo3-vxlan-gpe-05, October 2017.

Acknowledgments

   The authors would like to thank Sunil Vallamkonda, Nagaraj Bagepalli,
   Abhijit Patra, Peter Bosch, Darrel Lewis, Pritesh Kothari, Tal
   Mizrahi, and Ken Gray for their detailed reviews, comments, and
   contributions.

   A special thank you goes to David Ward and Tom Edsall for their
   guidance and feedback.

   Additionally, the authors would like to thank Larry Kreeger for his
   invaluable ideas and contributions, which are reflected throughout
   this document.

   Loa Andersson provided a thorough review and valuable comments; we
   thank him for that.

Top      Up      ToC       Page 39 
   Reinaldo Penno deserves a particular thank you for his architecture
   and implementation work that helped guide the protocol concepts and
   design.

   The editors also acknowledge comprehensive reviews and respective
   useful suggestions by Med Boucadair, Adrian Farrel, Juergen
   Schoenwaelder, Acee Lindem, and Kathleen Moriarty.

   Lastly, David Dolson has provided significant review, feedback, and
   suggestions throughout the evolution of this document.  His
   contributions are very much appreciated.

Contributors

   This WG document originated as draft-quinn-sfc-nsh; the following are
   its coauthors and contributors along with their respective
   affiliations at the time of WG adoption.  The editors of this
   document would like to thank and recognize them and their
   contributions.  These coauthors and contributors provided invaluable
   concepts and content for this document's creation.

   o  Jim Guichard, Cisco Systems, Inc.
   o  Surendra Kumar, Cisco Systems, Inc.
   o  Michael Smith, Cisco Systems, Inc.
   o  Wim Henderickx, Alcatel-Lucent
   o  Tom Nadeau, Brocade
   o  Puneet Agarwal
   o  Rajeev Manur, Broadcom
   o  Abhishek Chauhan, Citrix
   o  Joel Halpern, Ericsson
   o  Sumandra Majee, F5
   o  David Melman, Marvell
   o  Pankaj Garg, Microsoft
   o  Brad McConnell, Rackspace
   o  Chris Wright, Red Hat, Inc.
   o  Kevin Glavin, Riverbed
   o  Hong (Cathy) Zhang, Huawei US R&D
   o  Louis Fourie, Huawei US R&D
   o  Ron Parker, Affirmed Networks
   o  Myo Zarny, Goldman Sachs
   o  Andrew Dolganow, Alcatel-Lucent
   o  Rex Fernando, Cisco Systems, Inc.
   o  Praveen Muley, Alcatel-Lucent
   o  Navindra Yadav, Cisco Systems, Inc.

Top      Up      ToC       Page 40 
Authors' Addresses

   Paul Quinn (editor)
   Cisco Systems, Inc.

   Email: paulq@cisco.com


   Uri Elzur (editor)
   Intel

   Email: uri.elzur@intel.com


   Carlos Pignataro (editor)
   Cisco Systems, Inc.

   Email: cpignata@cisco.com