Internet DRAFT - draft-boutros-nvo3-ipsec-over-geneve
draft-boutros-nvo3-ipsec-over-geneve
NVO3 S. Boutros, Ed.
Internet-Draft C. Qian
Intended status: Standards Track D. Wing
Expires: July 14, 2018 VMware, Inc.
January 10, 2018
IPsec over Geneve Encapsulation
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 ESP the Geneve payload is
encrypted and integrity protected, and using IPSec AH the Geneve
headers and payload are integrity protected.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (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."
This Internet-Draft will expire on July 14, 2018.
Copyright Notice
Copyright (c) 2018 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
(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
Boutros, et al. Expires July 14, 2018 [Page 1]
Internet-Draft NVO3 IPsec over Geneve January 2018
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Encapsulation Security Payload (ESP) over Geneve tunnel . . . 3
5. IP Authentication header (AH) over Geneve tunnel . . . . . . 4
6. Control Plane Considerations . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
10.1. Normative References . . . . . . . . . . . . . . . . . . 6
10.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
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 2 and/
or layer 3 overlay services for virtual networks enabling multi-
tenancy and workload mobility. The Generic Network Virtualization
Encapsulation [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
Boutros, et al. Expires July 14, 2018 [Page 2]
Internet-Draft NVO3 IPsec over Geneve January 2018
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
[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. Using
IPsec 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. Abbreviations
NVO3: Network Virtualization Overlays over Layer 3
OAM: Operations, Administration, and Maintenance
TLV: Type, Length, and Value
VNI: Virtual Network Identifier
NVE: Network Virtualization Edge
NVA: Network Virtualization Authority
NIC: Network Interface Card
IPsec: IP Security
ESP: IP Encapsulating Security Payload
AH: IP Authentication Header
GRE: Generic Routing Encapsulation (GRE)
EtherIP: Tunneling Ethernet Frames in IP Datagrams
4. 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
Boutros, et al. Expires July 14, 2018 [Page 3]
Internet-Draft NVO3 IPsec over Geneve January 2018
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/
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-IP header:
+-----+------+------+----------+------+---+-------+------+-------+---+
|Ether|outer |UDP |Geneve Hdr|Geneve|ESP|EtherIP|Inner |ESP |ESP|
|hdr |IP |port= |Protocol |Option|Hdr|Header |Ether |Trailer|ICV|
| |header|Geneve|=50 |TLV(s)| | |packet| | |
+-----+------+------+----------+------+---+-------+------+-------+---+
|<----Encrypted------->|
|<---Integrity------------>|
After applying Geneve and ESP, with GRE header:
+-----+------+------+----------+------+---+-------+------+-------+---+
|Ether|outer |UDP |Geneve Hdr|Geneve|ESP|GRE |Inner |ESP |ESP|
|hdr |IP |port= |Protocol |Option|Hdr|Header |Ether |Trailer|ICV|
| |header|Geneve|=50 |TLV(s)| | |packet| | |
+-----+------+------+----------+------+---+-------+------+-------+---+
|<----Encrypted------->|
|<---Integrity------------>|
5. 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
Boutros, et al. Expires July 14, 2018 [Page 4]
Internet-Draft NVO3 IPsec over Geneve January 2018
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-IP 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 GRE 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 ---->|
6. 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.
Boutros, et al. Expires July 14, 2018 [Page 5]
Internet-Draft NVO3 IPsec over Geneve January 2018
In this document the next protocol signaled in control plane by
NVE(s) can be ESP or AH.
Once two NVE(s) agree to carry ESP or AH as next protocol, the NVEs
can use IKEv2 [RFC7296] to negotiate, establish, modify, and delete
IPsec Security Associations.
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 authors thank T. Sridhar for his valuable comments.
10. References
10.1. Normative References
[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, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic 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, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005,
<https://www.rfc-editor.org/info/rfc4302>.
Boutros, et al. Expires July 14, 2018 [Page 6]
Internet-Draft NVO3 IPsec over Geneve January 2018
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<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] Housley, R. and S. Hollenbeck, "EtherIP: Tunneling
Ethernet Frames in IP Datagrams", RFC 3378,
DOI 10.17487/RFC3378, September 2002,
<https://www.rfc-editor.org/info/rfc3378>.
Authors' Addresses
Sami Boutros (editor)
VMware, Inc.
3401 Hillview Ave.
Palo Alto, CA 94304
USA
Email: sboutros@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
Boutros, et al. Expires July 14, 2018 [Page 7]
