idnits 2.17.00 (12 Aug 2021) /tmp/idnits35461/draft-ietf-sfc-nsh-28.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 3, 2017) is 1653 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 7665 == Outdated reference: A later version (-05) exists of draft-brockners-proof-of-transit-04 == Outdated reference: A later version (-12) exists of draft-ietf-nvo3-vxlan-gpe-05 == Outdated reference: draft-ietf-sfc-oam-framework has been published as RFC 8924 == Outdated reference: A later version (-04) exists of draft-napper-sfc-nsh-broadband-allocation-03 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Service Function Chaining P. Quinn, Ed. 3 Internet-Draft Cisco 4 Intended status: Standards Track U. Elzur, Ed. 5 Expires: May 7, 2018 Intel 6 C. Pignataro, Ed. 7 Cisco 8 November 3, 2017 10 Network Service Header (NSH) 11 draft-ietf-sfc-nsh-28 13 Abstract 15 This document describes a Network Service Header (NSH) imposed on 16 packets or frames to realize service function paths. The NSH also 17 provides a mechanism for metadata exchange along the instantiated 18 service paths. The NSH is the SFC encapsulation required to support 19 the Service Function Chaining (SFC) architecture (defined in 20 RFC7665). 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 7, 2018. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 58 1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 59 1.3. Definition of Terms . . . . . . . . . . . . . . . . . . . 5 60 1.4. Problem Space . . . . . . . . . . . . . . . . . . . . . . 6 61 1.5. NSH-based Service Chaining . . . . . . . . . . . . . . . 6 62 2. Network Service Header . . . . . . . . . . . . . . . . . . . 7 63 2.1. Network Service Header Format . . . . . . . . . . . . . . 7 64 2.2. NSH Base Header . . . . . . . . . . . . . . . . . . . . . 8 65 2.3. Service Path Header . . . . . . . . . . . . . . . . . . . 11 66 2.4. NSH MD Type 1 . . . . . . . . . . . . . . . . . . . . . . 12 67 2.5. NSH MD Type 2 . . . . . . . . . . . . . . . . . . . . . . 12 68 2.5.1. Optional Variable Length Metadata . . . . . . . . . . 13 69 3. NSH Actions . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 4. NSH Transport Encapsulation . . . . . . . . . . . . . . . . . 16 71 5. Fragmentation Considerations . . . . . . . . . . . . . . . . 17 72 6. Service Path Forwarding with NSH . . . . . . . . . . . . . . 17 73 6.1. SFFs and Overlay Selection . . . . . . . . . . . . . . . 17 74 6.2. Mapping the NSH to Network Topology . . . . . . . . . . . 21 75 6.3. Service Plane Visibility . . . . . . . . . . . . . . . . 21 76 6.4. Service Graphs . . . . . . . . . . . . . . . . . . . . . 22 77 7. Policy Enforcement with NSH . . . . . . . . . . . . . . . . . 22 78 7.1. NSH Metadata and Policy Enforcement . . . . . . . . . . . 22 79 7.2. Updating/Augmenting Metadata . . . . . . . . . . . . . . 24 80 7.3. Service Path Identifier and Metadata . . . . . . . . . . 25 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 82 8.1. NSH Security Considerations from Operators' Environments 27 83 8.2. NSH Security Considerations from the SFC Architecture . . 28 84 8.2.1. Integrity . . . . . . . . . . . . . . . . . . . . . . 29 85 8.2.2. Confidentiality . . . . . . . . . . . . . . . . . . . 31 86 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32 87 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 88 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 89 11.1. Network Service Header (NSH) Parameters . . . . . . . . 34 90 11.1.1. NSH Base Header Bits . . . . . . . . . . . . . . . . 34 91 11.1.2. NSH Version . . . . . . . . . . . . . . . . . . . . 34 92 11.1.3. MD Type Registry . . . . . . . . . . . . . . . . . . 34 93 11.1.4. MD Class Registry . . . . . . . . . . . . . . . . . 35 94 11.1.5. New IETF Assigned Optional Variable Length Metadata 95 Type Registry . . . . . . . . . . . . . . . . . . . 36 96 11.1.6. NSH Base Header Next Protocol . . . . . . . . . . . 36 98 12. NSH-Related Codepoints . . . . . . . . . . . . . . . . . . . 37 99 12.1. NSH EtherType . . . . . . . . . . . . . . . . . . . . . 37 100 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 101 13.1. Normative References . . . . . . . . . . . . . . . . . . 37 102 13.2. Informative References . . . . . . . . . . . . . . . . . 38 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 105 1. Introduction 107 Service functions are widely deployed and essential in many networks. 108 These service functions provide a range of features such as security, 109 WAN acceleration, and server load balancing. Service functions may 110 be instantiated at different points in the network infrastructure 111 such as the wide area network, data center, and so forth. 113 Prior to development of the SFC architecture [RFC7665] and the 114 protocol specified in this document, current service function 115 deployment models have been relatively static and bound to topology 116 for insertion and policy selection. Furthermore, they do not adapt 117 well to elastic service environments enabled by virtualization. 119 New data center network and cloud architectures require more flexible 120 service function deployment models. Additionally, the transition to 121 virtual platforms demands an agile service insertion model that 122 supports dynamic and elastic service delivery. Specifically, the 123 following functions are necessary: 125 1. The movement of service functions and application workloads in 126 the network. 128 2. The ability to easily bind service policy to granular 129 information, such as per-subscriber state. 131 3. The capability to steer traffic to the requisite service 132 function(s). 134 The Network Service Header (NSH) specification defines a new data 135 plane protocol, which is an encapsulation for service function 136 chains. The NSH is designed to encapsulate an original packet or 137 frame, and in turn be encapsulated by an outer transport 138 encapsulation (which is used to deliver the NSH to NSH-aware network 139 elements), as shown in Figure 1: 141 +------------------------------+ 142 | Transport Encapsulation | 143 +------------------------------+ 144 | Network Service Header (NSH) | 145 +------------------------------+ 146 | Original Packet / Frame | 147 +------------------------------+ 149 Figure 1: Network Service Header Encapsulation 151 The NSH is composed of the following elements: 153 1. Service Function Path identification. 155 2. Indication of location within a Service Function Path. 157 3. Optional, per packet metadata (fixed length or variable). 159 [RFC7665] provides an overview of a service chaining architecture 160 that clearly defines the roles of the various elements and the scope 161 of a service function chaining encapsulation. Figure 3 of [RFC7665] 162 depicts the SFC architectural components after classification. The 163 NSH is the SFC encapsulation referenced in [RFC7665]. 165 1.1. Requirements Language 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 169 document are to be interpreted as described in RFC 2119 [RFC2119]. 171 1.2. Applicability 173 The NSH is designed to be easy to implement across a range of 174 devices, both physical and virtual, including hardware platforms. 176 The intended scope of the NSH is for use within a single provider's 177 operational domain. This deployment scope is deliberately 178 constrained, as explained also in [RFC7665], and limited to a single 179 network administrative domain. In this context, a "domain" is a set 180 of network entities within a single administration. For example, a 181 network administrative domain can include a single data center, or an 182 overlay domain using virtual connections and tunnels. A corollary is 183 that a network administrative domain has a well defined perimeter. 185 An NSH-aware control plane is outside the scope of this document. 187 1.3. Definition of Terms 189 Byte: All references to "bytes" in this document refer to 8-bit 190 bytes, or octets. 192 Classification: Defined in [RFC7665]. 194 Classifier: Defined in [RFC7665]. 196 Metadata: Defined in [RFC7665]. The metadata, or context 197 information shared between classifiers and SFs, and among SFs, is 198 carried on the NSH's Context Headers. It allows summarizing a 199 classification result in the packet itself, avoiding subsequent 200 re-classifications. Examples of metadata include classification 201 information used for policy enforcement and network context for 202 forwarding post service delivery. 204 Network Locator: Data plane address, typically IPv4 or IPv6, used to 205 send and receive network traffic. 207 Network Node/Element: Device that forwards packets or frames based 208 on an outer header (i.e., transport encapsulation) information. 210 Network Overlay: Logical network built on top of existing network 211 (the underlay). Packets are encapsulated or tunneled to create 212 the overlay network topology. 214 NSH-aware: NSH-aware means SFC-encapsulation-aware, where the NSH 215 provides the SFC encapsulation. This specification uses NSH-aware 216 as a more specific term from the more generic term SFC-aware 217 [RFC7665]. 219 Service Classifier: Logical entity providing classification 220 function. Since they are logical, classifiers may be co-resident 221 with SFC elements such as SFs or SFFs. Service classifiers 222 perform classification and impose the NSH. The initial classifier 223 imposes the initial NSH and sends the NSH packet to the first SFF 224 in the path. Non-initial (i.e., subsequent) classification can 225 occur as needed and can alter, or create a new service path. 227 Service Function (SF): Defined in [RFC7665]. 229 Service Function Chain (SFC): Defined in [RFC7665]. 231 Service Function Forwarder (SFF): Defined in [RFC7665]. 233 Service Function Path (SFP): Defined in [RFC7665]. 235 Service Plane: The collection of SFFs and associated SFs creates a 236 service-plane overlay in which all SFs and SFC Proxies reside 237 [RFC7665]. 239 SFC Proxy: Defined in [RFC7665]. 241 1.4. Problem Space 243 The NSH addresses several limitations associated with service 244 function deployments. [RFC7498] provides a comprehensive review of 245 those issues. 247 1.5. NSH-based Service Chaining 249 The NSH creates a dedicated service plane; more specifically, the NSH 250 enables: 252 1. Topological Independence: Service forwarding occurs within the 253 service plane, so the underlying network topology does not 254 require modification. The NSH provides an identifier used to 255 select the network overlay for network forwarding. 257 2. Service Chaining: The NSH enables service chaining per [RFC7665]. 258 The NSH contains path identification information needed to 259 realize a service path. Furthermore, the NSH provides the 260 ability to monitor and troubleshoot a service chain, end-to-end 261 via service-specific OAM messages. The NSH fields can be used by 262 administrators (via, for example, a traffic analyzer) to verify 263 (account, ensure correct chaining, provide reports, etc.) the 264 path specifics of packets being forwarded along a service path. 266 3. The NSH provides a mechanism to carry shared metadata between 267 participating entities and service functions. The semantics of 268 the shared metadata is communicated via a control plane, which is 269 outside the scope of this document, to participating nodes. 270 [I-D.ietf-sfc-control-plane] provides an example of such in 271 Section 3.3. Examples of metadata include classification 272 information used for policy enforcement and network context for 273 forwarding post service delivery. Sharing the metadata allows 274 service functions to share initial and intermediate 275 classification results with downstream service functions saving 276 re-classification, where enough information was enclosed. 278 4. The NSH offers a common and standards-based header for service 279 chaining to all network and service nodes. 281 5. Transport Encapsulation Agnostic: The NSH is transport 282 encapsulation-independent, meaning it can be transported by a 283 variety of encapsulation protocols. An appropriate (for a given 284 deployment) encapsulation protocol can be used to carry NSH- 285 encapsulated traffic. This transport encapsulation may form an 286 overlay network and if an existing overlay topology provides the 287 required service path connectivity, that existing overlay may be 288 used. 290 2. Network Service Header 292 An NSH is imposed on the original packet/frame. This NSH contains 293 service path information and optionally metadata that are added to a 294 packet or frame and used to create a service plane. Subsequently, an 295 outer transport encapsulation is imposed on the NSH, which is used 296 for network forwarding. 298 A Service Classifier adds the NSH. The NSH is removed by the last 299 SFF in the service chain or by an SF that consumes the packet. 301 2.1. Network Service Header Format 303 The NSH is composed of a 4-byte Base Header, a 4-byte Service Path 304 Header and optional Context Headers, as shown in Figure 2 below. 306 0 1 2 3 307 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 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Base Header | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Service Path Header | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | | 314 ~ Context Header(s) ~ 315 | | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 Figure 2: Network Service Header 320 Base header: Provides information about the service header and the 321 payload protocol. 323 Service Path Header: Provides path identification and location within 324 a service path. 326 Context header: Carries metadata (i.e., context data) along a service 327 path. 329 2.2. NSH Base Header 331 Figure 3 depicts the NSH base header: 333 0 1 2 3 334 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 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 Figure 3: NSH Base Header 341 Base Header Field Descriptions: 343 Version: The version field is used to ensure backward compatibility 344 going forward with future NSH specification updates. It MUST be set 345 to 0x0 by the sender, in this first revision of the NSH. If a packet 346 presumed to carry an NSH header is received at an SFF, and the SFF 347 does not understnad the version of the protocol as indicated in the 348 base header, the packet MUST be discarded, and the event SHOULD be 349 logged. Given the widespread implementation of existing hardware 350 that uses the first nibble after an MPLS label stack for equal-cost 351 multipath (ECMP) decision processing, this document reserves version 352 01b. This value MUST NOT be used in future versions of the protocol. 353 Please see [RFC7325] for further discussion of MPLS-related 354 forwarding requirements. 356 O bit: Setting this bit indicates an Operations, Administration, and 357 Maintenance (OAM, see [RFC6291]) packet. The actual format and 358 processing of SFC OAM packets is outside the scope of this 359 specification (see for example [I-D.ietf-sfc-oam-framework] for one 360 approach). 362 The O bit MUST be set for OAM packets and MUST NOT be set for non-OAM 363 packets. The O bit MUST NOT be modified along the SFP. 365 SF/SFF/SFC Proxy/Classifier implementations that do not support SFC 366 OAM procedures SHOULD discard packets with O bit set, but MAY support 367 a configurable parameter to enable forwarding received SFC OAM 368 packets unmodified to the next element in the chain. Forwarding OAM 369 packets unmodified by SFC elements that do not support SFC OAM 370 procedures may be acceptable for a subset of OAM functions, but can 371 result in unexpected outcomes for others; thus, it is recommended to 372 analyze the impact of forwarding an OAM packet for all OAM functions 373 prior to enabling this behavior. The configurable parameter MUST be 374 disabled by default. 376 TTL: Indicates the maximum SFF hops for an SFP. This field is used 377 for service plane loop detection. The initial TTL value SHOULD be 378 configurable via the control plane; the configured initial value can 379 be specific to one or more SFPs. If no initial value is explicitly 380 provided, the default initial TTL value of 63 MUST be used. Each SFF 381 involved in forwarding an NSH packet MUST decrement the TTL value by 382 1 prior to NSH forwarding lookup. Decrementing by 1 from an incoming 383 value of 0 shall result in a TTL value of 63. The packet MUST NOT be 384 forwarded if TTL is, after decrement, 0. 386 This TTL field is the primary loop prevention mechanism. This TTL 387 mechanism represents a robust complement to the Service Index (see 388 Section 2.3), as the TTL is decrement by each SFF. The handling of 389 incoming 0 TTL allows for better, although not perfect, 390 interoperation with pre-standard implementations that do not support 391 this TTL field. 393 Length: The total length, in 4-byte words, of the NSH including the 394 Base Header, the Service Path Header, the Fixed Length Context Header 395 or Variable Length Context Header(s). The length MUST be 0x6 for MD 396 Type equal to 0x1, and MUST be 0x2 or greater for MD Type equal to 397 0x2. The length of the NSH header MUST be an integer multiple of 4 398 bytes, thus variable length metadata is always padded out to a 399 multiple of 4 bytes. 401 Unassigned bits: All other flag fields, marked U, are unassigned and 402 available for future use, see Section 11.1.1. Unassigned bits MUST 403 be set to zero upon origination, and MUST be ignored and preserved 404 unmodified by other NSH supporting elements. At reception, all 405 elements MUST NOT modify their actions based on these unknown bits. 407 Metadata (MD) Type: Indicates the format of the NSH beyond the 408 mandatory Base Header and the Service Path Header. MD Type defines 409 the format of the metadata being carried. Please see the IANA 410 Considerations Section 11.1.3. 412 This document specifies the following four MD Type values: 414 0x0 - This is a reserved value. Implementations SHOULD silently 415 discard packets with MD Type 0x0. 417 0x1 - This indicates that the format of the header includes a fixed 418 length Context Header (see Figure 5 below). 420 0x2 - This does not mandate any headers beyond the Base Header and 421 Service Path Header, but may contain optional variable length Context 422 Header(s). With MD Type 0x2, a Length of 0x2 implies there are no 423 Context Headers. The semantics of the variable length Context 424 Header(s) are not defined in this document. The format of the 425 optional variable length Context Headers is provided in 426 Section 2.5.1. 428 0xF - This value is reserved for experimentation and testing, as per 429 [RFC3692]. Implementations not explicitly configured to be part of 430 an experiment SHOULD silently discard packets with MD Type 0xF. 432 The format of the Base Header and the Service Path Header is 433 invariant, and not affected by MD Type. 435 The NSH MD Type 1 and MD Type 2 are described in detail in Sections 436 2.4 and 2.5, respectively. NSH implementations MUST support MD types 437 0x1 and 0x2 (where the length is 0x2). NSH implementations SHOULD 438 support MD Type 0x2 with length greater than 0x2. Devices that do 439 not support MD Type 0x2 with length greater than 0x2 MUST ignore any 440 optional context headers and process the packet without them; the 441 base header length field can be used to determine the original 442 payload offset if access to the original packet/frame is required. 443 This specification does not disallow the MD Type value from changing 444 along an SFP; however, the specification of the necessary mechanism 445 to allow the MD Type to change along an SFP are outside the scope of 446 this document and would need to be defined for that functionality to 447 be available. Packets with MD Type values not supported by an 448 implementation MUST be silently dropped. 450 Next Protocol: indicates the protocol type of the encapsulated data. 451 The NSH does not alter the inner payload, and the semantics on the 452 inner protocol remain unchanged due to NSH service function chaining. 453 Please see the IANA Considerations section below, Section 11.1.6. 455 This document defines the following Next Protocol values: 457 0x1: IPv4 458 0x2: IPv6 459 0x3: Ethernet 460 0x4: NSH 461 0x5: MPLS 462 0xFE: Experiment 1 463 0xFF: Experiment 2 465 The functionality of hierarchical NSH using a Next Protocol value of 466 0x4 NSH is outside the scope of this specification. Packets with 467 Next Protocol values not supported SHOULD be silently dropped by 468 default, although an implementation MAY provide a configuration 469 parameter to forward them. Additionally, an implementation not 470 explicitly configured for a specific experiment [RFC3692] SHOULD 471 silently drop packets with Next Protocol values 0xFE and 0xFF. 473 2.3. Service Path Header 475 Figure 4 shows the format of the Service Path Header: 477 0 1 2 3 478 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 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Service Path Identifier (SPI) | Service Index | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 Service Path Identifier (SPI): 24 bits 484 Service Index (SI): 8 bits 486 Figure 4: NSH Service Path Header 488 The meaning of these fields is as follows: 490 Service Path Identifier (SPI): Uniquely identifies a service function 491 path. Participating nodes MUST use this identifier for Service 492 Function Path selection (SFP). The initial classifier MUST set the 493 appropriate SPI for a given classification result. 495 Service Index (SI): Provides location within the SFP. The initial 496 classifier for a given SFP SHOULD set the SI to 255, however the 497 control plane MAY configure the initial value of SI as appropriate 498 (i.e., taking into account the length of the service function path). 499 The Service Index MUST be decremented by a value of 1 by Service 500 Functions or by SFC Proxy nodes after performing required services 501 and the new decremented SI value MUST be used in the egress packet's 502 NSH. The initial Classifier MUST send the packet to the first SFF in 503 the identified SFP for forwarding along an SFP. If re-classification 504 occurs, and that re-classification results in a new SPI, the 505 (re)classifier is, in effect, the initial classifier for the 506 resultant SPI. 508 The SI is used in conjunction the with Service Path Identifier for 509 Service Function Path Selection and for determining the next SFF/SF 510 in the path. The SI is also valuable when troubleshooting or 511 reporting service paths. While the TTL provides the primary SFF 512 based loop prevention for this mechanism, SI decrement by SF serves 513 as a limited loop prevention mechanism. NSH packets, as described 514 above, are discarded when an SFF decrements the TTL to 0. In 515 addition, an SFF which is not the terminal SFF for a Service Function 516 Path will discard any NSH packet with an SI of 0, as there will be no 517 valid next SF information. 519 2.4. NSH MD Type 1 521 When the Base Header specifies MD Type = 0x1, a Fixed Length Context 522 Header (16-bytes) MUST be present immediately following the Service 523 Path Header, as per Figure 5. The value of a Fixed Length Context 524 Header that carries no metadata MUST be set to zero. 526 0 1 2 3 527 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 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | Service Path Identifier | Service Index | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | | 534 | Fixed Length Context Header | 535 | | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 Figure 5: NSH MD Type=0x1 540 This specification does not make any assumptions about the content of 541 the 16 byte Context Header that must be present when the MD Type 542 field is set to 1, and does not describe the structure or meaning of 543 the included metadata. 545 An SFC-aware SF or SFC Proxy needs to receive the data structure and 546 semantics first in order to process the data placed in the mandatory 547 context field. The data structure and semantics include both the 548 allocation schema and order, and the meaning of the included data. 549 How an SFC-aware SF or SFC Proxy gets the data structure and 550 semantics is outside the scope of this specification. 552 An SF or SFC Proxy that does not know the format or semantics of the 553 Context Header for an NSH with MD Type 1 MUST discard any packet with 554 such an NSH (i.e., MUST NOT ignore the metadata that it cannot 555 process), and MUST log the event at least once per the SPI for which 556 the event occurs (subject to thresholding). 558 [I-D.guichard-sfc-nsh-dc-allocation] and 559 [I-D.napper-sfc-nsh-broadband-allocation] provide specific examples 560 of how metadata can be allocated. 562 2.5. NSH MD Type 2 564 When the base header specifies MD Type = 0x2, zero or more Variable 565 Length Context Headers MAY be added, immediately following the 566 Service Path Header (see Figure 6). Therefore, Length = 0x2, 567 indicates that only the Base Header followed by the Service Path 568 Header are present. The optional Variable Length Context Headers 569 MUST be of an integer number of 4-bytes. The base header Length 570 field MUST be used to determine the offset to locate the original 571 packet or frame for SFC nodes that require access to that 572 information. 574 0 1 2 3 575 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 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | Service Path Identifier | Service Index | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | | 582 ~ Variable Length Context Headers (opt.) ~ 583 | | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 Figure 6: NSH MD Type=0x2 588 2.5.1. Optional Variable Length Metadata 590 The format of the optional variable length Context Headers, is as 591 depicted in Figure 7. 593 0 1 2 3 594 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 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | Metadata Class | Type |U| Length | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | Variable Metadata | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 Figure 7: Variable Context Headers 603 Metadata Class (MD Class): Defines the scope of the 'Type' field to 604 provide a hierarchical namespace. The IANA Considerations 605 Section 11.1.4 defines how the MD Class values can be allocated to 606 standards bodies, vendors, and others. 608 Type: Indicates the explicit type of metadata being carried. The 609 definition of the Type is the responsibility of the MD Class owner. 611 Unassigned bit: One unassigned bit is available for future use. This 612 bit MUST NOT be set, and MUST be ignored on receipt. 614 Length: Indicates the length of the variable metadata, in bytes. In 615 case the metadata length is not an integer number of 4-byte words, 616 the sender MUST add pad bytes immediately following the last metadata 617 byte to extend the metadata to an integer number of 4-byte words. 618 The receiver MUST round up the length field to the nearest 4-byte 619 word boundary, to locate and process the next field in the packet. 620 The receiver MUST access only those bytes in the metadata indicated 621 by the length field (i.e., actual number of bytes) and MUST ignore 622 the remaining bytes up to the nearest 4-byte word boundary. The 623 Length may be 0 or greater. 625 A value of 0 denotes a Context Header without a Variable Metadata 626 field. 628 This specification does not make any assumption about Context Headers 629 that are mandatory-to-implement or those that are mandatory-to- 630 process. These considerations are deployment-specific. However, the 631 control plane is entitled to instruct SFC-aware SFs with the data 632 structure of context header together with its scoping (see e.g., 633 Section 3.3.3 of [I-D.ietf-sfc-control-plane]). 635 Upon receipt of a packet that belongs to a given SFP, if a mandatory- 636 to-process context header is missing in that packet, the SFC-aware SF 637 MUST NOT process the packet and MUST log an error at least once per 638 the SPI for which the mandatory metadata is missing. 640 If multiple mandatory-to-process context headers are required for a 641 given SFP, the control plane MAY instruct the SFC-aware SF with the 642 order to consume these Context Headers. If no instructions are 643 provided and the SFC-aware SF will make use of or modify the specific 644 context header, then the SFC-aware SF MUST process these Context 645 Headers in the order they appear in an NSH packet. 647 If multiple instances of the same metadata are included in an NSH 648 packet, but the definition of that context header does not allow for 649 it, the SFC-aware SF MUST process the first instance and ignore 650 subsequent instances. The SFC-aware SF MAY log or increase a counter 651 for this event. 653 3. NSH Actions 655 NSH-aware nodes, which include service classifiers, SFFs, SFs and SFC 656 proxies, may alter the contents of the NSH headers. These nodes have 657 several possible NSH-related actions: 659 1. Insert or remove the NSH: These actions can occur respectively at 660 the start and end of a service path. Packets are classified, and 661 if determined to require servicing, an NSH will be imposed. A 662 service classifier MUST insert an NSH at the start of an SFP. An 663 imposed NSH MUST contain both a valid Base Header and Service 664 Path Header. At the end of a service function path, an SFF MUST 665 remove the NSH before forwarding or delivering the un- 666 encapsulated packet. It is therefore the last node operating on 667 the service header. 669 Multiple logical classifiers may exist within a given service 670 path. Non-initial classifiers may re-classify data and that re- 671 classification MAY result in the selection of a different Service 672 Function Path. When the logical classifier performs re- 673 classification that results in a change of service path, it MUST 674 replace the existing NSH with a new NSH with the Base Header and 675 Service Path Header reflecting the new service path information 676 and MUST set the initial SI. The O bit, the TTL field, as well 677 as unassigned flags, MUST be copied transparently from the old 678 NSH to a new NSH. Metadata MAY be preserved in the new NSH. 680 2. Select service path: The Service Path Header provides service 681 path information and is used by SFFs to determine correct service 682 path selection. SFFs MUST use the Service Path Header for 683 selecting the next SF or SFF in the service path. 685 3. Update the NSH: SFs MUST decrement the service index by one. If 686 an SFF receives a packet with an SPI and SI that do not 687 correspond to a valid next hop in a valid Service Function Path, 688 that packet MUST be dropped by the SFF. 690 Classifiers MAY update Context Headers if new/updated context is 691 available. 693 If an SFC proxy is in use (acting on behalf of an NSH-unaware 694 service function for NSH actions), then the proxy MUST update 695 Service Index and MAY update contexts. When an SFC proxy 696 receives an NSH-encapsulated packet, it MUST remove the NSH 697 before forwarding it to an NSH-unaware SF. When the SFC Proxy 698 receives a packet back from an NSH-unaware SF, it MUST re- 699 encapsulate it with the correct NSH, and MUST decrement the 700 Service Index by one. 702 4. Service policy selection: Service Functions derive policy (i.e., 703 service actions such as permit or deny) selection and enforcement 704 from the NSH. Metadata shared in the NSH can provide a range of 705 service-relevant information such as traffic classification. 707 Figure 8 maps each of the four actions above to the components in the 708 SFC architecture that can perform it. 710 +-----------+-----------------------+-------+---------------+-------+ 711 | | Insert, remove, or |Forward| Update |Service| 712 | | replace the NSH |the NSH| the NSH |policy | 713 | | |Packets| |sel. | 714 |Component +-------+-------+-------+ +-------+-------+ | 715 | | | | | |Dec. |Update | | 716 | |Insert |Remove |Replace| |Service|Context| | 717 | | | | | |Index |Header | | 718 +-----------+-------+-------+-------+-------+-------+-------+-------+ 719 | | + | | + | | | + | | 720 |Classifier | | | | | | | | 721 +-----------+-------+-------+-------+-------+-------+-------+-------+ 722 |Service | | + | | + | | | | 723 |Function | | | | | | | | 724 |Forwarder | | | | | | | | 725 |(SFF) | | | | | | | | 726 +-----------+-------+-------+-------+-------+-------+-------+-------+ 727 |Service | | | | | + | + | + | 728 |Function | | | | | | | | 729 |(SF) | | | | | | | | 730 +-----------+-------+-------+-------+-------+-------+-------+-------+ 731 | | + | + | | | + | + | | 732 |SFC Proxy | | | | | | | | 733 +-----------+-------+-------+-------+-------+-------+-------+-------+ 735 Figure 8: NSH Action and Role Mapping 737 4. NSH Transport Encapsulation 739 Once the NSH is added to a packet, an outer transport encapsulation 740 is used to forward the original packet and the associated metadata to 741 the start of a service chain. The encapsulation serves two purposes: 743 1. Creates a topologically independent services plane. Packets are 744 forwarded to the required services without changing the 745 underlying network topology. 747 2. Transit network nodes simply forward the encapsulated packets 748 without modification. 750 The service header is independent of the transport encapsulation 751 used. Existing transport encapsulations can be used. The presence 752 of an NSH is indicated via a protocol type or another indicator in 753 the outer transport encapsulation. 755 5. Fragmentation Considerations 757 The NSH and the associated transport encapsulation header are "added" 758 to the encapsulated packet/frame. This additional information 759 increases the size of the packet. 761 Within a managed administrative domain, an operator can ensure that 762 the underlay MTU is sufficient to carry SFC traffic without requiring 763 fragmentation. Given that the intended scope of the NSH is within a 764 single provider's operational domain, that approach is sufficient. 766 However, although explicitly outside the scope of this specification, 767 there might be cases where the underlay MTU is not large enough to 768 carry the NSH traffic. Since the NSH does not provide fragmentation 769 support at the service plane, the transport encapsulation protocol 770 ought to provide the requisite fragmentation handling. For instance, 771 Section 9 of [I-D.ietf-rtgwg-dt-encap] provides exemplary approaches 772 and guidance for those scenarios. 774 When the transport encapsulation protocol supports fragmentation, and 775 fragmentation procedures needs to be used, such fragmentation is part 776 of the transport encapsulation logic. If, as it is common, 777 fragmentation is performed by the endpoints of the transport 778 encapsulation, then fragmentation procedures are performed at the 779 sending NSH entity as part of the transport encapsulation, and 780 reassembly procedures are performed at the receiving NSH entity 781 during transport de-encapsulation handling logic. In no case would 782 such fragmentation result in duplication of the NSH header. 784 For example, when the NSH is encapsulated in IP, IP-level 785 fragmentation coupled with Path MTU Discovery (PMTUD) (e.g., 786 [RFC8201]) is used. Since PMTUD relies on ICMP messages, an operator 787 should ensure ICMP packets are not blocked. When, on the other hand, 788 the underlay does not support fragmentation procedures, an error 789 message SHOULD be logged when dropping a packet too big. Lastly, 790 NSH-specific fragmentation and reassembly methods may be defined as 791 well, but these methods are outside the scope of this document, and 792 subject for future work. 794 6. Service Path Forwarding with NSH 796 6.1. SFFs and Overlay Selection 798 As described above, the NSH contains a Service Path Identifier (SPI) 799 and a Service Index (SI). The SPI is, as per its name, an 800 identifier. The SPI alone cannot be used to forward packets along a 801 service path. Rather the SPI provides a level of indirection between 802 the service path/topology and the network transport encapsulation. 804 Furthermore, there is no requirement, or expectation of an SPI being 805 bound to a pre-determined or static network path. 807 The Service Index provides an indication of location within a service 808 path. The combination of SPI and SI provides the identification of a 809 logical SF and its order within the service plane, and is used to 810 select the appropriate network locator(s) for overlay forwarding. 811 The logical SF may be a single SF, or a set of eligible SFs that are 812 equivalent. In the latter case, the SFF provides load distribution 813 amongst the collection of SFs as needed. 815 SI serves as a mechanism for detecting invalid service function 816 paths. In particular, an SI value of zero indicates that forwarding 817 is incorrect and the packet must be discarded. 819 This indirection -- SPI to overlay -- creates a true service plane. 820 That is, the SFF/SF topology is constructed without impacting the 821 network topology but more importantly, service plane only 822 participants (i.e., most SFs) need not be part of the network overlay 823 topology and its associated infrastructure (e.g., control plane, 824 routing tables, etc.) SFs need to be able to return a packet to an 825 appropriate SFF (i.e., has the requisite NSH information) when 826 service processing is complete. This can be via the overlay or 827 underlay and in some cases require additional configuration on the 828 SF. As mentioned above, an existing overlay topology may be used 829 provided it offers the requisite connectivity. 831 The mapping of SPI to transport encapsulation occurs on an SFF (as 832 discussed above, the first SFF in the path gets an NSH encapsulated 833 packet from the Classifier). The SFF consults the SPI/ID values to 834 determine the appropriate overlay transport encapsulation protocol 835 (several may be used within a given network) and next hop for the 836 requisite SF. Table 1 below depicts an example of a single next-hop 837 SPI/SI to network overlay network locator mapping. 839 +------+------+---------------------+-------------------------+ 840 | SPI | SI | Next hop(s) | Transport Encapsulation | 841 +------+------+---------------------+-------------------------+ 842 | 10 | 255 | 192.0.2.1 | VXLAN-gpe | 843 | | | | | 844 | 10 | 254 | 198.51.100.10 | GRE | 845 | | | | | 846 | 10 | 251 | 198.51.100.15 | GRE | 847 | | | | | 848 | 40 | 251 | 198.51.100.15 | GRE | 849 | | | | | 850 | 50 | 200 | 01:23:45:67:89:ab | Ethernet | 851 | | | | | 852 | 15 | 212 | Null (end of path) | None | 853 +------+------+---------------------+-------------------------+ 855 Table 1: SFF NSH Mapping Example 857 Additionally, further indirection is possible: the resolution of the 858 required SF network locator may be a localized resolution on an SFF, 859 rather than a service function chain control plane responsibility, as 860 per Table 2 and Table 3 below. 862 Please note: VXLAN-gpe and GRE in the above table refer to 863 [I-D.ietf-nvo3-vxlan-gpe] and [RFC2784] [RFC7676], respectively. 865 +------+-----+----------------+ 866 | SPI | SI | Next hop(s) | 867 +------+-----+----------------+ 868 | 10 | 3 | SF2 | 869 | | | | 870 | 245 | 12 | SF34 | 871 | | | | 872 | 40 | 9 | SF9 | 873 +------+-----+----------------+ 875 Table 2: NSH to SF Mapping Example 877 +------+-------------------+-------------------------+ 878 | SF | Next hop(s) | Transport Encapsulation | 879 +------+-------------------+-------------------------+ 880 | SF2 | 192.0.2.2 | VXLAN-gpe | 881 | | | | 882 | SF34 | 198.51.100.34 | UDP | 883 | | | | 884 | SF9 | 2001:db8::1 | GRE | 885 +------+-------------------+-------------------------+ 887 Table 3: SF Locator Mapping Example 889 Since the SPI is a representation of the service path, the lookup may 890 return more than one possible next-hop within a service path for a 891 given SF, essentially a series of weighted (equally or otherwise) 892 paths to be used (for load distribution, redundancy, or policy), see 893 Table 4. The metric depicted in Table 4 is an example to help 894 illustrated weighing SFs. In a real network, the metric will range 895 from a simple preference (similar to routing next-hop), to a true 896 dynamic composite metric based on some service function-centric state 897 (including load, sessions state, capacity, etc.) 899 +------+-----+--------------+---------+ 900 | SPI | SI | NH | Metric | 901 +------+-----+--------------+---------+ 902 | 10 | 3 | 203.0.113.1 | 1 | 903 | | | | | 904 | | | 203.0.113.2 | 1 | 905 | | | | | 906 | 20 | 12 | 192.0.2.1 | 1 | 907 | | | | | 908 | | | 203.0.113.4 | 1 | 909 | | | | | 910 | 30 | 7 | 192.0.2.10 | 10 | 911 | | | | | 912 | | | 198.51.100.1 | 5 | 913 +------+-----+--------------+---------+ 915 (encapsulation type omitted for formatting) 917 Table 4: NSH Weighted Service Path 919 The information contained in Tables 1-4 may be received from the 920 control plane, but the exact mechanism is outside the scope of this 921 document. 923 6.2. Mapping the NSH to Network Topology 925 As described above, the mapping of SPI to network topology may result 926 in a single path, or it might result in a more complex topology. 927 Furthermore, the SPI to overlay mapping occurs at each SFF 928 independently. Any combination of topology selection is possible. 929 Please note, there is no requirement to create a new overlay topology 930 if a suitable one already exists. NSH packets can use any (new or 931 existing) overlay provided the requisite connectivity requirements 932 are satisfied. 934 Examples of mapping for a topology: 936 1. Next SF is located at SFFb with locator 2001:db8::1 937 SFFa mapping: SPI=10 --> VXLAN-gpe, dst-ip: 2001:db8::1 939 2. Next SF is located at SFFc with multiple network locators for 940 load distribution purposes: 941 SFFb mapping: SPI=10 --> VXLAN-gpe, dst_ip:203.0.113.1, 942 203.0.113.2, 203.0.113.3, equal cost 944 3. Next SF is located at SFFd with two paths from SFFc, one for 945 redundancy: 946 SFFc mapping: SPI=10 --> VXLAN-gpe, dst_ip:192.0.2.10 cost=10, 947 203.0.113.10, cost=20 949 In the above example, each SFF makes an independent decision about 950 the network overlay path and policy for that path. In other words, 951 there is no a priori mandate about how to forward packets in the 952 network (only the order of services that must be traversed). 954 The network operator retains the ability to engineer the network 955 paths as required. For example, the overlay path between SFFs may 956 utilize traffic engineering, QoS marking, or ECMP, without requiring 957 complex configuration and network protocol support to be extended to 958 the service path explicitly. In other words, the network operates as 959 expected, and evolves as required, as does the service plane. 961 6.3. Service Plane Visibility 963 The SPI and SI serve an important function for visibility into the 964 service topology. An operator can determine what service path a 965 packet is "on", and its location within that path simply by viewing 966 NSH information (packet capture, IPFIX, etc.) The information can be 967 used for service scheduling and placement decisions, troubleshooting, 968 and compliance verification. 970 6.4. Service Graphs 972 While a given realized service function path is a specific sequence 973 of service functions, the service as seen by a user can actually be a 974 collection of service function paths, with the interconnection 975 provided by classifiers (in-service path, non-initial 976 reclassification). These internal reclassifiers examine the packet 977 at relevant points in the network, and, if needed, SPI and SI are 978 updated (whether this update is a re-write, or the imposition of a 979 new NSH with new values is implementation specific) to reflect the 980 "result" of the classification. These classifiers may, of course, 981 also modify the metadata associated with the packet. 982 [RFC7665], Section 2.1 describes Service Graphs in detail. 984 7. Policy Enforcement with NSH 986 7.1. NSH Metadata and Policy Enforcement 988 As described in Section 2, NSH provides the ability to carry metadata 989 along a service path. This metadata may be derived from several 990 sources. Common examples include: 992 Network nodes/devices: Information provided by network nodes can 993 indicate network-centric information (such as VRF or tenant) that 994 may be used by service functions or conveyed to another network 995 node post service path egress. 997 External (to the network) systems: External systems, such as 998 orchestration systems, often contain information that is valuable 999 for service function policy decisions. In most cases, this 1000 information cannot be deduced by network nodes. For example, a 1001 cloud orchestration platform placing workloads "knows" what 1002 application is being instantiated and can communicate this 1003 information to all NSH nodes via metadata carried in the context 1004 header(s). 1006 Service Functions: A classifier co-resident with Service Functions 1007 often perform very detailed and valuable classification. 1009 Regardless of the source, metadata reflects the "result" of 1010 classification. The granularity of classification may vary. For 1011 example, a network switch, acting as a classifier, might only be able 1012 to classify based on a 2-tuple, or based on a 5-tuple, while a 1013 service function may be able to inspect application information. 1014 Regardless of granularity, the classification information can be 1015 represented in the NSH. 1017 Once the data is added to the NSH, it is carried along the service 1018 path, NSH-aware SFs receive the metadata, and can use that metadata 1019 for local decisions and policy enforcement. Figure 9 and Figure 10 1020 highlight the relationship between metadata and policy: 1022 +-------+ +-------+ +-------+ 1023 | SFF )------->( SFF |------->| SFF | 1024 +---+---+ +---+---+ +---+---+ 1025 ^ | | 1026 ,-|-. ,-|-. ,-|-. 1027 / \ / \ / \ 1028 ( Class ) ( SF1 ) ( SF2 ) 1029 \ ify / \ / \ / 1030 `---' `---' `---' 1031 5-tuple: Permit Inspect 1032 Tenant A Tenant A AppY 1033 AppY 1035 Figure 9: Metadata and Policy 1037 +-----+ +-----+ +-----+ 1038 | SFF |---------> | SFF |----------> | SFF | 1039 +--+--+ +--+--+ +--+--+ 1040 ^ | | 1041 ,-+-. ,-+-. ,-+-. 1042 / \ / \ / \ 1043 ( Class ) ( SF1 ) ( SF2 ) 1044 \ ify / \ / \ / 1045 `-+-' `---' `---' 1046 | Permit Deny AppZ 1047 +---+---+ employees 1048 | | 1049 +-------+ 1050 External 1051 system: 1052 Employee 1053 AppZ 1055 Figure 10: External Metadata and Policy 1057 In both of the examples above, the service functions perform policy 1058 decisions based on the result of the initial classification: the SFs 1059 did not need to perform re-classification; instead, they rely on a 1060 antecedent classification for local policy enforcement. 1062 Depending on the information carried in the metadata, data privacy 1063 impact needs to be considered. For example, if the metadata conveys 1064 tenant information, that information may need to be authenticated 1065 and/or encrypted between the originator and the intended recipients 1066 (which may include intended SFs only); one approach to an optional 1067 capability to do this is explored in [I-D.reddy-sfc-nsh-encrypt]. 1068 The NSH itself does not provide privacy functions, rather it relies 1069 on the transport encapsulation/overlay. An operator can select the 1070 appropriate set of transport encapsulation protocols to ensure 1071 confidentiality (and other security) considerations are met. 1072 Metadata privacy and security considerations are a matter for the 1073 documents that define metadata format. 1075 7.2. Updating/Augmenting Metadata 1077 Post-initial metadata imposition (typically performed during initial 1078 service path determination), the metadata may be augmented or 1079 updated: 1081 1. Metadata Augmentation: Information may be added to the NSH's 1082 existing metadata, as depicted in Figure 11. For example, if the 1083 initial classification returns the tenant information, a 1084 secondary classification (perhaps co-resident with DPI or SLB) 1085 may augment the tenant classification with application 1086 information, and impose that new information in NSH metadata. 1087 The tenant classification is still valid and present, but 1088 additional information has been added to it. 1090 2. Metadata Update: Subsequent classifiers may update the initial 1091 classification if it is determined to be incorrect or not 1092 descriptive enough. For example, the initial classifier adds 1093 metadata that describes the traffic as "Internet" but a security 1094 service function determines that the traffic is really "attack". 1095 Figure 12 illustrates an example of updating metadata. 1097 +-----+ +-----+ +-----+ 1098 | SFF |---------> | SFF |----------> | SFF | 1099 +--+--+ +--+--+ +--+--+ 1100 ^ | | 1101 ,---. ,---. ,---. 1102 / \ / \ / \ 1103 ( Class ) ( SF1 ) ( SF2 ) 1104 \ / \ / \ / 1105 `-+-' `---' `---' 1106 | Inspect Deny 1107 +---+---+ employees employee+ 1108 | | Class=AppZ appZ 1109 +-------+ 1110 External 1111 system: 1112 Employee 1114 Figure 11: Metadata Augmentation 1116 +-----+ +-----+ +-----+ 1117 | SFF |---------> | SFF |----------> | SFF | 1118 +--+--+ +--+--+ +--+--+ 1119 ^ | | 1120 ,---. ,---. ,---. 1121 / \ / \ / \ 1122 ( Class ) ( SF1 ) ( SF2 ) 1123 \ / \ / \ / 1124 `---' `---' `---' 1125 5-tuple: Inspect Deny 1126 Tenant A Tenant A attack 1127 --> attack 1129 Figure 12: Metadata Update 1131 7.3. Service Path Identifier and Metadata 1133 Metadata information may influence the service path selection since 1134 the Service Path Identifier values can represent the result of 1135 classification. A given SPI can be defined based on classification 1136 results (including metadata classification). The imposition of the 1137 SPI and SI results in the packet being placed on the newly specified 1138 SFP at the position indicated by the imposed SPI and SI. 1140 This relationship provides the ability to create a dynamic service 1141 plane based on complex classification without requiring each node to 1142 be capable of such classification, or requiring a coupling to the 1143 network topology. This yields service graph functionality as 1144 described in Section 6.4. Figure 13 illustrates an example of this 1145 behavior. 1147 +-----+ +-----+ +-----+ 1148 | SFF |---------> | SFF |------+---> | SFF | 1149 +--+--+ +--+--+ | +--+--+ 1150 | | | | 1151 ,---. ,---. | ,---. 1152 / \ / SF1 \ | / \ 1153 ( SCL ) ( + ) | ( SF2 ) 1154 \ / \SCL2 / | \ / 1155 `---' `---' +-----+ `---' 1156 5-tuple: Inspect | SFF | Original 1157 Tenant A Tenant A +--+--+ next SF 1158 --> DoS | 1159 V 1160 ,-+-. 1161 / \ 1162 ( SF10 ) 1163 \ / 1164 `---' 1165 DoS 1166 "Scrubber" 1168 Figure 13: Path ID and Metadata 1170 Specific algorithms for mapping metadata to an SPI are outside the 1171 scope of this document. 1173 8. Security Considerations 1175 NSH security must be considered in the contexts of the SFC 1176 architecture and operators' environments. One important 1177 characteristic of NSH is that it is not an end-to-end protocol. As 1178 opposed to a protocol that "starts" on a host, and "ends" on a server 1179 or another host, NSH is typically imposed by a network device on 1180 ingress to the SFC domain and removed at the egress of the SFC 1181 domain. As such, and as with any other network-centric protocol 1182 (e.g., IP Tunneling, Traffic Engineering, MPLS, or Provider 1183 Provisioned Virtual Private Networks) there an underlying trust that 1184 the network devices responsible for imposing, removing and acting on 1185 NSH information are trusted. 1187 The following sections detail an analysis and present a set of 1188 requirements and recommendations in those two areas. 1190 8.1. NSH Security Considerations from Operators' Environments 1192 Trusted Devices 1194 All classifiers, SFFs and SFSs (hereinafter referred to as "SFC 1195 devices") within an operator's environment are assumed to have 1196 been selected, vetted, and actively maintained, therefore trusted 1197 by that operator. This assumption differs from the oft held view 1198 that devices are untrusted, often refered to as zero trust model. 1199 Operators SHOULD regularly monitor (i.e. continuously audit) these 1200 devices to help ensure complaint behavior. This trust, therefore, 1201 extends into NSH operations: SFC devices are not, themselves, 1202 considered as attack vectors. This assumption, and the resultant 1203 conclusion is reasonable since this is the very basis of an 1204 operator posture; the operator depends on this reality to 1205 function. If these devices are not trusted, and indeed 1206 compromised, almost the entirety of the operator's standard-based 1207 IP and MPLS protocol suites are vulnerable, and therefore the 1208 operation of the entire network is compromised. Although there 1209 are well documented monitoring-based methods for detecting 1210 compromise, such as include continous monitoring, audit and log 1211 review, these may not be sufficient to contain damage by a 1212 completely compromised element. 1214 Methods and best practices to secure devices are also widely 1215 documented and outside the scope of this document. 1217 Single Domain Boundary 1219 As per [RFC7665], NSH is designed for use within a single 1220 administrative domain. This scoping provides two important 1221 characteristics: 1223 i) Clear NSH boundaries 1225 NSH egress devices MUST strip the NSH headers before they send the 1226 users' packets or frames out of the NSH domain. 1228 Means to prevent leaking privacy-related information outside an 1229 administrative domain are natively supported by the NSH given that 1230 the last SFF of a service path will systematically remove the NSH 1231 encapsulation before forwarding a packet exiting the service path. 1233 The second step in such prevention is to filter the transport 1234 encapsulation protocol used by NSH at the domain edge. The 1235 transport encapsulation protocol MUST be filtered and MUST NOT 1236 leave the domain edge. 1238 Depending upon the transport encapsulation protocol used for NSH, 1239 this can either be done by completely blocking the transport 1240 encapsulation (e.g., if MPLS is the chosen NSH transport 1241 encapsulation protocol, it is therefore never allowed to leave the 1242 domain) or by examining the carried protocol with the transport 1243 encapsulation (e.g., if VxLAN-gpe is used as the NSH transport 1244 encapsulation protocol, all domain edges need to filter based on 1245 the carried protocol in the VxLAN-gpe.) 1247 The other consequence of this bounding is that ingress packets 1248 MUST also be filtered to prevent attackers from sending in NSH 1249 packets with service path identification and metadata of their own 1250 selection. The same filters as described above for both the NSH 1251 at SFC devices and for the transport encapsulation protocol as 1252 general edge protections MUST be applied on ingress. 1254 In summary, packets originating outside the SFC-enabled domain 1255 MUST be dropped if they contain an NSH. Similarly, packets 1256 exiting the SFC-enabled domain MUST be dropped if they contain an 1257 NSH. 1259 ii) Mitigation of external threats 1261 As per the trusted SFC devices points raised above, given that NSH 1262 is scoped within an operator's domain, that operator can ensure 1263 that the environment, and its transitive properties, comply to 1264 that operator's required security posture. Continuous audits for 1265 assurance are recommended with this reliance on a fully trusted 1266 environment. The term 'continuous audits' describes a method 1267 (automated or manual) of checking security control compliance on a 1268 regular basis, at some set period of time. 1270 8.2. NSH Security Considerations from the SFC Architecture 1272 The SFC architecture defines functional roles (e.g., SFF), as well as 1273 protocol element (e.g. Metadata). This section considers each role 1274 and element in the context of threats posed in the areas of integrity 1275 and confidentiality. As with routing, the distributed computation 1276 model assumes a distributed trust model. 1278 An important consideration is that NSH contains mandatory to mute 1279 fields, and further, the SFC architecture describes cases where other 1280 fields in NSH change, all on a possible SFP hop-by-hop basis. This 1281 means that any cryptographic solution requires complex key 1282 distribution and lifecycle operations. 1284 8.2.1. Integrity 1286 SFC devices 1288 SFC devices MAY perform various forms of verification on received 1289 NSH packets such as only accepting NSH packets from expected 1290 devices, checking that NSH SPI and SI values received from 1291 expected devices conform to expected values and so on. 1292 Implementation of these additional checks are a local matter and 1293 thus out of scope of this document. 1295 NSH Base and Service Path Headers 1297 Attackers who can modify packets within the operator's network may 1298 be able to modify the service function path, path position, and / 1299 or the metadata associated with a packet. 1301 One specific concern is an attack in which a malicious 1302 modification of the SPI/SI results in an alteration of the path to 1303 avoid security devices. The options discussed in this section 1304 help twart that attack, and so does the use of the optional "Proof 1305 of Transit" method [I-D.brockners-proof-of-transit]. 1307 As stated above, SFC devices are trusted; in the case where an SFC 1308 device is compromised, NSH integrity protection would be subject 1309 to forging (in many cases) as well. 1311 NSH itself does not mandate protocol-specific integrity 1312 protection. However, if an operator deems protection required, 1313 several options are viable: 1315 1. SFF/SF NSH verification 1317 Although strictly speaking not integrity protection, some of 1318 the techniques mentioned above such as checking expected NSH 1319 values are received from expected SFC device(s) can provide a 1320 form of verification without incurring the burden of a full- 1321 fledged integrity protection deployment. 1323 2. Transport Security 1325 NSH is always encapsulated by an outer transport encapsulation 1326 as detailed in Section 4 of this specification, and as 1327 depicted in Figure 1. If an operator deems cryptographic 1328 integrity protection necessary due to their risk analysis, 1329 then an outer transport encapsulation that provides such 1330 protection [RFC6071], such as IPsec, MUST be used. 1332 Although the threat model and recommendations of BCP 72 1333 [RFC3552] Section 5 would normally require cryptographic data 1334 origin authentication for the header, this document does not 1335 mandate such mechanisms in order to reflect the operational 1336 and technical realities of deployment. 1338 Given that NSH is transport independent, as mentioned above, a 1339 secure transport, such as IPsec can be used for carry NSH. 1340 IPsec can be used either alone, or in conjunction with other 1341 transport encapsulation protocols in turn encapsulating NSH. 1343 Operators MUST ensure the selected transport encapsulation 1344 protocol can be supported by the transport encapsulation/ 1345 underlay of all relevant network segments as well as SFFs, SFs 1346 and SFC proxies in the service path. 1348 If connectivity between SFC-enabled devices traverses the 1349 public Internet, then such connectivity MUST be secured at the 1350 transport encapsulation layer. IPsec is an example of such a 1351 transport. 1353 3. NSH Variable Header-based Integrity 1355 Lastly, NSH MD-Type 2 provides, via variable length headers, 1356 the ability to append cryptographic integrity protection to 1357 the NSH packet. The implementation of such a scheme is 1358 outside the scope of this document. 1360 NSH metadata 1362 As with the base and service path headers, if an operator deems 1363 cryptographic integrity protection needed, then an existing, 1364 standard transport protocol MUST be used since the integrity 1365 protection applies to entire encapsulated NSH packets. As 1366 mentioned above, a risk assessment that deems dataplane traffic 1367 subject to tampering will apply not only to NSH but to the 1368 transport information and therefore the use of a secure transport 1369 is likely needed already to protect the entire stack. 1371 If an MD-Type 2 variable header integrity scheme is in place, then 1372 the integrity of the metadata can be ensured via that mechanism as 1373 well. 1375 8.2.2. Confidentiality 1377 SFC devices 1379 SFC devices can "see" (and need to use) NSH information. 1381 NSH base and service path headers 1383 SPI and other base/service path information does not typically 1384 require confidentiality; however, if an operator does deem 1385 confidentiality required, then, as with integrity, an existing 1386 transport encapsulation that provides encryption MUST be utilized. 1388 NSH metadata 1390 An attacker with access to the traffic in an operator's network 1391 can potentially observe the metadata NSH carries with packets, 1392 potentially discovering privacy sensitive information. 1394 Much of the metadata carried by NSH is not sensitive. It often 1395 reflects information that can be derived from the underlying 1396 packet or frame. Direct protection of such information is not 1397 necessary, as the risks are simply those of carrying the 1398 underlying packet or frame. 1400 Implementers and operators MUST be aware that metadata can have 1401 privacy implications, and those implications are sometimes hard to 1402 predict. Therefore, attached metadata should be limited to that 1403 necessary for correct operation of the SFP. Further, [RFC8165] 1404 defines metadata considerations that operators can take into 1405 account when using NSH. 1407 Protecting NSH metadata information between SFC components can be 1408 done using transport encapsulation protocols with suitable 1409 security capabilities, along the lines discussed above. If a 1410 security analysis deems these protections necessary, then security 1411 features in the transport encapsulation protocol (such as IPsec) 1412 MUST be used. 1414 One useful element of providing privacy protection for sensitive 1415 metadata is described under the "SFC Encapsulation" area of the 1416 Security Considerations of [RFC7665]. Operators can and should 1417 use indirect identification for metadata deemed to be sensitive 1418 (such as personally identifying information) significantly 1419 mitigating the risk of a privacy violation. In particular, 1420 subscriber identifying information should be handled carefully, 1421 and in general SHOULD be obfuscated. 1423 For those situations where obfuscation is either inapplicable or 1424 judged to be insufficient, an operator can also encrypt the 1425 metadata. An approach to an optional capability to do this was 1426 explored in [I-D.reddy-sfc-nsh-encrypt]. For other situations 1427 where greater assurance is desired, optional mechanisms such as 1428 [I-D.brockners-proof-of-transit] can be used. 1430 9. Contributors 1432 This WG document originated as draft-quinn-sfc-nsh; the following are 1433 its co-authors and contributors along with their respective 1434 affiliations at the time of WG adoption. The editors of this 1435 document would like to thank and recognize them and their 1436 contributions. These co-authors and contributors provided invaluable 1437 concepts and content for this document's creation. 1439 o Jim Guichard, Cisco Systems, Inc. 1441 o Surendra Kumar, Cisco Systems, Inc. 1443 o Michael Smith, Cisco Systems, Inc. 1445 o Wim Henderickx, Alcatel-Lucent 1447 o Tom Nadeau, Brocade 1449 o Puneet Agarwal 1451 o Rajeev Manur, Broadcom 1453 o Abhishek Chauhan, Citrix 1455 o Joel Halpern, Ericsson 1457 o Sumandra Majee, F5 1459 o David Melman, Marvell 1461 o Pankaj Garg, Microsoft 1463 o Brad McConnell, Rackspace 1465 o Chris Wright, Red Hat, Inc. 1467 o Kevin Glavin, Riverbed 1469 o Hong (Cathy) Zhang, Huawei US R&D 1470 o Louis Fourie, Huawei US R&D 1472 o Ron Parker, Affirmed Networks 1474 o Myo Zarny, Goldman Sachs 1476 o Andrew Dolganow, Alcatel-Lucent 1478 o Rex Fernando, Cisco Systems, Inc. 1480 o Praveen Muley, Alcatel-Lucent 1482 o Navindra Yadav, Cisco Systems, Inc. 1484 10. Acknowledgments 1486 The authors would like to thank Sunil Vallamkonda, Nagaraj Bagepalli, 1487 Abhijit Patra, Peter Bosch, Darrel Lewis, Pritesh Kothari, Tal 1488 Mizrahi and Ken Gray for their detailed review, comments and 1489 contributions. 1491 A special thank you goes to David Ward and Tom Edsall for their 1492 guidance and feedback. 1494 Additionally the authors would like to thank Larry Kreeger for his 1495 invaluable ideas and contributions which are reflected throughout 1496 this document. 1498 Loa Andersson provided a thorough review and valuable comments, we 1499 thank him for that. 1501 Reinaldo Penno deserves a particular thank you for his architecture 1502 and implementation work that helped guide the protocol concepts and 1503 design. 1505 The editors also acknowledge comprehensive reviews and respective 1506 useful suggestions by Med Boucadair, Adrian Farrel, Juergen 1507 Schoenwaelder, Acee Lindem, and Kathleen Moriarty. 1509 Lastly, David Dolson has provides significant review, feedback and 1510 suggestions throughout the evolution of this document. His 1511 contributions are very much appreciated. 1513 11. IANA Considerations 1514 11.1. Network Service Header (NSH) Parameters 1516 IANA is requested to create a new "Network Service Header (NSH) 1517 Parameters" registry. The following sub-sections request new 1518 registries within the "Network Service Header (NSH) Parameters " 1519 registry. 1521 11.1.1. NSH Base Header Bits 1523 There are five unassigned bits (U bits) in the NSH Base Header, and 1524 one assigned bit (O bit). New bits are assigned via Standards Action 1525 [RFC8126]. 1527 Bit 2 - O (OAM) bit 1528 Bit 3 - Unassigned 1529 Bits 16-19 - Unassigned 1531 11.1.2. NSH Version 1533 IANA is requested to setup a registry of "NSH Version". New values 1534 are assigned via Standards Action [RFC8126]. 1536 Version 00b: Protocol as defined by this document. 1537 Version 01b: Reserved. This document. 1538 Version 10b: Unassigned. 1539 Version 11b: Unassigned. 1541 11.1.3. MD Type Registry 1543 IANA is requested to set up a registry of "MD Types". These are 1544 4-bit values. MD Type values 0x0, 0x1, 0x2, and 0xF are specified in 1545 this document, see Table 5. Registry entries are assigned by using 1546 the "IETF Review" policy defined in RFC 8126 [RFC8126]. 1548 +----------+-----------------+---------------+ 1549 | MD Type | Description | Reference | 1550 +----------+-----------------+---------------+ 1551 | 0x0 | Reserved | This document | 1552 | | | | 1553 | 0x1 | NSH MD Type 1 | This document | 1554 | | | | 1555 | 0x2 | NSH MD Type 2 | This document | 1556 | | | | 1557 | 0x3..0xE | Unassigned | | 1558 | | | | 1559 | 0xF | Experimentation | This document | 1560 +----------+-----------------+---------------+ 1562 Table 5: MD Type Values 1564 11.1.4. MD Class Registry 1566 IANA is requested to set up a registry of "MD Class". These are 1567 16-bit values. New allocations are to be made according to the 1568 following policies: 1570 0x0000 to 0x01ff: IETF Review 1571 0x0200 to 0xfff5: Expert Review 1572 0xfff6 to 0xfffe: Experimental 1573 0xffff: Reserved 1575 IANA is requested to assign the values as per Table 6:: 1577 +-----------+-----------------------------+------------+ 1578 | MD Class | Meaning | Reference | 1579 +-----------+-----------------------------+------------+ 1580 | 0x0000 | IETF Base NSH MD Class | This.I-D | 1581 +-----------+-----------------------------+------------+ 1583 Table 6: MD Class Value 1585 A registry for Types for the MD Class of 0x0000 is defined in 1586 Section 11.1.5. 1588 Designated Experts evaluating new allocation requests from the 1589 "Expert Review" range should principally consider whether a new MD 1590 class is needed compared to adding MD types to an existing class. 1591 The Designated Experts should also encourage the existence of an 1592 associated and publicly visible registry of MD types although this 1593 registry need not be maintained by IANA. 1595 When evaluating a request for an allocation, the Expert should verify 1596 that the allocation plan includes considerations to handle privacy 1597 and security issues associated with the anticipated individual MD 1598 Types allocated within this class. These plans should consider, when 1599 appropriate, alternatives such as indirection, encryption, and 1600 limited deployment scenarios. Information that can't be directly 1601 derived from viewing the packet contents should be examined for 1602 privacy and security implications. 1604 11.1.5. New IETF Assigned Optional Variable Length Metadata Type 1605 Registry 1607 The Type values within the IETF Base NSH MD Class, i.e., when the MD 1608 Class is set to 0x0000 (see Section 11.1.4), are the Types owned by 1609 the IETF. This document requests IANA to create a registry for the 1610 Type values for the IETF Base NSH MD Class called the "IETF Assigned 1611 Optional Variable Length Metadata Type Registry", as specified in 1612 Section 2.5.1. 1614 The type values are assigned via Standards Action [RFC8126]. 1616 No initial values are assigned at the creation of the registry. 1618 11.1.6. NSH Base Header Next Protocol 1620 IANA is requested to set up a registry of "Next Protocol". These are 1621 8-bit values. Next Protocol values 0, 1, 2, 3, 4 and 5 are defined 1622 in this document (see Table 7. New values are assigned via "Expert 1623 Reviews" as per [RFC8126]. 1625 +---------------+--------------+---------------+ 1626 | Next Protocol | Description | Reference | 1627 +---------------+--------------+---------------+ 1628 | 0x0 | Unassigned | | 1629 | | | | 1630 | 0x1 | IPv4 | This document | 1631 | | | | 1632 | 0x2 | IPv6 | This document | 1633 | | | | 1634 | 0x3 | Ethernet | This document | 1635 | | | | 1636 | 0x4 | NSH | This document | 1637 | | | | 1638 | 0x5 | MPLS | This document | 1639 | | | | 1640 | 0x6..0xFD | Unassigned | | 1641 | | | | 1642 | 0xFE | Experiment 1 | This document | 1643 | | | | 1644 | 0xFF | Experiment 2 | This document | 1645 +---------------+--------------+---------------+ 1647 Table 7: NSH Base Header Next Protocol Values 1649 Expert Review requests MUST include a single code point per request. 1650 Designated Experts evaluating new allocation requests from this 1651 registry should consider the potential scarcity of code points for an 1652 8-bit value, and check both for duplications as well as availability 1653 of documentation. If the actual assignment of the Next Protocol 1654 field allocation reaches half of the range, that is when there are 1655 128 unassigned values, IANA needs to alert the IESG. At this point, 1656 a new more strict allocation policy SHOULD be considered. 1658 12. NSH-Related Codepoints 1660 12.1. NSH EtherType 1662 An IEEE EtherType, 0x894F, has been allocated for NSH. 1664 13. References 1666 13.1. Normative References 1668 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1669 Requirement Levels", BCP 14, RFC 2119, 1670 DOI 10.17487/RFC2119, March 1997, 1671 . 1673 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 1674 Chaining (SFC) Architecture", RFC 7665, 1675 DOI 10.17487/RFC7665, October 2015, 1676 . 1678 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1679 Writing an IANA Considerations Section in RFCs", BCP 26, 1680 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1681 . 1683 13.2. Informative References 1685 [I-D.brockners-proof-of-transit] 1686 Brockners, F., Bhandari, S., Dara, S., Pignataro, C., 1687 Leddy, J., Youell, S., Mozes, D., and T. Mizrahi, "Proof 1688 of Transit", draft-brockners-proof-of-transit-04 (work in 1689 progress), October 2017. 1691 [I-D.guichard-sfc-nsh-dc-allocation] 1692 Guichard, J., Smith, M., Kumar, S., Majee, S., Agarwal, 1693 P., Glavin, K., Laribi, Y., and T. Mizrahi, "Network 1694 Service Header (NSH) MD Type 1: Context Header Allocation 1695 (Data Center)", draft-guichard-sfc-nsh-dc-allocation-07 1696 (work in progress), August 2017. 1698 [I-D.ietf-nvo3-vxlan-gpe] 1699 Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol 1700 Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-05 (work 1701 in progress), October 2017. 1703 [I-D.ietf-rtgwg-dt-encap] 1704 Nordmark, E., Tian, A., Gross, J., Hudson, J., Kreeger, 1705 L., Garg, P., Thaler, P., and T. Herbert, "Encapsulation 1706 Considerations", draft-ietf-rtgwg-dt-encap-02 (work in 1707 progress), October 2016. 1709 [I-D.ietf-sfc-control-plane] 1710 Boucadair, M., "Service Function Chaining (SFC) Control 1711 Plane Components & Requirements", draft-ietf-sfc-control- 1712 plane-08 (work in progress), October 2016. 1714 [I-D.ietf-sfc-oam-framework] 1715 Aldrin, S., Pignataro, C., Kumar, N., Akiya, N., Krishnan, 1716 R., and A. Ghanwani, "Service Function Chaining (SFC) 1717 Operation, Administration and Maintenance (OAM) 1718 Framework", draft-ietf-sfc-oam-framework-03 (work in 1719 progress), September 2017. 1721 [I-D.napper-sfc-nsh-broadband-allocation] 1722 Napper, J., Kumar, S., Muley, P., Henderickx, W., and M. 1723 Boucadair, "NSH Context Header Allocation -- Broadband", 1724 draft-napper-sfc-nsh-broadband-allocation-03 (work in 1725 progress), July 2017. 1727 [I-D.reddy-sfc-nsh-encrypt] 1728 Reddy, T., Patil, P., Fluhrer, S., and P. Quinn, 1729 "Authenticated and encrypted NSH service chains", draft- 1730 reddy-sfc-nsh-encrypt-00 (work in progress), April 2015. 1732 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 1733 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 1734 DOI 10.17487/RFC2784, March 2000, 1735 . 1737 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1738 Text on Security Considerations", BCP 72, RFC 3552, 1739 DOI 10.17487/RFC3552, July 2003, 1740 . 1742 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 1743 Considered Useful", BCP 82, RFC 3692, 1744 DOI 10.17487/RFC3692, January 2004, 1745 . 1747 [RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and 1748 Internet Key Exchange (IKE) Document Roadmap", RFC 6071, 1749 DOI 10.17487/RFC6071, February 2011, 1750 . 1752 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 1753 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 1754 Acronym in the IETF", BCP 161, RFC 6291, 1755 DOI 10.17487/RFC6291, June 2011, 1756 . 1758 [RFC7325] Villamizar, C., Ed., Kompella, K., Amante, S., Malis, A., 1759 and C. Pignataro, "MPLS Forwarding Compliance and 1760 Performance Requirements", RFC 7325, DOI 10.17487/RFC7325, 1761 August 2014, . 1763 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 1764 Service Function Chaining", RFC 7498, 1765 DOI 10.17487/RFC7498, April 2015, 1766 . 1768 [RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support 1769 for Generic Routing Encapsulation (GRE)", RFC 7676, 1770 DOI 10.17487/RFC7676, October 2015, 1771 . 1773 [RFC8165] Hardie, T., "Design Considerations for Metadata 1774 Insertion", RFC 8165, DOI 10.17487/RFC8165, May 2017, 1775 . 1777 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 1778 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 1779 DOI 10.17487/RFC8201, July 2017, 1780 . 1782 Authors' Addresses 1784 Paul Quinn (editor) 1785 Cisco Systems, Inc. 1787 Email: paulq@cisco.com 1789 Uri Elzur (editor) 1790 Intel 1792 Email: uri.elzur@intel.com 1794 Carlos Pignataro (editor) 1795 Cisco Systems, Inc. 1797 Email: cpignata@cisco.com