idnits 2.17.1 draft-herbert-gue-extensions-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 482: '... packet MUST be dropped....' RFC 2119 keyword, line 535: '... Fragments MUST be non-overlapping. ...' RFC 2119 keyword, line 636: '... packet it MUST be dropped....' RFC 2119 keyword, line 667: '... fragment MUST be discarded...' RFC 2119 keyword, line 739: '...y, the SEC flags MUST be set. Differen...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 21, 2016) is 2859 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: 'RFC0793' is mentioned on line 252, but not defined ** Obsolete undefined reference: RFC 793 (Obsoleted by RFC 9293) == Unused Reference: 'RFC1122' is defined on line 1131, but no explicit reference was found in the text == Unused Reference: 'RFC1624' is defined on line 1148, but no explicit reference was found in the text == Unused Reference: 'RFC1936' is defined on line 1151, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 3 errors (**), 0 flaws (~~), 5 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: December 2016 L. Yong 5 Huawei 6 F. Templin 7 Boeing 9 June 21, 2016 11 Extensions for Generic UDP Encapsulation 12 draft-herbert-gue-extensions-00 14 Abstract 16 This specification defines a set of the fundamental extensions for 17 Generic UDP Encapsulation (GUE). The extensions defined in this 18 specification are the security option, payload transform option, 19 checksum option, fragmentation option, and the remote checksum 20 offload option. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as 30 Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/1id-abstracts.html 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 Copyright and License Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. GUE header format with options . . . . . . . . . . . . . . . . 4 62 3. Checksum option . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.1. Option format . . . . . . . . . . . . . . . . . . . . . . 6 64 3.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 65 3.3. GUE checksum pseudo header . . . . . . . . . . . . . . . . 7 66 3.4. Checksum computation . . . . . . . . . . . . . . . . . . . 8 67 3.5. Transmitter operation . . . . . . . . . . . . . . . . . . 8 68 3.6. Receiver operation . . . . . . . . . . . . . . . . . . . . 8 69 3.7. Security Considerations . . . . . . . . . . . . . . . . . 9 70 4. Fragmentation option . . . . . . . . . . . . . . . . . . . . . 9 71 4.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 9 72 4.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 4.3. Option format . . . . . . . . . . . . . . . . . . . . . . 11 74 4.4. Fragmentation procedure . . . . . . . . . . . . . . . . . 12 75 4.5. Reassembly procedure . . . . . . . . . . . . . . . . . . . 14 76 4.6. Security Considerations . . . . . . . . . . . . . . . . . 16 77 5. Security and payload transform options . . . . . . . . . . . . 16 78 5.1. Security option format . . . . . . . . . . . . . . . . . . 16 79 5.2. Security option usage . . . . . . . . . . . . . . . . . . 17 80 5.2.1. Cookies . . . . . . . . . . . . . . . . . . . . . . . 17 81 5.2.2. Secure hash . . . . . . . . . . . . . . . . . . . . . 18 82 5.3. Payload Transform Option format . . . . . . . . . . . . . 18 83 5.3.1. Payload transform option usage . . . . . . . . . . . . 19 84 5.4. Operation of security mechanisms . . . . . . . . . . . . . 19 85 5.5. Considerations of Using Other Security Tunnel Mechanisms . 20 86 6. Remote checksum offload option . . . . . . . . . . . . . . . . 21 87 6.1. Option format . . . . . . . . . . . . . . . . . . . . . . 21 88 6.2. Transmitter operation . . . . . . . . . . . . . . . . . . 22 89 6.3. Receiver operation . . . . . . . . . . . . . . . . . . . . 22 90 6.4. Security Considerations . . . . . . . . . . . . . . . . . 23 91 7. Processing order of options . . . . . . . . . . . . . . . . . 23 92 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 93 9. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 25 94 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 95 10.1. Normative References . . . . . . . . . . . . . . . . . . 25 96 10.2. Informative References . . . . . . . . . . . . . . . . . 25 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 99 1. Introduction 101 Generic UDP Encapsulation [I.D.nvo3-gue] is a generic and extensible 102 encapsulation protocol. This specification defines a basic set of 103 extensions for GUE. These extensions are the security option, payload 104 transform option, checksum option, fragmentation option, and the 105 remote checksum offload option. 107 2. GUE header format with options 109 The general format of GUE with the options defined in this 110 specification is: 112 0 1 2 3 113 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 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ 115 | Source port | Destination port | \ 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP 117 | Length | Checksum | / 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ 119 |Ver|C| Hlen | Proto/ctype |V|SEC|K|F|T|R| Rsvd Flags | 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 | VNID (optional) | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | | 124 ~ Security (optional) ~ 125 | | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | Checksum (optional) | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | | 130 + Fragmentation (optional) + 131 | | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | Payload transform (optional | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | Remote checksum offload (optional) | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | | 138 ~ Private fields (optional) ~ 139 | | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 The contents of the UDP are described in [I.D.herbert-gue]. 144 The GUE header consists of: 146 o Ver: Version. Set to 0x0 to indicate GUE encapsulation header. 148 Note that version 0x1 does not allow options. 150 o C: Control bit. May be set or unset. GUE options can be used 151 with either control or data packets unless otherwise specified 152 in the option definition. 154 o Hlen: Length in 32-bit words of the GUE header, including 155 optional fields but not the first four bytes of the header. 156 Computed as (header_len - 4) / 4. The length of the encapsulated 157 packet is determined from the UDP length and the Hlen: 158 encapsulated_packet_length = UDP_Length - 8 - GUE_Hlen. 160 o Proto/ctype: If the C bit is not set this indicates IP protocol 161 number for the packet in the payload, else if the C bit is set 162 this type of control message for the payload. The next header 163 begins at the offset provided by Hlen. When the fragmentation 164 option or payload transform option is used this field may be set 165 to protocol number 59 for a data message, or a value of 0 for a 166 control message, to indicate no next header for the payload. 168 o V: Indicates the network virtualization option (VNID) field is 169 present. The VNID option is described in [I.D.hy-nvo3-gue-4- 170 nvo]. 172 o SEC: Indicates security option field is present. The security 173 option is described in section 5. 175 o K: Indicates checksum option field is present. The checksum 176 option is described in section 3. 178 o F: Indicates fragmentation option field is present. The 179 fragmentation option is described in section 4. 181 o T: Indicates transform option field is present. The transform 182 option is described in section 5. 184 o R: Indicates the remote checksum option field is present. The 185 remote checksum offload option is described in section 6. 187 o Private fields are described in [I.D.nvo3-gue]. 189 3. Checksum option 191 The GUE checksum option provides a checksum that covers the GUE 192 header, a GUE pseudo header, and optionally part or all of the GUE 193 payload. The GUE pseudo header includes the corresponding IP 194 addresses as well as the UDP ports of the encapsulating headers. This 195 checksum should provide adequate protection against address 196 corruption in IPv6 when the UDP checksum is zero. Additionally, the 197 GUE checksum provides protection of the GUE header when the UDP 198 checksum is set to zero with either IPv4 or IPv6. In particular, the 199 GUE checksum can provide protection for some sensitive data, such as 200 the virtual network identifier ([I.D.hy-nvo3-gue-4-nvo]), which when 201 corrupted could lead to mis-delivery of a packet to the wrong virtual 202 network. 204 3.1. Option format 206 The presence of the GUE checksum option is indicated by the K bit in 207 the GUE header. 209 The format of the checksum option is: 211 0 1 2 3 212 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 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | Checksum | Payload coverage | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 The fields of the option are: 219 o Checksum: Computed checksum value. This checksum covers the GUE 220 header (including fields and private data covered by Hlen), the 221 GUE pseudo header, and optionally all or part of the payload 222 (encapsulated packet). 224 o Payload coverage: Number of bytes of payload to cover in the 225 checksum. Zero indicates that the checksum only covers the GUE 226 header and GUE pseudo header. If the value is greater than the 227 encapsulated payload length, the packet must be dropped. 229 3.2. Requirements 231 The GUE header checksum must be set on transmit when using a zero UDP 232 checksum with IPv6. 234 The GUE header checksum must be set when the UDP checksum is zero for 235 IPv4 if the GUE header includes data that when corrupted can lead to 236 misdelivery or other serious consequences, and there is no other 237 mechanism that provides protection (no security field for instance). 238 Otherwise the GUE header checksum should be used with IPv4 when the 239 UDP checksum is zero. 241 The GUE header checksum should not be set when the UDP checksum is 242 non-zero. In this case the UDP checksum provides adequate protection 243 and this avoids convolutions when a packet traverses NAT that does 244 address translation (in that case the UDP checksum is required). 246 3.3. GUE checksum pseudo header 248 The GUE pseudo header checksum is included in the GUE checksum to 249 provide protection for the IP and UDP header elements which when 250 corrupted could lead to misdelivery of the GUE packet. The GUE pseudo 251 header checksum is similar to the standard IP pseudo header defined 252 in [RFC0768] and [RFC0793] for IPv4, and in [RFC2460] for IPv6. 254 The GUE pseudo header for IPv4 is: 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Source Address | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | Destination Address | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Source port | Destination port | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 The GUE pseudo header for IPv6 is: 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | | 268 + + 269 | | 270 + Source Address + 271 | | 272 + + 273 | | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | | 276 + + 277 | | 278 + Destination Address + 279 | | 280 + + 281 | | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Source port | Destination port | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 Note that the GUE pseudo header does not include payload length or 287 protocol as in the standard IP pseudo headers. The length field is 288 deemed unnecessary because: 290 o If the length is corrupted this will usually be detected by a 291 checksum validation failure on the inner packet. 293 o Fragmentation of packets in a tunnel should occur on the inner 294 packet before being encapsulated or GUE fragmentation (section 295 4) may be performed at tunnel ingress. GUE packets are not 296 expected to be fragmented when using IPv6. See RFC6936 for 297 considerations of payload length and IPv6 checksum. 299 o A corrupted length field in itself should not lead to 300 misdelivery of a packet. 302 o Without the length field, the GUE pseudo header checksum is the 303 same for all packets of flow. This is a useful property for 304 optimizations such as TCP Segment Offload (TSO). 306 3.4. Checksum computation 308 The GUE checksum is computed and verified following the standard 309 process for computing the Internet checksum [RFC1071]. Checksum 310 computation may be optimized per the mathematical properties 311 including parallel computation and incremental updates. 313 3.5. Transmitter operation 315 The procedure for setting the GUE checksum on transmit is: 317 1) Create the GUE header including the checksum and payload 318 coverage fields. The checksum field is initially set to zero. 320 2) Calculate the 1's complement checksum of the GUE header from 321 the start of the GUE header through the its length as indicated 322 in GUE Hlen. 324 3) Calculate the checksum of the GUE pseudo header for IPv4 or 325 IPv6. 327 4) Calculate checksum of payload portion if payload coverage is 328 enabled (payload coverage field is non-zero). If the length of 329 the payload coverage is odd, logically append a single zero 330 byte for the purposes of checksum calculation. 332 5) Add and fold the computed checksums for the GUE header, GUE 333 pseudo header and payload coverage. Set the bitwise not of the 334 result in the GUE checksum field. 336 3.6. Receiver operation 338 If the GUE checksum option is present, the receiver must validate the 339 checksum before processing any other fields or accepting the packet. 341 The procedure for verifying the checksum is: 343 1) If the payload coverage length is greater than the length of 344 the encapsulated payload then drop the packet. 346 2) Calculate the checksum of the GUE header from the start of the 347 header to the end as indicated by Hlen. 349 3) Calculate the checksum of the appropriate GUE pseudo header. 351 4) Calculate the checksum of payload if payload coverage is 352 enabled (payload coverage is non-zero). If the length of the 353 payload coverage is odd logically append a single zero byte for 354 the purposes of checksum calculation. 356 5) Sum the computed checksums for the GUE header, GUE pseudo 357 header, and payload coverage. If the result is all 1 bits (-0 358 in 1's complement arithmetic), the checksum is valid and the 359 packet is accepted; otherwise the checksum is considered 360 invalid and the packet must be dropped. 362 3.7. Security Considerations 364 The checksum option is only a mechanism for corruption detection, it 365 is not a security mechanism. To provide integrity checks or 366 authentication of the GUE header, the GUE security option should be 367 used. 369 4. Fragmentation option 371 The fragmentation option allows an encapsulator to perform 372 fragmentation of packets being ingress to a tunnel. Procedures for 373 fragmentation and reassembly are defined in this section. This 374 specification adapts the procedures for IP fragmentation and 375 reassembly described in [RFC0791] and [RFC2460]. Fragmentation may be 376 performed on both data and control messages in GUE. 378 4.1. Motivation 380 This section describes the motivation for having a fragmentation 381 option in GUE. 383 MTU and fragmentation issues with In-the-Network Tunneling are 384 described in [RFC4459]. Considerations need to be made when a packet 385 is received at a tunnel ingress point which may be too large to 386 traverse the path between tunnel endpoints. 388 There are four suggested alternatives in [RFC4459] to deal with this: 390 1) Fragmentation and Reassembly by the Tunnel Endpoints 392 2) Signaling the Lower MTU to the Sources 394 3) Encapsulate Only When There is Free MTU 396 4) Fragmentation of the Inner Packet 398 Many tunneling protocol implementations have assumed that 399 fragmentation should be avoided, and in particular alternative #3 400 seems preferred for deployment. In this case, it is assumed that an 401 operator can configure the MTUs of links in the paths of tunnels to 402 ensure that they are large enough to accommodate any packets and 403 required encapsulation overhead. This method, however, may not be 404 feasible in certain deployments and may be prone to misconfiguration 405 in others. 407 Similarly, the other alternatives have drawbacks that are described 408 in [RFC4459]. Alternative #2 implies use of something like Path MTU 409 Discovery which is not known to be sufficiently reliable. Alternative 410 #4 is not permissible with IPv6 or when the DF bit is set for IPv4, 411 and it also introduces other known issues with IP fragmentation. 413 For alternative #1, fragmentation and reassembly at the tunnel 414 endpoints, there are two possibilities: encapsulate the large packet 415 and then perform IP fragmentation, or segment the packet and then 416 encapsulate each segment (a non-IP fragmentation approach). 418 Performing IP fragmentation on an encapsulated packet has the same 419 issues as that of normal IP fragmentation. Most significant of these 420 is that the Identification field is only sixteen bits in IPv4 which 421 introduces problems with wraparound as described in [RFC4963]. 423 The second possibility follows the suggestion expressed in [RFC2764] 424 and the fragmentation feature described in the AERO protocol 425 [I.D.templin-aerolink], that is for the tunneling protocol itself to 426 incorporate a segmentation and reassembly capability that operates at 427 the tunnel level. In this method fragmentation is part of the 428 encapsulation and an encapsulation header contains the information 429 for reassembly. This is different from IP fragmentation in that the 430 IP headers of the original packet are not replicated for each 431 fragment. 433 Incorporating fragmentation into the encapsulation protocol has some 434 advantages: 436 o At least a 32 bit identifier can be defined to avoid issues of 437 the 16 bit Identification in IPv4. 439 o Encapsulation mechanisms for security and identification, such 440 as virtual network identifiers, can be applied to each segment. 442 o This allows the possibility of using alternate fragmentation and 443 reassembly algorithms (e.g. fragmentation with Forward Error 444 Correction). 446 o Fragmentation is transparent to the underlying network so it is 447 unlikely that fragmented packet will be unconditionally dropped 448 as might happen with IP fragmentation. 450 4.2. Scope 452 This specification describes the mechanics of fragmentation in 453 Generic UDP Encapsulation. The operational aspects and details for 454 higher layer implementation must be considered for deployment, but 455 are considered out of scope for this document. The AERO protocol 456 [I.D.templin-aerolink] defines one use case of fragmentation with 457 encapsulation. 459 4.3. Option format 461 The presence of the GUE fragmentation option is indicated by the F 462 bit in the GUE header. 464 The format of the fragmentation option is: 466 0 1 2 3 467 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 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | Fragment offset |Res|M| Orig-proto | | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 471 | Identification | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 The fields of the option are: 476 o Fragment offset: This field indicates where in the datagram this 477 fragment belongs. The fragment offset is measured in units of 8 478 octets (64 bits). The first fragment has offset zero. 480 o Res: Two bit reserved field. Must be set to zero for 481 transmission. If set to non-zero in a received packet then the 482 packet MUST be dropped. 484 o M: More fragments bit. Set to 1 when there are more fragments 485 following in the datagram, set to 0 for the last fragment. 487 o Orig-proto: The control type (when C bit is set) or the IP 488 protocol (when C bit is not set) of the fragmented packet. 490 o Identification: 40 bits. Identifies fragments of a fragmented 491 packet. 493 Pertinent GUE header fields to fragmentation are: 495 o C: This bit is set for each fragment based on the whether the 496 original packet being fragmented is a control or data message. 498 o Proto/ctype - For the first fragment (fragment offset is zero) 499 this is set to that of the original packet being fragmented 500 (either will be a control type or IP protocol). For other 501 fragments, this is set to zero for a control message being 502 fragmented, or to "No next header" (protocol number 59) for a 503 data message being fragmented. 505 o F bit - Set to indicate presence of the fragmentation option 506 field. 508 4.4. Fragmentation procedure 510 If an encapsulator determines that a packet must be fragmented (eg. 511 the packet's size exceeds the Path MTU of the tunnel) it should 512 divide the packet into fragments and send each fragment as a separate 513 GUE packet, to be reassembled at the decapsulator (tunnel egress). 515 For every packet that is to be fragmented, the source node generates 516 an Identification value. The Identification must be different than 517 that of any other fragmented packet sent within the past 60 seconds 518 (Maximum Segment Lifetime) with the same tunnel identification-- that 519 is the same outer source and destination addresses, same UDP ports, 520 same orig-proto, and same virtual network identifier if present. 522 The initial, unfragmented, and unencapsulated packet is referred to 523 as the "original packet". This will be a layer 2 packet, layer 3 524 packet, or the payload of a GUE control message: 526 +-------------------------------//------------------------------+ 527 | Original packet | 528 | (e.g. an IPv4, IPv6, Ethernet packet) | 529 +------------------------------//-------------------------------+ 531 Fragmentation and encapsulation are performed on the original packet 532 in sequence. First the packet is divided up in to fragments, and then 533 each fragment is encapsulated. Each fragment, except possibly the 534 last ("rightmost") one, is an integer multiple of 8 octets long. 535 Fragments MUST be non-overlapping. The number of fragments should be 536 minimized, and all but the last fragment should be approximately 537 equal in length. 539 The fragments are transmitted in separate "fragment packets" as: 541 +--------------+--------------+---------------+--//--+----------+ 542 | first | second | third | | last | 543 | fragment | fragment | fragment | .... | fragment | 544 +--------------+--------------+---------------+--//--+----------+ 546 Each fragment is encapsulated as the payload of a GUE packet. This is 547 illustrated as: 549 +------------------+----------------+-----------------------+ 550 | IP/UDP header | GUE header | first | 551 | header | w/ frag option | fragment | 552 +------------------+----------------+-----------------------+ 554 +------------------+----------------+-----------------------+ 555 | IP/UDP header | GUE header | second | 556 | header | w/ frag option | fragment | 557 +------------------+----------------+-----------------------+ 558 o 559 o 560 +------------------+----------------+-----------------------+ 561 | IP/UDP header | GUE header | last | 562 | header | w/ frag option | fragment | 563 +------------------+----------------+-----------------------+ 565 Each fragment packet is composed of: 567 (1) Outer IP and UDP headers as defined for GUE encapsulation. 569 o The IP addresses and UDP destination port must be the same 570 for all fragments of a fragmented packet. 572 o The source port selected for the inner flow identifier must 573 be the same value for all fragments of a fragmented packet. 575 (2) A GUE header that contains: 577 o The C bit which is set to the same value for all the 578 fragments of a fragmented packet based on whether a control 579 message or data message was fragmented. 581 o A proto/ctype. In the first fragment this is set to the 582 value corresponding to the next header of the original 583 packet and will be either an IP protocol or a control type. 584 For subsequent fragments, this field is set to 0 for a 585 fragmented control message or 59 (no next header) for a 586 fragmented data messages. 588 o The F bit is set and fragment option is present. 590 o Other GUE options. Note that options apply to the individual 591 GUE packet. For instance, the security option would be 592 validated before reassembly. 594 (3) The GUE fragmentation option. The option contents include: 596 o Orig-proto that identifies the first header of the original 597 packet. 599 o A Fragment Offset containing the offset of the fragment, in 600 8-octet units, relative to the start of the of the original 601 packet. The Fragment Offset of the first ("leftmost") 602 fragment is 0. 604 o An M flag value of 0 if the fragment is the last 605 ("rightmost") one, else an M flag value of 1. 607 o The Identification value generated for the original packet. 609 (4) The fragment itself. 611 4.5. Reassembly procedure 613 At the destination, fragment packets are decapsulated and reassembled 614 into their original, unfragmented form, as illustrated: 616 +-------------------------------//------------------------------+ 617 | Original packet | 618 | (e.g. an IPv4, IPv6, Ethernet packet) | 619 +------------------------------//-------------------------------+ 621 The following rules govern reassembly: 623 The IP/UDP/GUE headers of each packet are retained until all 624 fragments have arrived. The reassembled packet is then composed 625 of the decapsulated payloads in the GUE fragments, and the 626 IP/UDP/GUE headers are discarded. 628 When a GUE packet is received with the fragment option, the 629 proto/ctype in the GUE header must be validated. In the case 630 that the packet is a first fragment (fragment offset is zero), 631 the proto/ctype in the GUE header must equal the orig-proto 632 value in the fragmentation option. For subsequent fragments 633 (fragment offset is non-zero) the proto/ctype in the GUE header 634 must be 0 for a control message or 59 (no-next-hdr) for a data 635 message. If the proto/ctype value is invalid then for a received 636 packet it MUST be dropped. 638 An original packet is reassembled only from GUE fragment packets 639 that have the same outer Source Address, Destination Address, 640 UDP source port, UDP destination port, GUE header C bit, virtual 641 network identifier if present, orig-proto value in the 642 fragmentation option, and Fragment Identification. The protocol 643 type or control message type (depending on the C bit) for the 644 reassembled packet is the value of the GUE header proto/ctype 645 field in the first fragment. 647 The following error conditions may arise when reassembling fragmented 648 packets with GUE encapsulation: 650 If insufficient fragments are received to complete reassembly of 651 a packet within 60 seconds (or a configurable period) of the 652 reception of the first-arriving fragment of that packet, 653 reassembly of that packet must be abandoned and all the 654 fragments that have been received for that packet must be 655 discarded. 657 If the payload length of a fragment is not a multiple of 8 658 octets and the M flag of that fragment is 1, then that fragment 659 must be discarded. 661 If the length and offset of a fragment are such that the payload 662 length of the packet reassembled from that fragment would exceed 663 65,535 octets, then that fragment must be discarded. 665 If a fragment overlaps another fragment already saved for 666 reassembly then the new fragment that overlaps the existing 667 fragment MUST be discarded 669 If the first fragment is too small then it is possible that it 670 does not contain the necessary headers for a stateful firewall. 671 Sending small fragments like this has been used as an attack on 672 IP fragmentation. To mitigate this problem, an implementation 673 should ensure that the first fragment contains the headers of 674 the encapsulated packet at least through the transport header. 676 A GUE node must be able to accept a fragmented packet that, 677 after reassembly and decapsulation, is as large as 1500 octets. 678 This means that the node must configure a reassembly buffer that 679 is at least as large as 1500 octets plus the maximum-sized 680 encapsulation headers that may be inserted during encapsulation. 681 Implementations may find it more convenient and efficient to 682 configure a reassembly buffer size of 2KB which is large enough 683 to accommodate even the largest set of encapsulation headers and 684 provides a natural memory page size boundary. 686 4.6. Security Considerations 688 Exploits that have been identified with IP fragmentation are 689 conceptually applicable to GUE fragmentation. 691 Attacks on GUE fragmentation can be mitigated by: 693 o Hardened implementation that applies applicable techniques from 694 implementation of IP fragmentation. 696 o Application of GUE security (section 5) or IPsec [RFC4301]. 697 Security mechanisms can prevent spoofing of fragments from 698 unauthorized sources. 700 o Implement fragment filter techniques for GUE encapsulation as 701 described in [RFC1858] and [RFC3128]. 703 o Do not accepted data in overlapping segments. 705 o Enforce a minimum size for the first fragment. 707 5. Security and payload transform options 709 The security option and the payload transform option are used to 710 provide security for the GUE headers and payload. The GUE security 711 option provides origin authentication and integrity protection of the 712 GUE header at tunnel end points to guarantee isolation between 713 tunnels and mitigate Denial of Service attacks. The payload transform 714 option provides a means to perform encryption and authentication of 715 the GUE packet that protects the payload from eavesdropping, 716 tampering, or message forgery. 718 5.1. Security option format 720 The presence of the GUE security option is indicated in the SEC flag 721 bits of the GUE header. 723 The format of the fragmentation option is: 725 0 1 2 3 726 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 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 | | 729 ~ Security ~ 730 | | 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 The fields of the option are: 735 o Security (8, 16, or 32 octets). Contains the security 736 information. The specific semantics and format of this field is 737 expected to be negotiated between the two communicating nodes. 739 To provide security capability, the SEC flags MUST be set. Different 740 sizes are allowed to provide different methods and extensibility. The 741 use of the security field is expected to be negotiated out of band 742 between two tunnel end points. 744 The possible values in the SEC flags are: 746 o 00 - No security field 748 o 01 - 64 bit security field 750 o 10 - 128 bit security field 752 o 11 - 256 bit security field 754 5.2. Security option usage 756 The GUE security field should be used to provide integrity and 757 authentication of the GUE header. Security negotiation 758 (interpretation of security field, key management, etc.) is expected 759 to be negotiated out of band between two communicating hosts. Two 760 possible uses for this field are outlined below, a more precise 761 specification is deferred to other documents. 763 5.2.1. Cookies 765 The security field may be used as a cookie. This would be similar to 766 cookie mechanism described in L2TP [RFC3931], and the general 767 properties should be the same. The cookie may be used to validate the 768 encapsulation. The cookie is a shared value between an encapsulator 769 and decapsulator which should be chosen randomly and may be changed 770 periodically. Different cookies may used for logical flows between 771 the encapsulator and decapsulator, for instance packets sent with 772 different VNIs in network virtualization [I.D.hy-nvo3-gue-4-nvo] 773 might have different cookies. 775 5.2.2. Secure hash 777 Strong authentication of the GUE header can be provided using a 778 secure hash. This may follow the model of the TCP authentication 779 option [RFC5925]. In this case the security field holds a message 780 digest for the GUE header (e.g. 16 bytes from MD5). The digest might 781 be done over static fields in IP and UDP headers per negotiation 782 (addresses, ports, and protocols). In order to provide enough 783 entropy, a random salt value in each packet might be added, for 784 instance the security field could be a 256 bit value that contains 785 128 bits of salt value, and a 128 bit digest value. The use of secure 786 hashes requires shared keys which are presumably negotiated and 787 rotated as needed out of band. 789 5.3. Payload Transform Option format 791 The presence of the GUE payload transform option is indicated by the 792 T bit in the GUE header. 794 The format of Payload Transform Field is: 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 | Type | Payload Type | Reserved | 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 The fields of the option are: 802 Type: Payload Transform Type or Code point. Each payload transform 803 mechanism must have one code point registered in IANA. This 804 document specifies: 806 0x01: for DTLS [RFC6347] 808 0x80~0xFF: for private payload transform types 810 A private payload transform type can be used for 811 experimental purpose or vendor proprietary mechanisms. 813 Payload Type: Indicates the encrypted payload type. When payload 814 transform option is present, proto/ctype in the base header 815 should set to 59 ("No next header") for a data message and 816 zero for a control message. The payload type (IP protocol or 817 control message type) of the unencrypted payload must be 818 encoded in this field. 820 The benefit of this rule is to prevent a middle box from 821 inspecting the encrypted payload according to GUE next 822 protocol. The assumption here is that a middle box may 823 understand GUE base header but does not understand GUE 824 option flag definitions. 826 Reserved field for DTLS type MUST set to Zero. For other 827 transformation types, the use of reserved field may be specified. 829 5.3.1. Payload transform option usage 831 The payload transform option provides a mechanism to transform or 832 interpret the payload of a GUE packet. The Type field describes the 833 format of the payload before transformation and Payload Type provides 834 the protocol of the packet after transformation. The payload 835 transformation option is generic so that it can have both security 836 related uses (such as DTLS) as well as non security related uses 837 (such as compression, CRC, etc.). 839 The payload of a GUE packet can be secured using Datagram Transport 840 Layer Security [RFC6347]. An encapsulator would apply DTLS to the GUE 841 payload so that the payload packets are encrypted and the GUE header 842 remains in plaintext. The payload transform option is set to indicate 843 that the payload should be interpreted as a DTLS record. 845 5.4. Operation of security mechanisms 847 GUE secure transport mechanisms apply to both IPv4 and IPv6 underlay 848 networks. The outer IP address MUST be tunnel egress IP address (dst) 849 and tunnel ingress IP address (src). The GUE security option provides 850 origin authentication and integrity to GUE based tunnel; GUE payload 851 encryption provides payload privacy over an IP delivery network or 852 Internet. The two functions are processed separately at tunnel end 853 points. A GUE tunnel can use both functions or use one of them. 855 When both encryption and security are required, an encapsulator must 856 perform payload encryption first and then encapsulate the encrypted 857 packet with security flag and payload transform flag set in GUE 858 header; the security option field must be filled according Section 859 5.2 above and the payload transform field must be filled according to 860 Section 5.3 above. The decapsulator must decapsulate the packet 861 first, then perform the authentication validation. If the validation 862 is successful, it performs the payload decryption according to the 863 encryption information in the payload encryption field in the header. 864 Else if the validation fails, the decapsulator must discard the 865 packet and may generate an alert to the management system. These 866 processing rules also apply when only one function, either encryption 867 or security, is enabled, except the other function is not performed 868 as stated above. 870 If GUE fragmentation is used in concert with the GUE security option 871 and/or payload transform option, the security and playload 872 transformation are performed after fragmentation at the encapsulator 873 and before reassembly at the decapsulator. 875 In order to get flow entropy from the payload, an encapsulator must 876 determine the flow entropy value (e.g. a hash over the 4-tuple of a 877 TCP connection) before performing the payload encryption. The flow 878 entropy value can then be set in UDP src port of the GUE packet. 880 DTLS [RFC6347] provides packet fragmentation capability. To avoid 881 packets fragmentation being performed multiple times by an 882 encapsulator, an encapsulator SHOULD only perform the packet 883 fragmentation at part of the packet encapsulation process (e.g. using 884 the GUE fragmentation option), not in payload encryption process 885 (i.e. DTLS layer fragmentation should be avoided). 887 DTLS usage [RFC6347] is limited to a single DTLS session for any 888 specific tunnel encapsulator/decapsulator pair (identified by source 889 and destination IP addresses). Both IP addresses MUST be unicast 890 addresses - multicast traffic is not supported when DTLS is used. A 891 GUE tunnel decapsulator implementation that supports DTLS can 892 establish DTLS session(s) with one or multiple tunnel encapsulators, 893 and likewise a GUE tunnel encapsulator implementation can establish 894 DTLS session(s) with one or multiple decapsulators. 896 5.5. Considerations of Using Other Security Tunnel Mechanisms 898 GUE may rely on other secure tunnel mechanisms such as DTLS [RFC6347] 899 over the whole UDP payload for securing the whole GUE packet or IPsec 900 [RFC4301] to achieve the secure transport over an IP network or 901 Internet. 903 IPsec [RFC4301] was designed as a network security mechanism, and 904 therefore it resides at the network layer. As such, if the tunnel is 905 secured with IPsec, the UDP header would not be visible to 906 intermediate routers anymore in either IPsec tunnel or transport 907 mode. The big drawback here prohibits intermediate routers to perform 908 load balancing based on the flow entropy in UDP header. In addition, 909 this method prohibits any middle box function on the path. 911 By comparison, DTLS [RFC6347] was designed with application security 912 and can better preserve network and transport layer protocol 913 information than IPsec [RFC4301]. Using DTLS to secure the GUE 914 tunnel, both GUE header and payload will be encrypted. In order to 915 differentiate plaintext GUE header from encrypted GUE header, the 916 destination port of the UDP header between two must be different, 917 which essentially requires another standard UDP port for GUE with 918 DTLS. The drawback on this method is to prevent a middle box 919 operation to GUE tunnel on the path. 921 Use of two independent tunnel mechanisms such as GUE and DTLS to 922 carry a network protocol over an IP network adds some overlap and 923 process complex. For example, fragmentation will be done twice. 925 As the result, a GUE tunnel SHOULD use the security mechanisms 926 specified in this document to provide secure transport over an IP 927 network or Internet when it is needed. GUE tunnels with the GUE 928 security options can be used as a secure transport mechanism over an 929 IP network and Internet. 931 6. Remote checksum offload option 933 Remote checksum offload is mechanism that provides checksum offload 934 of encapsulated packets using rudimentary offload capabilities found 935 in most Network Interface Card (NIC) devices. Many NIC 936 implementations can only offload the outer UDP checksum in UDP 937 encapsulation. Remote checksum offload is described in [UDPENCAP]. 939 In remote checksum offload the outer header checksum, that is in the 940 outer UDP header, is enabled in packets and, with some additional 941 meta information, a receiver is able to deduce the checksum to be set 942 for an inner encapsulated packet. Effectively this offloads the 943 computation of the inner checksum. Enabling the outer checksum in 944 encapsulation has the additional advantage that it covers more of the 945 packet than the inner checksum including the encapsulation headers. 947 The remote offload checksum option should not be used when GUE 948 fragmentation is also being performed. In this case the offload of 949 the outer UDP checksum does not cover the whole transport segment so 950 remote checksum offload would not properly set the inner transport 951 layer checksum. 953 6.1. Option format 955 The presence of the GUE remote checksum offload option is indicated 956 by the R bit in the GUE header. 958 The format of remote checksum offload field is: 960 0 1 2 3 961 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 962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 963 | Checksum start | Checksum offset | 964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 965 The fields of the option are: 967 o Checksum start: starting offset for checksum computation 968 relative to the start of the encapsulated payload. This is 969 typically the offset of a transport header (e.g. UDP or TCP). 971 o Checksum offset: Offset relative to the start of the 972 encapsulated packet where the derived checksum value is to be 973 written. This typically is the offset of the checksum field in 974 the transport header (e.g. UDP or TCP). 976 6.2. Transmitter operation 978 The typical actions to set remote checksum offload on transmit 979 are: 981 1) Transport layer creates a packet and indicates in internal 982 packet meta data that checksum is to be offloaded to the NIC 983 (normal transport layer processing for checksum offload). The 984 checksum field is populated with the bitwise not of the 985 checksum of the pseudo header or zero as appropriate. 987 2) Encapsulation layer adds its headers to the packet including 988 the offload meta data. The start offset and checksum offset are 989 set accordingly. 991 3) Encapsulation layer arranges for checksum offload of the outer 992 header checksum (e.g. UDP). 994 4) Packet is sent to the NIC. The NIC will perform transmit 995 checksum offload and set the checksum field in the outer 996 header. The inner header and rest of the packet are transmitted 997 without modification. 999 6.3. Receiver operation 1001 The typical actions a host receiver does to support remote checksum 1002 offload are: 1004 1) Receive packet and validate outer checksum following normal 1005 processing (e.g. validate non-zero UDP checksum). 1007 2) Validate the checksum option. If checksum start is greater than 1008 the length of the packet, then the packet must be dropped. If 1009 checksum offset is greater then the length of the packet minus 1010 two, then the packet must be dropped. 1012 3) Deduce full checksum for the IP packet. If a NIC is capable of 1013 receive checksum offload it will return either the full 1014 checksum of the received packet or an indication that the UDP 1015 checksum is correct. Either of these methods can be used to 1016 deduce the checksum over the IP packet [UDPENCAP]. 1018 4) From the packet checksum, subtract the checksum computed from 1019 the start of the packet (outer IP header) to the offset in the 1020 packet indicted by checksum start in the meta data. The result 1021 is the deduced checksum to set in the checksum field of the 1022 encapsulated transport packet. 1024 In pseudo code: 1026 csum: initialized to checksum computed from start (outer IP 1027 header) to the end of the packet 1028 start_of_packet: address of start of packet 1029 encap_payload_offset: relative to start_of_packet 1030 csum_start: value from meta data 1031 checksum(start, len): function to compute checksum from start 1032 address for len bytes 1034 csum -= checksum(start_of_packet, encap_payload_offset + 1035 csum_start) 1037 4) Write the resultant checksum value into the packet at the 1038 offset provided by checksum offset in the meta data. 1040 In pseudo code: 1042 csum_offset: offset of checksum field 1044 *(start_of_packet + encap_payload_offset + 1045 csum_offset) = csum 1047 5) Checksum is verified at the transport layer using normal 1048 processing. This should not require any checksum computation 1049 over the packet since the complete checksum has already been 1050 provided. 1052 6.4. Security Considerations 1054 Remote checksum offload allows a means to change the GUE payload 1055 before being received at a decapsulator. In order to prevent misuse 1056 of this mechanism, a decapsulator should apply security checks on the 1057 GUE payload only after checksum remote offload has been processed. 1059 7. Processing order of options 1060 Options must be processed in a specific order for both sending and 1061 receive. Note that some options, such as the checksum option, depend 1062 on other fields in the GUE header to be set. 1064 The order of processing options to send a GUE packet are: 1066 1) Set VNID option. 1068 2) Fragment if necessary and set fragmentation option. VNID is 1069 copied into each fragment. Note that if payload transformation 1070 will increase the size of the payload that must be accounted 1071 for when deciding how to fragment 1073 3) Set Remote checksum offload. 1075 4) Perform payload transform (potentially on each fragment) and 1076 set payload transform option. 1078 5) Set security option. 1080 6) Calculate GUE checksum and set checksum option. 1082 On reception the order of actions is reversed. 1084 1) Verify GUE checksum. 1086 2) Verify security option. 1088 3) Perform payload transformation (i.e. decrypt payload) 1090 4) Adjust packet for remote checksum offload. 1092 5) Perform reassembly. 1094 6) Receive on virtual network indicated by VNID. 1096 Note that the relative processing order of private fields is 1097 unspecified. 1099 8. Security Considerations 1101 Encapsulation of network protocol in GUE should not increase security 1102 risk, nor provide additional security in itself. GUE requires that 1103 the source port for UDP packets should be randomly seeded to mitigate 1104 some possible denial service attacks. 1106 If the integrity and privacy of data packets being transported 1107 through GUE is a concern, GUE security and payload encryption SHOULD 1108 be used to remove the concern. If the integrity is the only concern, 1109 the tunnel may consider use of GUE security only for optimization. 1110 Likewise, if the privacy is the only concern, the tunnel may use GUE 1111 encryption function only. 1113 If GUE payload already provides secure mechanism, e.g., the payload 1114 is IPsec packets, it is still valuable to consider use of GUE 1115 security. 1117 9. IANA Consideration 1119 IANA is requested to assign flags for the extensions defined in this 1120 specification. Specifically, an assignment is requested for the V, 1121 SEC, K, F, T and R flags in the "GUE flag-fields" registry (proposed 1122 in [I.D.nvo3-gue]). 1124 10. References 1126 10.1. Normative References 1128 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1129 1981. 1131 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 1132 Communication Layers", STD 3, RFC 1122, October 1989. 1134 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1135 August 1980. 1137 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1138 (IPv6) Specification", RFC 2460, December 1998. 1140 [I.D.nvo3-gue] T. Herbert, L. Yong, and O. Zia, "Generic UDP 1141 Encapsulation" draft-ietf-nvo3-gue-03 1143 10.2. Informative References 1145 [RFC1071] Braden, R., Borman, D., and C. Partridge, "Computing the 1146 Internet checksum", RFC1071, September 1988. 1148 [RFC1624] Rijsinghani, A., Ed., "Computation of the Internet Checksum 1149 via Incremental Update", RFC1624, May 1994. 1151 [RFC1936] Touch, J. and B. Parham, "Implementing the Internet 1152 Checksum in Hardware", RFC1936, April 1996. 1154 [RFC4459] MTU and Fragmentation Issues with In-the-Network Tunneling. 1156 P. Savola. April 2006. 1158 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 1159 Errors at High Data Rates", RFC 4963, DOI 10.17487/RFC4963, 1160 July 2007, . 1162 [RFC2764] B. Gleeson, A. Lin, J. Heinanen, G. Armitage, A. Malis, "A 1163 Framework for IP Based Virtual Private Networks", RFC2764, 1164 February 2000. 1166 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1167 Internet Protocol", RFC 4301, December 2005. 1169 [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security 1170 Considerations for IP Fragment Filtering", RFC 1858, 1171 October 1995. 1173 [RFC3128] Miller, I., "Protection Against a Variant of the Tiny 1174 Fragment Attack (RFC 1858)", RFC 3128, June 2001. 1176 [RFC3931] Lau, J., Townsley, W., et al, "Layer Two Tunneling Protocol 1177 - Version 3 (L2TPv3)", RFC3931, 1999 1179 [RFC5925] Touch, J., et al, "The TCP Authentication Option", RFC5925, 1180 June 2010. 1182 [RFC6347] Rescoria, E., Modadugu, N., "Datagram Transport Layer 1183 Security Version 1.2", RFC6347, 2012. 1185 [I.D.hy-nvo3-gue-4-nvo] Yong, L., Herbert, T., "Generic UDP 1186 Encapsulation (GUE) for Network Virtualization Overlay" 1187 draft-hy-nvo3-gue-4-nvo-03 1189 [I.D.draft-mathis-frag-harmful] M. Mathis, J. Heffner, and B. 1190 Chandler, "Fragmentation Considered Very Harmful" 1192 [I.D.templin-aerolink] F. Templin, "Transmission of IP Packets over 1193 AERO Links" draft-templin-aerolink-62.txt 1195 [UDPENCAP] T. Herbert, "UDP Encapsulation in Linux", 1196 http://people.netfilter.org/pablo/netdev0.1/papers/UDP- 1197 Encapsulation-in-Linux.pdf 1199 Authors' Addresses 1201 Tom Herbert 1202 Facebook 1203 1 Hacker Way 1204 Menlo Park, CA 1205 USA 1207 EMail: tom@herbertland.com 1209 Lucy Yong 1210 Huawei USA 1211 5340 Legacy Dr. 1212 Plano, TX 75024 1213 USA 1215 Email: lucy.yong@huawei.com 1217 Fred L. Templin 1218 Boeing Research & Technology 1219 P.O. Box 3707 1220 Seattle, WA 98124 1221 USA 1223 Email: fltemplin@acm.org