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
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
|
<pre>Internet Engineering Task Force (IETF) R. Bonica
Request for Comments: 7588 Juniper Networks
Category: Informational C. Pignataro
ISSN: 2070-1721 Cisco Systems
J. Touch
USC/ISI
July 2015
<span class="h1">A Widely Deployed Solution to the Generic Routing Encapsulation (GRE)</span>
<span class="h1">Fragmentation Problem</span>
Abstract
This memo describes how many vendors have solved the Generic Routing
Encapsulation (GRE) fragmentation problem. The solution described
herein is configurable. It is widely deployed on the Internet in its
default configuration.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc7588">http://www.rfc-editor.org/info/rfc7588</a>.
<span class="grey">Bonica, et al. Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc7588">RFC 7588</a> GRE Fragmentation July 2015</span>
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) 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
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-1.1">1.1</a>. Terminology . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-1.2">1.2</a>. Requirements Language . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-2">2</a>. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-2.1">2.1</a>. <a href="./rfc4459">RFC 4459</a> Solutions . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-2.2">2.2</a>. A Widely Deployed Solution . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-3">3</a>. Implementation Details . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-3.1">3.1</a>. General . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-3.2">3.2</a>. GRE MTU (GMTU) Estimation and Discovery . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-3.3">3.3</a>. GRE Ingress Node Procedures . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-3.3.1">3.3.1</a>. Procedures Affecting the GRE Payload . . . . . . . . <a href="#page-7">7</a>
<a href="#section-3.3.2">3.3.2</a>. Procedures Affecting the GRE Deliver Header . . . . . <a href="#page-8">8</a>
<a href="#section-3.4">3.4</a>. GRE Egress Node Procedures . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-4">4</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-5">5</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-5.1">5.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-5.2">5.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<span class="grey">Bonica, et al. Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc7588">RFC 7588</a> GRE Fragmentation July 2015</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Generic Routing Encapsulation (GRE) [<a href="./rfc2784" title=""Generic Routing Encapsulation (GRE)"">RFC2784</a>] [<a href="./rfc2890" title=""Key and Sequence Number Extensions to GRE"">RFC2890</a>] can be used
to carry any network-layer protocol over any network-layer protocol.
GRE has been implemented by many vendors and is widely deployed in
the Internet.
The GRE specification does not describe fragmentation procedures.
Lacking guidance from the specification, vendors have developed
implementation-specific fragmentation solutions. A GRE tunnel will
operate correctly only if its ingress and egress nodes support
compatible fragmentation solutions. [<a href="./rfc4459" title=""MTU and Fragmentation Issues with In-the- Network Tunneling"">RFC4459</a>] describes several
fragmentation solutions and evaluates their relative merits.
This memo reviews the fragmentation solutions presented in [<a href="./rfc4459" title=""MTU and Fragmentation Issues with In-the- Network Tunneling"">RFC4459</a>].
It also describes how many vendors have solved the GRE fragmentation
problem. The solution described herein is configurable and has been
widely deployed in its default configuration.
This memo addresses point-to-point unicast GRE tunnels that carry
IPv4, IPv6, or MPLS payloads over IPv4 or IPv6. All other tunnel
types are beyond the scope of this document.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Terminology</span>
The following terms are specific to GRE:
o GRE delivery header - an IPv4 or IPv6 header whose source address
represents the GRE ingress node and whose destination address
represents the GRE egress node. The GRE delivery header
encapsulates a GRE header.
o GRE header - the GRE protocol header. The GRE header is
encapsulated in the GRE delivery header and encapsulates the GRE
payload.
o GRE payload - a network-layer packet that is encapsulated by the
GRE header. The GRE payload can be IPv4, IPv6, or MPLS.
Procedures for encapsulating IPv4 in GRE are described in
[<a href="./rfc2784" title=""Generic Routing Encapsulation (GRE)"">RFC2784</a>] and [<a href="./rfc2890" title=""Key and Sequence Number Extensions to GRE"">RFC2890</a>]. Procedures for encapsulating IPv6 in GRE
are described in [<a href="#ref-IPv6-GRE" title=""IPv6 Support for Generic Routing Encapsulation (GRE)"">IPv6-GRE</a>]. Procedures for encapsulating MPLS in
GRE are described in [<a href="./rfc4023" title=""Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)"">RFC4023</a>]. While other protocols may be
delivered over GRE, they are beyond the scope of this document.
o GRE delivery packet - a packet containing a GRE delivery header, a
GRE header, and the GRE payload.
<span class="grey">Bonica, et al. Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc7588">RFC 7588</a> GRE Fragmentation July 2015</span>
o GRE payload header - the IPv4, IPv6, or MPLS header of the GRE
payload.
o GRE overhead - the combined size of the GRE delivery header and
the GRE header, measured in octets.
The following terms are specific to MTU discovery:
o Link MTU (LMTU) - the maximum transmission unit, i.e., maximum
packet size in octets, that can be conveyed over a link. LMTU is
a unidirectional metric. A bidirectional link may be
characterized by one LMTU in the forward direction and another
LMTU in the reverse direction.
o Path MTU (PMTU) - the minimum LMTU of all the links in a path
between a source node and a destination node. If the source and
destination nodes are connected through an Equal-Cost Multipath
(ECMP), the PMTU is equal to the minimum LMTU of all links
contributing to the multipath.
o GRE MTU (GMTU) - the maximum transmission unit, i.e., maximum
packet size in octets, that can be conveyed over a GRE tunnel
without fragmentation of any kind. The GMTU is equal to the PMTU
associated with the path between the GRE ingress and the GRE
egress nodes minus the GRE overhead.
o Path MTU Discovery (PMTUD) - a procedure for dynamically
discovering the PMTU between two nodes on the Internet. PMTUD
procedures for IPv4 are defined in [<a href="./rfc1191" title=""Path MTU discovery"">RFC1191</a>]. PMTUD procedures
for IPv6 are defined in [<a href="./rfc1981" title=""Path MTU Discovery for IP version 6"">RFC1981</a>].
The following terms are introduced by this memo:
o Fragmentable Packet - a packet that can be fragmented by the GRE
ingress node before being transported over a GRE tunnel. That is,
an IPv4 packet with the Don't Fragment (DF) bit equal to 0 and
whose payload is larger than 64 bytes. IPv6 packets are not
fragmentable.
o ICMP Packet Too Big (PTB) message - an ICMPv4 [<a href="./rfc792" title=""Internet Control Message Protocol"">RFC792</a>] Destination
Unreachable message (Type = 3) with code equal to 4 (fragmentation
needed and DF set) or an ICMPv6 [<a href="./rfc4443" title=""Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification"">RFC4443</a>] Packet Too Big message
(Type = 2).
<span class="grey">Bonica, et al. Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc7588">RFC 7588</a> GRE Fragmentation July 2015</span>
<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>. Requirements Language</span>
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 <a href="./rfc2119">RFC 2119</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Solutions</span>
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. <a href="./rfc4459">RFC 4459</a> Solutions</span>
<a href="./rfc4459#section-3">Section 3 of [RFC4459]</a> identifies several tunnel fragmentation
solutions. These solutions define procedures to be invoked when the
tunnel ingress router receives a packet so large that it cannot be
forwarded through the tunnel without fragmentation of any kind. When
applied to GRE, these procedures are:
1. Discard the incoming packet and send an ICMP PTB message to the
incoming packet's source.
2. Fragment the incoming packet and encapsulate each fragment within
a complete GRE header and GRE delivery header.
3. Encapsulate the incoming packet in a single GRE header and GRE
delivery header. Perform source fragmentation on the resulting
GRE delivery packet.
As per <a href="./rfc4459">RFC 4459</a>, Strategy 2 is applicable only when the incoming
packet is fragmentable. Also as per <a href="./rfc4459">RFC 4459</a>, each strategy has its
relative merits and costs.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. A Widely Deployed Solution</span>
Many vendors have implemented a configurable GRE fragmentation
solution. In its default configuration, the solution behaves as
follows:
o When the GRE ingress node receives a fragmentable packet with
length greater than the GMTU, it fragments the incoming packet and
encapsulates each fragment within a complete GRE header and GRE
delivery header. Fragmentation logic is as specified by the
payload protocol.
o When the GRE ingress node receives a non-fragmentable packet with
length greater than the GMTU, it discards the packet and sends an
ICMP PTB message to the packet's source.
<span class="grey">Bonica, et al. Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc7588">RFC 7588</a> GRE Fragmentation July 2015</span>
o When the GRE egress node receives a GRE delivery packet fragment,
it silently discards the fragment without attempting to reassemble
the GRE delivery packet to which the fragment belongs.
In non-default configurations, the GRE ingress node can execute any
of the procedures defined in <a href="./rfc4459">RFC 4459</a>.
The solution described above is widely deployed on the Internet in
its default configuration. However, the default configuration is not
always appropriate for GRE tunnels that carry IPv6.
IPv6 requires that every link in the Internet have an MTU of 1280
octets or greater. On any link that cannot convey a 1280-octet
packet in one piece, link-specific fragmentation and reassembly must
be provided at a layer below IPv6.
Therefore, the default configuration is appropriate for tunnels that
carry IPv6 only if the network is engineered so that the GMTU is
guaranteed to be 1280 bytes or greater. In all other scenarios, a
non-default configuration is required.
In the non-default configuration, when the GRE ingress router
receives a packet lager than the GMTU, the GRE ingress router
encapsulates the entire packet in a single GRE and delivery header.
It then fragments the delivery header and sends the resulting
fragments to the GRE egress node, where they are reassembled.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Implementation Details</span>
This section describes how many vendors have implemented the solution
described in <a href="#section-2.2">Section 2.2</a>.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. General</span>
The GRE ingress nodes satisfy all of the requirements stated in
[<a href="./rfc2784" title=""Generic Routing Encapsulation (GRE)"">RFC2784</a>].
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. GRE MTU (GMTU) Estimation and Discovery</span>
GRE ingress nodes support a configuration option that associates a
GMTU with a GRE tunnel. By default, GMTU is equal to the MTU
associated with the next hop toward the GRE egress node minus the GRE
overhead.
Typically, GRE ingress nodes further refine their GMTU estimate by
executing PMTUD procedures. However, if an implementation supports
PMTUD for GRE tunnels, it also includes a configuration option that
<span class="grey">Bonica, et al. Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc7588">RFC 7588</a> GRE Fragmentation July 2015</span>
disables PMTUD. This configuration option is required to mitigate
certain denial-of-service attacks (see <a href="#section-4">Section 4</a>).
The GRE ingress node's estimate of the GMTU will not always be
accurate. It is only an estimate. When the GMTU changes, the GRE
ingress node will not discover that change immediately. Likewise, if
the GRE ingress node performs PMTUD procedures and interior nodes
cannot deliver ICMP feedback to the GRE ingress node, GMTU estimates
may be inaccurate.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. GRE Ingress Node Procedures</span>
This section defines procedures that GRE ingress nodes execute when
they receive a packet whose size is greater than the relevant GMTU.
<span class="h4"><a class="selflink" id="section-3.3.1" href="#section-3.3.1">3.3.1</a>. Procedures Affecting the GRE Payload</span>
<span class="h5"><a class="selflink" id="section-3.3.1.1" href="#section-3.3.1.1">3.3.1.1</a>. IPv4 Payloads</span>
By default, if the payload is fragmentable, the GRE ingress node
fragments the incoming packet and encapsulates each fragment within a
complete GRE header and GRE delivery header. Therefore, the GRE
egress node receives several complete, non-fragmented delivery
packets. Each delivery packet contains a fragment of the GRE
payload. The GRE egress node forwards the payload fragments to their
ultimate destination where they are reassembled.
Also by default, if the payload is not fragmentable, the GRE ingress
node discards the packet and sends an ICMPv4 Destination Unreachable
message to the packet's source. The ICMPv4 Destination Unreachable
message code equals 4 (fragmentation needed and DF set). The ICMPv4
Destination Unreachable message also contains a next-hop MTU (as
specified by [<a href="./rfc1191" title=""Path MTU discovery"">RFC1191</a>]), and the next-hop MTU is equal to the GMTU
associated with the tunnel.
The GRE ingress node supports a non-default configuration option that
invokes an alternative behavior. If that option is configured, the
GRE ingress node fragments the delivery packet. See <a href="#section-3.3.2">Section 3.3.2</a>
for details.
<span class="h5"><a class="selflink" id="section-3.3.1.2" href="#section-3.3.1.2">3.3.1.2</a>. IPv6 Payloads</span>
By default, the GRE ingress node discards the packet and sends an
ICMPv6 [<a href="./rfc4443" title=""Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification"">RFC4443</a>] Packet Too Big message to the payload source. The
MTU specified in the Packet Too Big message is equal to the GMTU
associated with the tunnel.
<span class="grey">Bonica, et al. Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc7588">RFC 7588</a> GRE Fragmentation July 2015</span>
The GRE ingress node supports a non-default configuration option that
invokes an alternative behavior. If that option is configured, the
GRE ingress node fragments the delivery packet. See <a href="#section-3.3.2">Section 3.3.2</a>
for details.
<span class="h5"><a class="selflink" id="section-3.3.1.3" href="#section-3.3.1.3">3.3.1.3</a>. MPLS Payloads</span>
By default, the GRE ingress node discards the packet. As it is
impossible to reliably identify the payload source, the GRE ingress
node does not attempt to send an ICMP PTB message to the payload
source.
The GRE ingress node supports a non-default configuration option that
invokes an alternative behavior. If that option is configured, the
GRE ingress node fragments the delivery packet. See <a href="#section-3.3.2">Section 3.3.2</a>
for details.
<span class="h4"><a class="selflink" id="section-3.3.2" href="#section-3.3.2">3.3.2</a>. Procedures Affecting the GRE Deliver Header</span>
<span class="h5"><a class="selflink" id="section-3.3.2.1" href="#section-3.3.2.1">3.3.2.1</a>. Tunneling GRE over IPv4</span>
By default, the GRE ingress node does not fragment delivery packets.
However, the GRE ingress node includes a configuration option that
allows delivery packet fragmentation.
By default, the GRE ingress node sets the DF bit in the delivery
header to 1 (Don't Fragment). However, the GRE ingress node also
supports a configuration option that invokes the following behavior:
o When the GRE payload is IPv6, the DF bit on the delivery header is
set to 0 (Fragments Allowed).
o When the GRE payload is IPv4, the DF bit is copied from the
payload header to the delivery header.
When the DF bit on an IPv4 delivery header is set to 0, the GRE
delivery packet can be fragmented by any router between the GRE
ingress and egress nodes.
If the GRE egress node is configured to support reassembly, it will
reassemble fragmented delivery packets. Otherwise, the GRE egress
node will discard delivery packet fragments.
<span class="grey">Bonica, et al. Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc7588">RFC 7588</a> GRE Fragmentation July 2015</span>
<span class="h5"><a class="selflink" id="section-3.3.2.2" href="#section-3.3.2.2">3.3.2.2</a>. Tunneling GRE over IPv6</span>
By default, the GRE ingress node does not fragment delivery packets.
However, the GRE ingress node includes a configuration option that
allows this.
If the GRE egress node is configured to support reassembly, it will
reassemble fragmented delivery packets. Otherwise, the GRE egress
node will discard delivery packet fragments.
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>. GRE Egress Node Procedures</span>
By default, the GRE egress node silently discards GRE delivery packet
fragments without attempting to reassemble the GRE delivery packets
to which the fragments belongs.
However, the GRE egress node supports a configuration option that
allows it to reassemble GRE delivery packets.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Security Considerations</span>
In the GRE fragmentation solution described above, either the GRE
payload or the GRE delivery packet can be fragmented. If the GRE
payload is fragmented, it is typically reassembled at its ultimate
destination. If the GRE delivery packet is fragmented, it is
typically reassembled at the GRE egress node.
The packet reassembly process is resource intensive and vulnerable to
several denial-of-service attacks. In the simplest attack, the
attacker sends fragmented packets more quickly than the victim can
reassemble them. In a variation on that attack, the first fragment
of each packet is missing so that no packet can ever be reassembled.
Given that the packet reassembly process is resource intensive and
vulnerable to denial-of-service attacks, operators should decide
where the reassembly process is best performed. Having made that
decision, they should decide whether to fragment the GRE payload or
GRE delivery packet accordingly.
Some IP implementations are vulnerable to the Overlapping Fragment
Attack [<a href="./rfc1858" title=""Security Considerations for IP Fragment Filtering"">RFC1858</a>]. This vulnerability is not specific to GRE and
needs to be considered in all environments where IP fragmentation is
present. [<a href="./rfc3128" title=""Protection Against a Variant of the Tiny Fragment Attack (RFC 1858)"">RFC3128</a>] describes a procedure by which IPv4
implementations can partially mitigate the vulnerability. [<a href="./rfc5722" title=""Handling of Overlapping IPv6 Fragments"">RFC5722</a>]
mandates a procedure by which IPv6-compliant implementations are
required to mitigate the vulnerability. The procedure described in
<span class="grey">Bonica, et al. Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc7588">RFC 7588</a> GRE Fragmentation July 2015</span>
<a href="./rfc5722">RFC 5722</a> completely mitigates the vulnerability. Operators SHOULD
ensure that the vulnerability is mitigated to their satisfaction on
equipment that they deploy.
PMTUD is vulnerable to two denial-of-service attacks (see <a href="./rfc1191#section-8">Section 8
of [RFC1191]</a> for details). Both attacks are based upon on a
malicious party sending forged ICMPv4 Destination Unreachable or
ICMPv6 Packet Too Big messages to a host. In the first attack, the
forged message indicates an inordinately small PMTU. In the second
attack, the forged message indicates an inordinately large MTU. In
both cases, throughput is adversely affected. In order to mitigate
such attacks, GRE implementations include a configuration option to
disable PMTUD on GRE tunnels. Also, they can include a configuration
option that conditions the behavior of PMTUD to establish a minimum
PMTU.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. References</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Normative References</span>
[<a id="ref-RFC792">RFC792</a>] Postel, J., "Internet Control Message Protocol", STD 5,
<a href="./rfc792">RFC 792</a>, DOI 10.17487/RFC0792, September 1981,
<<a href="http://www.rfc-editor.org/info/rfc792">http://www.rfc-editor.org/info/rfc792</a>>.
[<a id="ref-RFC1191">RFC1191</a>] Mogul, J. and S. Deering, "Path MTU discovery", <a href="./rfc1191">RFC 1191</a>,
DOI 10.17487/RFC1191, November 1990,
<<a href="http://www.rfc-editor.org/info/rfc1191">http://www.rfc-editor.org/info/rfc1191</a>>.
[<a id="ref-RFC1858">RFC1858</a>] Ziemba, G., Reed, D., and P. Traina, "Security
Considerations for IP Fragment Filtering", <a href="./rfc1858">RFC 1858</a>,
DOI 10.17487/RFC1858, October 1995,
<<a href="http://www.rfc-editor.org/info/rfc1858">http://www.rfc-editor.org/info/rfc1858</a>>.
[<a id="ref-RFC1981">RFC1981</a>] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
for IP version 6", <a href="./rfc1981">RFC 1981</a>, DOI 10.17487/RFC1981, August
1996, <<a href="http://www.rfc-editor.org/info/rfc1981">http://www.rfc-editor.org/info/rfc1981</a>>.
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>,
DOI 10.17487/RFC2119, March 1997,
<<a href="http://www.rfc-editor.org/info/rfc2119">http://www.rfc-editor.org/info/rfc2119</a>>.
[<a id="ref-RFC2784">RFC2784</a>] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", <a href="./rfc2784">RFC 2784</a>,
DOI 10.17487/RFC2784, March 2000,
<<a href="http://www.rfc-editor.org/info/rfc2784">http://www.rfc-editor.org/info/rfc2784</a>>.
<span class="grey">Bonica, et al. Informational [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc7588">RFC 7588</a> GRE Fragmentation July 2015</span>
[<a id="ref-RFC2890">RFC2890</a>] Dommety, G., "Key and Sequence Number Extensions to GRE",
<a href="./rfc2890">RFC 2890</a>, DOI 10.17487/RFC2890, September 2000,
<<a href="http://www.rfc-editor.org/info/rfc2890">http://www.rfc-editor.org/info/rfc2890</a>>.
[<a id="ref-RFC3128">RFC3128</a>] Miller, I., "Protection Against a Variant of the Tiny
Fragment Attack (<a href="./rfc1858">RFC 1858</a>)", <a href="./rfc3128">RFC 3128</a>,
DOI 10.17487/RFC3128, June 2001,
<<a href="http://www.rfc-editor.org/info/rfc3128">http://www.rfc-editor.org/info/rfc3128</a>>.
[<a id="ref-RFC4023">RFC4023</a>] Worster, T., Rekhter, Y., and E. Rosen, Ed.,
"Encapsulating MPLS in IP or Generic Routing Encapsulation
(GRE)", <a href="./rfc4023">RFC 4023</a>, DOI 10.17487/RFC4023, March 2005,
<<a href="http://www.rfc-editor.org/info/rfc4023">http://www.rfc-editor.org/info/rfc4023</a>>.
[<a id="ref-RFC4443">RFC4443</a>] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", <a href="./rfc4443">RFC 4443</a>,
DOI 10.17487/RFC4443, March 2006,
<<a href="http://www.rfc-editor.org/info/rfc4443">http://www.rfc-editor.org/info/rfc4443</a>>.
[<a id="ref-RFC5722">RFC5722</a>] Krishnan, S., "Handling of Overlapping IPv6 Fragments",
<a href="./rfc5722">RFC 5722</a>, DOI 10.17487/RFC5722, December 2009,
<<a href="http://www.rfc-editor.org/info/rfc5722">http://www.rfc-editor.org/info/rfc5722</a>>.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Informative References</span>
[<a id="ref-IPv6-GRE">IPv6-GRE</a>] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support
for Generic Routing Encapsulation (GRE)", Work in
Progress, <a href="./draft-ietf-intarea-gre-ipv6-10">draft-ietf-intarea-gre-ipv6-10</a>, June 2015.
[<a id="ref-RFC4459">RFC4459</a>] Savola, P., "MTU and Fragmentation Issues with In-the-
Network Tunneling", <a href="./rfc4459">RFC 4459</a>, DOI 10.17487/RFC4459, April
2006, <<a href="http://www.rfc-editor.org/info/rfc4459">http://www.rfc-editor.org/info/rfc4459</a>>.
<span class="grey">Bonica, et al. Informational [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc7588">RFC 7588</a> GRE Fragmentation July 2015</span>
Acknowledgements
The authors would like to thank Fred Baker, Fred Detienne, Jagadish
Grandhi, Jeff Haas, Brian Haberman, Vanitha Neelamegam, Masataka
Ohta, John Scudder, Mike Sullenberger, Tom Taylor, and Wen Zhang for
their constructive comments. The authors also express their
gratitude to Vanessa Ameen, without whom this memo could not have
been written.
Authors' Addresses
Ron Bonica
Juniper Networks
2251 Corporate Park Drive
Herndon, Virginia 20170
United States
Email: rbonica@juniper.net
Carlos Pignataro
Cisco Systems
7200-12 Kit Creek Road
Research Triangle Park, North Carolina 27709
United States
Email: cpignata@cisco.com
Joe Touch
USC/ISI
4676 Admiralty Way
Marina del Rey, California 90292-6695
United States
Phone: +1 (310) 448-9151
Email: touch@isi.edu
URI: <a href="http://www.isi.edu/touch">http://www.isi.edu/touch</a>
Bonica, et al. Informational [Page 12]
</pre>
|
