idnits 2.17.1 draft-boutros-nvo3-geneve-applicability-for-sfc-02.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 14, 2018) is 2051 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) == Missing Reference: 'RFC2119' is mentioned on line 140, but not defined -- Looks like a reference, but probably isn't: '0' on line 263 == Missing Reference: 'RFC2104' is mentioned on line 431, but not defined == Unused Reference: 'KEYWORDS' is defined on line 499, but no explicit reference was found in the text == Unused Reference: 'Geneve' is defined on line 504, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Sami Boutros, Ed. 3 Intended Status: Standard Track VMware 4 Dharma Rajan 5 Philip Kippen 6 Pierluigi Rolando 7 VMware 9 Expires: March 18, 2019 September 14, 2018 11 Geneve applicability for service function chaining 12 draft-boutros-nvo3-geneve-applicability-for-sfc-02 14 Abstract 16 This document describes the applicability of using Generic Network 17 Virtualization Encapsulation (Geneve), to carry the service function 18 path (SFP) information, and the network service header (NSH) 19 encapsulation. The SFP information will be carried in Geneve option 20 TLV(s). 22 Status of this Memo 24 This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that 29 other groups may also distribute working documents as 30 Internet-Drafts. 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 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/1id-abstracts.html 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 Copyright and License Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1 Requirement for SFC in NVO3 domain . . . . . . . . . . . . . 3 61 1.2 Proposed solution for SFC in NVO3 domain . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4. Geneve Option TLV(s) . . . . . . . . . . . . . . . . . . . . . 5 65 4.1 Geneve Service Function List (SFL) Option TLV . . . . . . . 5 66 5.. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 5.1 Operation at Ingress . . . . . . . . . . . . . . . . . . . . 7 68 5.2 Operation at each NVE along the service function path . . . 8 69 5.3 Operation at Egress . . . . . . . . . . . . . . . . . . . . 9 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 9 71 7. Management Considerations . . . . . . . . . . . . . . . . . . . 10 72 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 73 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 10.1 Normative References . . . . . . . . . . . . . . . . . . . 11 76 10.2 Informative References . . . . . . . . . . . . . . . . . . 11 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 79 1. Introduction 81 The Service Function Chaining (SFC) Architecture [rfc7665] defines a 82 service function chain (SFC) as (1) the instantiation of an ordered 83 set of service functions and (2) the subsequent "steering" of traffic 84 through them. 86 SFC defines a Service Function Path (SFP) as the exact set of service 87 function forwarders (SFF)/service functions (SF)s the packet will 88 visit when it actually traverses the network. 90 An optimized SFP helps to build an efficient Service function chain 91 (SFC) that can be used to steer traffic based on classification 92 rules, and metadata information to provide services for Network 93 Function Virtualization (NFV). Metadata are typically passed between 94 service functions and Service function forwarders SFF(s) along a 95 service function path. 97 In a Network Virtualization Overlays (NVO3) domain, Network 98 Virtualization Edges (NVE)s can be implemented on hypervisors hosting 99 virtual network functions (VNF)s implementing service functions, or 100 on physical routers connected to service function appliances. NVO3 101 domain uses tunneling and encapsulation protocols such as Geneve to 102 provide connectivity for tenants workloads and service function 103 running in its domain. NVEs in an NVO3 domain are typically 104 controlled by a centralized network virtualization authority NVA. 106 [RFC8300] defines a new encapsulation protocol, network service 107 header (NSH) to encode the SFP and the metadata. 109 1.1 Requirement for SFC in NVO3 domain 111 The requirement is to provide service function chaining in an NVO3 112 domain without the need to implement yet another control plane for 113 service topology. 115 1.2 Proposed solution for SFC in NVO3 domain 117 This document specifies the applicability of using Generic Network 118 Virtualization Encapsulation (Geneve), to carry the service function 119 path (SFP) information, and the network service header (NSH) 120 encapsulation. 122 The SFP will be implemented using a new Geneve Service Function List 123 (SFL) option for use strictly between Network Virtualization Edges 124 (NVEs) performing the service forwarding function (SFF) in the same 125 Network Virtualization Overlay over Layer 3 NVO3 domain. The next 126 protocol in the Geneve Header will be the NSH EtherType, 0x894F. The 127 NSH encapsulation will include the Service Path Identifier (SPI) and 128 the Service Index (SI). The NSH SI will serve as an index to the VNF 129 hop to visit in the SFL. 131 In the absence of the SFL we would need a service topology control 132 plane. The Geneve overlay will encap the NSH encapsulation and the 133 next protocol on Geneve will be the NSH Ethertype. 135 2. Terminology 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in RFC 2119 [RFC2119]. 141 3. Abbreviations 143 NVO3 Network Virtualization Overlays over Layer 3 145 OAM Operations, Administration, and Maintenance 147 TLV Type, Length, and Value 149 VNI Virtual Network Identifier 151 NVE Network Virtualization Edge 153 NVA Network Virtualization Authority 155 NIC Network interface card 157 VTEP Virtual Tunnel End Point 159 Transit device Underlay network devices between NVE(s). 161 Service Function (SF): Defined in [RFC7665]. 163 Service Function Chain (SFC): Defined in [RFC7665]. 165 Service Function Forwarder (SFF): Defined in [RFC7665]. 167 Service Function Path (SFP): Defined in [RFC7665]. 169 Metadata: Defined in [[draft-ietf-sfc-nsh] 171 NFV: Network function virtualization. 173 VNF: Virtual network function 175 4. Geneve Option TLV(s) 177 4.1 Geneve Service Function List (SFL) Option TLV 179 Geneve Header: 181 0 1 2 3 182 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 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 |Ver| Opt Len |O|C| Rsvd. |Protocol Type = NSH Ethertype | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Virtual Network Identifier (VNI) | Reserved | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 Geneve Option Header: 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | SFL Option Class | Type |R|R|R| Length | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Variable Option Data | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 Followed by the NSH encapsulation which is composed of a 4-byte 198 Base Header, a 4-byte Service Path Header, and optional Context 199 Headers. 201 0 1 2 3 202 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 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Base Header | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Service Path Header | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | | 209 ~ Context Header(s) ~ 210 | | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 SFL Option Class = To be assigned by IANA 215 Type = To be assigned by IANA 217 'C' bit set, indicating endpoints must drop if they do not 218 recognize this option) 220 Length = variable. 222 Variable option data: 224 0 1 2 3 225 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 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 |Version|Flags |Reserved | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 ~ SF List[0] (32 or 128 bits IPv4/6 address) ~ 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | | 232 | | 233 ... 234 | | 235 | | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 ~ SF List [n] (32 or 128 bits IPv4/6 address) ~ 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 // // 240 // Optional sub-Type Length Value objects (variable) // 241 // // 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 Figure 1: Service Function List (SFL) Option TLV. 246 Reserved: 12 bits. SHOULD be unset on transmission and MUST be 247 ignored on receipt. 249 Flags: 250 0 1 2 3 4 5 6 7 251 +-+-+-+-+-+-+-+-+ 252 |H| Unused | 253 +-+-+-+-+-+-+-+-+ 254 Figure 2: SFL flags 256 H-flag: HMAC flag. If set, the HMAC sub-TLV is present and is 257 encoded as the last sub-TLV. 259 SF List[n]: 32 or 128 bits IPv4/6 addresses representing the nth 260 service function ip address in the List. 262 The SF List is encoded starting from the last hop of the path. I.e., 263 the first element of the list (SF List [0]) contains the last service 264 function of the path while the last element of the SF List (SF 265 List[n]) contains the first service function in the path. 267 HMAC sub-TLV is optional and contains the HMAC information. The 268 HMAC sub-TLV has the following format: 270 0 1 2 3 271 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 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | Type | Length | Reserved | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | HMAC Key ID (4 octets) | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | // 278 | HMAC (32 octets) // 279 | // 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 Figure 3: SFL HMAC sub-TLV. 283 Type: to be assigned by IANA (suggested value 1). 284 Length: 38. 285 Reserved: 2 octets. SHOULD be unset on transmission and MUST be 286 ignored on receipt. 287 HMAC Key ID: 4 octets. 288 HMAC: 32 octets. 289 HMAC and HMAC Key ID usage is described in Operation section. 291 The Following applies to the HMAC TLV: 293 When present, the HMAC sub-TLV MUST be encoded as the last sub-TLV 295 If the HMAC sub-TLV is present, the H-Flag (Figure 2) MUST be set. 297 When the H-flag is set, the NVE inspecting the Geneve Service 298 Function List Option TLV MUST find the HMAC sub-TLV in the last 38 299 octets of the option TLV. 301 5.. Operation 303 The mechanisms described in this section should work with both ipv4 304 and ipv6 for both customer inner payload and Geneve tunnel packets. 306 5.1 Operation at Ingress 308 A Source NVE acting as a service function classifier and a service 309 function forwarder can be any node in an NVO3 domain, originating 310 based on a classification policy for some customer inner payload an 311 IP Geneve tunnel packet with the service function list (SFL) option 312 TLV. The service functions in the SFL represent the IP addresses of 313 the service functions that the inner customer packets needs to be 314 inspected by. A controller can program the ingress NVE node to 315 classify traffic and identify a service function paths i.e the set of 316 service functions in the path. The mechanism through which an SFL is 317 derived by a controller or any other mechanisms is outside of the 318 scope of this document. 320 The ingress NVE node fills in the list of service functions in the 321 path, to the Geneve Service Function List option TLV, putting the 322 first service function ip address as the last element in the list and 323 the last service function ip address as the first element, setting of 324 the NSH service index to the first element. The ingress NVE node, 325 then, resolves the service first function ip address, to the NVE 326 virtual tunnel endpoint node hosting or directly connected to the 327 service function. 329 The Geneve tunnel destination is then set to the NVE tunnel endpoint 330 hosting the first service function, and the service index is 331 decremented to n-1 (where n is the number of elements in the SFL), 332 and set on the SFL option TLV. An NSH metadata can also be set on the 333 packet by the NVE ingress node. 335 The Geneve packet is sent out towards the first NVE. 337 HMAC optional sub-TLV may be set too. 339 5.2 Operation at each NVE along the service function path 341 The NVE node along the service function path corresponding to the 342 Geneve tunnel destination of the packet, receives the packet, perform 343 the service function forwarder function and identifies the SFL 344 option, and locates the service function in the list based on the 345 service index. 347 The Geneve tunnel header and option TLV(s) will be stripped and the 348 packet will be delivered to the service function or virtual network 349 function (VNF). The NVE maintains state related to the association of 350 the SFL option TLV and the NSH service path identifier. The packet 351 passed to the service function encaped with the NSH header and NSH 352 context, if the SF is NSH aware, other encapsulations like vlan or q- 353 in-q encap may be used to pass the metadata and NSH SPI to the SF 354 too. 356 When the packet comes back from the service function along with the 357 service path identifier (SPI) context, based on SPI on the packet the 358 NVE acting as the SFF will be able to locate the SFL option TLV. 360 If the metadata context indicate (1) that some service functions need 361 to be bypassed the NVE should bypass in the SFL the service functions 362 to be skipped and update the NSH service index accordingly. (2) A new 363 classification need to be performed on the packet, in that case the 364 NVE can re-classify the packet or sent it to an NVE node capable of 365 classification. 367 The NVE node, then, resolves the next service function ip address, to 368 the NVE virtual tunnel endpoint node hosting or directly connected to 369 the service function. 371 The NVE then sets the Geneve tunnel destination to the next NVE 372 tunnel endpoint, and the NSH service index is decremented by 1 and 373 set on the NSH Header, along with other NSH metadata option TLV. 375 The Geneve ip packet is sent out towards the next NVE. 377 5.3 Operation at Egress 379 At the last NVE node along the service function path, the NVE locates 380 the service function in the SFL option TLV based on the NSH service 381 index. The service index received at the last NVE node will be set to 382 1. 384 The Geneve tunnel header and option TLV(s) will be stripped and the 385 packet will be delivered to the service function. The NVE maintains 386 state related to the association of the SFL option TLV and the NSH 387 service path identifier. The packet passed to the service function 388 encaped with the NSH header and NSH context, if the SF is NSH aware, 389 other encapsulations like vlan or q-in-q encap may be used to pass 390 the metadata and NSH SPI to the SF too. 392 When the packet comes back from the service function, based on NSH 393 SPI on the packet or based the NVE will be able to locate the SFL 394 option TLV. 396 Given that the service index will be set to 1, the last NVE will now 397 deliver the packet to the NVE hosting or directly connected to the 398 inner packet destination. 400 A packet received with a service function index of 0 MUST be dropped. 402 6. Security Considerations 404 Only NVE(s) that are the destinations of the Geneve tunnel packet 405 will be inspecting the List of Service Function next hops Option. A 406 Source routing option has some well-known security issues as 407 described in [RFC4942] and [RFC5095]. 409 The main use case for the use of the Geneve List of Service Function 410 next hops Option will be within a single NVO3 administrative domain 411 where only trusted NVE nodes are enabled and configured participate, 412 this is the same model as in [RFC6554]. 414 NVE nodes MUST ignore the Geneve List of Service Function next hops 415 Option created by outsiders based on NVA or trusted control plane 416 information. 418 There is a need to prevent non-participating NVE node from using the 419 Geneve Service Function List option TLV, as described in [draft-ietf- 420 6man-segment-routing-header], we will use a security sub-TLV in the 421 Service Function List option TLV, the security sub-TLV will be based 422 on a key-hashed message authentication code (HMAC). 424 HMAC sub-TLV will contain: 426 HMAC Key-id, 32 bits wide; 428 HMAC, 256 bits wide (optional, exists only if HMAC Key-id is not 0). 430 The HMAC field is the output of the HMAC computation (per RFC 2104 431 [RFC2104]) using a pre-shared key identified by HMAC Key-id and of 432 the text which consists of the concatenation of: 434 The source IPv4/IPv6 Geneve tunnel address 436 Version and Flags 438 HMAC Key-id. 440 All addresses in the List. 442 The purpose of the HMAC optional sub-TLV is to verify the validity, 443 the integrity and the authorization of the Geneve Service Function 444 List option TLV itself. 446 The HMAC optional sub-TLV is located at the end of the Geneve Service 447 Function List option TLV. 449 The HMAC Key-id field serves as an index to the right combination of 450 pre-shared key and hash algorithm and except that a value of 0 means 451 that there is no HMAC field. 453 The HMAC Selection of a hash algorithm and Pre-shared key management 454 will follow the procedures described in [draft-ietf-6man-segment- 455 routing-header] section 6.2. 457 7. Management Considerations 458 The Source NVE can receive its information through any form of north 459 bound Orchestrator. These could be from any open networking 460 automation platform (ONAP) or others. The ingress to egress tunnel is 461 built and managed by the service function classifier and service 462 function forwarder by each node in an NVO3 domain. Error handling, is 463 handled by the classifier reporting to north bound management 464 systems. 466 8. Acknowledgements 468 The authors would like to acknowledge Jim Guichard for his feedback 469 and valuable comments to this document. 471 9. IANA Considerations 473 This document makes the following registrations in the "Geneve Option 474 Class" registry maintained by IANA: 476 Suggested Description Reference 477 Value 478 ---------------------------------------------------------- 479 XX Geneve List of Service Function next hops This document 481 In addition, this document request IANA to create and maintain a 482 new Registry: "Geneve List of Service Function next hops 483 Type-Value Objects". 485 The following code-point are requested from the registry: 487 Registry: Geneve List of Service Function next hops Type-Value 488 Objects 490 Suggested Description Reference 491 Value 492 ----------------------------------------------------- 493 1 HMAC TLV This document 495 10. References 497 10.1 Normative References 499 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 500 Requirement Levels", BCP 14, RFC 2119, March 1997. 502 10.2 Informative References 504 [Geneve] "Generic Network Virtualization Encapsulation", [I-D.ietf- 505 nvo3-geneve] 507 [RFC8300] Quinn, P., Elzur, U., and C. Pignataro, "Network Service 508 Header (NSH)", RFC 8300, January 2018, . 511 [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 512 Transition/Co-existence Security Considerations", RFC 4942, DOI 513 10.17487/RFC4942, September 2007, . 516 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 517 Routing Header for Source Routes with the Routing Protocol for Low- 518 Power and Lossy Networks (RPL)", RFC 6554, DOI 10.17487/RFC6554, 519 March 2012, . 521 [draft-ietf-6man-segment-routing-header] Previdi, S., et all, "IPv6 522 Segment Routing Header (SRH)", July 20, 2017, draft-ietf-6man- 523 segment-routing-header-07 525 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 526 of Type 0 Routing Headers in IPv6", RFC 5095, DOI 10.17487/RFC5095, 527 December 2007, . 529 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 530 Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 531 2015, . 533 Authors' Addresses 535 Sami Boutros 536 VMware 537 Email: sboutros@vmware.com 539 Dharma Rajan 540 VMware 541 Email: drajan@vmware.com 543 Philip Kippen 544 VMware 545 Email: pkippen@vmware.com 547 Pierluigi Rolando 548 VMware 549 Email: prolando@vmware.com