idnits 2.17.1 draft-boutros-nvo3-ipsec-over-geneve-01.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 (January 10, 2018) is 2297 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) == Outdated reference: A later version (-16) exists of draft-ietf-nvo3-geneve-05 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NVO3 S. Boutros, Ed. 3 Internet-Draft C. Qian 4 Intended status: Standards Track D. Wing 5 Expires: July 14, 2018 VMware, Inc. 6 January 10, 2018 8 IPsec over Geneve Encapsulation 9 draft-boutros-nvo3-ipsec-over-geneve-01 11 Abstract 13 This document specifies how Generic Network Virtualization 14 Encapsulation (Geneve) can be used to carry IP Encapsulating Security 15 Payload (ESP) and IP Authentication Header (AH) to provide secure 16 transport over IP networks. Using IPSec ESP the Geneve payload is 17 encrypted and integrity protected, and using IPSec AH the Geneve 18 headers and payload are integrity protected. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on July 14, 2018. 37 Copyright Notice 39 Copyright (c) 2018 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Encapsulation Security Payload (ESP) over Geneve tunnel . . . 3 58 5. IP Authentication header (AH) over Geneve tunnel . . . . . . 4 59 6. Control Plane Considerations . . . . . . . . . . . . . . . . 5 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 61 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 62 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 63 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 65 10.2. Informative References . . . . . . . . . . . . . . . . . 7 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 68 1. Introduction 70 The Network Virtualization over Layer 3 (NVO3) develop solutions for 71 network virtualization within a data center (DC) environment that 72 assumes an IP-based underlay. An NVO3 solution provides layer 2 and/ 73 or layer 3 overlay services for virtual networks enabling multi- 74 tenancy and workload mobility. The Generic Network Virtualization 75 Encapsulation [I-D.ietf-nvo3-geneve] have been recently recommended 76 to be the proposed standard for network virtualization overlay 77 encapsulation. 79 Generic Network Virtualization Encapsulation (Geneve) does not have 80 any inherent security mechanisms. An attacker with access to the 81 underlay network transporting the IP packets has the ability to snoop 82 or inject packets. 84 Within a particular security domain, such as a data center operated 85 by a single provider, the most common and highest performing security 86 mechanism is isolation of trusted components. Tunnel traffic can be 87 carried over a separate VLAN and filtered at any untrusted 88 boundaries. In addition, tunnel endpoints should only be operated in 89 environments controlled by the service provider, such as the 90 hypervisor itself rather than within a customer VM. 92 When crossing an untrusted link, such as the public Internet, IPsec 93 [RFC4301] may be used to provide authentication and/or encryption of 94 the IP packets formed as part of Geneve encapsulation. If the remote 95 tunnel endpoint is not completely trusted, for example it resides on 96 a customer premises, then it may also be necessary to sanitize any 97 tunnel metadata to prevent tenant-hopping attacks. 99 This document describes how Geneve tunnel encapsulation 100 [I-D.ietf-nvo3-geneve] can be used to carry both the IP Encapsulation 101 security payload (ESP) [RFC4303] and the IP authentication header 102 (AH) [RFC4302] to provide secure transport over IP networks. Using 103 IPsec ESP and AH will provide both Geneve header integrity protection 104 and Geneve payload encryption. 106 2. Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC 2119 [RFC2119]. 112 3. Abbreviations 114 NVO3: Network Virtualization Overlays over Layer 3 116 OAM: Operations, Administration, and Maintenance 118 TLV: Type, Length, and Value 120 VNI: Virtual Network Identifier 122 NVE: Network Virtualization Edge 124 NVA: Network Virtualization Authority 126 NIC: Network Interface Card 128 IPsec: IP Security 130 ESP: IP Encapsulating Security Payload 132 AH: IP Authentication Header 134 GRE: Generic Routing Encapsulation (GRE) 136 EtherIP: Tunneling Ethernet Frames in IP Datagrams 138 4. Encapsulation Security Payload (ESP) over Geneve tunnel 140 The Geneve packet is encapsulated in UDP over either IPv4 or IPv6. 141 The Geneve packet consists of a Geneve header which is then followed 142 by a set of variable options. The Geneve header protocol type will 143 indicate that the Geneve payload is the ESP protocol (IP Protocol 144 50), and the Geneve payload will consist of the ESP protocol data. 145 The ESP next header can carry only an IP protocol so can't carry the 146 inner Ethernet frame, so given that (1) Generic Routing Encapsulation 147 (GRE) [RFC2784] and EtherIP [RFC3378] are IP protocols and (2) GRE/ 148 EtherIP can carry Ethernet Frames, hence the need of EtherIP/GRE 149 encapsulation for the inner Ethernet payload. 151 The ESP Next Header field will be set to inner payload protocol which 152 can be either EtherIP (97) or to the Generic Routing Encapsulation 153 (GRE) (47). The GRE protocol type will be set to the Ethernet 154 protocol type. IPsec transport mode encryption is used. 156 Inner Ethernet packet, as sent/received by the virtual machine: 158 +----------+---------+ 159 | Ethernet | Ethernet| 160 | header | Payload | 161 +----------+---------+ 163 After applying Geneve and ESP, with ETH-IP header: 165 +-----+------+------+----------+------+---+-------+------+-------+---+ 166 |Ether|outer |UDP |Geneve Hdr|Geneve|ESP|EtherIP|Inner |ESP |ESP| 167 |hdr |IP |port= |Protocol |Option|Hdr|Header |Ether |Trailer|ICV| 168 | |header|Geneve|=50 |TLV(s)| | |packet| | | 169 +-----+------+------+----------+------+---+-------+------+-------+---+ 170 |<----Encrypted------->| 171 |<---Integrity------------>| 173 After applying Geneve and ESP, with GRE header: 175 +-----+------+------+----------+------+---+-------+------+-------+---+ 176 |Ether|outer |UDP |Geneve Hdr|Geneve|ESP|GRE |Inner |ESP |ESP| 177 |hdr |IP |port= |Protocol |Option|Hdr|Header |Ether |Trailer|ICV| 178 | |header|Geneve|=50 |TLV(s)| | |packet| | | 179 +-----+------+------+----------+------+---+-------+------+-------+---+ 180 |<----Encrypted------->| 181 |<---Integrity------------>| 183 5. IP Authentication header (AH) over Geneve tunnel 185 The Geneve packet is encapsulated in UDP over either IPv4 or IPv6. 186 The Geneve packet consists of a Geneve header which is then followed 187 by a set of variable options. The Geneve header protocol type will 188 indicate that the Geneve payload is the AH protocol (IP Protocol 51), 189 and the Geneve payload will consist of the Authentication header 190 (AH). The AH next header can carry only an IP protocol so can't 191 carry the inner Ethernet frame, so given that (1) Generic Routing 192 Encapsulation (GRE) [RFC2784] and EtherIP [RFC3378] are IP protocols 193 and (2) GRE/EtherIP can carry Ethernet Frames, hence the need of 194 EtherIP/GRE encapsulation for the inner Ethernet payload. 196 The AH Next Header field will be set to inner payload protocol which 197 can be either EtherIP (97) or to the Generic Routing Encapsulation 198 (GRE) (47). The GRE protocol type will be set to the Ethernet 199 protocol type. 201 It is to be noted that some of the option TLV(s) in the Geneve header 202 SHOULD be treated as mutable fields and not included in the AH 203 authentication. 205 Inner Ethernet packet, as sent/received by the virtual machine: 207 +----------+---------+ 208 | Ethernet | Ethernet| 209 | header | Payload | 210 +----------+---------+ 212 After applying Geneve and AH, with ETH-IP header: 214 +--------+------+------+----------+------+---+-------+------+ 215 |Ethernet|outer |UDP |Geneve Hdr|Geneve|AH |EtherIP|Inner | 216 |header |IP |port= |Protocol |Option| |Header |Ether | 217 | |header|Geneve|=51 |TLV(s)| | |packet| 218 +--------+------+------+----------+------+---+-------+------+ 219 |<--- authenticated except for mutable fields ---->| 221 After applying Geneve and AH, with GRE header: 223 +--------+------+------+----------+------+---+-------+------+ 224 |Ethernet|outer |UDP |Geneve Hdr|Geneve|AH |GRE |Inner | 225 |header |IP |port= |Protocol |Option| |Header |Ether | 226 | |header|Geneve|=51 |TLV(s)| | |packet| 227 +--------+------+------+----------+------+---+-------+------+ 228 |<--- authenticated except for mutable fields ---->| 230 6. Control Plane Considerations 232 A control plane extension could allow a Network Virtualization 233 Endpoint (NVE) to express the next protocol that can be carried by 234 Geneve to its peers. 236 In the datapath, a transmitting NVE MUST NOT encapsulate a packet 237 destined to another NVE with any protocol the receiving NVE is not 238 capable of processing. 240 In this document the next protocol signaled in control plane by 241 NVE(s) can be ESP or AH. 243 Once two NVE(s) agree to carry ESP or AH as next protocol, the NVEs 244 can use IKEv2 [RFC7296] to negotiate, establish, modify, and delete 245 IPsec Security Associations. 247 7. Security Considerations 249 If network policy requires IPsec encryption for certain traffic, it 250 is important to ensure un-encrypted packets are not delivered to the 251 guest virtual machine. This is implemented by dropping packets that 252 arrive without the necessary IPsec encryption. 254 8. IANA Considerations 256 This document does not register anything new with IANA. 258 9. Acknowledgements 260 The authors thank T. Sridhar for his valuable comments. 262 10. References 264 10.1. Normative References 266 [I-D.ietf-nvo3-geneve] 267 Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic 268 Network Virtualization Encapsulation", draft-ietf- 269 nvo3-geneve-05 (work in progress), September 2017. 271 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 272 Requirement Levels", BCP 14, RFC 2119, 273 DOI 10.17487/RFC2119, March 1997, 274 . 276 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 277 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 278 DOI 10.17487/RFC2784, March 2000, 279 . 281 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 282 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 283 December 2005, . 285 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 286 DOI 10.17487/RFC4302, December 2005, 287 . 289 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 290 RFC 4303, DOI 10.17487/RFC4303, December 2005, 291 . 293 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 294 Kivinen, "Internet Key Exchange Protocol Version 2 295 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 296 2014, . 298 10.2. Informative References 300 [RFC3378] Housley, R. and S. Hollenbeck, "EtherIP: Tunneling 301 Ethernet Frames in IP Datagrams", RFC 3378, 302 DOI 10.17487/RFC3378, September 2002, 303 . 305 Authors' Addresses 307 Sami Boutros (editor) 308 VMware, Inc. 309 3401 Hillview Ave. 310 Palo Alto, CA 94304 311 USA 313 Email: sboutros@vmware.com 315 Calvin Qian 316 VMware, Inc. 317 3401 Hillview Ave. 318 Palo Alto, CA 94304 319 USA 321 Email: calvinq@vmware.com 323 Dan Wing 324 VMware, Inc. 325 3401 Hillview Ave. 326 Palo Alto, CA 94304 327 USA 329 Email: dwing@vmware.com