idnits 2.17.1 draft-herbert-gue-fragmentation-02.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 (October 19, 2015) is 3083 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC4459' is mentioned on line 111, but not defined -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT T. Herbert 3 Intended Status: Proposed Standard Facebook 4 Expires: April 2016 F. Templin 5 Boeing Research & Technology 6 October 19, 2015 8 Fragmentation option for Generic UDP Encapsulation 9 draft-herbert-gue-fragmentation-02 11 Abstract 13 This specification describes a fragmentation and reassembly 14 capability with an associated header option for Generic UDP 15 Encapsulation. 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/1id-abstracts.html 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 Copyright and License Notice 40 Copyright (c) 2015 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2 Option format . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3 Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 3.1 Fragmentation . . . . . . . . . . . . . . . . . . . . . . . 6 62 3.2 Reassembly . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 11 64 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11 65 6 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 66 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 67 7.1 Normative References . . . . . . . . . . . . . . . . . . . 11 68 7.2 Informative References . . . . . . . . . . . . . . . . . . 11 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 71 1 Introduction 73 This specification describes a fragmentation and reassembly 74 capability in Generic UDP Encapsulation (GUE) [I.D.ietf-nvo3-gue]. 75 This entails adding a GUE option and procedures for fragmentation and 76 reassembly in the encapsulation layer. This specification adapts the 77 procedures for IP fragmentation and reassembly described in [RFC0791] 78 and [RFC2460]. Fragmentation may be performed on both data and 79 control messages in GUE. 81 1.1 Motivation 83 This section describes the motivation for having a fragmentation 84 option in GUE. 86 MTU and fragmentation issues with In-the-Network Tunneling are 87 described in [RFC4459]. Considerations need to be made when a packet 88 is received at a tunnel ingress point which may be too large to 89 traverse the path between tunnel endpoints. 91 There are four suggested alternatives in [RFC4459] to deal with this: 93 1) Fragmentation and Reassembly by the Tunnel Endpoints 95 2) Signaling the Lower MTU to the Sources 97 3) Encapsulate Only When There is Free MTU 99 4) Fragmentation of the Inner Packet 101 Many tunneling protocol implementations have assumed that 102 fragmentation should be avoided, and in particular alternative #3 103 seems preferred for deployment. In this case, it is assumed that an 104 operator can configure the MTUs of links in the paths of tunnels to 105 ensure that they are large enough to accommodate any packets and 106 required encapsulation overhead. This method, however, may not be 107 feasible in certain deployments and may be prone to misconfiguration 108 in others. 110 Similarly, the other alternatives have drawbacks that are described 111 in [RFC4459]. Alternative #2 implies use of something like Path MTU 112 Discovery which is not known to be sufficiently reliable. Alternative 113 #4 is not permissible with IPv6 or when the DF bit is set for IPv4, 114 and it also introduces other known issues with IP fragmentation. 116 For alternative #1, fragmentation and reassembly at the tunnel 117 endpoints, there are two possibilities: encapsulate the large packet 118 and then perform IP fragmentation, or segment the packet and then 119 encapsulate each segment (a non-IP fragmentation approach). 121 Performing IP fragmentation on an encapsulated packet has the same 122 issues as that of normal IP fragmentation. Most significant of these 123 is that the Identification field is only sixteen bits in IPv4 which 124 introduces problems with wraparound as described in [FRAGHRM]. 126 The second possibility follows the suggestion expressed in [RFC2764] 127 and the fragmentation feature described in the AERO protocol 128 [I.D.templin-aerolink], that is for the tunneling protocol itself to 129 incorporate a segmentation and reassembly capability that operates at 130 the tunnel level. In this method fragmentation is part of the 131 encapsulation and an encapsulation header contains the information 132 for reassembly. This is different from IP fragmentation in that the 133 IP headers of the original packet are not replicated for each 134 fragment. 136 Incorporating fragmentation into the encapsulation protocol has some 137 advantages: 139 o A 32 bit identifier can be defined to avoid issues of the 16 bit 140 Identification in IPv4. 142 o Encapsulation mechanisms for security and identification such as 143 virtual network identifiers can be applied to each segment. 145 o This allows the possibility of using alternate fragmentation and 146 reassembly algorithms (e.g. fragmentation with Forward Error 147 Correction). 149 o Fragmentation is transparent to the underlying network so it is 150 unlikely that fragmented packet will be unconditionally dropped 151 as might happen with IP fragmentation. 153 1.2 Scope 155 This specification describes the mechanics of fragmentation in 156 Generic UDP Encapsulation. The operational aspects and details for 157 higher layer implementation must be considered for deployment, but 158 are considered out of scope for this document. The AERO protocol 159 [I.D.templin-aerolink] defines one use case of fragmentation with 160 encapsulation. 162 1.3 Terminology 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 166 document are to be interpreted as described in RFC 2119 [RFC2119]. 168 2 Option format 170 Fragments in GUE are sent with a fragmentation option in the GUE 171 header. The format of this option is: 173 0 1 2 3 174 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Fragment offset |Res|M| Orig-proto | Reserved | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Identification | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 o Fragment offset: This field indicates where in the datagram this 182 fragment belongs. The fragment offset is measured in units of 8 183 octets (64 bits). The first fragment has offset zero. 185 o Res: Two bit reserved field. Must be set to zero for 186 transmission. If set to non-zero in a received packet then the 187 packet MUST be dropped. 189 o M: More fragments bit. Set to 1 when there are more fragments 190 following in the datagram, set to 0 for the last fragment. 192 o Orig-proto: The control type (when C bit is set) or the IP 193 protocol (when C bit is not set) of the fragmented packet. 195 o Reserved: Must be set to 0 on transmission. If set to non-zero 196 in a received packet then the packet MUST be dropped. 198 o Identification: Identifies fragments of a fragmented packet. 200 The format of the fragmentation option within the GUE header is: 202 0 1 2 3 203 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 |0x0|C| Hlen | Proto/ctype |V|SEC|K|F| Flags |E| 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | | 208 ~ VNID, security fields, checksum (optional) ~ 209 | | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Fragment offset |Res|M| Orig-proto | Reserved | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Identification | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Extension flags(optional) | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | | 218 ~ Extension fields (optional) ~ 219 | | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 Pertinent fields to fragmentation are: 224 o C: This bit is set for each fragment based on the whether the 225 original packet being fragmented is a control or data message. 227 o Proto/ctype - For the first fragment (fragment offset is zero) 228 this is set to that of the original packet being fragmented 229 (either will be a control type or IP protocol). For other 230 fragments, this is set to zero for a control message being 231 fragmented, or to "No next header" (protocol number 59) for a 232 data message being fragmented. 234 o F bit - Set to indicate presence of the fragmentation option 235 field. 237 3 Procedures 239 3.1 Fragmentation 241 If an encapsulator determines that a packet must be fragmented (eg. 242 the packets size exceed the Path MTU of the tunnel) it may divide the 243 packet into fragments and send each fragment as a separate GUE 244 packet, to be reassembled at the decapsulator (tunnel egress). 246 For every packet that is to be fragmented, the source node generates 247 an Identification value. The Identification must be different than 248 that of any other fragmented packet sent within the past 60 seconds 249 (Maximum Segment Lifetime) with the same tunnel identification-- that 250 is the same outer source and destination addresses, same UDP ports, 251 same orig-proto, and same virtual network identifier if present. 253 The initial, unfragmented, and unencapsulated packet is referred to 254 as the "original packet". This will be a layer 2 packet, layer 3 255 packet, or the payload of a GUE control message: 257 +-------------------------------//------------------------------+ 258 | Original packet | 259 | (e.g. an IPv4, IPv6, Ethernet packet) | 260 +------------------------------//-------------------------------+ 262 Fragmentation and encapsulation are performed on the original packet 263 in sequence. First the packet is divided up in to fragments, and then 264 each fragment is encapsulated. Each fragment, except possibly the 265 last ("rightmost") one, is an integer multiple of 8 octets long. 266 Fragments MUST be non-overlapping. The number of fragments should be 267 minimized, and all but the last fragment should be approximately 268 equal in length. 270 The fragments are transmitted in separate "fragment packets" as: 272 +--------------+--------------+---------------+--//--+----------+ 273 | first | second | third | | last | 274 | fragment | fragment | fragment | .... | fragment | 275 +--------------+--------------+---------------+--//--+----------+ 277 Each fragment is encapsulated as the payload of a GUE packet. This is 278 illustrated as: 280 +------------------+----------------+-----------------------+ 281 | IP/UDP header | GUE header | first | 282 | header | w/ frag option | fragment | 283 +------------------+----------------+-----------------------+ 285 +------------------+----------------+-----------------------+ 286 | IP/UDP header | GUE header | second | 287 | header | w/ frag option | fragment | 288 +------------------+----------------+-----------------------+ 289 o 290 o 291 +------------------+----------------+-----------------------+ 292 | IP/UDP header | GUE header | last | 293 | header | w/ frag option | fragment | 294 +------------------+----------------+-----------------------+ 296 Each fragment packet is composed of: 298 (1) Outer IP and UDP headers as defined for GUE encapsulation. 300 o The IP addresses and UDP destination port must be the same 301 for all fragments of a fragmented packet. 303 o The source port selected for the inner flow identifier must 304 be the same value for all fragments of a fragmented packet. 306 (2) A GUE header that contains: 308 o The C bit which is set to the same value for all the 309 fragments of a fragmented packet based on whether a control 310 message or data message was fragmented. 312 o A proto/ctype. In the first fragment this is set to the 313 value corresponding to the next header of the original 314 packet and will be either an IP protocol or a control type. 315 For subsequent fragments, this field is set to 0 for a 316 fragmented control message or 59 (no next header) for a 317 fragmented data messages. 319 o The F bit is set and fragment option is present. See below. 321 o Other GUE options. Note that options apply to the individual 322 GUE packet. For instance, the security option would be 323 validated before reassembly. 325 (2) The GUE fragmentation option. The option contents include: 327 o Orig-proto that identifies the first header of the original 328 packet. 330 o A Fragment Offset containing the offset of the fragment, in 331 8-octet units, relative to the start of the of the original 332 packet. The Fragment Offset of the first ("leftmost") 333 fragment is 0. 335 o An M flag value of 0 if the fragment is the last 336 ("rightmost") one, else an M flag value of 1. 338 o The Identification value generated for the original packet. 340 (3) The fragment itself. 342 3.2 Reassembly 343 At the destination, fragment packets are decapsulated and reassembled 344 into their original, unfragmented form, as illustrated: 346 +-------------------------------//------------------------------+ 347 | Original packet | 348 | (e.g. an IPv4, IPv6, Ethernet packet) | 349 +------------------------------//-------------------------------+ 351 The following rules govern reassembly: 353 The IP/UDP/GUE headers of each packet are retained until all 354 fragments have arrived. The reassembled packet is then composed 355 of the decapsulated payloads in the GUE fragments, and the 356 IP/UDP/GUE headers are discarded 358 When a GUE packet is received with the fragment option, the 359 proto/ctype in the GUE header must be validated. In the case 360 that the packet is a first fragment (fragment offset is zero), 361 the proto/ctype in the GUE header must equal the orig-proto 362 value in the fragmentation option. For subsequent fragments 363 (fragment offset is non-zero) the proto/ctype in the GUE header 364 must be 0 for a control message or 59 (no-next-hdr) for a data 365 message. If the proto/ctype value is invalid then the packet 366 MUST be dropped. 368 An original packet is reassembled only from GUE fragment packets 369 that have the same outer Source Address, Destination Address, 370 UDP source port, UDP destination port, GUE header C bit, virtual 371 network identifier if present, orig-proto value in the 372 fragmentation option, and Fragment Identification. The protocol 373 type or control message type (depending on the C bit) for the 374 reassembled packet is the value of the GUE header proto/ctype 375 field in the first fragment. 377 The following error conditions may arise when reassembling fragmented 378 packets with GUE encapsulation: 380 If insufficient fragments are received to complete reassembly of 381 a packet within 60 seconds (or a configurable period) of the 382 reception of the first-arriving fragment of that packet, 383 reassembly of that packet must be abandoned and all the 384 fragments that have been received for that packet must be 385 discarded. 387 If the length of a fragment, as derived from the GUE fragment 388 packet's Payload Length field, is not a multiple of 8 octets and 389 the M flag of that fragment is 1, then that fragment must be 390 discarded. 392 If the length and offset of a fragment are such that the Payload 393 Length of the packet reassembled from that fragment would exceed 394 65,535 octets, then that fragment must be discarded. 396 If a fragment overlaps another fragment already saved for 397 reassembly then the portion of data in the new fragment that 398 overlaps the existing fragment must be ignored. 400 If the first fragment is too small then it is possible that it 401 does not contain the necessary headers for a stateful firewall. 402 Sending small fragments like this has been used as an attack on 403 IP fragmentation. To mitigate this problem, an implementation 404 should ensure that the first fragment contains the headers of 405 the encapsulated packet at least through the transport header. 407 4 Security Considerations 409 Exploits that have been identified with IP fragmentation are 410 conceptually applicable to GUE fragmentation. 412 Attacks on GUE fragmentation can be mitigated by: 414 o Hardened implementation that applies applicable techniques from 415 implementation of IP fragmentation. 417 o Application of GUE security [I.D.hy-gue-4-secure-transport] or 418 IPsec [RFC4301]. Security mechanisms can prevent spoofing of 419 fragments from unauthorized sources. 421 o Implement fragment filter techniques for GUE encapsulation as 422 described in [RFC1858] and [RFC3128]. 424 o Do not accepted data in overlapping segments. 426 o Enforce a minimum size for the first fragment. 428 5 IANA Considerations 430 GUE fragmentation defines one flag bit in the GUE header and a 431 corresponding 64-bit field. 433 6 Acknowledgements 435 Motivations for including an encapsulation fragment header option 436 were discussed on the int-area mailing list in the August 2015 437 timeframe. 439 7 References 441 7.1 Normative References 443 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 444 Requirement Levels", BCP 14, RFC 2119, March 1997, 445 . 447 [I.D.ietf-nvo3-gue] T. Herbert, L. Yong, and O. Zia, "Generic UDP 448 Encapsulation" draft-ietf-nvo3-gue-01 450 7.2 Informative References 452 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 453 1981, . 455 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 456 (IPv6) Specification", RFC 2460, December 1998, 457 . 459 [RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A. 460 Malis, "A Framework for IP Based Virtual Private Networks", 461 RFC 2764, February 2000, . 464 [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security 465 Considerations for IP Fragment Filtering", RFC 1858, 466 October 1995, . 468 [RFC3128] Miller, I., "Protection Against a Variant of the Tiny 469 Fragment Attack (RFC 1858)", RFC 3128, June 2001, 470 . 472 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 473 Internet Protocol", RFC 4301, December 2005, 474 . 476 [I.D.templin-aerolink] F. Templin, "Transmission of IP Packets over 477 AERO Links" draft-templin-aerolink-62.txt 479 [FRAGHRM] M. Mathis, J, Heffner, and B. Chandler, "Fragmentation 480 Considered Very Harmful", draft-mathis-frag-harmful-00 482 [I.D.hy-gue-4-secure-transport] L. Yong and T. Herbert, "Generic UDP 483 Encapsulation (GUE) for Secure Transport" draft-hy-gue-4- 484 secure-transport-02 486 Authors' Addresses 488 Tom Herbert 489 Facebook 490 Menlo Park, CA 491 USA 493 Email: tom@herbertland.com 495 Fred L. Templin 496 Boeing Research & Technology 497 P.O. Box 3707 498 Seattle, WA 98124 499 USA 501 Email: fltemplin@acm.org