idnits 2.17.1 draft-ietf-sfc-nsh-24.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 (September 24, 2017) is 2404 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-03 == Outdated reference: A later version (-13) exists of draft-ietf-nvo3-vxlan-gpe-04 == Outdated reference: A later version (-15) exists of draft-ietf-sfc-oam-framework-03 == 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: March 28, 2018 Intel 6 C. Pignataro, Ed. 7 Cisco 8 September 24, 2017 10 Network Service Header (NSH) 11 draft-ietf-sfc-nsh-24 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 March 28, 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. Definition of Terms . . . . . . . . . . . . . . . . . . . 4 59 1.3. Problem Space . . . . . . . . . . . . . . . . . . . . . . 6 60 1.4. NSH-based Service Chaining . . . . . . . . . . . . . . . 6 61 2. Network Service Header . . . . . . . . . . . . . . . . . . . 7 62 2.1. Network Service Header Format . . . . . . . . . . . . . . 7 63 2.2. NSH Base Header . . . . . . . . . . . . . . . . . . . . . 7 64 2.3. Service Path Header . . . . . . . . . . . . . . . . . . . 10 65 2.4. NSH MD Type 1 . . . . . . . . . . . . . . . . . . . . . . 11 66 2.5. NSH MD Type 2 . . . . . . . . . . . . . . . . . . . . . . 12 67 2.5.1. Optional Variable Length Metadata . . . . . . . . . . 13 68 3. NSH Actions . . . . . . . . . . . . . . . . . . . . . . . . . 14 69 4. NSH Transport Encapsulation . . . . . . . . . . . . . . . . . 16 70 5. Fragmentation Considerations . . . . . . . . . . . . . . . . 17 71 6. Service Path Forwarding with NSH . . . . . . . . . . . . . . 17 72 6.1. SFFs and Overlay Selection . . . . . . . . . . . . . . . 17 73 6.2. Mapping the NSH to Network Topology . . . . . . . . . . . 20 74 6.3. Service Plane Visibility . . . . . . . . . . . . . . . . 21 75 6.4. Service Graphs . . . . . . . . . . . . . . . . . . . . . 21 76 7. Policy Enforcement with NSH . . . . . . . . . . . . . . . . . 21 77 7.1. NSH Metadata and Policy Enforcement . . . . . . . . . . . 21 78 7.2. Updating/Augmenting Metadata . . . . . . . . . . . . . . 23 79 7.3. Service Path Identifier and Metadata . . . . . . . . . . 25 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 81 8.1. Transport Encapsulation Protocol Security . . . . . . . . 26 82 8.2. Boundary Protection . . . . . . . . . . . . . . . . . . . 26 83 8.3. Metadata Considerations . . . . . . . . . . . . . . . . . 27 84 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28 85 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 86 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 87 11.1. NSH EtherType . . . . . . . . . . . . . . . . . . . . . 30 88 11.2. Network Service Header (NSH) Parameters . . . . . . . . 30 89 11.2.1. NSH Base Header Bits . . . . . . . . . . . . . . . . 30 90 11.2.2. NSH Version . . . . . . . . . . . . . . . . . . . . 30 91 11.2.3. MD Type Registry . . . . . . . . . . . . . . . . . . 31 92 11.2.4. MD Class Registry . . . . . . . . . . . . . . . . . 31 93 11.2.5. NSH Base Header Next Protocol . . . . . . . . . . . 32 94 11.2.6. New IETF Assigned Optional Variable Length Metadata 95 Type Registry . . . . . . . . . . . . . . . . . . . 33 96 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 97 12.1. Normative References . . . . . . . . . . . . . . . . . . 33 98 12.2. Informative References . . . . . . . . . . . . . . . . . 33 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 101 1. Introduction 103 Service functions are widely deployed and essential in many networks. 104 These service functions provide a range of features such as security, 105 WAN acceleration, and server load balancing. Service functions may 106 be instantiated at different points in the network infrastructure 107 such as the wide area network, data center, and so forth. 109 Prior to development of the SFC architecture [RFC7665] and the 110 protocol specified in this document, current service function 111 deployment models have been relatively static and bound to topology 112 for insertion and policy selection. Furthermore, they do not adapt 113 well to elastic service environments enabled by virtualization. 115 New data center network and cloud architectures require more flexible 116 service function deployment models. Additionally, the transition to 117 virtual platforms demands an agile service insertion model that 118 supports dynamic and elastic service delivery. Specifically, the 119 following functions are necessary: 121 1. The movement of service functions and application workloads in 122 the network. 124 2. The ability to easily bind service policy to granular 125 information, such as per-subscriber state. 127 3. The capability to steer traffic to the requisite service 128 function(s). 130 The Network Service Header (NSH) specification defines a new protocol 131 and associated encapsulation for the creation of dynamic service 132 chains, operating at the service plane. The NSH is designed to 133 encapsulate an original packet or frame, and in turn be encapsulated 134 by an outer transport encapsulation (which is used to deliver the NSH 135 to NSH-aware network elements), as shown in Figure 1: 137 +------------------------------+ 138 | Transport Encapsulation | 139 +------------------------------+ 140 | Network Service Header (NSH) | 141 +------------------------------+ 142 | Original Packet / Frame | 143 +------------------------------+ 145 Figure 1: Network Service Header Encapsulation 147 The NSH is composed of the following elements: 149 1. Service Function Path identification. 151 2. Indication of location within a Service Function Path. 153 3. Optional, per packet metadata (fixed length or variable). 155 The NSH is designed to be easy to implement across a range of 156 devices, both physical and virtual, including hardware platforms. 158 The intended scope of the NSH is for use within a single provider's 159 operational domain. This deployment scope is deliberately 160 constrained, as explained also in [RFC7665], and limited to a single 161 network administrative domain. In this context, a "domain" is a set 162 of network entities within a single administration. For example, a 163 network administrative domain can include a single data center, or an 164 overlay domain using virtual connections and tunnels. A corollary is 165 that a network administrative domain has a well defined perimeter. 167 An NSH-aware control plane is outside the scope of this document. 169 [RFC7665] provides an overview of a service chaining architecture 170 that clearly defines the roles of the various elements and the scope 171 of a service function chaining encapsulation. The NSH is the SFC 172 encapsulation referenced in [RFC7665]. 174 1.1. Requirements Language 176 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 177 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 178 document are to be interpreted as described in RFC 2119 [RFC2119]. 180 1.2. Definition of Terms 182 Byte: All references to "bytes" in this document refer to 8-bit 183 bytes, or octets. 185 Classification: Defined in [RFC7665]. 187 Classifier: Defined in [RFC7665]. 189 Metadata: Defined in [RFC7665]. The metadata, or context 190 information shared between classifiers and SFs, and among SFs, is 191 carried on the NSH's Context Headers. It allows summarizing a 192 classification result in the packet itself, avoiding subsequent 193 re-classifications. Examples of metadata include classification 194 information used for policy enforcement and network context for 195 forwarding post service delivery. 197 Network Locator: Data plane address, typically IPv4 or IPv6, used to 198 send and receive network traffic. 200 Network Node/Element: Device that forwards packets or frames based 201 on an outer header (i.e., transport encapsulation) information. 203 Network Overlay: Logical network built on top of existing network 204 (the underlay). Packets are encapsulated or tunneled to create 205 the overlay network topology. 207 NSH-aware: NSH-aware means SFC-encapsulation-aware, where the NSH 208 provides the SFC encapsulation. This specification uses NSH-aware 209 as a more specific term from the more generic term SFC-aware 210 [RFC7665]. 212 Service Classifier: Logical entity providing classification 213 function. Since they are logical, classifiers may be co-resident 214 with SFC elements such as SFs or SFFs. Service classifiers 215 perform classification and impose the NSH. The initial classifier 216 imposes the initial NSH and sends the NSH packet to the first SFF 217 in the path. Non-initial (i.e., subsequent) classification can 218 occur as needed and can alter, or create a new service path. 220 Service Function (SF): Defined in [RFC7665]. 222 Service Function Chain (SFC): Defined in [RFC7665]. 224 Service Function Forwarder (SFF): Defined in [RFC7665]. 226 Service Function Path (SFP): Defined in [RFC7665]. 228 Service Plane: The collection of SFFs and associated SFs creates a 229 service-plane overlay in which all SFs and SFC Proxies reside 230 [RFC7665]. 232 SFC Proxy: Defined in [RFC7665]. 234 1.3. Problem Space 236 The NSH addresses several limitations associated with service 237 function deployments. [RFC7498] provides a comprehensive review of 238 those issues. 240 1.4. NSH-based Service Chaining 242 The NSH creates a dedicated service plane; more specifically, the NSH 243 enables: 245 1. Topological Independence: Service forwarding occurs within the 246 service plane, so the underlying network topology does not 247 require modification. The NSH provides an identifier used to 248 select the network overlay for network forwarding. 250 2. Service Chaining: The NSH enables service chaining per [RFC7665]. 251 The NSH contains path identification information needed to 252 realize a service path. Furthermore, the NSH provides the 253 ability to monitor and troubleshoot a service chain, end-to-end 254 via service-specific OAM messages. The NSH fields can be used by 255 administrators (via, for example, a traffic analyzer) to verify 256 (account, ensure correct chaining, provide reports, etc.) the 257 path specifics of packets being forwarded along a service path. 259 3. The NSH provides a mechanism to carry shared metadata between 260 participating entities and service functions. The semantics of 261 the shared metadata is communicated via a control plane, which is 262 outside the scope of this document, to participating nodes. 263 [I-D.ietf-sfc-control-plane] provides an example of such in 264 Section 3.3. Examples of metadata include classification 265 information used for policy enforcement and network context for 266 forwarding post service delivery. Sharing the metadata allows 267 service functions to share initial and intermediate 268 classification results with downstream service functions saving 269 re-classification, where enough information was enclosed. 271 4. The NSH offers a common and standards-based header for service 272 chaining to all network and service nodes. 274 5. Transport Encapsulation Agnostic: The NSH is transport 275 encapsulation-independent, meaning it can be transported by a 276 variety of encapsulation protocols. An appropriate (for a given 277 deployment) encapsulation protocol can be used to carry NSH- 278 encapsulated traffic. This transport encapsulation may form an 279 overlay network and if an existing overlay topology provides the 280 required service path connectivity, that existing overlay may be 281 used. 283 2. Network Service Header 285 An NSH is imposed on the original packet/frame. This NSH contains 286 service path information and optionally metadata that are added to a 287 packet or frame and used to create a service plane. Subsequently, an 288 outer transport encapsulation is imposed on the NSH, which is used 289 for network forwarding. 291 A Service Classifier adds the NSH. The NSH is removed by the last 292 SFF in the service chain or by an SF that consumes the packet. 294 2.1. Network Service Header Format 296 The NSH is composed of a 4-byte Base Header, a 4-byte Service Path 297 Header and optional Context Headers, as shown in Figure 2 below. 299 0 1 2 3 300 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 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Base Header | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Service Path Header | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | | 307 ~ Context Header(s) ~ 308 | | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 Figure 2: Network Service Header 313 Base header: Provides information about the service header and the 314 payload protocol. 316 Service Path Header: Provides path identification and location within 317 a service path. 319 Context header: Carries metadata (i.e., context data) along a service 320 path. 322 2.2. NSH Base Header 324 Figure 3 depicts the NSH base header: 326 0 1 2 3 327 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 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 Figure 3: NSH Base Header 334 Base Header Field Descriptions: 336 Version: The version field is used to ensure backward compatibility 337 going forward with future NSH specification updates. It MUST be set 338 to 0x0 by the sender, in this first revision of the NSH. Given the 339 widespread implementation of existing hardware that uses the first 340 nibble after an MPLS label stack for equal-cost multipath (ECMP) 341 decision processing, this document reserves version 01b. This value 342 MUST NOT be used in future versions of the protocol. Please see 343 [RFC7325] for further discussion of MPLS-related forwarding 344 requirements. 346 O bit: Setting this bit indicates an Operations, Administration, and 347 Maintenance (OAM) packet. The actual format and processing of SFC 348 OAM packets is outside the scope of this specification (see for 349 example [I-D.ietf-sfc-oam-framework] for one approach). 351 The O bit MUST be set for OAM packets and MUST NOT be set for non-OAM 352 packets. The O bit MUST NOT be modified along the SFP. 354 SF/SFF/SFC Proxy/Classifier implementations that do not support SFC 355 OAM procedures SHOULD discard packets with O bit set, but MAY support 356 a configurable parameter to enable forwarding received SFC OAM 357 packets unmodified to the next element in the chain. Forwarding OAM 358 packets unmodified by SFC elements that do not support SFC OAM 359 procedures may be acceptable for a subset of OAM functions, but can 360 result in unexpected outcomes for others; thus, it is recommended to 361 analyze the impact of forwarding an OAM packet for all OAM functions 362 prior to enabling this behavior. The configurable parameter MUST be 363 disabled by default. 365 TTL: Indicates the maximum SFF hops for an SFP. This field is used 366 for service plane loop detection. The initial TTL value SHOULD be 367 configurable via the control plane; the configured initial value can 368 be specific to one or more SFPs. If no initial value is explicitly 369 provided, the default initial TTL value of 63 MUST be used. Each SFF 370 involved in forwarding an NSH packet MUST decrement the TTL value by 371 1 prior to NSH forwarding lookup. Decrementing by 1 from an incoming 372 value of 0 shall result in a TTL value of 63. The packet MUST NOT be 373 forwarded if TTL is, after decrement, 0. 375 This TTL field is the primary loop prevention This TTL mechanism 376 represents a robust complement to the Service Index, as the TTL is 377 decrement by each SFF. The handling of incoming 0 TTL allows for 378 better, although not perfect, interoperation with pre-standard 379 implementations that do not support this TTL field. 381 Unassigned bits: All other flag fields, marked U, are unassigned and 382 available for future use, see Section 11.2.1. Unassigned bits MUST 383 be set to zero upon origination, and MUST be ignored and preserved 384 unmodified by other NSH supporting elements. At reception, all 385 elements MUST NOT modify their actions based on these unknown bits. 387 Length: The total length, in 4-byte words, of the NSH including the 388 Base Header, the Service Path Header, the Fixed Length Context Header 389 or Variable Length Context Header(s). The length MUST be 0x6 for MD 390 Type equal to 0x1, and MUST be 0x2 or greater for MD Type equal to 391 0x2. The length of the NSH header MUST be an integer multiple of 4 392 bytes, thus variable length metadata is always padded out to a 393 multiple of 4 bytes. 395 Metadata (MD) Type: Indicates the format of the NSH beyond the 396 mandatory Base Header and the Service Path Header. MD Type defines 397 the format of the metadata being carried. Please see the IANA 398 Considerations Section 11.2.3. 400 This document specifies the following four MD Type values: 402 0x0 - This is a reserved value. Implementations SHOULD silently 403 discard packets with MD Type 0x0. 405 0x1 - This indicates that the format of the header includes a fixed 406 length Context Header (see Figure 5 below). 408 0x2 - This does not mandate any headers beyond the Base Header and 409 Service Path Header, but may contain optional variable length Context 410 Header(s). The semantics of the variable length Context Header(s) 411 are not defined in this document. The format of the optional 412 variable length Context Headers is provided in Section 2.5.1. 414 0xF - This value is reserved for experimentation and testing, as per 415 [RFC3692]. Implementations not explicitly configured to be part of 416 an experiment SHOULD silently discard packets with MD Type 0xF. 418 The format of the Base Header and the Service Path Header is 419 invariant, and not affected by MD Type. 421 The NSH MD Type 1 and MD Type 2 are described in detail in Sections 422 2.4 and 2.5, respectively. NSH implementations MUST support MD types 423 0x1 and 0x2 (where the length is 0x2). NSH implementations SHOULD 424 support MD Type 0x2 with length greater than 0x2. There exists, 425 however, a middle ground, wherein a device will support MD Type 0x1 426 (as per the MUST) metadata, yet be deployed in a network with MD Type 427 0x2 metadata packets. In that case, the MD Type 0x1 node, MUST 428 utilize the base header length field to determine the original 429 payload offset if it requires access to the original packet/frame. 430 This specification does not disallow the MD Type value from changing 431 along an SFP; however, the specification of the necessary mechanism 432 to allow the MD Type to change along an SFP are outside the scope of 433 this document and would need to be defined for that functionality to 434 be available. Packets with MD Type values not supported by an 435 implementation MUST be silently dropped. 437 Next Protocol: indicates the protocol type of the encapsulated data. 438 The NSH does not alter the inner payload, and the semantics on the 439 inner protocol remain unchanged due to NSH service function chaining. 440 Please see the IANA Considerations section below, Section 11.2.5. 442 This document defines the following Next Protocol values: 444 0x1: IPv4 445 0x2: IPv6 446 0x3: Ethernet 447 0x4: NSH 448 0x5: MPLS 449 0xFE: Experiment 1 450 0xFF: Experiment 2 452 Packets with Next Protocol values not supported SHOULD be silently 453 dropped by default, although an implementation MAY provide a 454 configuration parameter to forward them. Additionally, an 455 implementation not explicitly configured for a specific experiment 456 [RFC3692] SHOULD silently drop packets with Next Protocol values 0xFE 457 and 0xFF. 459 2.3. Service Path Header 461 Figure 4 shows the format of the Service Path Header: 463 0 1 2 3 464 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 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Service Path Identifier (SPI) | Service Index | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 Service Path Identifier (SPI): 24 bits 470 Service Index (SI): 8 bits 472 Figure 4: NSH Service Path Header 474 The meaning of these fields is as follows: 476 Service Path Identifier (SPI): Identifies a service path. 477 Participating nodes MUST use this identifier for Service Function 478 Path selection. The initial classifier MUST set the appropriate SPI 479 for a given classification result. 481 Service Index (SI): Provides location within the SFP. The initial 482 classifier for a given SFP SHOULD set the SI to 255, however the 483 control plane MAY configure the initial value of SI as appropriate 484 (i.e., taking into account the length of the service function path). 485 The Service Index MUST be decremented by a value of 1 by Service 486 Functions or by SFC Proxy nodes after performing required services 487 and the new decremented SI value MUST be used in the egress packet's 488 NSH. The initial Classifier MUST send the packet to the first SFF in 489 the identified SFP for forwarding along an SFP. If re-classification 490 occurs, and that re-classification results in a new SPI, the 491 (re)classifier is, in effect, the initial classifier for the 492 resultant SPI. 494 The SI is used in conjunction the with Service Path Identifier for 495 Service Function Path Selection and for determining the next SFF/SF 496 in the path. The SI is also valuable when troubleshooting or 497 reporting service paths. While the TTL provides the primary SFF 498 based loop prevention for this mechanism, SI decrement by SF serves 499 as a limited loop prevention mechanism. NSH packets, as described 500 above, are discarded when an SFF decrements the TTL to 0. In 501 addition, an SFF which is not the terminal SFF for a Service Function 502 Path will discard any NSH packet with an SI of 0, as there will be no 503 valid next SF information. 505 2.4. NSH MD Type 1 507 When the Base Header specifies MD Type = 0x1, a Fixed Length Context 508 Header (16-bytes) MUST be present immediately following the Service 509 Path Header, as per Figure 5. The value of a Fixed Length Context 510 Header that carries no metadata MUST be set to zero. 512 0 1 2 3 513 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 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | Service Path Identifier | Service Index | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | | 520 | Fixed Length Context Header | 521 | | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 Figure 5: NSH MD Type=0x1 526 This specification does not make any assumptions about the content of 527 the 16 byte Context Header that must be present when the MD Type 528 field is set to 1, and does not describe the structure or meaning of 529 the included metadata. 531 An SFC-aware SF MUST receive the data semantics first in order to 532 process the data placed in the mandatory context field. The data 533 semantics include both the allocation schema and the meaning of the 534 included data. How an SFC-aware SF gets the data semantics is 535 outside the scope of this specification. 537 An SF or SFC Proxy that does not know the format or semantics of the 538 Context Header for an NSH with MD Type 1 MUST discard any packet with 539 such an NSH (i.e., MUST NOT ignore the metadata that it cannot 540 process), and MUST log the event at least once per the SPI for which 541 the event occurs (subject to thresholding). 543 [I-D.guichard-sfc-nsh-dc-allocation] and 544 [I-D.napper-sfc-nsh-broadband-allocation] provide specific examples 545 of how metadata can be allocated. 547 2.5. NSH MD Type 2 549 When the base header specifies MD Type = 0x2, zero or more Variable 550 Length Context Headers MAY be added, immediately following the 551 Service Path Header (see Figure 6). Therefore, Length = 0x2, 552 indicates that only the Base Header followed by the Service Path 553 Header are present. The optional Variable Length Context Headers 554 MUST be of an integer number of 4-bytes. The base header Length 555 field MUST be used to determine the offset to locate the original 556 packet or frame for SFC nodes that require access to that 557 information. 559 0 1 2 3 560 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 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | Service Path Identifier | Service Index | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | | 567 ~ Variable Length Context Headers (opt.) ~ 568 | | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 Figure 6: NSH MD Type=0x2 573 2.5.1. Optional Variable Length Metadata 575 The format of the optional variable length Context Headers, is as 576 depicted in Figure 7. 578 0 1 2 3 579 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 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | Metadata Class | Type |U| Length | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 | Variable Metadata | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 Figure 7: Variable Context Headers 588 Metadata Class (MD Class): Defines the scope of the 'Type' field to 589 provide a hierarchical namespace. The IANA Considerations 590 Section 11.2.4 defines how the MD Class values can be allocated to 591 standards bodies, vendors, and others. 593 Type: Indicates the explicit type of metadata being carried. The 594 definition of the Type is the responsibility of the MD Class owner. 596 Unassigned bit: One unassigned bit is available for future use. This 597 bit MUST NOT be set, and MUST be ignored on receipt. 599 Length: Indicates the length of the variable metadata, in bytes. In 600 case the metadata length is not an integer number of 4-byte words, 601 the sender MUST add pad bytes immediately following the last metadata 602 byte to extend the metadata to an integer number of 4-byte words. 603 The receiver MUST round up the length field to the nearest 4-byte 604 word boundary, to locate and process the next field in the packet. 605 The receiver MUST access only those bytes in the metadata indicated 606 by the length field (i.e., actual number of bytes) and MUST ignore 607 the remaining bytes up to the nearest 4-byte word boundary. The 608 Length may be 0 or greater. 610 A value of 0 denotes a Context Header without a Variable Metadata 611 field. 613 This specification does not make any assumption about Context Headers 614 that are mandatory-to-implement or those that are mandatory-to- 615 process. These considerations are deployment-specific. However, the 616 control plane is entitled to instruct SFC-aware SFs with the data 617 structure of context header together with its scoping (see e.g., 618 Section 3.3.3 of [I-D.ietf-sfc-control-plane]). 620 Upon receipt of a packet that belongs to a given SFP, if a mandatory- 621 to-process context header is missing in that packet, the SFC-aware SF 622 MUST NOT process the packet and MUST log an error at least once per 623 the SPI for which the mandatory metadata is missing. 625 If multiple mandatory-to-process context headers are required for a 626 given SFP, the control plane MAY instruct the SFC-aware SF with the 627 order to consume these Context Headers. If no instructions are 628 provided and the SFC-aware SF will make use of or modify the specific 629 context header, then the SFC-aware SF MUST process these Context 630 Headers in the order they appear in an NSH packet. 632 If multiple instances of the same metadata are included in an NSH 633 packet, but the definition of that context header does not allow for 634 it, the SFC-aware SF MUST process the first instance and ignore 635 subsequent instances. 637 3. NSH Actions 639 NSH-aware nodes, which include service classifiers, SFFs, SFs and SFC 640 proxies, may alter the contents of the NSH headers. These nodes have 641 several possible NSH-related actions: 643 1. Insert or remove the NSH: These actions can occur respectively at 644 the start and end of a service path. Packets are classified, and 645 if determined to require servicing, an NSH will be imposed. A 646 service classifier MUST insert an NSH at the start of an SFP. An 647 imposed NSH MUST contain both a valid Base Header and Service 648 Path Header. At the end of a service function path, an SFF MUST 649 remove the NSH before forwarding or delivering the un- 650 encapsulated packet. It is therefore the last node operating on 651 the service header. 653 Multiple logical classifiers may exist within a given service 654 path. Non-initial classifiers may re-classify data and that re- 655 classification MAY result in the selection of a different Service 656 Function Path. When the logical classifier performs re- 657 classification that results in a change of service path, it MUST 658 replace the existing NSH with a new NSH with the Base Header and 659 Service Path Header reflecting the new service path information 660 and MUST set the initial SI. The O bit, as well as unassigned 661 flags, MUST be copied transparently from the old NSH to a new 662 NSH. Metadata MAY be preserved in the new NSH. 664 2. Select service path: The Service Path Header provides service 665 path information and is used by SFFs to determine correct service 666 path selection. SFFs MUST use the Service Path Header for 667 selecting the next SF or SFF in the service path. 669 3. Update the NSH: SFs MUST decrement the service index by one. If 670 an SFF receives a packet with an SPI and SI that do not 671 correspond to a valid next hop in a valid Service Function Path, 672 that packet MUST be dropped by the SFF. 674 Classifiers MAY update Context Headers if new/updated context is 675 available. 677 If an SFC proxy is in use (acting on behalf of an NSH-unaware 678 service function for NSH actions), then the proxy MUST update 679 Service Index and MAY update contexts. When an SFC proxy 680 receives an NSH-encapsulated packet, it MUST remove the NSH 681 before forwarding it to an NSH-unaware SF. When the SFC Proxy 682 receives a packet back from an NSH-unaware SF, it MUST re- 683 encapsulate it with the correct NSH, and MUST decrement the 684 Service Index by one. 686 4. Service policy selection: Service Functions derive policy (i.e., 687 service actions such as permit or deny) selection and enforcement 688 from the NSH. Metadata shared in the NSH can provide a range of 689 service-relevant information such as traffic classification. 691 Figure 8 maps each of the four actions above to the components in the 692 SFC architecture that can perform it. 694 +-----------+-----------------------+-------+---------------+-------+ 695 | | Insert, remove, or |Forward| Update |Service| 696 | | replace the NSH |the NSH| the NSH |policy | 697 | | |Packets| |sel. | 698 |Component +-------+-------+-------+ +-------+-------+ | 699 | | | | | |Dec. |Update | | 700 | |Insert |Remove |Replace| |Service|Context| | 701 | | | | | |Index |Header | | 702 +-----------+-------+-------+-------+-------+-------+-------+-------+ 703 | | + | | + | | | + | | 704 |Classifier | | | | | | | | 705 +-----------+-------+-------+-------+-------+-------+-------+-------+ 706 |Service | | + | | + | | | | 707 |Function | | | | | | | | 708 |Forwarder | | | | | | | | 709 |(SFF) | | | | | | | | 710 +-----------+-------+-------+-------+-------+-------+-------+-------+ 711 |Service | | | | | + | + | + | 712 |Function | | | | | | | | 713 |(SF) | | | | | | | | 714 +-----------+-------+-------+-------+-------+-------+-------+-------+ 715 | | + | + | | | + | + | | 716 |SFC Proxy | | | | | | | | 717 +-----------+-------+-------+-------+-------+-------+-------+-------+ 719 Figure 8: NSH Action and Role Mapping 721 4. NSH Transport Encapsulation 723 Once the NSH is added to a packet, an outer transport encapsulation 724 is used to forward the original packet and the associated metadata to 725 the start of a service chain. The encapsulation serves two purposes: 727 1. Creates a topologically independent services plane. Packets are 728 forwarded to the required services without changing the 729 underlying network topology. 731 2. Transit network nodes simply forward the encapsulated packets 732 without modification. 734 The service header is independent of the transport encapsulation 735 used. Existing transport encapsulations can be used. The presence 736 of an NSH is indicated via a protocol type or another indicator in 737 the outer transport encapsulation. 739 5. Fragmentation Considerations 741 The NSH and the associated transport encapsulation header are "added" 742 to the encapsulated packet/frame. This additional information 743 increases the size of the packet. 745 Within a managed administrative domain, an operator can ensure that 746 the underlay MTU is sufficient to carry SFC traffic without requiring 747 fragmentation. Given that the intended scope of the NSH is within a 748 single provider's operational domain, that approach is sufficient. 750 However, although explicitly outside the scope of this specification, 751 there might be cases where the underlay MTU is not large enough to 752 carry the NSH traffic. Since the NSH does not provide fragmentation 753 support at the service plane, the transport encapsulation protocol 754 ought to provide the requisite fragmentation handling. For instance, 755 Section 9 of [I-D.ietf-rtgwg-dt-encap] provides exemplary approaches 756 and guidance for those scenarios. 758 For example, when the NSH is encapsulated in IP, IP-level 759 fragmentation coupled with Path MTU Discovery (PMTUD) is used. When, 760 on the other hand, the underlay does not support fragmentation 761 procedures, an error message SHOULD be logged when dropping a packet 762 too big. Lastly, NSH-specific fragmentation and reassembly methods 763 may be defined as well, but these methods are outside the scope of 764 this document, and subject for future work. 766 6. Service Path Forwarding with NSH 768 6.1. SFFs and Overlay Selection 770 As described above, the NSH contains a Service Path Identifier (SPI) 771 and a Service Index (SI). The SPI is, as per its name, an 772 identifier. The SPI alone cannot be used to forward packets along a 773 service path. Rather the SPI provides a level of indirection between 774 the service path/topology and the network transport encapsulation. 775 Furthermore, there is no requirement, or expectation of an SPI being 776 bound to a pre-determined or static network path. 778 The Service Index provides an indication of location within a service 779 path. The combination of SPI and SI provides the identification of a 780 logical SF and its order within the service plane, and is used to 781 select the appropriate network locator(s) for overlay forwarding. 782 The logical SF may be a single SF, or a set of eligible SFs that are 783 equivalent. In the latter case, the SFF provides load distribution 784 amongst the collection of SFs as needed. 786 SI serves as a mechanism for detecting invalid service function 787 paths. In particular, an SI value of zero indicates that forwarding 788 is incorrect and the packet must be discarded. 790 This indirection -- SPI to overlay -- creates a true service plane. 791 That is, the SFF/SF topology is constructed without impacting the 792 network topology but more importantly, service plane only 793 participants (i.e., most SFs) need not be part of the network overlay 794 topology and its associated infrastructure (e.g., control plane, 795 routing tables, etc.) SFs need to be able to return a packet to an 796 appropriate SFF (i.e., has the requisite NSH information) when 797 service processing is complete. This can be via the overlay or 798 underlay and in some cases require additional configuration on the 799 SF. As mentioned above, an existing overlay topology may be used 800 provided it offers the requisite connectivity. 802 The mapping of SPI to transport encapsulation occurs on an SFF (as 803 discussed above, the first SFF in the path gets an NSH encapsulated 804 packet from the Classifier). The SFF consults the SPI/ID values to 805 determine the appropriate overlay transport encapsulation protocol 806 (several may be used within a given network) and next hop for the 807 requisite SF. Table 1 below depicts an example of a single next-hop 808 SPI/SI to network overlay network locator mapping. 810 +------+------+---------------------+-------------------------+ 811 | SPI | SI | Next hop(s) | Transport Encapsulation | 812 +------+------+---------------------+-------------------------+ 813 | 10 | 255 | 192.0.2.1 | VXLAN-gpe | 814 | | | | | 815 | 10 | 254 | 198.51.100.10 | GRE | 816 | | | | | 817 | 10 | 251 | 198.51.100.15 | GRE | 818 | | | | | 819 | 40 | 251 | 198.51.100.15 | GRE | 820 | | | | | 821 | 50 | 200 | 01:23:45:67:89:ab | Ethernet | 822 | | | | | 823 | 15 | 212 | Null (end of path) | None | 824 +------+------+---------------------+-------------------------+ 826 Table 1: SFF NSH Mapping Example 828 Additionally, further indirection is possible: the resolution of the 829 required SF network locator may be a localized resolution on an SFF, 830 rather than a service function chain control plane responsibility, as 831 per Table 2 and Table 3 below. 833 Please note: VXLAN-gpe and GRE in the above table refer to 834 [I-D.ietf-nvo3-vxlan-gpe] and [RFC2784] [RFC7676], respectively. 836 +------+-----+----------------+ 837 | SPI | SI | Next hop(s) | 838 +------+-----+----------------+ 839 | 10 | 3 | SF2 | 840 | | | | 841 | 245 | 12 | SF34 | 842 | | | | 843 | 40 | 9 | SF9 | 844 +------+-----+----------------+ 846 Table 2: NSH to SF Mapping Example 848 +------+-------------------+-------------------------+ 849 | SF | Next hop(s) | Transport Encapsulation | 850 +------+-------------------+-------------------------+ 851 | SF2 | 192.0.2.2 | VXLAN-gpe | 852 | | | | 853 | SF34 | 198.51.100.34 | UDP | 854 | | | | 855 | SF9 | 2001:db8::1 | GRE | 856 +------+-------------------+-------------------------+ 858 Table 3: SF Locator Mapping Example 860 Since the SPI is a representation of the service path, the lookup may 861 return more than one possible next-hop within a service path for a 862 given SF, essentially a series of weighted (equally or otherwise) 863 paths to be used (for load distribution, redundancy, or policy), see 864 Table 4. The metric depicted in Table 4 is an example to help 865 illustrated weighing SFs. In a real network, the metric will range 866 from a simple preference (similar to routing next-hop), to a true 867 dynamic composite metric based on some service function-centric state 868 (including load, sessions state, capacity, etc.) 869 +------+-----+--------------+---------+ 870 | SPI | SI | NH | Metric | 871 +------+-----+--------------+---------+ 872 | 10 | 3 | 203.0.113.1 | 1 | 873 | | | | | 874 | | | 203.0.113.2 | 1 | 875 | | | | | 876 | 20 | 12 | 192.0.2.1 | 1 | 877 | | | | | 878 | | | 203.0.113.4 | 1 | 879 | | | | | 880 | 30 | 7 | 192.0.2.10 | 10 | 881 | | | | | 882 | | | 198.51.100.1 | 5 | 883 +------+-----+--------------+---------+ 885 (encapsulation type omitted for formatting) 887 Table 4: NSH Weighted Service Path 889 6.2. Mapping the NSH to Network Topology 891 As described above, the mapping of SPI to network topology may result 892 in a single path, or it might result in a more complex topology. 893 Furthermore, the SPI to overlay mapping occurs at each SFF 894 independently. Any combination of topology selection is possible. 895 Please note, there is no requirement to create a new overlay topology 896 if a suitable one already exists. NSH packets can use any (new or 897 existing) overlay provided the requisite connectivity requirements 898 are satisfied. 900 Examples of mapping for a topology: 902 1. Next SF is located at SFFb with locator 2001:db8::1 903 SFFa mapping: SPI=10 --> VXLAN-gpe, dst-ip: 2001:db8::1 905 2. Next SF is located at SFFc with multiple network locators for 906 load distribution purposes: 907 SFFb mapping: SPI=10 --> VXLAN-gpe, dst_ip:203.0.113.1, 908 203.0.113.2, 203.0.113.3, equal cost 910 3. Next SF is located at SFFd with two paths from SFFc, one for 911 redundancy: 912 SFFc mapping: SPI=10 --> VXLAN-gpe, dst_ip:192.0.2.10 cost=10, 913 203.0.113.10, cost=20 915 In the above example, each SFF makes an independent decision about 916 the network overlay path and policy for that path. In other words, 917 there is no a priori mandate about how to forward packets in the 918 network (only the order of services that must be traversed). 920 The network operator retains the ability to engineer the network 921 paths as required. For example, the overlay path between SFFs may 922 utilize traffic engineering, QoS marking, or ECMP, without requiring 923 complex configuration and network protocol support to be extended to 924 the service path explicitly. In other words, the network operates as 925 expected, and evolves as required, as does the service plane. 927 6.3. Service Plane Visibility 929 The SPI and SI serve an important function for visibility into the 930 service topology. An operator can determine what service path a 931 packet is "on", and its location within that path simply by viewing 932 NSH information (packet capture, IPFIX, etc.) The information can be 933 used for service scheduling and placement decisions, troubleshooting, 934 and compliance verification. 936 6.4. Service Graphs 938 While a given realized service function path is a specific sequence 939 of service functions, the service as seen by a user can actually be a 940 collection of service function paths, with the interconnection 941 provided by classifiers (in-service path, non-initial 942 reclassification). These internal reclassifiers examine the packet 943 at relevant points in the network, and, if needed, SPI and SI are 944 updated (whether this update is a re-write, or the imposition of a 945 new NSH with new values is implementation specific) to reflect the 946 "result" of the classification. These classifiers may, of course, 947 also modify the metadata associated with the packet. 948 [RFC7665], Section 2.1 describes Service Graphs in detail. 950 7. Policy Enforcement with NSH 952 7.1. NSH Metadata and Policy Enforcement 954 As described in Section 2, NSH provides the ability to carry metadata 955 along a service path. This metadata may be derived from several 956 sources. Common examples include: 958 Network nodes/devices: Information provided by network nodes can 959 indicate network-centric information (such as VRF or tenant) that 960 may be used by service functions or conveyed to another network 961 node post service path egress. 963 External (to the network) systems: External systems, such as 964 orchestration systems, often contain information that is valuable 965 for service function policy decisions. In most cases, this 966 information cannot be deduced by network nodes. For example, a 967 cloud orchestration platform placing workloads "knows" what 968 application is being instantiated and can communicate this 969 information to all NSH nodes via metadata carried in the context 970 header(s). 972 Service Functions: A classifier co-resident with Service Functions 973 often perform very detailed and valuable classification. 975 Regardless of the source, metadata reflects the "result" of 976 classification. The granularity of classification may vary. For 977 example, a network switch, acting as a classifier, might only be able 978 to classify based on a 2-tuple, or based on a 5-tuple, while a 979 service function may be able to inspect application information. 980 Regardless of granularity, the classification information can be 981 represented in the NSH. 983 Once the data is added to the NSH, it is carried along the service 984 path, NSH-aware SFs receive the metadata, and can use that metadata 985 for local decisions and policy enforcement. Figure 9 and Figure 10 986 highlight the relationship between metadata and policy: 988 +-------+ +-------+ +-------+ 989 | SFF )------->( SFF |------->| SFF | 990 +---+---+ +---+---+ +---+---+ 991 ^ | | 992 ,-|-. ,-|-. ,-|-. 993 / \ / \ / \ 994 ( Class ) ( SF1 ) ( SF2 ) 995 \ ify / \ / \ / 996 `---' `---' `---' 997 5-tuple: Permit Inspect 998 Tenant A Tenant A AppY 999 AppY 1001 Figure 9: Metadata and Policy 1003 +-----+ +-----+ +-----+ 1004 | SFF |---------> | SFF |----------> | SFF | 1005 +--+--+ +--+--+ +--+--+ 1006 ^ | | 1007 ,-+-. ,-+-. ,-+-. 1008 / \ / \ / \ 1009 ( Class ) ( SF1 ) ( SF2 ) 1010 \ ify / \ / \ / 1011 `-+-' `---' `---' 1012 | Permit Deny AppZ 1013 +---+---+ employees 1014 | | 1015 +-------+ 1016 External 1017 system: 1018 Employee 1019 AppZ 1021 Figure 10: External Metadata and Policy 1023 In both of the examples above, the service functions perform policy 1024 decisions based on the result of the initial classification: the SFs 1025 did not need to perform re-classification; instead, they rely on a 1026 antecedent classification for local policy enforcement. 1028 Depending on the information carried in the metadata, data privacy 1029 considerations may need to be considered. For example, if the 1030 metadata conveys tenant information, that information may need to be 1031 authenticated and/or encrypted between the originator and the 1032 intended recipients (which may include intended SFs only); one 1033 approach to an optional capability to do this is explored in 1034 [I-D.reddy-sfc-nsh-encrypt]. The NSH itself does not provide privacy 1035 functions, rather it relies on the transport encapsulation/overlay. 1036 An operator can select the appropriate set of transport encapsulation 1037 protocols to ensure confidentiality (and other security) 1038 considerations are met. Metadata privacy and security considerations 1039 are a matter for the documents that define metadata format. 1041 7.2. Updating/Augmenting Metadata 1043 Post-initial metadata imposition (typically performed during initial 1044 service path determination), the metadata may be augmented or 1045 updated: 1047 1. Metadata Augmentation: Information may be added to the NSH's 1048 existing metadata, as depicted in Figure 11. For example, if the 1049 initial classification returns the tenant information, a 1050 secondary classification (perhaps co-resident with DPI or SLB) 1051 may augment the tenant classification with application 1052 information, and impose that new information in NSH metadata. 1053 The tenant classification is still valid and present, but 1054 additional information has been added to it. 1056 2. Metadata Update: Subsequent classifiers may update the initial 1057 classification if it is determined to be incorrect or not 1058 descriptive enough. For example, the initial classifier adds 1059 metadata that describes the traffic as "Internet" but a security 1060 service function determines that the traffic is really "attack". 1061 Figure 12 illustrates an example of updating metadata. 1063 +-----+ +-----+ +-----+ 1064 | SFF |---------> | SFF |----------> | SFF | 1065 +--+--+ +--+--+ +--+--+ 1066 ^ | | 1067 ,---. ,---. ,---. 1068 / \ / \ / \ 1069 ( Class ) ( SF1 ) ( SF2 ) 1070 \ / \ / \ / 1071 `-+-' `---' `---' 1072 | Inspect Deny 1073 +---+---+ employees employee+ 1074 | | Class=AppZ appZ 1075 +-------+ 1076 External 1077 system: 1078 Employee 1080 Figure 11: Metadata Augmentation 1082 +-----+ +-----+ +-----+ 1083 | SFF |---------> | SFF |----------> | SFF | 1084 +--+--+ +--+--+ +--+--+ 1085 ^ | | 1086 ,---. ,---. ,---. 1087 / \ / \ / \ 1088 ( Class ) ( SF1 ) ( SF2 ) 1089 \ / \ / \ / 1090 `---' `---' `---' 1091 5-tuple: Inspect Deny 1092 Tenant A Tenant A attack 1093 --> attack 1095 Figure 12: Metadata Update 1097 7.3. Service Path Identifier and Metadata 1099 Metadata information may influence the service path selection since 1100 the Service Path Identifier values can represent the result of 1101 classification. A given SPI can be defined based on classification 1102 results (including metadata classification). The imposition of the 1103 SPI and SI results in the packet being placed on the newly specified 1104 SFP at the position indicated by the imposed SPI and SI. 1106 This relationship provides the ability to create a dynamic service 1107 plane based on complex classification without requiring each node to 1108 be capable of such classification, or requiring a coupling to the 1109 network topology. This yields service graph functionality as 1110 described in Section 6.4. Figure 13 illustrates an example of this 1111 behavior. 1113 +-----+ +-----+ +-----+ 1114 | SFF |---------> | SFF |------+---> | SFF | 1115 +--+--+ +--+--+ | +--+--+ 1116 | | | | 1117 ,---. ,---. | ,---. 1118 / \ / SF1 \ | / \ 1119 ( SCL ) ( + ) | ( SF2 ) 1120 \ / \SCL2 / | \ / 1121 `---' `---' +-----+ `---' 1122 5-tuple: Inspect | SFF | Original 1123 Tenant A Tenant A +--+--+ next SF 1124 --> DoS | 1125 V 1126 ,-+-. 1127 / \ 1128 ( SF10 ) 1129 \ / 1130 `---' 1131 DoS 1132 "Scrubber" 1134 Figure 13: Path ID and Metadata 1136 Specific algorithms for mapping metadata to an SPI are outside the 1137 scope of this document. 1139 8. Security Considerations 1141 NSH is designed for use within operator environments. As such, it 1142 does not include any mandatory security mechanisms. As with many 1143 other protocols, without enhancements, the NSH encapsulation can be 1144 spoofed and is subject to snooping and modification in transit. 1146 However, the deployment scope (as defined in [RFC7665]) of the NSH 1147 encapsulation is limited to a single network administrative domain as 1148 a controlled environment, with trusted devices (e.g., a data center) 1149 hence mitigating the risk of unauthorized manipulation of the 1150 encapsulation headers or metadata. This controlled environment is an 1151 important assumption for NSH. There is one additional important 1152 assumption: All of the service functions used by an operator in 1153 service chains are assumed to be selected and vetted by the operator. 1155 An attacker with access to the traffic in an operators network can 1156 potentially observe the metadata NSH carries with packets, 1157 potentially discovering privacy sensitive information. Similarly, 1158 attackers who can modify packets within the operators network may be 1159 able to modify the service function path, path position, and / or the 1160 metadata associated with a packet. If an attacker can compromise SFC 1161 Classifiers, Service Function Forwarders, or Service Functions, then 1162 they can inspect any or the NSH information. 1164 8.1. Transport Encapsulation Protocol Security 1166 NSH is always encapsulated in a transport encapsulation protocol 1167 between SFC components (as detailed in Section 4 of this 1168 specification). In selecting the transport encapsulation protocol to 1169 use in a partciular deployment, operators SHOULD evaluate the degree 1170 of protection from e.g., intermediate observation and modification 1171 that is needed. Operators SHOULD then select a transport 1172 encapsulation protocol such as one that supports [RFC6071] to provide 1173 the needed protection (e.g., authenticity, confidentiality) for the 1174 traffic between SFC components. Operators MUST ensure the selected 1175 transport encapsulation protocol can be supported by the transport 1176 encapsulation/underlay of all relevant network segments as well as 1177 SFFs, SFs and SFC proxies in the service path. 1179 One example where transport encapsulation protocol security is highly 1180 applicable is when an operator is using the public Internet to 1181 provide communication between two parts of their own administrative 1182 domain. 1184 Further, existing best practices, such as [BCP38] SHOULD be deployed 1185 at the network layer to ensure that traffic entering the service path 1186 is indeed "valid". [I-D.ietf-rtgwg-dt-encap] provides additional 1187 transport encapsulation considerations. 1189 8.2. Boundary Protection 1191 Given the potential sensitivity of NSH information, it is important 1192 that operators ensure that NSH encapsulated packets do not leave the 1193 operator domain. The first step in such is that NSH Egress devices 1194 MUST strip the NSH headers before they send the users packets or 1195 frames out of the NSH domain. Means to prevent leaking privacy- 1196 related information outside an administrative domain are natively 1197 supported by the NSH given that the last SFF of a service path will 1198 systematically remove the NSH encapsulation before forwarding a 1199 packet exiting the service path. 1201 The second step in such prevention is to filter the transport 1202 encapsulation protocol used by NSH at the doamin edge. Depending 1203 upon the transport encapsulation protocol used for NSH, this can 1204 either be done by completely blocking the transport encapsulation 1205 (for example if MPLS is the chosen NSH transport encapsulation 1206 protocol, and is never allowed to leave the domain) or by examing the 1207 carried protocol with the transport encapsulation (for example if 1208 VxLAN-gpe is used as the NSH transport encapsulation protocol, all 1209 domain edges MUST filter based on the carried protocol in the VxLAN- 1210 gpe.) 1212 The other consequence of this sensitivity is that ingress packets 1213 MUST also be filtered to prevent attackers from sending in NSH 1214 packets with service path identification and metadata of their own 1215 selection. The same filters as described above for both the NSH 1216 devices and for the general edge protections MUST be applied on 1217 ingress. 1219 In summary, packets originating outside the SFC-enabled domain must 1220 be dropped if they contain an NSH. Similarly, packets exiting the 1221 SFC-enabled domain must be dropped if they contain an NSH. 1223 8.3. Metadata Considerations 1225 Much of the metadata carried by NSH is not sensitive. It often 1226 reflects information that can be derived from the underlying packet 1227 or frame. Direct protection of such information is not necessary, as 1228 the risks are simply those of carrying the underlying packet or 1229 frame. Protection of traffic at that level is the responsibility of 1230 the end systems. 1232 Having said that, some of the metadata can be either privacy or 1233 operationally sensitive. For example, mdofiying the metadata 1234 indicating the charging category of packets can cause subscribers to 1235 underpay or overpay the operator in certain environments. The 1236 service path identification and position is often itself sensitive, 1237 since modification of that information can cause packets to avoid 1238 service functions the customer or operator intend the packet to 1239 visit. 1241 Protecting such information between SFC components can be done using 1242 transport encapsulation protocols with suitable security capabilites, 1243 along the lines discussed above. Protecting the information at SFC 1244 components is more complicated as re-classifers are permitted to 1245 modify NSH fields (with the caveats noted above regarding the flag 1246 bits); SFFs read the service function path information and modify the 1247 service function path index; and in general service functions need to 1248 read, and potentially modify NSH metadata. 1250 One useful element of providing privacy protection for sensitive 1251 metadata is described under the "SFC Encapsulation" area of the 1252 Security Considerations of [RFC7665]. Operators can and should use 1253 indirect identification for metadata deemed to be sensitive (such as 1254 personally identifying information) significantly mitigating the risk 1255 of privacy violation. In particular, subscriber identifying 1256 information should be handled carefully, and in general should be 1257 obfuscated. 1259 For those situations where obfuscation is either inapplicable or 1260 judged to be insufficient, an operator can also encrypt the metadata. 1261 An approach to an optional capability to do this was explored in 1262 [I-D.reddy-sfc-nsh-encrypt]. For other situations where greater 1263 assurance is desired, optional mechanisms such as 1264 [I-D.brockners-proof-of-transit] can be used. 1266 Lastly, SF security, although out of scope of this document, should 1267 be considered, particularly if an SF needs to access, authenticate, 1268 or update the NSH encapsulation or metadata. However, again, the 1269 selection and placement of SFs is assumed to be bounded within the 1270 scope of a single administrative domain and therefore under direct 1271 control of the operator. 1273 9. Contributors 1275 This WG document originated as draft-quinn-sfc-nsh; the following are 1276 its co-authors and contributors along with their respective 1277 affiliations at the time of WG adoption. The editors of this 1278 document would like to thank and recognize them and their 1279 contributions. These co-authors and contributors provided invaluable 1280 concepts and content for this document's creation. 1282 o Jim Guichard, Cisco Systems, Inc. 1284 o Surendra Kumar, Cisco Systems, Inc. 1286 o Michael Smith, Cisco Systems, Inc. 1288 o Wim Henderickx, Alcatel-Lucent 1289 o Tom Nadeau, Brocade 1291 o Puneet Agarwal 1293 o Rajeev Manur, Broadcom 1295 o Abhishek Chauhan, Citrix 1297 o Joel Halpern, Ericsson 1299 o Sumandra Majee, F5 1301 o David Melman, Marvell 1303 o Pankaj Garg, Microsoft 1305 o Brad McConnell, Rackspace 1307 o Chris Wright, Red Hat, Inc. 1309 o Kevin Glavin, Riverbed 1311 o Hong (Cathy) Zhang, Huawei US R&D 1313 o Louis Fourie, Huawei US R&D 1315 o Ron Parker, Affirmed Networks 1317 o Myo Zarny, Goldman Sachs 1319 o Andrew Dolganow, Alcatel-Lucent 1321 o Rex Fernando, Cisco Systems, Inc. 1323 o Praveen Muley, Alcatel-Lucent 1325 o Navindra Yadav, Cisco Systems, Inc. 1327 10. Acknowledgments 1329 The authors would like to thank Sunil Vallamkonda, Nagaraj Bagepalli, 1330 Abhijit Patra, Peter Bosch, Darrel Lewis, Pritesh Kothari, Tal 1331 Mizrahi and Ken Gray for their detailed review, comments and 1332 contributions. 1334 A special thank you goes to David Ward and Tom Edsall for their 1335 guidance and feedback. 1337 Additionally the authors would like to thank Larry Kreeger for his 1338 invaluable ideas and contributions which are reflected throughout 1339 this document. 1341 Loa Andersson provided a thorough review and valuable comments, we 1342 thank him for that. 1344 Reinaldo Penno deserves a particular thank you for his architecture 1345 and implementation work that helped guide the protocol concepts and 1346 design. 1348 The editors also acknowledge comprehensive reviews and respective 1349 suggestions by Med Boucadair, Adrian Farrel, Juergen Schoenwaelder, 1350 and Acee Lindem. 1352 Lastly, David Dolson has provides significant review, feedback and 1353 suggestions throughout the evolution of this document. His 1354 contributions are very much appreciated. 1356 11. IANA Considerations 1358 11.1. NSH EtherType 1360 An IEEE EtherType, 0x894F, has been allocated for NSH. 1362 11.2. Network Service Header (NSH) Parameters 1364 IANA is requested to create a new "Network Service Header (NSH) 1365 Parameters" registry. The following sub-sections request new 1366 registries within the "Network Service Header (NSH) Parameters " 1367 registry. 1369 11.2.1. NSH Base Header Bits 1371 There are five unassigned bits (U bits) in the NSH Base Header, and 1372 one assigned bit (O bit). New bits are assigned via Standards Action 1373 [RFC8126]. 1375 Bit 2 - O (OAM) bit 1376 Bit 3 - Unassigned 1377 Bits 16-19 - Unassigned 1379 11.2.2. NSH Version 1381 IANA is requested to setup a registry of "NSH Version". New values 1382 are assigned via Standards Action [RFC8126]. 1384 Version 00b: Protocol as defined by this document. 1386 Version 01b: Reserved. This document. 1387 Version 10b: Unassigned. 1388 Version 11b: Unassigned. 1390 11.2.3. MD Type Registry 1392 IANA is requested to set up a registry of "MD Types". These are 1393 4-bit values. MD Type values 0x0, 0x1, 0x2, and 0xF are specified in 1394 this document, see Table 5. Registry entries are assigned by using 1395 the "IETF Review" policy defined in RFC 8126 [RFC8126]. 1397 +----------+-----------------+---------------+ 1398 | MD Type | Description | Reference | 1399 +----------+-----------------+---------------+ 1400 | 0x0 | Reserved | This document | 1401 | | | | 1402 | 0x1 | NSH MD Type 1 | This document | 1403 | | | | 1404 | 0x2 | NSH MD Type 2 | This document | 1405 | | | | 1406 | 0x3..0xE | Unassigned | | 1407 | | | | 1408 | 0xF | Experimentation | This document | 1409 +----------+-----------------+---------------+ 1411 Table 5: MD Type Values 1413 11.2.4. MD Class Registry 1415 IANA is requested to set up a registry of "MD Class". These are 1416 16-bit values. New allocations are to be made according to the 1417 following policies: 1419 0x0000 to 0x01ff: IETF Review 1420 0x0200 to 0xfff5: Expert Review 1421 0xfff6 to 0xfffe: Experimental 1422 0xffff: Reserved 1424 IANA is requested to assign the values as per Table 6:: 1426 +-----------+-----------------------------+------------+ 1427 | MD Class | Meaning | Reference | 1428 +-----------+-----------------------------+------------+ 1429 | 0x0000 | IETF Base NSH MD Class | This.I-D | 1430 +-----------+-----------------------------+------------+ 1432 Table 6: MD Class Value 1434 Designated Experts evaluating new allocation requests from the 1435 "Expert Review" range should principally consider whether a new MD 1436 class is needed compared to adding MD types to an existing class. 1437 The Designated Experts should also encourage the existence of an 1438 associated and publicly visible registry of MD types although this 1439 registry need not be maintained by IANA. 1441 When evaluating a request for an allocation, the Expert should verify 1442 that the allocation plan includes considerations to handle privacy 1443 and security issues associated with the anticipated individual MD 1444 Types allocated within this class. These plans should consider, when 1445 appropriate, alternatives such as indirection, encryption, and 1446 limited deployment scenarios. Information that can't be directly 1447 derived from viewing the packet contents should be examined for 1448 privacy and security implications. 1450 11.2.5. NSH Base Header Next Protocol 1452 IANA is requested to set up a registry of "Next Protocol". These are 1453 8-bit values. Next Protocol values 0, 1, 2, 3, 4 and 5 are defined 1454 in this document (see Table 7. New values are assigned via "Expert 1455 Reviews" as per [RFC8126]. 1457 +---------------+--------------+---------------+ 1458 | Next Protocol | Description | Reference | 1459 +---------------+--------------+---------------+ 1460 | 0x0 | Unassigned | | 1461 | | | | 1462 | 0x1 | IPv4 | This document | 1463 | | | | 1464 | 0x2 | IPv6 | This document | 1465 | | | | 1466 | 0x3 | Ethernet | This document | 1467 | | | | 1468 | 0x4 | NSH | This document | 1469 | | | | 1470 | 0x5 | MPLS | This document | 1471 | | | | 1472 | 0x6..0xFD | Unassigned | | 1473 | | | | 1474 | 0xFE | Experiment 1 | This document | 1475 | | | | 1476 | 0xFF | Experiment 2 | This document | 1477 +---------------+--------------+---------------+ 1479 Table 7: NSH Base Header Next Protocol Values 1481 Expert Review requests MUST include a single code point per request. 1482 Designated Experts evaluating new allocation requests from this 1483 registry should consider the potential scarcity of code points for an 1484 8-bit value, and check both for duplications as well as availability 1485 of documentation. If the actual assignment of the Next Protocol 1486 field allocation reaches half of the range, that is when there are 1487 128 unassigned values, IANA needs to alert the IESG. At this point, 1488 a new more strict allocation policy SHOULD be considered. 1490 11.2.6. New IETF Assigned Optional Variable Length Metadata Type 1491 Registry 1493 This document requests IANA to create a registry for the type values 1494 owned by the IETF (i.e., MD Class set to 0x0000) called the "IETF 1495 Assigned Optional Variable Length Metadata Type Registry", as 1496 specified in Section 2.5.1. 1498 The type values are assigned via Standards Action [RFC8126]. 1500 No initial values are assigned at the creation of the registry. 1502 12. References 1504 12.1. Normative References 1506 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1507 Requirement Levels", BCP 14, RFC 2119, 1508 DOI 10.17487/RFC2119, March 1997, 1509 . 1511 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 1512 Chaining (SFC) Architecture", RFC 7665, 1513 DOI 10.17487/RFC7665, October 2015, 1514 . 1516 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1517 Writing an IANA Considerations Section in RFCs", BCP 26, 1518 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1519 . 1521 12.2. Informative References 1523 [BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1524 Defeating Denial of Service Attacks which employ IP Source 1525 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 1526 May 2000, . 1528 [I-D.brockners-proof-of-transit] 1529 Brockners, F., Bhandari, S., Dara, S., Pignataro, C., 1530 Leddy, J., Youell, S., Mozes, D., and T. Mizrahi, "Proof 1531 of Transit", draft-brockners-proof-of-transit-03 (work in 1532 progress), March 2017. 1534 [I-D.guichard-sfc-nsh-dc-allocation] 1535 Guichard, J., Smith, M., Kumar, S., Majee, S., Agarwal, 1536 P., Glavin, K., Laribi, Y., and T. Mizrahi, "Network 1537 Service Header (NSH) MD Type 1: Context Header Allocation 1538 (Data Center)", draft-guichard-sfc-nsh-dc-allocation-07 1539 (work in progress), August 2017. 1541 [I-D.ietf-nvo3-vxlan-gpe] 1542 Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol 1543 Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-04 (work 1544 in progress), April 2017. 1546 [I-D.ietf-rtgwg-dt-encap] 1547 Nordmark, E., Tian, A., Gross, J., Hudson, J., Kreeger, 1548 L., Garg, P., Thaler, P., and T. Herbert, "Encapsulation 1549 Considerations", draft-ietf-rtgwg-dt-encap-02 (work in 1550 progress), October 2016. 1552 [I-D.ietf-sfc-control-plane] 1553 Boucadair, M., "Service Function Chaining (SFC) Control 1554 Plane Components & Requirements", draft-ietf-sfc-control- 1555 plane-08 (work in progress), October 2016. 1557 [I-D.ietf-sfc-oam-framework] 1558 Aldrin, S., Pignataro, C., Kumar, N., Akiya, N., Krishnan, 1559 R., and A. Ghanwani, "Service Function Chaining (SFC) 1560 Operation, Administration and Maintenance (OAM) 1561 Framework", draft-ietf-sfc-oam-framework-03 (work in 1562 progress), September 2017. 1564 [I-D.napper-sfc-nsh-broadband-allocation] 1565 Napper, J., Kumar, S., Muley, P., Henderickx, W., and M. 1566 Boucadair, "NSH Context Header Allocation -- Broadband", 1567 draft-napper-sfc-nsh-broadband-allocation-03 (work in 1568 progress), July 2017. 1570 [I-D.reddy-sfc-nsh-encrypt] 1571 Reddy, T., Patil, P., Fluhrer, S., and P. Quinn, 1572 "Authenticated and encrypted NSH service chains", draft- 1573 reddy-sfc-nsh-encrypt-00 (work in progress), April 2015. 1575 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 1576 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 1577 DOI 10.17487/RFC2784, March 2000, 1578 . 1580 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 1581 Considered Useful", BCP 82, RFC 3692, 1582 DOI 10.17487/RFC3692, January 2004, 1583 . 1585 [RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and 1586 Internet Key Exchange (IKE) Document Roadmap", RFC 6071, 1587 DOI 10.17487/RFC6071, February 2011, 1588 . 1590 [RFC7325] Villamizar, C., Ed., Kompella, K., Amante, S., Malis, A., 1591 and C. Pignataro, "MPLS Forwarding Compliance and 1592 Performance Requirements", RFC 7325, DOI 10.17487/RFC7325, 1593 August 2014, . 1595 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 1596 Service Function Chaining", RFC 7498, 1597 DOI 10.17487/RFC7498, April 2015, 1598 . 1600 [RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support 1601 for Generic Routing Encapsulation (GRE)", RFC 7676, 1602 DOI 10.17487/RFC7676, October 2015, 1603 . 1605 Authors' Addresses 1607 Paul Quinn (editor) 1608 Cisco Systems, Inc. 1610 Email: paulq@cisco.com 1612 Uri Elzur (editor) 1613 Intel 1615 Email: uri.elzur@intel.com 1617 Carlos Pignataro (editor) 1618 Cisco Systems, Inc. 1620 Email: cpignata@cisco.com