-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathdraft-boutros-nvo3-ipsec-over-geneve.xml
320 lines (278 loc) · 12.6 KB
/
draft-boutros-nvo3-ipsec-over-geneve.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc='yes' ?>
<?rfc tocdepth='5'?>
<?rfc symrefs="yes"?>
<?rfc sortrefs='yes' ?>
<rfc category="std" docName="draft-boutros-nvo3-ipsec-over-geneve-01" ipr="trust200902">
<front>
<title abbrev="NVO3 IPsec over Geneve">IPsec over Geneve Encapsulation</title>
<author surname="Boutros" initials="S.B." fullname="Sami Boutros" role="editor">
<organization>VMware, Inc.</organization>
<address>
<postal>
<street>3401 Hillview Ave.</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94304</code>
<country>USA</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author surname="Qian" initials="C.Q." fullname="Calvin Qian">
<organization>VMware, Inc.</organization>
<address>
<postal>
<street>3401 Hillview Ave.</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94304</code>
<country>USA</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author surname="Wing" initials="D.W." fullname="Dan Wing">
<organization>VMware, Inc.</organization>
<address>
<postal>
<street>3401 Hillview Ave.</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94304</code>
<country>USA</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<date/>
<area>INT</area>
<workgroup>NVO3</workgroup>
<keyword>IPsec</keyword>
<keyword>Geneve</keyword>
<abstract>
<t>
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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>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 <xref target="I-D.ietf-nvo3-geneve">Generic Network
Virtualization Encapsulation</xref> have been recently recommended
to be the proposed standard for network virtualization overlay
encapsulation.</t>
<t>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.</t>
<t>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.</t>
<t>When crossing an untrusted link, such as the public Internet,
<xref target="RFC4301">IPsec</xref> 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.</t>
<t>This document describes
how <xref target="I-D.ietf-nvo3-geneve">Geneve tunnel
encapsulation</xref> can be used to carry both the IP Encapsulation
security payload (ESP) <xref target="RFC4303"/> and the IP
authentication header (AH) <xref target="RFC4302"/> to provide
secure transport over IP networks. Using IPsec ESP and AH will
provide both Geneve header integrity protection and Geneve payload
encryption.</t>
</section>
<section title="Terminology">
<t>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 <xref target="RFC2119">RFC 2119</xref>.</t>
</section>
<!-- If abbreviations are necessary for this document, bring in
just those necessary abbreviations, with citations to where
more information can be found or pretty self-contained
descriptions. -->
<!--
<section title="Abbreviations">
<t><list style="hanging">
<t>NVO3: Network Virtualization Overlays over Layer 3</t>
<t>OAM: Operations, Administration, and Maintenance</t>
<t>TLV: Type, Length, and Value</t>
<t>VNI: Virtual Network Identifier</t>
<t>NVE: Network Virtualization Edge</t>
<t>NVA: Network Virtualization Authority</t>
<t>NIC: Network Interface Card</t>
<t>IPsec: IP Security</t>
<t>ESP: IP Encapsulating Security Payload</t>
<t>AH: IP Authentication Header</t>
<t>GRE: Generic Routing Encapsulation (GRE)</t>
<t>EtherIP: Tunneling Ethernet Frames in IP Datagrams</t>
<t>Transit device Underlay network devices between NVE(s).</t>
</list></t>
</section>
-->
<section title="Encapsulation Security Payload (ESP) over Geneve tunnel">
<t>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) <xref target="RFC2784">Generic Routing Encapsulation
(GRE)</xref> and <xref target="RFC3378">EtherIP</xref> are IP
protocols and (2) GRE/EtherIP can carry Ethernet Frames, hence the
need of EtherIP/GRE encapsulation for the inner Ethernet
payload.</t>
<t>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.</t>
<t>Inner Ethernet packet, as sent/received by the virtual machine:</t>
<figure><artwork align="left" xml:space="preserve" name="" type="" alt=""
width="" height=""><![CDATA[
+----------+---------+
| Ethernet | Ethernet|
| header | Payload |
+----------+---------+
]]></artwork></figure>
<t>After applying Geneve and ESP, with ETH-IP header:</t>
<figure><artwork align="left" xml:space="preserve" name="" type="" alt=""
width="" height=""><![CDATA[
+-----+------+------+----------+------+---+-------+------+-------+---+
|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------------>|
]]></artwork></figure>
<t>After applying Geneve and ESP, with GRE header:</t>
<figure><artwork align="center" xml:space="preserve" name="" type="" alt=""
width="" height=""><![CDATA[
+-----+------+------+----------+------+---+-------+------+-------+---+
|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------------>|
]]></artwork></figure>
</section>
<section title="IP Authentication header (AH) over Geneve tunnel">
<t>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) <xref target="RFC2784"/> and
EtherIP <xref target="RFC3378"/> are IP protocols and (2)
GRE/EtherIP can carry Ethernet Frames, hence the need of
EtherIP/GRE encapsulation for the inner Ethernet payload.</t>
<t>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.</t>
<t>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.</t>
<t>Inner Ethernet packet, as sent/received by the virtual machine:</t>
<figure><artwork align="left" xml:space="preserve" name="" type="" alt=""
width="" height=""><![CDATA[
+----------+---------+
| Ethernet | Ethernet|
| header | Payload |
+----------+---------+
]]></artwork></figure>
<t>After applying Geneve and AH, with ETH-IP header:</t>
<figure><artwork align="left" xml:space="preserve" name="" type="" alt=""
width="" height=""><![CDATA[
+--------+------+------+----------+------+---+-------+------+
|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 ---->|
]]></artwork></figure>
<t>After applying Geneve and AH, with GRE header:</t>
<figure><artwork align="left" xml:space="preserve" name="" type="" alt=""
width="" height=""><![CDATA[
+--------+------+------+----------+------+---+-------+------+
|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 ---->|
]]></artwork></figure>
</section>
<section title="Control Plane Considerations">
<t>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.</t>
<t>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.</t>
<t>In this document the next protocol signaled in control plane by
NVE(s) can be ESP or AH.</t>
<t>Once two NVE(s) agree to carry ESP or AH as next protocol, the
NVEs can use <xref target="RFC7296">IKEv2</xref> to negotiate,
establish, modify, and delete IPsec Security Associations.</t>
</section>
<section anchor="security_considerations" title="Security Considerations">
<t>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.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document does not register anything new with IANA.</t>
</section>
<section title="Acknowledgements">
<t>The authors thank T. Sridhar for his valuable comments.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119.xml"?>
<?rfc include="reference.RFC.4301.xml"?>
<?rfc include="reference.RFC.4302.xml"?>
<?rfc include="reference.RFC.4303.xml"?>
<?rfc include="reference.RFC.2784.xml"?>
<?rfc include="reference.RFC.7296.xml"?>
<?rfc include="reference.I-D.ietf-nvo3-geneve.xml"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.3378.xml"?>
</references>
<!--
<section title="Acknowledgements" numbered="no">
</section>
-->
<!-- Section appearing inside <back> is handled as an Appendix
<section title="On Walden Pond">
<t>Henry David Thoreau was an author,
an author was he.</t>
</section>
-->
</back>
</rfc>