idnits 2.17.1 draft-ietf-sfc-nsh-19.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 (August 12, 2017) is 2421 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 (-07) exists of draft-guichard-sfc-nsh-dc-allocation-05 == 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-02 == 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: February 13, 2018 Intel 6 C. Pignataro, Ed. 7 Cisco 8 August 12, 2017 10 Network Service Header (NSH) 11 draft-ietf-sfc-nsh-19 13 Abstract 15 This document describes a Network Service Header (NSH) inserted onto 16 packets or frames to realize service function paths. NSH also 17 provides a mechanism for metadata exchange along the instantiated 18 service paths. NSH is the SFC encapsulation required to support the 19 Service Function Chaining (SFC) architecture (defined in RFC7665). 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on February 13, 2018. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 57 1.2. Definition of Terms . . . . . . . . . . . . . . . . . . . 4 58 1.3. Problem Space . . . . . . . . . . . . . . . . . . . . . . 5 59 1.4. NSH-based Service Chaining . . . . . . . . . . . . . . . 5 60 2. Network Service Header . . . . . . . . . . . . . . . . . . . 6 61 2.1. Network Service Header Format . . . . . . . . . . . . . . 6 62 2.2. NSH Base Header . . . . . . . . . . . . . . . . . . . . . 7 63 2.3. Service Path Header . . . . . . . . . . . . . . . . . . . 9 64 2.4. NSH MD Type 1 . . . . . . . . . . . . . . . . . . . . . . 10 65 2.5. NSH MD Type 2 . . . . . . . . . . . . . . . . . . . . . . 11 66 2.5.1. Optional Variable Length Metadata . . . . . . . . . . 12 67 3. NSH Actions . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 4. NSH Transport Encapsulation . . . . . . . . . . . . . . . . . 15 69 5. Fragmentation Considerations . . . . . . . . . . . . . . . . 15 70 6. Service Path Forwarding with NSH . . . . . . . . . . . . . . 16 71 6.1. SFFs and Overlay Selection . . . . . . . . . . . . . . . 16 72 6.2. Mapping NSH to Network Transport . . . . . . . . . . . . 19 73 6.3. Service Plane Visibility . . . . . . . . . . . . . . . . 20 74 6.4. Service Graphs . . . . . . . . . . . . . . . . . . . . . 20 75 7. Policy Enforcement with NSH . . . . . . . . . . . . . . . . . 20 76 7.1. NSH Metadata and Policy Enforcement . . . . . . . . . . . 20 77 7.2. Updating/Augmenting Metadata . . . . . . . . . . . . . . 22 78 7.3. Service Path Identifier and Metadata . . . . . . . . . . 24 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 80 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26 81 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 82 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 83 11.1. NSH EtherType . . . . . . . . . . . . . . . . . . . . . 28 84 11.2. Network Service Header (NSH) Parameters . . . . . . . . 28 85 11.2.1. NSH Base Header Bits . . . . . . . . . . . . . . . . 29 86 11.2.2. NSH Version . . . . . . . . . . . . . . . . . . . . 29 87 11.2.3. MD Type Registry . . . . . . . . . . . . . . . . . . 29 88 11.2.4. MD Class Registry . . . . . . . . . . . . . . . . . 29 89 11.2.5. NSH Base Header Next Protocol . . . . . . . . . . . 30 90 11.2.6. New IETF Assigned Optional Variable Length Metadata 91 Type Registry . . . . . . . . . . . . . . . . . . . 31 92 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 93 12.1. Normative References . . . . . . . . . . . . . . . . . . 31 94 12.2. Informative References . . . . . . . . . . . . . . . . . 32 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 97 1. Introduction 99 Service functions are widely deployed and essential in many networks. 100 These service functions provide a range of features such as security, 101 WAN acceleration, and server load balancing. Service functions may 102 be instantiated at different points in the network infrastructure 103 such as the wide area network, data center, campus, and so forth. 105 Prior to development of the SFC architecture [RFC7665] and the 106 protocol specified in this document, current service function 107 deployment models have been relatively static, and bound to topology 108 for insertion and policy selection. Furthermore, they do not adapt 109 well to elastic service environments enabled by virtualization. 111 New data center network and cloud architectures require more flexible 112 service function deployment models. Additionally, the transition to 113 virtual platforms demands an agile service insertion model that 114 supports dynamic and elastic service delivery. Specifically, the 115 following functions are necessary: 117 The movement of service functions and application workloads in the 118 network. 120 The ability to easily bind service policy to granular information, 121 such as per-subscriber state. 123 The capability to steer traffic to the requisite service 124 function(s). 126 The Network Service Header (NSH) specification defines a new protocol 127 for the creation of dynamic service chains, operating at the service 128 plane. NSH is composed of the following elements: 130 1. Service Function Path identification. 132 2. Indication of location within a Service Function Path. 134 3. Optional, per packet metadata (fixed length or variable). 136 NSH is designed to be easy to implement across a range of devices, 137 both physical and virtual, including hardware platforms. 139 The intended scope of NSH is for use within a single provider's 140 operational domain. This deployment scope is deliberatedly 141 constrained, as explained also in [RFC7665], and limited to a single 142 network administrative domain. In this context, a "domain" is a set 143 of network entities within a single administration. For example, a 144 network administrative domain can include a single data center, a 145 campus physical network, or an overlay domain using virtual 146 connetions and tunnels. A corollary is that a network administrative 147 domain has a well defined perimeter. 149 An NSH-aware control plane is outside the scope of this document. 151 [RFC7665] provides an overview of a service chaining architecture 152 that clearly defines the roles of the various elements and the scope 153 of a service function chaining encapsulation. NSH is the SFC 154 encapsulation referenced in [RFC7665]. 156 1.1. Requirements Language 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 160 document are to be interpreted as described in RFC 2119 [RFC2119]. 162 1.2. Definition of Terms 164 Byte: All references to "bytes" in this document refer to 8-bit 165 bytes, or octets. 167 Classification: Defined in [RFC7665]. 169 Classifier: Defined in [RFC7665]. 171 Metadata: Defined in [RFC7665]. 173 Network Locator: Dataplane address, typically IPv4 or IPv6, used to 174 send and receive network traffic. 176 Network Node/Element: Device that forwards packets or frames based 177 on an outer header (i.e., encapsulation) information. 179 Network Overlay: Logical network built on top of existing network 180 (the underlay). Packets are encapsulated or tunneled to create 181 the overlay network topology. 183 NSH-aware: NSH-aware means SFC-encapsulation-aware, with NSH as the 184 SFC encapsulation. This specification uses NSH-aware as a more 185 specific term from the more generic term SFC-aware [RFC7665]. 187 Service Classifier: Logical entity providing classification 188 function. Since they are logical, classifiers may be co-resident 189 with SFC elements such as SFs or SFFs. Service classifiers 190 perform classification and impose NSH. The initial classifier 191 imposes the initial NSH and sends the NSH packet to the first SFF 192 in the path. Non-initial (i.e., subsequent) classification can 193 occur as needed and can alter, or create a new service path. 195 Service Function (SF): Defined in [RFC7665]. 197 Service Function Chain (SFC): Defined in [RFC7665]. 199 Service Function Forwarder (SFF): Defined in [RFC7665]. 201 Service Function Path (SFP): Defined in [RFC7665]. 203 Service Plane: The collection of SFFs and associated SFs creates a 204 service-plane overlay in which all SFs reside [RFC7665]. 206 SFC Proxy: Defined in [RFC7665]. 208 1.3. Problem Space 210 NSH addresses several limitations associated with service function 211 deployments. [RFC7498] provides a comprehensive review of those 212 issues. 214 1.4. NSH-based Service Chaining 216 NSH creates a dedicated service plane, more specifically, NSH 217 enables: 219 1. Topological Independence: Service forwarding occurs within the 220 service plane, the underlying network topology does not require 221 modification. NSH provides an identifier used to select the 222 network overlay for network forwarding. 224 2. Service Chaining: NSH enables service chaining per [RFC7665]. 225 NSH contains path identification information needed to realize a 226 service path. Furthermore, NSH provides the ability to monitor 227 and troubleshoot a service chain, end-to-end via service-specific 228 OAM messages. NSH fields can be used by administrators (via, for 229 example, a traffic analyzer) to verify (account, ensure correct 230 chaining, provide reports, etc.) the path specifics of packets 231 being forwarded along a service path. 233 3. NSH provides a mechanism to carry shared metadata between 234 participating entities and service functions. The semantics of 235 the shared metadata is communicated via a control plane, which is 236 outside the scope of this document, to participating nodes. 237 [I-D.ietf-sfc-control-plane] provides an example of such in 238 Section 3.3. Examples of metadata include classification 239 information used for policy enforcement and network context for 240 forwarding post service delivery. Sharing the metadata allows 241 service functions to share initial and intermediate 242 classification results with downstream service functions saving 243 re-classification, where enough information was enclosed. 245 4. NSH offers a common and standards-based header for service 246 chaining to all network and service nodes. 248 5. Transport Agnostic: NSH is encapsulation-independent, meaning it 249 can be transported by a variety of protocols. An appropriate 250 (for a given deployment) encapsulation protocol can be used to 251 carry NSH-encapsulated traffic. This transport may form an 252 overlay network and if an existing overlay topology provides the 253 required service path connectivity, that existing overlay may be 254 used. 256 2. Network Service Header 258 NSH contains service path information and optionally metadata that 259 are added to a packet or frame and used to create a service plane. 260 An outer transport header is imposed, on NSH and the original packet/ 261 frame, for network forwarding. 263 A Service Classifier adds NSH. NSH is removed by the last SFF in the 264 service chain or by an SF that consumes the packet. 266 2.1. Network Service Header Format 268 NSH is composed of a 4-byte Base Header, a 4-byte Service Path Header 269 and optional Context Headers, as shown in Figure 1 below. 271 0 1 2 3 272 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 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Base Header | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Service Path Header | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | | 279 ~ Context Header(s) ~ 280 | | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 Figure 1: Network Service Header 285 Base header: Provides information about the service header and the 286 payload protocol. 288 Service Path Header: Provides path identification and location within 289 a service path. 291 Context header: Carries metadata (i.e., context data) along a service 292 path. 294 2.2. NSH Base Header 296 Figure 2 depicts the NSH base header: 298 0 1 2 3 299 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 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 Figure 2: NSH Base Header 306 Base Header Field Descriptions: 308 Version: The version field is used to ensure backward compatibility 309 going forward with future NSH specification updates. It MUST be set 310 to 0x0 by the sender, in this first revision of NSH. Given the 311 widespread implementation of existing hardware that uses the first 312 nibble after an MPLS label stack for ECMP decision processing, this 313 document reserves version 01b and this value MUST NOT be used in 314 future versions of the protocol. Please see [RFC7325] for further 315 discussion of MPLS-related forwarding requirements. 317 O bit: Setting this bit indicates an Operations, Administration, and 318 Maintenance (OAM) packet. The actual format and processing of SFC 319 OAM packets is outside the scope of this specification (see for 320 example [I-D.ietf-sfc-oam-framework] for one approach). 322 The O bit MUST be set for OAM packets and MUST NOT be set for non-OAM 323 packets. The O bit MUST NOT be modified along the SFP. 325 SF/SFF/SFC Proxy/Classifier implementations that do not support SFC 326 OAM procedures SHOULD discard packets with O bit set, but MAY support 327 a configurable parameter to enable forwarding received SFC OAM 328 packets unmodified to the next element in the chain. Forwarding OAM 329 packets unmodified by SFC elements that do not support SFC OAM 330 procedures may be acceptable for a subset of OAM functions, but can 331 result in unexpected outcomes for others, thus it is recommended to 332 analyze the impact of forwarding an OAM packet for all OAM functions 333 prior to enabling this behavior. The configurable parameter MUST be 334 disabled by default. 336 TTL: Indicates the maximum SFF hops for an SFP. This field is used 337 for service plane loop detection. The initial TTL value SHOULD be 338 configurable via the control plane; the configured initial value can 339 be specific to one or more SFPs. If no initial value is explicitly 340 provided, the default initial TTL value of 63 MUST be used. Each SFF 341 involved in forwarding an NSH packet MUST decrement the TTL value by 342 1 prior to NSH forwarding lookup. Decrementing by 1 from an incoming 343 value of 0 shall result in a TTL value of 63. The packet MUST NOT be 344 forwarded if TTL is, after decrement, 0. 346 All other flag fields, marked U, are unassigned and available for 347 future use, see Section 11.2.1. Unassigned bits MUST be set to zero 348 upon origination, and MUST be ignored and preserved unmodified by 349 other NSH supporting elements. Elements which do not understand the 350 meaning of any of these bits MUST NOT modify their actions based on 351 those unknown bits. 353 Length: The total length, in 4-byte words, of NSH including the Base 354 Header, the Service Path Header, the Fixed Length Context Header or 355 Variable Length Context Header(s). The length MUST be 0x6 for MD 356 Type equal to 0x1, and MUST be 0x2 or greater for MD Type equal to 357 0x2. The length of the NSH header MUST be an integer multiple of 4 358 bytes, thus variable length metadata is always padded out to a 359 multiple of 4 bytes. 361 MD Type: Indicates the format of NSH beyond the mandatory Base Header 362 and the Service Path Header. MD Type defines the format of the 363 metadata being carried. Please see the IANA Considerations 364 Section 11.2.3. 366 This document specifies the following four MD Type values: 368 0x0 - This is a reserved value. Implementations SHOULD silently 369 discard packets with MD Type 0x0. 371 0x1 - This indicates that the format of the header includes a fixed 372 length Context Header (see Figure 4 below). 374 0x2 - This does not mandate any headers beyond the Base Header and 375 Service Path Header, but may contain optional variable length Context 376 Header(s). The semantics of the variable length Context Header(s) 377 are not defined in this document. The format of the optional 378 variable length Context Headers is provided in Section 2.5.1. 380 0xF - This value is reserved for experimentation and testing, as per 381 [RFC3692]. Implementations not explicitly configured to be part of 382 an experiment SHOULD silently discard packets with MD Type 0xF. 384 The format of the Base Header and the Service Path Header is 385 invariant, and not affected by MD Type. 387 NSH MD Type 1 and MD Type 2 are described in detail in Sections 2.4 388 and 2.5, respectively. NSH implementations MUST support MD types 0x1 389 and 0x2 (where the length is 0x2). NSH implementations SHOULD 390 support MD Type 0x2 with length greater than 0x2. There exists, 391 however, a middle ground, wherein a device will support MD Type 0x1 392 (as per the MUST) metadata, yet be deployed in a network with MD Type 393 0x2 metadata packets. In that case, the MD Type 0x1 node, MUST 394 utilize the base header length field to determine the original 395 payload offset if it requires access to the original packet/frame. 396 This specification does not disallow the MD Type value from changing 397 along an SFP; however, the specification of the necessary mechanism 398 to allow the MD Type to change along an SFP are outside the scope of 399 this document, and would need to be defined for that functionality to 400 be available. Packets with MD Type values not supported by an 401 implementation MUST be silently dropped. 403 Next Protocol: indicates the protocol type of the encapsulated data. 404 NSH does not alter the inner payload, and the semantics on the inner 405 protocol remain unchanged due to NSH service function chaining. 406 Please see the IANA Considerations section below, Section 11.2.5. 408 This document defines the following Next Protocol values: 410 0x1: IPv4 411 0x2: IPv6 412 0x3: Ethernet 413 0x4: NSH 414 0x5: MPLS 415 0xFE: Experiment 1 416 0xFF: Experiment 2 418 Packets with Next Protocol values not supported SHOULD be silently 419 dropped by default, although an implementation MAY provide a 420 configuration parameter to forward them. Additionally, an 421 implementation not explicitly configured for a specific experiment 422 [RFC3692] SHOULD silently drop packets with Next Protocol values 0xFE 423 and 0xFF. 425 2.3. Service Path Header 427 Figure 3 shows the format of the Service Path Header: 429 0 1 2 3 430 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 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | Service Path Identifier (SPI) | Service Index | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 Service Path Identifier (SPI): 24 bits 436 Service Index (SI): 8 bits 438 Figure 3: NSH Service Path Header 440 The meaning of these fields is as follows: 442 Service Path Identifier (SPI): Identifies a service path. 443 Participating nodes MUST use this identifier for Service Function 444 Path selection. The initial classifier MUST set the appropriate SPI 445 for a given classification result. 447 Service Index (SI): Provides location within the SFP. The initial 448 classifier for a given SFP SHOULD set the SI to 255, however the 449 control plane MAY configure the initial value of SI as appropriate 450 (i.e., taking into account the length of the service function path). 451 The Service Index MUST be decremented by a value of 1 by Service 452 Functions or by SFC Proxy nodes after performing required services 453 and the new decremented SI value MUST be used in the egress packet's 454 NSH. The initial Classifier MUST send the packet to the first SFF in 455 the identified SFP for forwarding along an SFP. If re-classification 456 occurs, and that re-classification results in a new SPI, the 457 (re)classifier is, in effect, the initial classifier for the 458 resultant SPI. 460 The SI is used in conjunction the with Service Path Identifier for 461 Service Function Path Selection and for determining the next SFF/SF 462 in the path. The SI is also valuable when troubleshooting or 463 reporting service paths. Additionally, while the TTL field is the 464 main mechanism for service plane loop detection, the SI can also be 465 used for detecting service plane loops. 467 2.4. NSH MD Type 1 469 When the Base Header specifies MD Type = 0x1, a Fixed Length Context 470 Header (16-bytes) MUST be present immediately following the Service 471 Path Header, as per Figure 4. The value of a Fixed Length Context 472 Header that carries no metadata MUST be set to zero. 474 0 1 2 3 475 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 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | Service Path Identifier | Service Index | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | | 482 | Fixed Length Context Header | 483 | | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 Figure 4: NSH MD Type=0x1 488 This specification does not make any assumptions about the content of 489 the 16 byte Context Header that must be present when the MD Type 490 field is set to 1, and does not describe the structure or meaning of 491 the included metadata. 493 An SFC-aware SF MUST receive the data semantics first in order to 494 process the data placed in the mandatory context field. The data 495 semantics include both the allocation schema and the meaning of the 496 included data. How an SFC-aware SF gets the data semantics is 497 outside the scope of this specification. 499 An SF or SFC Proxy that does not know the format or semantics of the 500 Context Header for an NSH with MD Type 1 MUST discard any packet with 501 such an NSH (i.e., MUST NOT ignore the metadata that it cannot 502 process), and MUST log the event at least once per the SPI for which 503 the event occurs (subject to thresholding). 505 [I-D.guichard-sfc-nsh-dc-allocation] and 506 [I-D.napper-sfc-nsh-broadband-allocation] provide specific examples 507 of how metadata can be allocated. 509 2.5. NSH MD Type 2 511 When the base header specifies MD Type = 0x2, zero or more Variable 512 Length Context Headers MAY be added, immediately following the 513 Service Path Header (see Figure 5). Therefore, Length = 0x2, 514 indicates that only the Base Header followed by the Service Path 515 Header are present. The optional Variable Length Context Headers 516 MUST be of an integer number of 4-bytes. The base header Length 517 field MUST be used to determine the offset to locate the original 518 packet or frame for SFC nodes that require access to that 519 information. 521 0 1 2 3 522 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 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | Service Path Identifier | Service Index | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | | 529 ~ Variable Length Context Headers (opt.) ~ 530 | | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 Figure 5: NSH MD Type=0x2 535 2.5.1. Optional Variable Length Metadata 537 The format of the optional variable length Context Headers, is as 538 depicted in Figure 6. 540 0 1 2 3 541 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 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | Metadata Class | Type |U| Length | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | Variable Metadata | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 Figure 6: Variable Context Headers 550 Metadata Class (MD Class): Defines the scope of the 'Type' field to 551 provide a hierarchical namespace. The IANA Considerations 552 Section 11.2.4 defines how the MD Class values can be allocated to 553 standards bodies, vendors, and others. 555 Type: Indicates the explicit type of metadata being carried. The 556 definition of the Type is the responsibility of the MD Class owner. 558 Unassigned bit: One unassigned bit is available for future use. This 559 bit MUST NOT be set, and MUST be ignored on receipt. 561 Length: Indicates the length of the variable metadata, in bytes. In 562 case the metadata length is not an integer number of 4-byte words, 563 the sender MUST add pad bytes immediately following the last metadata 564 byte to extend the metadata to an integer number of 4-byte words. 565 The receiver MUST round up the length field to the nearest 4-byte 566 word boundary, to locate and process the next field in the packet. 567 The receiver MUST access only those bytes in the metadata indicated 568 by the length field (i.e., actual number of bytes) and MUST ignore 569 the remaining bytes up to the nearest 4-byte word boundary. The 570 Length may be 0 or greater. 572 A value of 0 denotes a Context Header without a Variable Metadata 573 field. 575 This specification does not make any assumption about Context Headers 576 that are mandatory-to-implement or those that are mandatory-to- 577 process. These considerations are deployment-specific. However, the 578 control plane is entitled to instruct SFC-aware SFs with the data 579 structure of context header together with its scoping (see 580 Section 3.3.3 of [I-D.ietf-sfc-control-plane]). 582 Upon receipt of a packet that belongs to a given SFP, if a mandatory- 583 to-process context header is missing in that packet, the SFC-aware SF 584 MUST NOT process the packet and MUST log at least once per the SPI 585 for which the mandatory metadata is missing. 587 If multiple mandatory-to-process context headers are required for a 588 given SFP, the control plane MAY instruct the SFC-aware SF with the 589 order to consume these Context Headers. If no instructions are 590 provided, the SFC-aware SF MUST process these Context Headers in the 591 order they appear in an NSH packet. 593 If multiple instances of the same metadata are included in an NSH 594 packet, but the definition of that context header does not allow for 595 it, the SFC-aware SF MUST process the first instance and ignore 596 subsequent instances. 598 3. NSH Actions 600 NSH-aware nodes are the only nodes that may alter the content of NSH 601 headers. NSH-aware nodes include: service classifiers, SFFs, SFs and 602 SFC proxies. These nodes have several possible NSH-related actions: 604 1. Insert or remove NSH: These actions can occur respectively at the 605 start and end of a service path. Packets are classified, and if 606 determined to require servicing, NSH will be imposed. A service 607 classifier MUST insert NSH at the start of an SFP. An imposed 608 NSH MUST contain both a valid Base Header and Service Path 609 Header. At the end of a service function path, an SFF, MUST be 610 the last node operating on the service header and MUST remove NSH 611 before forwarding or delivering the un-encapsulated packet. 613 Multiple logical classifiers may exist within a given service 614 path. Non-initial classifiers may re-classify data and that re- 615 classification MAY result in the selection of a different Service 616 Function Path. When the logical classifier performs re- 617 classification that results in a change of service path, it MUST 618 remove the existing NSH and MUST impose a new NSH with the Base 619 Header and Service Path Header reflecting the new service path 620 information and MUST set the initial SI. Metadata MAY be 621 preserved in the new NSH. 623 2. Select service path: The Service Path Header provides service 624 path information and is used by SFFs to determine correct service 625 path selection. SFFs MUST use the Service Path Header for 626 selecting the next SF or SFF in the service path. 628 3. Update NSH: SFs MUST decrement the service index by one. If an 629 SFF receives a packet with an SPI and SI that do not correspond 630 to a valid next hop in a valid Service Function Path, that packet 631 MUST be dropped by the SFF. 633 Classifiers MAY update Context Headers if new/updated context is 634 available. 636 If an SFC proxy is in use (acting on behalf of a NSH unaware 637 service function for NSH actions), then the proxy MUST update 638 Service Index and MAY update contexts. When an SFC proxy 639 receives an NSH-encapsulated packet, it MUST remove NSH before 640 forwarding it to an NSH unaware SF. When the SFC Proxy receives 641 a packet back from an NSH unaware SF, it MUST re-encapsulate it 642 with the correct NSH, and MUST decrement the Service Index by 643 one. 645 4. Service policy selection: Service Functions derive policy (i.e., 646 service actions such as permit or deny) selection and enforcement 647 from NSH. Metadata shared in NSH can provide a range of service- 648 relevant information such as traffic classification. 650 Figure 7 maps each of the four actions above to the components in the 651 SFC architecture that can perform it. 653 +----------------+---------------+-------+----------------+---------+ 654 | | Insert |Forward| Update |Service | 655 | | or remove NSH |NSH | NSH |policy | 656 | | |Packets| |selection| 657 | Component +-------+-------+ +----------------+ | 658 | | | | | Dec. |Update | | 659 | |Insert |Remove | |Service |Context| | 660 | | | | | Index |Header | | 661 +----------------+-------+-------+-------+--------+-------+---------+ 662 | | + | + | | | + | | 663 |Classifier | | | | | | | 664 +----------------+-------+-------+-------+--------+-------+---------+ 665 |Service Function| | + | + | | | | 666 |Forwarder(SFF) | | | | | | | 667 +----------------+-------+-------+-------+--------+-------+---------+ 668 |Service | | | | + | + | + | 669 |Function (SF) | | | | | | | 670 +----------------+-------+-------+-------+--------+-------+---------+ 671 |SFC Proxy | + | + | | + | + | | 672 +----------------+-------+-------+-------+--------+-------+---------+ 674 Figure 7: NSH Action and Role Mapping 676 4. NSH Transport Encapsulation 678 Once NSH is added to a packet, an outer encapsulation is used to 679 forward the original packet and the associated metadata to the start 680 of a service chain. The encapsulation serves two purposes: 682 1. Creates a topologically independent services plane. Packets are 683 forwarded to the required services without changing the 684 underlying network topology. 686 2. Transit network nodes simply forward the encapsulated packets 687 without modification. 689 The service header is independent of the encapsulation used and is 690 encapsulated in existing transports. The presence of NSH is 691 indicated via protocol type or other indicator in the outer 692 encapsulation. 694 5. Fragmentation Considerations 696 NSH and the associated transport header are "added" to the 697 encapsulated packet/frame. This additional information increases the 698 size of the packet. 700 As discussed in [I-D.ietf-rtgwg-dt-encap], within an administrative 701 domain, an operator can ensure that the underlay MTU is sufficient to 702 carry SFC traffic without requiring fragmentation. 704 However, there will be cases where the underlay MTU is not large 705 enough to carry the NSH traffic. Since NSH does not provide 706 fragmentation support at the service plane, the transport/overlay 707 layer MUST provide the requisite fragmentation handling. Section 9 708 of [I-D.ietf-rtgwg-dt-encap] provides guidance for those scenarios. 710 For example, when NSH is encapsulated in IP, IP-level fragmentation 711 coupled with Path MTU Discovery (PMTUD) is used. When, on the other 712 hand, the underlay does not support fragmentation procedures, an 713 error message SHOULD be logged when dropping a packet too big. 714 Lastly, NSH-specific fragmentation and reassembly methods may be 715 defined as well, but these methods are outside the scope of this 716 document. 718 6. Service Path Forwarding with NSH 720 6.1. SFFs and Overlay Selection 722 As described above, NSH contains a Service Path Identifier (SPI) and 723 a Service Index (SI). The SPI is, as per its name, an identifier. 724 The SPI alone cannot be used to forward packets along a service path. 725 Rather the SPI provides a level of indirection between the service 726 path/topology and the network transport. Furthermore, there is no 727 requirement, or expectation of an SPI being bound to a pre-determined 728 or static network path. 730 The Service Index provides an indication of location within a service 731 path. The combination of SPI and SI provides the identification of a 732 logical SF and its order within the service plane, and is used to 733 select the appropriate network locator(s) for overlay forwarding. 734 The logical SF may be a single SF, or a set of eligible SFs that are 735 equivalent. In the latter case, the SFF provides load distribution 736 amongst the collection of SFs as needed. 738 SI serves as a mechanism for detecting invalid service function 739 paths. In particular, an SI value of zero indicates that forwarding 740 is incorrect and the packet must be discarded. 742 This indirection -- SPI to overlay -- creates a true service plane. 743 That is, the SFF/SF topology is constructed without impacting the 744 network topology but more importantly, service plane only 745 participants (i.e., most SFs) need not be part of the network overlay 746 topology and its associated infrastructure (e.g., control plane, 747 routing tables, etc.) SFs need to be able to return a packet to an 748 appropriate SFF (i.e., has the requisite NSH information) when 749 service processing is complete. This can be via the overlay or 750 underlay and in some case require additional configuration on the SF. 751 As mentioned above, an existing overlay topology may be used provided 752 it offers the requisite connectivity. 754 The mapping of SPI to transport occurs on an SFF (as discussed above, 755 the first SFF in the path gets an NSH encapsulated packet from the 756 Classifier). The SFF consults the SPI/ID values to determine the 757 appropriate overlay transport protocol (several may be used within a 758 given network) and next hop for the requisite SF. Table 1 below 759 depicts an example of a single next-hop SPI/SI to network overlay 760 network locator mapping. 762 +------+------+---------------------+-------------------+ 763 | SPI | SI | Next hop(s) | Transport | 764 +------+------+---------------------+-------------------+ 765 | 10 | 255 | 192.0.2.1 | VXLAN-gpe | 766 | | | | | 767 | 10 | 254 | 198.51.100.10 | GRE | 768 | | | | | 769 | 10 | 251 | 198.51.100.15 | GRE | 770 | | | | | 771 | 40 | 251 | 198.51.100.15 | GRE | 772 | | | | | 773 | 50 | 200 | 01:23:45:67:89:ab | Ethernet | 774 | | | | | 775 | 15 | 212 | Null (end of path) | None | 776 +------+------+---------------------+-------------------+ 778 Table 1: SFF NSH Mapping Example 780 Additionally, further indirection is possible: the resolution of the 781 required SF network locator may be a localized resolution on an SFF, 782 rather than a service function chain control plane responsibility, as 783 per Table 2 and Table 3 below. 785 Please note: VXLAN-gpe and GRE in the above table refer to 786 [I-D.ietf-nvo3-vxlan-gpe] and [RFC2784] [RFC7676], respectively. 788 +------+-----+----------------+ 789 | SPI | SI | Next hop(s) | 790 +------+-----+----------------+ 791 | 10 | 3 | SF2 | 792 | | | | 793 | 245 | 12 | SF34 | 794 | | | | 795 | 40 | 9 | SF9 | 796 +------+-----+----------------+ 798 Table 2: NSH to SF Mapping Example 800 +------+-------------------+-------------+ 801 | SF | Next hop(s) | Transport | 802 +------+-------------------+-------------+ 803 | SF2 | 192.0.2.2 | VXLAN-gpe | 804 | | | | 805 | SF34 | 198.51.100.34 | UDP | 806 | | | | 807 | SF9 | 2001:db8::1 | GRE | 808 +------+-------------------+-------------+ 810 Table 3: SF Locator Mapping Example 812 Since the SPI is a representation of the service path, the lookup may 813 return more than one possible next-hop within a service path for a 814 given SF, essentially a series of weighted (equally or otherwise) 815 paths to be used (for load distribution, redundancy, or policy), see 816 Table 4. The metric depicted in Table 4 is an example to help 817 illustrated weighing SFs. In a real network, the metric will range 818 from a simple preference (similar to routing next-hop), to a true 819 dynamic composite metric based on some service function-centric state 820 (including load, sessions state, capacity, etc.) 821 +------+-----+--------------+---------+ 822 | SPI | SI | NH | Metric | 823 +------+-----+--------------+---------+ 824 | 10 | 3 | 203.0.113.1 | 1 | 825 | | | | | 826 | | | 203.0.113.2 | 1 | 827 | | | | | 828 | 20 | 12 | 192.0.2.1 | 1 | 829 | | | | | 830 | | | 203.0.113.4 | 1 | 831 | | | | | 832 | 30 | 7 | 192.0.2.10 | 10 | 833 | | | | | 834 | | | 198.51.100.1 | 5 | 835 +------+-----+--------------+---------+ 837 (encapsulation type omitted for formatting) 839 Table 4: NSH Weighted Service Path 841 6.2. Mapping NSH to Network Transport 843 As described above, the mapping of SPI to network topology may result 844 in a single path, or it might result in a more complex topology. 845 Furthermore, the SPI to overlay mapping occurs at each SFF 846 independently. Any combination of topology selection is possible. 847 Please note, there is no requirement to create a new overlay topology 848 if a suitable one already exists. NSH packets can use any (new or 849 existing) overlay provided the requisite connectivity requirements 850 are satisfied. 852 Examples of mapping for a topology: 854 1. Next SF is located at SFFb with locator 2001:db8::1 855 SFFa mapping: SPI=10 --> VXLAN-gpe, dst-ip: 2001:db8::1 857 2. Next SF is located at SFFc with multiple network locators for 858 load distribution purposes: 859 SFFb mapping: SPI=10 --> VXLAN-gpe, dst_ip:203.0.113.1, 860 203.0.113.2, 203.0.113.3, equal cost 862 3. Next SF is located at SFFd with two paths from SFFc, one for 863 redundancy: 864 SFFc mapping: SPI=10 --> VXLAN-gpe, dst_ip:192.0.2.10 cost=10, 865 203.0.113.10, cost=20 867 In the above example, each SFF makes an independent decision about 868 the network overlay path and policy for that path. In other words, 869 there is no a priori mandate about how to forward packets in the 870 network (only the order of services that must be traversed). 872 The network operator retains the ability to engineer the network 873 paths as required. For example, the overlay path between SFFs may 874 utilize traffic engineering, QoS marking, or ECMP, without requiring 875 complex configuration and network protocol support to be extended to 876 the service path explicitly. In other words, the network operates as 877 expected, and evolves as required, as does the service plane. 879 6.3. Service Plane Visibility 881 The SPI and SI serve an important function for visibility into the 882 service topology. An operator can determine what service path a 883 packet is "on", and its location within that path simply by viewing 884 NSH information (packet capture, IPFIX, etc.) The information can be 885 used for service scheduling and placement decisions, troubleshooting, 886 and compliance verification. 888 6.4. Service Graphs 890 While a given realized service function path is a specific sequence 891 of service functions, the service as seen by a user can actually be a 892 collection of service function paths, with the interconnection 893 provided by classifiers (in-service path, non-initial 894 reclassification). These internal reclassifiers examine the packet 895 at relevant points in the network, and, if needed, SPI and SI are 896 updated (whether this update is a re-write, or the imposition of a 897 new NSH with new values is implementation specific) to reflect the 898 "result" of the classification. These classifiers may also of course 899 modify the metadata associated with the packet. 900 [RFC7665], Section 2.1 describes Service Graphs in detail. 902 7. Policy Enforcement with NSH 904 7.1. NSH Metadata and Policy Enforcement 906 As described in Section 2, NSH provides the ability to carry metadata 907 along a service path. This metadata may be derived from several 908 sources, common examples include: 910 Network nodes/devices: Information provided by network nodes can 911 indicate network-centric information (such as VRF or tenant) that 912 may be used by service functions, or conveyed to another network 913 node post service path egress. 915 External (to the network) systems: External systems, such as 916 orchestration systems, often contain information that is valuable 917 for service function policy decisions. In most cases, this 918 information cannot be deduced by network nodes. For example, a 919 cloud orchestration platform placing workloads "knows" what 920 application is being instantiated and can communicate this 921 information to all NSH nodes via metadata carried in the context 922 header(s). 924 Service Functions: A classifier co-resident with Service Functions 925 often perform very detailed and valuable classification. 927 Regardless of the source, metadata reflects the "result" of 928 classification. The granularity of classification may vary. For 929 example, a network switch, acting as a classifier, might only be able 930 to classify based on a 5-tuple, whereas, a service function may be 931 able to inspect application information. Regardless of granularity, 932 the classification information can be represented in NSH. 934 Once the data is added to NSH, it is carried along the service path, 935 NSH-aware SFs receive the metadata, and can use that metadata for 936 local decisions and policy enforcement. Figure 8 and Figure 9 937 highlight the relationship between metadata and policy: 939 +-------+ +-------+ +-------+ 940 | SFF )------->( SFF |------->| SFF | 941 +---+---+ +---+---+ +---+---+ 942 ^ | | 943 ,-|-. ,-|-. ,-|-. 944 / \ / \ / \ 945 ( Class ) ( SF1 ) ( SF2 ) 946 \ ify / \ / \ / 947 `---' `---' `---' 948 5-tuple: Permit Inspect 949 Tenant A Tenant A AppY 950 AppY 952 Figure 8: Metadata and Policy 954 +-----+ +-----+ +-----+ 955 | SFF |---------> | SFF |----------> | SFF | 956 +--+--+ +--+--+ +--+--+ 957 ^ | | 958 ,-+-. ,-+-. ,-+-. 959 / \ / \ / \ 960 ( Class ) ( SF1 ) ( SF2 ) 961 \ ify / \ / \ / 962 `-+-' `---' `---' 963 | Permit Deny AppZ 964 +---+---+ employees 965 | | 966 +-------+ 967 External 968 system: 969 Employee 970 AppZ 972 Figure 9: External Metadata and Policy 974 In both of the examples above, the service functions perform policy 975 decisions based on the result of the initial classification: the SFs 976 did not need to perform re-classification, rather they rely on a 977 antecedent classification for local policy enforcement. 979 Depending on the information carried in the metadata, data privacy 980 considerations may need to be considered. For example, if the 981 metadata conveys tenant information, that information may need to be 982 authenticated and/or encrypted between the originator and the 983 intended recipients (which may include intended SFs only) . NSH 984 itself does not provide privacy functions, rather it relies on the 985 transport/overlay layer. An operator can select the appropriate 986 transport to ensure confidentially (and other security) 987 considerations are met. Metadata privacy and security considerations 988 are a matter for the documents that define metadata format. 990 7.2. Updating/Augmenting Metadata 992 Post-initial metadata imposition (typically performed during initial 993 service path determination), the metadata may be augmented or 994 updated: 996 1. Metadata Augmentation: Information may be added to NSH's existing 997 metadata, as depicted in Figure 10. For example, if the initial 998 classification returns the tenant information, a secondary 999 classification (perhaps co-resident with DPI or SLB) may augment 1000 the tenant classification with application information, and 1001 impose that new information in NSH metadata. The tenant 1002 classification is still valid and present, but additional 1003 information has been added to it. 1005 2. Metadata Update: Subsequent classifiers may update the initial 1006 classification if it is determined to be incorrect or not 1007 descriptive enough. For example, the initial classifier adds 1008 metadata that describes the traffic as "Internet" but a security 1009 service function determines that the traffic is really "attack". 1010 Figure 11 illustrates an example of updating metadata. 1012 +-----+ +-----+ +-----+ 1013 | SFF |---------> | SFF |----------> | SFF | 1014 +--+--+ +--+--+ +--+--+ 1015 ^ | | 1016 ,---. ,---. ,---. 1017 / \ / \ / \ 1018 ( Class ) ( SF1 ) ( SF2 ) 1019 \ / \ / \ / 1020 `-+-' `---' `---' 1021 | Inspect Deny 1022 +---+---+ employees employee+ 1023 | | Class=AppZ appZ 1024 +-------+ 1025 External 1026 system: 1027 Employee 1029 Figure 10: Metadata Augmentation 1031 +-----+ +-----+ +-----+ 1032 | SFF |---------> | SFF |----------> | SFF | 1033 +--+--+ +--+--+ +--+--+ 1034 ^ | | 1035 ,---. ,---. ,---. 1036 / \ / \ / \ 1037 ( Class ) ( SF1 ) ( SF2 ) 1038 \ / \ / \ / 1039 `---' `---' `---' 1040 5-tuple: Inspect Deny 1041 Tenant A Tenant A attack 1042 --> attack 1044 Figure 11: Metadata Update 1046 7.3. Service Path Identifier and Metadata 1048 Metadata information may influence the service path selection since 1049 the Service Path Identifier values can represent the result of 1050 classification. A given SPI can be defined based on classification 1051 results (including metadata classification). The imposition of the 1052 SPI and SI results in the packet being placed on the newly specified 1053 SFP at the position indicated by the imposed SPI and SI. 1055 This relationship provides the ability to create a dynamic service 1056 plane based on complex classification without requiring each node to 1057 be capable of such classification, or requiring a coupling to the 1058 network topology. This yields service graph functionality as 1059 described in Section 6.4. Figure 12 illustrates an example of this 1060 behavior. 1062 +-----+ +-----+ +-----+ 1063 | SFF |---------> | SFF |------+---> | SFF | 1064 +--+--+ +--+--+ | +--+--+ 1065 | | | | 1066 ,---. ,---. | ,---. 1067 / \ / SF1 \ | / \ 1068 ( SCL ) ( + ) | ( SF2 ) 1069 \ / \SCL2 / | \ / 1070 `---' `---' +-----+ `---' 1071 5-tuple: Inspect | SFF | Original 1072 Tenant A Tenant A +--+--+ next SF 1073 --> DoS | 1074 V 1075 ,-+-. 1076 / \ 1077 ( SF10 ) 1078 \ / 1079 `---' 1080 DoS 1081 "Scrubber" 1083 Figure 12: Path ID and Metadata 1085 Specific algorithms for mapping metadata to an SPI are outside the 1086 scope of this document. 1088 8. Security Considerations 1090 As with many other protocols, the NSH encapsulation could be spoofed 1091 or otherwise modified in transit. However, the deployment scope (as 1092 defined in [RFC7665]) of the NSH encapsulation is limited to a single 1093 network administrative domain as a controlled environment, with 1094 trusted devices (e.g., a data center) thus mitigating the risk of 1095 unauthorized manipulation of the encapsulation headers or metadata. 1097 NSH is always encapsulated in a transport protocol (as detailed in 1098 Section 4 of this specification) and therefore, when required, 1099 existing security protocols that provide authenticity (e.g., 1100 [RFC6071]) can be used. Similarly, if confidentiality is required, 1101 existing encryption protocols can be used in conjunction with the NSH 1102 encapsulation. 1104 Further, existing best practices, such as [BCP38] SHOULD be deployed 1105 at the network layer to ensure that traffic entering the service path 1106 is indeed "valid". [I-D.ietf-rtgwg-dt-encap] provides additional 1107 transport encapsulation considerations. 1109 Even though much of the metadata carried within the NSH encapsulation 1110 is derived from the packet contents, and thus is not privacy or 1111 security sensitive, NSH metadata authenticity and confidentiality 1112 must be considered as well. In order to protect the metadata, an 1113 operator can leverage the aforementioned mechanisms provided by the 1114 transport layer including authenticity and/or confidentiality. An 1115 operator MUST carefully select the transport/underlay services to 1116 ensure end-to-end security services, when those are sought. For 1117 example, if [RFC6071] is used, the operator MUST ensure it can be 1118 supported by the transport/underlay of all relevant network segments 1119 as well as SFFs and SFs in the service path. Further, as described 1120 under the "SFC Encapsulation" area of the Security Considerations of 1121 [RFC7665], operators can and should use indirect identification for 1122 metadata deemed to be sensitive (such as personally identifying 1123 information), thus significantly mitigating the risk of privacy 1124 violation. In particular, subscriber identifying information should 1125 be handled carefully, and in general should be obfuscated. This is 1126 covered in the Security Considerations of [RFC7665]. For those 1127 situations where obfuscation is either inapplicable or judged to be 1128 insufficient, one can also encrypt the metadata. An approach to an 1129 optional capability to do this was explored 1130 [I-D.reddy-sfc-nsh-encrypt]. Means to prevent leaking privacy- 1131 related information outside an administrative domain are natively 1132 supported by NSH given that the last SFF of a servicepath will 1133 systematically remove the NSH encapsulation before forwarding a 1134 packet exiting the service path. 1136 Lastly, SF security, although out of scope of this document, should 1137 be considered, particularly if an SF needs to access, authenticate, 1138 or update the NSH encapsulation or metadata. However, again the 1139 placement of SFs is assumed to be bounded within the scope of a 1140 single administrative domain and therefore under direct control of 1141 the operator. 1143 9. Contributors 1145 This WG document originated as draft-quinn-sfc-nsh and had the 1146 following co-authors and contributors. The editors of this document 1147 would like to thank and recognize them and their contributions. 1148 These co-authors and contributors provided invaluable concepts and 1149 content for this document's creation. 1151 Surendra Kumar 1152 Cisco Systems 1153 smkumar@cisco.com 1155 Michael Smith 1156 Cisco Systems 1157 michsmit@cisco.com 1159 Jim Guichard 1160 Huawei 1161 james.n.guichard@huawei.com 1163 Rex Fernando 1164 Cisco Systems 1165 Email: rex@cisco.com 1167 Navindra Yadav 1168 Cisco Systems 1169 Email: nyadav@cisco.com 1171 Wim Henderickx 1172 Alcatel-Lucent 1173 wim.henderickx@alcatel-lucent.com 1175 Andrew Dolganow 1176 Alcaltel-Lucent 1177 Email: andrew.dolganow@alcatel-lucent.com 1179 Praveen Muley 1180 Alcaltel-Lucent 1181 Email: praveen.muley@alcatel-lucent.com 1183 Tom Nadeau 1184 Brocade 1185 tnadeau@lucidvision.com 1187 Puneet Agarwal 1188 puneet@acm.org 1190 Rajeev Manur 1191 Broadcom 1192 rmanur@broadcom.com 1194 Abhishek Chauhan 1195 Citrix 1196 Abhishek.Chauhan@citrix.com 1198 Joel Halpern 1199 Ericsson 1200 joel.halpern@ericsson.com 1202 Sumandra Majee 1203 F5 1204 S.Majee@f5.com 1206 David Melman 1207 Marvell 1208 davidme@marvell.com 1210 Pankaj Garg 1211 Microsoft 1212 pankajg@microsoft.com 1214 Brad McConnell 1215 Rackspace 1216 bmcconne@rackspace.com 1218 Chris Wright 1219 Red Hat Inc. 1220 chrisw@redhat.com 1222 Kevin Glavin 1223 Riverbed 1224 kevin.glavin@riverbed.com 1226 Hong (Cathy) Zhang 1227 Huawei US R&D 1228 cathy.h.zhang@huawei.com 1230 Louis Fourie 1231 Huawei US R&D 1232 louis.fourie@huawei.com 1234 Ron Parker 1235 Affirmed Networks 1236 ron_parker@affirmednetworks.com 1238 Myo Zarny 1239 Goldman Sachs 1240 myo.zarny@gs.com 1242 10. Acknowledgments 1244 The authors would like to thank Sunil Vallamkonda, Nagaraj Bagepalli, 1245 Abhijit Patra, Peter Bosch, Darrel Lewis, Pritesh Kothari, Tal 1246 Mizrahi and Ken Gray for their detailed review, comments and 1247 contributions. 1249 A special thank you goes to David Ward and Tom Edsall for their 1250 guidance and feedback. 1252 Additionally the authors would like to thank Larry Kreeger for his 1253 invaluable ideas and contributions which are reflected throughout 1254 this document. 1256 Loa Andersson provided a thorough review and valuable comments, we 1257 thank him for that. 1259 Reinaldo Penno deserves a particular thank you for his architecture 1260 and implementation work that helped guide the protocol concepts and 1261 design. 1263 The editors also acknowledge comprehensive reviews and respective 1264 suggestions by Med Boucadair, Adrian Farrel, Juergen Schoenwaelder, 1265 and Acee Lindem. 1267 Lastly, David Dolson has provides significant review, feedback and 1268 suggestions throughout the evolution of this document. His 1269 contributions are very much appreciated. 1271 11. IANA Considerations 1273 11.1. NSH EtherType 1275 An IEEE EtherType, 0x894F, has been allocated for NSH. 1277 11.2. Network Service Header (NSH) Parameters 1279 IANA is requested to create a new "Network Service Header (NSH) 1280 Parameters" registry. The following sub-sections request new 1281 registries within the "Network Service Header (NSH) Parameters " 1282 registry. 1284 11.2.1. NSH Base Header Bits 1286 There are five unassigned bits (U bits) in the NSH Base Header, and 1287 one assigned bit (O bit). New bits are assigned via Standards Action 1288 [RFC8126]. 1290 Bit 2 - O (OAM) bit 1291 Bit 3 - Unassigned 1292 Bits 16-19 - Unassigned 1294 11.2.2. NSH Version 1296 IANA is requested to setup a registry of "NSH Version". New values 1297 are assigned via Standards Action [RFC8126]. 1299 Version 00b: This protocol version. This document. 1300 Version 01b: Reserved. This document. 1301 Version 10b: Unassigned. 1302 Version 11b: Unassigned. 1304 11.2.3. MD Type Registry 1306 IANA is requested to set up a registry of "MD Types". These are 1307 4-bit values. MD Type values 0x0, 0x1, 0x2, and 0xF are specified in 1308 this document, see Table 5. Registry entries are assigned by using 1309 the "IETF Review" policy defined in RFC 8126 [RFC8126]. 1311 +----------+-----------------+---------------+ 1312 | MD Type | Description | Reference | 1313 +----------+-----------------+---------------+ 1314 | 0x0 | Reserved | This document | 1315 | | | | 1316 | 0x1 | NSH MD Type 1 | This document | 1317 | | | | 1318 | 0x2 | NSH MD Type 2 | This document | 1319 | | | | 1320 | 0x3..0xE | Unassigned | | 1321 | | | | 1322 | 0xF | Experimentation | This document | 1323 +----------+-----------------+---------------+ 1325 Table 5: MD Type Values 1327 11.2.4. MD Class Registry 1329 IANA is requested to set up a registry of "MD Class". These are 1330 16-bit values. New allocations are to be made according to the 1331 following policies: 1333 0x0000 to 0x01ff: IETF Review 1334 0x0200 to 0xfff5: Expert Review 1335 0xfff6 to 0xfffe: Experimental 1336 0xffff: Reserved 1338 IANA is requested to assign the values as per Table 6:: 1340 +-----------+-----------------------------+------------+ 1341 | MD Class | Meaning | Reference | 1342 +-----------+-----------------------------+------------+ 1343 | 0x0000 | IETF Base NSH MD Class | This.I-D | 1344 +-----------+-----------------------------+------------+ 1346 Table 6: MD Class Value 1348 Designated Experts evaluating new allocation requests from the 1349 "Expert Review" range should principally consider whether a new MD 1350 class is needed compared to adding MD types to an existing class. 1351 The Designated Experts should also encourage the existence of an 1352 associated and publicly visible registry of MD types although this 1353 registry need not be maintained by IANA. 1355 11.2.5. NSH Base Header Next Protocol 1357 IANA is requested to set up a registry of "Next Protocol". These are 1358 8-bit values. Next Protocol values 0, 1, 2, 3, 4 and 5 are defined 1359 in this document (see Table 7. New values are assigned via "Expert 1360 Reviews" as per [RFC8126]. 1362 +---------------+--------------+---------------+ 1363 | Next Protocol | Description | Reference | 1364 +---------------+--------------+---------------+ 1365 | 0x0 | Unassigned | | 1366 | | | | 1367 | 0x1 | IPv4 | This document | 1368 | | | | 1369 | 0x2 | IPv6 | This document | 1370 | | | | 1371 | 0x3 | Ethernet | This document | 1372 | | | | 1373 | 0x4 | NSH | This document | 1374 | | | | 1375 | 0x5 | MPLS | This document | 1376 | | | | 1377 | 0x6..0xFD | Unassigned | | 1378 | | | | 1379 | 0xFE | Experiment 1 | This document | 1380 | | | | 1381 | 0xFF | Experiment 2 | This document | 1382 +---------------+--------------+---------------+ 1384 Table 7: NSH Base Header Next Protocol Values 1386 11.2.6. New IETF Assigned Optional Variable Length Metadata Type 1387 Registry 1389 This document requests IANA to create a registry for the type values 1390 owned by the IETF (i.e., MD Class set to 0x0000) called the "IETF 1391 Assigned Optional Variable Length Metadata Type Registry", as 1392 specified in Section 2.5.1. 1394 The type values are assigned via Standards Action [RFC8126]. 1396 No initial values are assigned at the creation of the registry. 1398 12. References 1400 12.1. Normative References 1402 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1403 Requirement Levels", BCP 14, RFC 2119, 1404 DOI 10.17487/RFC2119, March 1997, 1405 . 1407 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 1408 Chaining (SFC) Architecture", RFC 7665, 1409 DOI 10.17487/RFC7665, October 2015, 1410 . 1412 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1413 Writing an IANA Considerations Section in RFCs", BCP 26, 1414 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1415 . 1417 12.2. Informative References 1419 [BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1420 Defeating Denial of Service Attacks which employ IP Source 1421 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 1422 May 2000, . 1424 [I-D.guichard-sfc-nsh-dc-allocation] 1425 Guichard, J., Smith, M., Surendra, S., Majee, S., Agarwal, 1426 P., Glavin, K., and Y. Laribi, "Network Service Header 1427 (NSH) Context Header Allocation (Data Center)", draft- 1428 guichard-sfc-nsh-dc-allocation-05 (work in progress), 1429 August 2016. 1431 [I-D.ietf-nvo3-vxlan-gpe] 1432 Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol 1433 Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-04 (work 1434 in progress), April 2017. 1436 [I-D.ietf-rtgwg-dt-encap] 1437 Nordmark, E., Tian, A., Gross, J., Hudson, J., Kreeger, 1438 L., Garg, P., Thaler, P., and T. Herbert, "Encapsulation 1439 Considerations", draft-ietf-rtgwg-dt-encap-02 (work in 1440 progress), October 2016. 1442 [I-D.ietf-sfc-control-plane] 1443 Boucadair, M., "Service Function Chaining (SFC) Control 1444 Plane Components & Requirements", draft-ietf-sfc-control- 1445 plane-08 (work in progress), October 2016. 1447 [I-D.ietf-sfc-oam-framework] 1448 Aldrin, S., Pignataro, C., Kumar, N., Akiya, N., Krishnan, 1449 R., and A. Ghanwani, "Service Function Chaining Operation, 1450 Administration and Maintenance Framework", draft-ietf-sfc- 1451 oam-framework-02 (work in progress), July 2017. 1453 [I-D.napper-sfc-nsh-broadband-allocation] 1454 Napper, J., Kumar, S., Muley, P., Henderickx, W., and M. 1455 Boucadair, "NSH Context Header Allocation -- Broadband", 1456 draft-napper-sfc-nsh-broadband-allocation-03 (work in 1457 progress), July 2017. 1459 [I-D.reddy-sfc-nsh-encrypt] 1460 Reddy, T., Patil, P., Fluhrer, S., and P. Quinn, 1461 "Authenticated and encrypted NSH service chains", draft- 1462 reddy-sfc-nsh-encrypt-00 (work in progress), April 2015. 1464 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 1465 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 1466 DOI 10.17487/RFC2784, March 2000, 1467 . 1469 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 1470 Considered Useful", BCP 82, RFC 3692, 1471 DOI 10.17487/RFC3692, January 2004, 1472 . 1474 [RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and 1475 Internet Key Exchange (IKE) Document Roadmap", RFC 6071, 1476 DOI 10.17487/RFC6071, February 2011, 1477 . 1479 [RFC7325] Villamizar, C., Ed., Kompella, K., Amante, S., Malis, A., 1480 and C. Pignataro, "MPLS Forwarding Compliance and 1481 Performance Requirements", RFC 7325, DOI 10.17487/RFC7325, 1482 August 2014, . 1484 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 1485 Service Function Chaining", RFC 7498, 1486 DOI 10.17487/RFC7498, April 2015, 1487 . 1489 [RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support 1490 for Generic Routing Encapsulation (GRE)", RFC 7676, 1491 DOI 10.17487/RFC7676, October 2015, 1492 . 1494 Authors' Addresses 1496 Paul Quinn (editor) 1497 Cisco Systems, Inc. 1499 Email: paulq@cisco.com 1500 Uri Elzur (editor) 1501 Intel 1503 Email: uri.elzur@intel.com 1505 Carlos Pignataro (editor) 1506 Cisco Systems, Inc. 1508 Email: cpignata@cisco.com