INTERNET-DRAFT Sami Boutros(Ed.)NVO3 S. Boutros, Ed. Internet-Draft C. Qian IntendedStatus: Standardstatus: Standards TrackVMware DanD. WingCalvin Qian VMwareExpires: July 14, 2018 VMware, Inc. January1,10, 2018June 30, 2017 IPSecIPsec over Geneveencapsulation draft-boutros-nvo3-ipsec-over-geneve-00Encapsulation draft-boutros-nvo3-ipsec-over-geneve-01 Abstract This document specifies how Generic Network Virtualization Encapsulation (Geneve) can be used to carry IP Encapsulating Security Payload (ESP) and IP Authentication Header (AH) to provide secure transport over IP networks. Using IPSec ESPand AH will provide boththe Geneveheaderpayload is encrypted and integrityprotectionprotected, and using IPSec AH the Geneve headers and payloadencryption.are integrity protected. Status ofthisThis Memo This Internet-Draft is submittedto IETFin full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force(IETF), its areas, and its working groups.(IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list ofThis Internet-DraftShadow Directories can be accessed at http://www.ietf.org/shadow.htmlwill expire on July 14, 2018. Copyrightand LicenseNotice Copyright (c)20172018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents(http://trustee.ietf.org/license-info)(https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . .. 32 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . ..3 3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . ..34.04. Encapsulation Security Payload (ESP) over Geneve tunnel . .4 5.0. 3 5. IP Authentication header (AH) over Geneve tunnel . . . . . .54 6. Control Plane Considerations . . . . . . . . . . . . . . . .. 65 7.Acknowledgements . . . .Security Considerations . . . . . . . . . . . . . . . . . . .76 8.SecurityIANA Considerations . . . . . . . . . . . . . . . . . . . .7. 6 9.IANA ConsiderationsAcknowledgements . . . . . . . . . . . . . . . . . . . . . .76 10. References . . . . . . . . . . . . . . . . . . . . . . . . .7 10.16 10.1. Normative References . . . . . . . . . . . . . . . . . .. 7 10.26 10.2. Informative References . . . . . . . . . . . . . . . . ..7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .. 87 1. Introduction The Network Virtualization over Layer 3 (NVO3) develop solutions for network virtualization within a data center (DC) environment that assumes an IP-based underlay. An NVO3 solution provides layer 2and/orand/ or layer 3 overlay services for virtual networks enabling multi- tenancy and workload mobility. The Generic Network Virtualization Encapsulation[GENEVE][I-D.ietf-nvo3-geneve] have been recently recommended to be the proposed standard for network virtualization overlay encapsulation. Generic Network Virtualization Encapsulation (Geneve) does not have any inherent security mechanisms. An attacker with access to the underlay network transporting the IP packets has the ability to snoop or inject packets. Within a particular security domain, such as a data center operated by a single provider, the most common and highest performing security mechanism is isolation of trusted components. Tunnel traffic can be carried over a separate VLAN and filtered at any untrusted boundaries. In addition, tunnel endpoints should only be operated in environments controlled by the service provider, such as the hypervisor itself rather than within a customer VM. When crossing an untrusted link, such as the public Internet, IPsec [RFC4301] may be used to provide authentication and/or encryption of the IP packets formed as part of Geneve encapsulation. If the remote tunnel endpoint is not completely trusted, for example it resides on a customer premises, then it may also be necessary to sanitize any tunnel metadata to prevent tenant-hopping attacks. This document describes how Geneve tunnel encapsulation[GENEVE][I-D.ietf-nvo3-geneve] can be used to carry both the IP Encapsulation security payload (ESP) [RFC4303] and the IP authentication header (AH) [RFC4302] to provide secure transport over IP networks. UsingIPSecIPsec ESP and AH will provide both Geneve header integrity protection and Geneve payload encryption. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. AbbreviationsNVO3NVO3: Network Virtualization Overlays over Layer 3OAMOAM: Operations, Administration, and MaintenanceTLVTLV: Type, Length, and ValueVNIVNI: Virtual Network IdentifierNVENVE: Network Virtualization EdgeNVANVA: Network Virtualization AuthorityNICNIC: Networkinterface card IPSecInterface Card IPsec: IP SecurityESPESP: IP Encapsulating Security PayloadAHAH: IP Authentication HeaderGREGRE: Generic Routing Encapsulation (GRE)EtherIPEtherIP: Tunneling Ethernet Frames in IP DatagramsTransit device Underlay network devices between NVE(s). 4.04. Encapsulation Security Payload (ESP) over Geneve tunnel The Geneve packet is encapsulated in UDP over either IPv4 or IPv6. The Geneve packet consists of a Geneve header which is then followed by a set of variable options. The Geneve header protocol type will indicate that the Geneve payload is the ESP protocol (IP Protocol 50), and the Geneve payload will consist of the ESP protocol data. The ESP next header can carry only an IP protocol so can't carry the inner Ethernet frame, so given that (1) Generic Routing Encapsulation (GRE) [RFC2784] and EtherIP [RFC3378] are IP protocols and (2)GRE/EtherIPGRE/ EtherIP can carry Ethernet Frames, hence the need of EtherIP/GRE encapsulation for the inner Ethernet payload. The ESP Next Header field will be set to inner payload protocol which can be either EtherIP (97) or to the Generic Routing Encapsulation (GRE) (47). The GRE protocol type will be set to the Ethernet protocol type. IPsec transport mode encryption is used. Inner Ethernet packet, as sent/received by the virtual machine: +----------+---------+ | Ethernet | Ethernet| | header | Payload | +----------+---------+ After applying Geneve and ESP, with ETH-IPheader. +--------+------+------+----------+------+---+-------+------+-------+---+ |Ethernet|outerheader: +-----+------+------+----------+------+---+-------+------+-------+---+ |Ether|outer |UDP |Geneve Hdr|Geneve|ESP|EtherIP|Inner |ESP |ESP||header|hdr |IP |port= |Protocol |Option|Hdr|Header |Ether |Trailer|ICV| | |header|Geneve|=50 |TLV(s)| | |packet| | |+--------+------+------+----------+------+---+-------+------+-------+---++-----+------+------+----------+------+---+-------+------+-------+---+ |<----Encrypted------->| |<---Integrity------------>| After applying Geneve and ESP, with GREheader. +--------+------+------+----------+------+---+-------+------+-------+---+ |Ethernet|outerheader: +-----+------+------+----------+------+---+-------+------+-------+---+ |Ether|outer |UDP |Geneve Hdr|Geneve|ESP|GRE |Inner |ESP |ESP||header|hdr |IP |port= |Protocol |Option|Hdr|Header |Ether |Trailer|ICV| | |header|Geneve|=50 |TLV(s)| | |packet| | |+--------+------+------+----------+------+---+-------+------+-------+---++-----+------+------+----------+------+---+-------+------+-------+---+ |<----Encrypted------->| |<---Integrity------------>|Figure 1: ESP over Geneve Packet Diagram 5.05. IP Authentication header (AH) over Geneve tunnel The Geneve packet is encapsulated in UDP over either IPv4 or IPv6. The Geneve packet consists of a Geneve header which is then followed by a set of variable options. The Geneve header protocol type will indicate that the Geneve payload is the AH protocol (IP Protocol 51), and the Geneve payload will consist of the Authentication header (AH). The AH next header can carry only an IP protocol so can't carry the inner Ethernet frame, so given that (1) Generic Routing Encapsulation (GRE) [RFC2784] and EtherIP [RFC3378] are IP protocols and (2) GRE/EtherIP can carry Ethernet Frames, hence the need of EtherIP/GRE encapsulation for the inner Ethernet payload. The AH Next Header field will be set to inner payload protocol which can be either EtherIP (97) or to the Generic Routing Encapsulation (GRE) (47). The GRE protocol type will be set to the Ethernet protocol type. It is to be noted that some of the option TLV(s) in the Geneve header SHOULD be treated as mutable fields and not included in the AH authentication. Inner Ethernet packet, as sent/received by the virtual machine: +----------+---------+ | Ethernet | Ethernet| | header | Payload | +----------+---------+ After applying Geneve and AH, with ETH-IPheader.header: +--------+------+------+----------+------+---+-------+------+ |Ethernet|outer |UDP |Geneve Hdr|Geneve|AH |EtherIP|Inner | |header |IP |port= |Protocol |Option| |Header |Ether | | |header|Geneve|=51 |TLV(s)| | |packet| +--------+------+------+----------+------+---+-------+------+ |<--- authenticated except for mutable fields ---->| After applying Geneve and AH, with GREheader.header: +--------+------+------+----------+------+---+-------+------+ |Ethernet|outer |UDP |Geneve Hdr|Geneve|AH |GRE |Inner | |header |IP |port= |Protocol |Option| |Header |Ether | | |header|Geneve|=51 |TLV(s)| | |packet| +--------+------+------+----------+------+---+-------+------+ |<--- authenticated except for mutable fields ---->|Figure 2: AH over Geneve Packet Diagram6. Control Plane Considerations A control plane extension could allow a Network Virtualization Endpoint (NVE) to express the next protocol that can be carried by Geneve to its peers. In the datapath, a transmitting NVE MUST NOT encapsulate a packet destined to another NVE with any protocol the receiving NVE is not capable of processing. In this document the next protocol signaled in control plane by NVE(s) can be ESP or AH. Once2two NVE(s) agree to carry ESP or AH as next protocol,Security Association and Key Management Protocol defined in [RFC2408]the NVEs canbe useduse IKEv2 [RFC7296] to negotiate, establish,modifymodify, and delete IPsec Security Associations.As well, mechanisms to perform key exchange defined in [RFC2409] can be used.7. Security Considerations If network policy requires IPsec encryption for certain traffic, it is important to ensure un-encrypted packets are not delivered to the guest virtual machine. This is implemented by dropping packets that arrive without the necessary IPsec encryption. 8. IANA Considerations This document does not register anything new with IANA. 9. Acknowledgements The authorswould like tothank T. Sridhar for his valuable comments.8. Security Considerations This document does not introduce any additional security constraints. 9. IANA Considerations TBD10. References10.110.1. Normative References[KEYWORDS][I-D.ietf-nvo3-geneve] Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic Network Virtualization Encapsulation", draft-ietf- nvo3-geneve-05 (work in progress), September 2017. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March1997. 10.2 Informative References [Geneve]1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "GenericNetwork Virtualization Encapsulation", [I-D.ietf- nvo3-geneve]Routing Encapsulation (GRE)", RFC 2784, DOI 10.17487/RFC2784, March 2000, <https://www.rfc-editor.org/info/rfc2784>. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005,<http://www.rfc-editor.org/info/rfc4301>.<https://www.rfc-editor.org/info/rfc4301>. [RFC4302] Kent,S.S., "IP Authentication Header", RFC 4302, DOI 10.17487/RFC4302, December 2005,<http://www.rfc-editor.org/info/rfc4302>.<https://www.rfc-editor.org/info/rfc4302>. [RFC4303] Kent,S.S., "IP Encapsulating SecurityPayload",Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005,<http://www.rfc-editor.org/info/rfc4303>.<https://www.rfc-editor.org/info/rfc4303>. [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, <https://www.rfc-editor.org/info/rfc7296>. 10.2. Informative References [RFC3378]R.Housley,et al.R. and S. Hollenbeck, "EtherIP: Tunneling Ethernet Frames in IP Datagrams", RFC 3378, DOI 10.17487/RFC3378, September 2002,<http://www.rfc- editor.org/info/rfc3378>. [RFC2784] T. Li, et al. "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000, <http://www.rfc-editor.org/info/rfc2784>. [RFC2408] D. Maughan, et al. "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998, <http://www.rfc-editor.org/info/rfc2408>. [RFC2409] D. Harkins, et al. "The Internet Key Exchange (IKE)", RFC 2409, November 1998, <http://www.rfc-editor.org/info/rfc2409>.<https://www.rfc-editor.org/info/rfc3378>. Authors' Addresses Sami BoutrosVMware Email: sboutros@vmware.com Dan Wing(editor) VMware, Inc. 3401 Hillview Ave. Palo Alto, CA 94304 USA Email:dwing@vmware.comsboutros@vmware.com Calvin Qian VMware, Inc. 3401 Hillview Ave. Palo Alto, CA 94304 USA Email: calvinq@vmware.com Dan Wing VMware, Inc. 3401 Hillview Ave. Palo Alto, CA 94304 USA Email: dwing@vmware.com