idnits 2.17.1 draft-ietf-intarea-gue-extensions-03.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 194: '... SHOULD be set to protocol numb...' RFC 2119 keyword, line 256: '...termediate nodes MAY apply semantics t...' RFC 2119 keyword, line 288: '...y, the SEC flags MUST be set. Differen...' RFC 2119 keyword, line 319: '...e same. A cookie MAY be used to valida...' RFC 2119 keyword, line 321: '...capsulator which SHOULD be chosen rand...' (50 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 18, 2018) is 2287 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) == Unused Reference: 'RFC1122' is defined on line 1671, but no explicit reference was found in the text == Unused Reference: 'RFC6936' is defined on line 1727, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. 'RFC2104') (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 5 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 Quantonium 4 Expires: July 22, 2018 L. Yong 5 Huawei 6 F. Templin 7 Boeing 9 January 18, 2018 11 Extensions for Generic UDP Encapsulation 12 draft-ietf-intarea-gue-extensions-03 14 Abstract 16 This specification defines a set of the fundamental optional 17 extensions for Generic UDP Encapsulation (GUE). 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as 27 Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/1id-abstracts.html 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 Copyright and License Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. GUE header format with optional extensions . . . . . . . . . . 4 59 3. Group identifier option . . . . . . . . . . . . . . . . . . . 6 60 3.1. Extension field format . . . . . . . . . . . . . . . . . . 6 61 3.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 4. Security option . . . . . . . . . . . . . . . . . . . . . . . 6 63 4.1. Extension field format . . . . . . . . . . . . . . . . . . 7 64 4.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 4.3. Cookies . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 4.4. HMAC . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 4.4.1. Extension field format . . . . . . . . . . . . . . . . 8 68 4.4.2. Selecting a hash algorithm . . . . . . . . . . . . . . 9 69 4.4.3. Pre-shared key management . . . . . . . . . . . . . . . 10 70 4.5. Interaction with other optional extensions . . . . . . . . 10 71 5. Fragmentation option . . . . . . . . . . . . . . . . . . . . . 10 72 5.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 11 73 5.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 5.3. Extension field format . . . . . . . . . . . . . . . . . . 12 75 5.4. Fragmentation procedure . . . . . . . . . . . . . . . . . 13 76 5.5. Reassembly procedure . . . . . . . . . . . . . . . . . . . 15 77 5.6. Security Considerations . . . . . . . . . . . . . . . . . 16 78 6. Payload transform option . . . . . . . . . . . . . . . . . . . 17 79 6.1. Extension field format . . . . . . . . . . . . . . . . . . 17 80 6.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 18 81 6.3. Interaction with other optional extensions . . . . . . . . 18 82 6.4. DTLS transform . . . . . . . . . . . . . . . . . . . . . . 19 83 7. Remote checksum offload option . . . . . . . . . . . . . . . . 19 84 7.1. Extension field format . . . . . . . . . . . . . . . . . . 20 85 7.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 20 86 7.2.1. Transmitter operation . . . . . . . . . . . . . . . . . 20 87 7.2.2. Receiver operation . . . . . . . . . . . . . . . . . . 21 88 7.3. Security Considerations . . . . . . . . . . . . . . . . . 22 89 8. Checksum option . . . . . . . . . . . . . . . . . . . . . . . 22 90 8.1. Extension field format . . . . . . . . . . . . . . . . . . 22 91 8.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 23 92 8.3. GUE checksum pseudo header . . . . . . . . . . . . . . . . 23 93 8.4. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 24 94 8.4.1. Transmitter operation . . . . . . . . . . . . . . . . . 24 95 8.4.2. Receiver operation . . . . . . . . . . . . . . . . . . 25 96 8.5. Corrupted flags . . . . . . . . . . . . . . . . . . . . . 25 97 8.6. Security Considerations . . . . . . . . . . . . . . . . . 26 98 9. NAT checksum address option . . . . . . . . . . . . . . . . . 26 99 9.1. Extension field format . . . . . . . . . . . . . . . . . . 26 100 9.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 26 101 9.2.1. Transmitter operation . . . . . . . . . . . . . . . . . 27 102 9.2.2. Receiver operation . . . . . . . . . . . . . . . . . . 28 103 10. Alternative checksum option . . . . . . . . . . . . . . . . . 28 104 10.1. Extension field format . . . . . . . . . . . . . . . . . . 28 105 10.1.1. CRC-16-CCITT and CRC-16 alternate checksums . . . . . 29 106 10.1.2. 32-bit CRC alternate checksum . . . . . . . . . . . . 30 107 10.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 30 108 10.2.1. Transmitter operation . . . . . . . . . . . . . . . . 30 109 10.2.2. Receiver operation . . . . . . . . . . . . . . . . . . 31 110 10.3. Corrupted flags . . . . . . . . . . . . . . . . . . . . . 31 111 10.4. Security Considerations . . . . . . . . . . . . . . . . . 32 112 11. Processing order of options . . . . . . . . . . . . . . . . . 32 113 11.1. Processing order when sending . . . . . . . . . . . . . . 32 114 11.2. Processing order when receiving . . . . . . . . . . . . . 33 115 12. Security Considerations . . . . . . . . . . . . . . . . . . . 33 116 13. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 34 117 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 118 14.1. Normative References . . . . . . . . . . . . . . . . . . . 36 119 14.2. Informative References . . . . . . . . . . . . . . . . . . 36 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 122 1. Introduction 124 Generic UDP Encapsulation (GUE) [I.D.ietf-gue] is a generic and 125 extensible encapsulation protocol. This specification defines a 126 fundamental set of optional extensions for version 0 of GUE. These 127 extensions are the group identifier, security, fragmentation, payload 128 transform, remote checksum offload, checksum, NAT address checksum, 129 and alternate checksum. 131 2. GUE header format with optional extensions 133 The format of a version 0 GUE header with optional extensions is: 135 0 1 2 3 136 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 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ 138 | Source port | Destination port | UDP 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ 140 | Length | Checksum | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | 0 |C| Hlen | Proto/ctype |G| SEC |F|T|R|K|N|ACS| Rsvd | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | Group identifier (optional) | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | | 147 ~ Security (optional) ~ 148 | | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | | 151 + Fragmentation (optional) + 152 | | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Payload transform (optional) | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Remote checksum offload (optional) | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Checksum (optional) | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | NAT Address Checksum (optional) | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | | 163 ~ Alternate checksum (optional) ~ 164 | | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | | 167 ~ Private data (optional) ~ 168 | | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 The contents of the UDP header are described in [I.D.ietf-gue]. 172 The GUE header consists of: 174 o Variant: Set to 0 to indicate GUE encapsulation header. Note 175 that variant 1 (direct IP encapsulation) does not allow options. 177 o C: C-bit. Indicates the GUE payload is a control message when 178 set, a data message when not set. GUE optional extensions can be 179 used with either control or data messages unless otherwise 180 specified in the extension definition. 182 o Hlen: Length in 32-bit words of the GUE header, including 183 optional extension fields and private data but not the first 184 four bytes of the header. Computed as (header_len - 4) / 4. The 185 length of the encapsulated packet is determined from the UDP 186 length and the Hlen: encapsulated_packet_length = UDP_Length - 187 12 - 4 * Hlen. 189 o Proto/ctype: If the C-bit is not set this indicates IP protocol 190 number for the packet in the payload; if the C bit is set this 191 is the type of control message in the payload. The next header 192 begins at the offset provided by Hlen. When the payload 193 transform option or fragmentation option is used this field 194 SHOULD be set to protocol number 59 for a data message, or zero 195 for a control message, to indicate no next header for the 196 payload. 198 o G: Indicates the the group identifier extension field is 199 present. The group identifier option is described in section 3. 201 o SEC: Indicates security extension field is present. The security 202 option is described in section 4. 204 o F: Indicates fragmentation extension field is present. The 205 fragmentation option is described in section 5. 207 o T: Indicates payload transform extension field is present. The 208 payload transform option is described in section 6. 210 o R: Indicates the remote checksum extension field is present. The 211 remote checksum offload option is described in section 7. 213 o K: Indicates checksum extension field is present. The checksum 214 option is described in section 8. 216 o N: Indicates NAT address checksum field is present. The NAT 217 address checksum option is described in section 9. 219 o ACS: Indicates alternative checksum field is present. The 220 alternative checksum option is described in section 10. 222 o Private data is described in [I.D.ietf-gue]. 224 3. Group identifier option 226 A group identifier classifies packets that logically belong to the 227 same group. Groups are arbitrarily defined for different purposes and 228 their definition is shared between the communicating end nodes. 230 3.1. Extension field format 232 The presence of the GUE group identifier option is indicated in the G 233 flag bit of the GUE header. 235 The format of the group identifier option is: 237 0 1 2 3 238 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 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | Group identifier | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 The fields of the option are: 245 o Group identifier: Identifier value of a group. 247 3.2. Usage 249 The group identifier is set by an encapsulator to indicate that a 250 packet belongs to a group. Groups may be arbitrarily defined to 251 classify packets. Specific use cases of the group identifier may be 252 defined in other documents ([I.D.hy-nvo3-gue-4-nvo] defines a use of 253 this field to contain a virtual networking identifier for 254 implementing network virtualization). 256 Intermediate nodes MAY apply semantics to group identifiers if group 257 identifier information is shared and made global within a network. 258 For instance, a firewall could block packets based on a group 259 identifier that serves as a virtual identifier for a tenant. 261 4. Security option 263 The GUE security option provides origin authentication and integrity 264 protection of the GUE header at tunnel end points to guarantee 265 isolation between tunnels and mitigate Denial of Service attacks. 267 4.1. Extension field format 269 The presence of the GUE security option is indicated in the SEC flag 270 bits of the GUE header. 272 The format of the security option is: 274 0 1 2 3 275 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 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | | 278 ~ Security ~ 279 | | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 The fields of the option are: 284 o Security (variable length). Contains the security information. 285 The specific semantics and format of this field are expected to 286 be negotiated between the two communicating nodes. 288 To provide security capability, the SEC flags MUST be set. Different 289 field sizes allow different methods and extensibility. The use of the 290 security field is expected to be negotiated out of band between two 291 tunnel end points. 293 The values in the SEC flags are: 295 o 000b - No security field 297 o 001b - 64 bit security field 299 o 010b - 128 bit security field 301 o 011b - 256 bit security field 303 o 100b - 320 bit security field (HMAC) 305 o 101b, 110b, 111b - Reserved values 307 4.2. Usage 309 The GUE security option is used to provide integrity and 310 authentication of the GUE header. Security parameters (interpretation 311 of security field, key management, etc.) are expected to be 312 negotiated out of band between two communicating hosts. Two security 313 algorithms are defined below. 315 4.3. Cookies 317 The security field may be used as a cookie. This would be similar to 318 the cookie mechanism described in L2TP [RFC3931], and the general 319 properties should be the same. A cookie MAY be used to validate the 320 encapsulation. A cookie is a shared value between an encapsulator and 321 decapsulator which SHOULD be chosen randomly and MAY be changed 322 periodically. Different cookies MAY be used for logical flows between 323 the encapsulator and decapsulator; for instance packets sent with 324 different VNIs in network virtualization [I.D.hy-nvo3-gue-4-nvo] 325 might have different cookies. Cookies can be 64, 128, or 256 bits in 326 size. 328 4.4. HMAC 330 Key-hashed message authentication code (HMAC) is a strong method of 331 checking integrity and authentication of data. This sections defines 332 a GUE security option for HMAC. Note that this is based on the HMAC 333 TLV description in "IPv6 Segment Routing Header (SRH)" [I.D.previdi- 334 6man-sr-header]. 336 4.4.1. Extension field format 338 The HMAC option is a 320 bit field (40 octets). The security flags 339 are set to 100b to indicate the presence of a 320 bit security field. 341 The format of the field is: 343 0 1 2 3 344 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 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | HMAC Key-id | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | Payload offset | Payload length | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | | 351 ~ HMAC (256 bits) ~ 352 | | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 Fields are: 357 o HMAC Key-id: opaque field to allow multiple hash algorithms or 358 key selection 360 o Payload offset: offset in payload that indicates the first octet 361 of payload data included in the HMAC. 363 o Payload length: length of payload data starting from the payload 364 offset to be included in the HMAC calculation. Zero 365 indicates no payload data in used in the 366 calculation. 368 o HMAC: Output of HMAC computation 370 The HMAC field is the output of the HMAC computation (per [RFC2104]) 371 using a pre-shared key identified by HMAC Key-id and of the text 372 which consists of the concatenation of: 374 o The IP addresses 376 o The GUE header including all optional extensions except for the 377 security option 379 o Optionally some or all of GUE payload. The portion of payload 380 covered is indicated by an offset into the payload and a length 381 relative to the offset. 383 The purpose of the HMAC option is to verify the validity, the 384 integrity and the authentication of the GUE header itself and 385 optionally some or all of the GUE payload. 387 The HMAC Key-id field allows for the simultaneous existence of 388 several hash algorithms (SHA-256, SHA3-256 ... or future ones) as 389 well as pre-shared keys. The HMAC Key-id field is opaque, i.e., it 390 has neither syntax nor semantic. Having an HMAC Key-id field allows 391 for pre-shared key roll-over when two pre-shared keys are supported 392 for a while when GUE endpoints converge to a fresher pre-shared key. 394 A portion of the GUE payload MAY be included in the HMAC calculation. 395 The payload coverage is indicated in the option in the payload offset 396 and payload length fields. If no payload data is included in the HMAC 397 then the payload length field is set to zero. On reception, if the 398 sum of the payload offset and the payload length is greater than the 399 total length of the payload, then the packet MUST be dropped. 401 4.4.2. Selecting a hash algorithm 403 The HMAC field in the HMAC option is 256 bit wide. Therefore, the 404 HMAC MUST be based on a hash function whose output is at least 256 405 bits. If the output of the hash function is 256 bits, then this 406 output is simply inserted in the HMAC field. If the output of the 407 hash function is larger than 256 bits, then the output value is 408 truncated to 256 bits by taking the least-significant 256 bits and 409 inserting them in the HMAC field. 411 GUE implementations can support multiple hash functions but MUST 412 implement SHA-2 [FIPS180-4] in its SHA-256 variant. 414 4.4.3. Pre-shared key management 416 The field HMAC Key-id allows for: 418 o Key roll-over: when there is a need to change the key (the hash 419 pre-shared secret), then multiple pre-shared keys can be used 420 simultaneously. A decapsulator can have a table of for the currently active and future keys. 423 o Different algorithms: by extending the previous table to , the decapsulator can 425 also support simultaneously several hash algorithms 427 The pre-shared secret distribution can be done: 429 o In the configuration of the endpoints 431 o Dynamically using a trusted key distribution such as [RFC6407] 433 4.5. Interaction with other optional extensions 435 If GUE fragmentation (section 5) is used in concert with the GUE 436 security option, the security option processing is performed after 437 fragmentation at the encapsulator and before reassembly at the 438 decapsulator. 440 The GUE payload transform option (section 6) may be used in concert 441 with the GUE security option. The payload transform option could be 442 used to encrypt the GUE payload to provide privacy for an 443 encapsulated packet during transit. The security option provides 444 authentication and integrity for the GUE header (including the 445 payload transform field in the header). The two functions are 446 processed separately at tunnel end points. A GUE tunnel can use both 447 functions or use one of them. Section 6.3 details handling for when 448 both are used in a packet. 450 5. Fragmentation option 452 The fragmentation option allows an encapsulator to perform 453 fragmentation of packets being ingress to a tunnel. Procedures for 454 fragmentation and reassembly are defined in this section. This 455 specification adapts the procedures for IP fragmentation and 456 reassembly described in [RFC0791] and [RFC8200]. Fragmentation can be 457 performed on both data and control messages in GUE. 459 5.1. Motivation 461 This section describes the motivation for having a fragmentation 462 option in GUE. 464 MTU and fragmentation issues with In-the-Network Tunneling are 465 described in [RFC4459]. Considerations need to be made when a packet 466 is received at a tunnel ingress point which may be too large to 467 traverse the path between tunnel endpoints. 469 There are four suggested alternatives in [RFC4459] to deal with this: 471 1) Fragmentation and Reassembly by the Tunnel Endpoints 473 2) Signaling the Lower MTU to the Sources 475 3) Encapsulate Only When There is Free MTU 477 4) Fragmentation of the Inner Packet 479 Many tunneling protocol implementations have assumed that 480 fragmentation should be avoided, and in particular alternative #3 481 seems preferred for deployment. In this case, it is assumed that an 482 operator can configure the MTUs of links in the paths of tunnels to 483 ensure that they are large enough to accommodate any packets and 484 required encapsulation overhead. This method, however, may not be 485 feasible in certain deployments and may be prone to misconfiguration 486 in others. 488 Similarly, the other alternatives have drawbacks that are described 489 in [RFC4459]. Alternative #2 implies use of something like Path MTU 490 Discovery which is not known to be sufficiently reliable. Alternative 491 #4 is not permissible with IPv6 or when the DF bit is set for IPv4, 492 and it also introduces other known issues with IP fragmentation. 494 For alternative #1, fragmentation and reassembly at the tunnel 495 endpoints, there are two possibilities: encapsulate the large packet 496 and then perform IP fragmentation, or segment the packet and then 497 encapsulate each segment (a non-IP fragmentation approach). 499 Performing IP fragmentation on an encapsulated packet has the same 500 issues as that of normal IP fragmentation. Most significant of these 501 is that the Identification field is only sixteen bits in IPv4 which 502 introduces problems with wraparound as described in [RFC4963]. 504 The second possibility of alternative #1 follows the suggestion 505 expressed in [RFC2764] and the fragmentation feature described in the 506 AERO protocol [I.D.templin-aerolink]; that is for the tunneling 507 protocol itself to incorporate a segmentation and reassembly 508 capability. In this method, fragmentation is part of the 509 encapsulation and an encapsulation header contains the information 510 for reassembly. This differs from IP fragmentation in that the IP 511 headers of the original packet are not replicated for each fragment. 513 Incorporating fragmentation into the encapsulation protocol has some 514 advantages: 516 o At least a 32 bit identifier can be defined to avoid issues of 517 the 16 bit Identification in IPv4. 519 o Encapsulation mechanisms for security and identification, such 520 as group identifiers, can be applied to each segment. 522 o This allows the possibility of using alternate fragmentation and 523 reassembly algorithms (e.g. fragmentation with Forward Error 524 Correction). 526 o Fragmentation is transparent to the underlying network so it is 527 unlikely that fragmented packet will be unconditionally dropped 528 as might happen with IP fragmentation. 530 5.2. Scope 532 This specification describes the mechanics of fragmentation in 533 Generic UDP Encapsulation. The operational aspects and details for 534 higher layer implementation must be considered for deployment, but 535 are considered out of scope for this document. The AERO protocol 536 [I.D.templin-aerolink] defines one use case of fragmentation with 537 encapsulation. 539 5.3. Extension field format 541 The presence of the GUE fragmentation option is indicated by the F 542 bit in the GUE header. 544 The format of the fragmentation option is: 546 0 1 2 3 547 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 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | Fragment offset |Res|M| Orig-proto | | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 551 | Identification | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 The fields of the option are: 556 o Fragment offset: This field indicates where in the datagram this 557 fragment belongs. The fragment offset is measured in units of 8 558 octets (64 bits). The first fragment has offset zero. 560 o Res: Two bit reserved field. MUST be set to zero for 561 transmission. If set to non-zero in a received packet then the 562 packet MUST be dropped. 564 o M: More fragments bit. Set to 1 when there are more fragments 565 following in the datagram, set to 0 for the last fragment. 567 o Orig-proto: The control type (when the C-bit in the GUE header 568 is set) or the IP protocol (when C-bit is not set) of the 569 fragmented packet. 571 o Identification: 40 bits. Identifies fragments of a fragmented 572 packet. 574 Pertinent GUE header fields to fragmentation are: 576 o C-bit: This is set for each fragment based on the whether the 577 original packet being fragmented is a control or data message. 579 o Proto/ctype - For the first fragment (fragment offset is zero) 580 this is set to that of the original packet being fragmented 581 (either will be a control type or IP protocol). For other 582 fragments, this is set to zero for a control message being 583 fragmented, or to "No next header" (protocol number 59) for a 584 data message being fragmented. 586 o F bit - Set to indicate presence of the fragmentation extension 587 field. 589 5.4. Fragmentation procedure 591 If an encapsulator determines that a packet must be fragmented (e.g. 592 the packet's size exceeds the Path MTU of the tunnel) it should 593 divide the packet into fragments and send each fragment as a separate 594 GUE packet, to be reassembled at the decapsulator (tunnel egress). 596 For every packet that is to be fragmented, the source node generates 597 an Identification value. The Identification MUST be different than 598 that of any other fragmented packet sent within the past 60 seconds 599 (Maximum Segment Lifetime) with the same tunnel identification-- that 600 is the same outer source and destination addresses, same UDP ports, 601 same orig-proto, and same group identifier if present. 603 The initial, unfragmented, and unencapsulated packet is referred to 604 as the "original packet". This will be a layer 2 packet, layer 3 605 packet, or the payload of a GUE control message: 607 +-------------------------------//------------------------------+ 608 | Original packet | 609 | (e.g. an IPv4, IPv6, Ethernet packet) | 610 +------------------------------//-------------------------------+ 612 Fragmentation and encapsulation are performed on the original packet 613 in sequence. First the packet is divided up in to fragments, and then 614 each fragment is encapsulated. Each fragment, except possibly the 615 last ("rightmost") one, is an integer multiple of 8 octets long. 616 Fragments MUST be non-overlapping. The number of fragments SHOULD be 617 minimized, and all but the last fragment should be approximately 618 equal in length. 620 The fragments are transmitted in separate "fragment packets" as: 622 +--------------+--------------+---------------+--//--+----------+ 623 | first | second | third | | last | 624 | fragment | fragment | fragment | .... | fragment | 625 +--------------+--------------+---------------+--//--+----------+ 627 Each fragment is encapsulated as the payload of a GUE packet. This is 628 illustrated as: 630 +------------------+----------------+-----------------------+ 631 | IP/UDP header | GUE header | first | 632 | | w/ frag option | fragment | 633 +------------------+----------------+-----------------------+ 635 +------------------+----------------+-----------------------+ 636 | IP/UDP header | GUE header | second | 637 | | w/ frag option | fragment | 638 +------------------+----------------+-----------------------+ 639 o 640 o 641 +------------------+----------------+-----------------------+ 642 | IP/UDP header | GUE header | last | 643 | | w/ frag option | fragment | 644 +------------------+----------------+-----------------------+ 646 Each fragment packet is composed of: 648 (1) Outer IP and UDP headers as defined for GUE encapsulation. The 649 IP addresses and UDP ports MUST be the same for all fragments 650 of a fragmented packet. 652 (2) A GUE header that indicates the fragmentation option is 653 present. The C-bit and and proto/ctype are set appropriately 654 as described above. 656 (3) The GUE fragmentation option. Orig-protocol is set to the 657 protocol of the original packet. The M-bit is set for all 658 fragments except the last one. Fragment offset is set as the 659 offset of each fragment in the original packet. 661 (4) Other GUE extensions. 663 (5) The fragment itself as payload of the GUE packet. 665 5.5. Reassembly procedure 667 At the destination, fragment packets are decapsulated and reassembled 668 into their original, unfragmented form, as illustrated: 670 +-------------------------------//------------------------------+ 671 | Original packet | 672 | (e.g. an IPv4, IPv6, Ethernet packet) | 673 +------------------------------//-------------------------------+ 675 The following rules govern reassembly: 677 The IP/UDP/GUE headers of each packet are retained until all 678 fragments have arrived. The reassembled packet is then composed 679 of the decapsulated payloads in the GUE packets, and the 680 IP/UDP/GUE headers are discarded. 682 When a GUE packet is received with the fragment extension, the 683 proto/ctype field in the GUE header MUST be validated. In the 684 case that the packet is a first fragment (fragment offset is 685 zero), the proto/ctype in the GUE header MUST equal the orig- 686 proto value in the fragmentation option. For subsequent 687 fragments (fragment offset is non-zero) the proto/ctype in the 688 GUE header must be 0 for a control message or 59 (no-next-hdr) 689 for a data message. If the proto/ctype value is invalid for a 690 received packet it MUST be dropped. 692 An original packet is reassembled only from GUE fragment packets 693 that have the same outer source address, destination address, 694 UDP source port, UDP destination port, GUE header C-bit, group 695 identifier if present, orig-proto value in the fragmentation 696 option, and Fragment Identification. The protocol type or 697 control message type (depending on the C-bit) for the 698 reassembled packet is the value of the GUE header proto/ctype 699 field in the first fragment. 701 The following error conditions can arise when reassembling fragmented 702 packets with GUE encapsulation: 704 If insufficient fragments are received to complete reassembly of 705 a packet within 60 seconds (or a configurable period) of the 706 reception of the first-arriving fragment of that packet, 707 reassembly of that packet MUST be abandoned and all the 708 fragments that have been received for that packet MUST be 709 discarded. 711 If the payload length of a fragment is not a multiple of 8 712 octets and the M flag of that fragment is 1, then that fragment 713 MUST be discarded. 715 If the length and offset of a fragment are such that the payload 716 length of the packet reassembled from that fragment would exceed 717 65,535 octets, then that fragment MUST be discarded. 719 If a fragment overlaps another fragment already saved for 720 reassembly then the new fragment that overlaps the existing 721 fragment MUST be discarded. 723 If the first fragment is too small then it is possible that it does 724 not contain the necessary headers for a stateful firewall. Sending 725 small fragments like this has been used as an attack on IP 726 fragmentation. To mitigate this problem, an implementation SHOULD 727 ensure that the first fragment contains the headers of the 728 encapsulated packet at least through the transport header. 730 A GUE node MUST be able to accept a fragmented packet that, after 731 reassembly and decapsulation, is as large as 1500 octets. This means 732 that the node must configure a reassembly buffer that is at least as 733 large as 1500 octets plus the maximum-sized encapsulation headers 734 that may be inserted during encapsulation. Implementations may find 735 it more convenient and efficient to configure a reassembly buffer 736 size of 2KB which is large enough to accommodate even the largest set 737 of encapsulation headers and provides a natural memory page size 738 boundary. 740 5.6. Security Considerations 742 Exploits that have been identified with IP fragmentation are 743 conceptually applicable to GUE fragmentation. 745 Attacks on GUE fragmentation can be mitigated by: 747 o Hardened implementation that applies applicable techniques from 748 implementation of IP fragmentation. 750 o Application of GUE security (section 4) or IPsec [RFC4301]. 751 Security mechanisms can prevent spoofing of fragments from 752 unauthorized sources. 754 o Implement fragment filter techniques for GUE encapsulation as 755 described in [RFC1858] and [RFC3128]. 757 o Do not accept data in overlapping segments. 759 o Enforce a minimum size for the first fragment. 761 6. Payload transform option 763 The payload transform option indicates that the GUE payload has been 764 transformed. Transforming a payload is done by running a function 765 over the data and possibly modifying it (encrypting it for instance). 766 The payload transform option indicates the method used to transform 767 the data so that a decapsulator is able to validate and reverse the 768 transformation to recover the original data. Payload transformations 769 could include encryption, authentication, CRC coverage, and 770 compression. This specification defines a transformation for DTLS. 772 6.1. Extension field format 774 The presence of the GUE payload transform option is indicated by the 775 T bit in the GUE header. 777 The format of Payload Transform Field is: 779 0 1 2 3 780 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 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 | Type | P_C_type | Info | 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 The fields of the option are: 787 Type: Payload Transform Type or Code point. Each payload transform 788 mechanism must have one code point registered in IANA. This 789 document specifies: 791 0x01: for DTLS [RFC6347] 793 0x80~0xFF: for private payload transform types 795 A private payload transform type can be used for 796 experimental purposes or proprietary mechanisms. 798 P_C_type: Indicates the protocol or control type of the 799 untransformed payload. When payload transform option is 800 present, proto/ctype in the GUE header is set to 59 ("No 801 next header") for a data message and zero for a control 802 message. The IP protocol or control message type of the 803 untransformed payload MUST be encoded in this field. 805 The benefit of this rule is to prevent a middle box from 806 inspecting the encrypted payload according to GUE next 807 protocol. The assumption here is that a middle box may 808 understand GUE base header but does not understand GUE 809 option flag definitions. 811 Info: A field that can be set according to the requirements of 812 each payload transform type. If the specification for a 813 payload transform type does not specify how this field is to 814 be set, then the field MUST be set to zero. 816 6.2. Usage 818 The payload transform option provides a mechanism to transform or 819 interpret the payload of a GUE packet. The Type field provides the 820 method used to transform the payload, and the P_C_type field provides 821 the protocol or control message type of the of payload before being 822 transformed. The payload transformation option is generic so that it 823 can have both security related uses (such as DTLS) as well as non 824 security related uses (such as compression, CRC, etc.). 826 An encapsulator performs payload transformation before transmission, 827 and a decapsulator performs the reverse transformation before 828 accepting a packet. For example, if an encapsulator transforms a 829 payload by encrypting it, the peer decaspsulator MUST decrypt the 830 payload before accepting the packet. If a decapsulator fails to 831 perform the reverse transformation or cannot validate the 832 transformation it MUST discard the packet and MAY generate an alert 833 to the management system. 835 6.3. Interaction with other optional extensions 837 If GUE fragmentation (section 5) is used in concert with the GUE 838 transform option, the transform option processing is performed after 839 fragmentation at the encapsulator and before reassembly at the 840 decapsulator. If the payload transform changes the size of the data 841 being fragmented this must be taken into account during 842 fragmentation. 844 If both the security option and the payload transform are used in a 845 GUE packet, an encapsulator MUST perform the payload transformation 846 first, set the payload transform option in the GUE header, and then 847 create the security option. A decapsulator does processing in 848 reverse-- the security option is processed (GUE header is validated) 849 and then the reverse payload transform is performed. 851 In order to get flow entropy from the payload, an encapsulator should 852 derive the flow entropy before performing a payload transform. 854 6.4. DTLS transform 856 The payload of a GUE packet can be secured using Datagram Transport 857 Layer Security [RFC6347]. An encapsulator would apply DTLS to the GUE 858 payload so that the payload packets are encrypted and the GUE header 859 remains in plaintext. The payload transform option is set to indicate 860 that the payload is interpreted as a DTLS record. 862 The payload transform option for DTLS is: 864 0 1 2 3 865 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 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 | 1 | P_C_type | 0 | 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 DTLS [RFC6347] provides a packet fragmentation capability. To avoid 871 packet fragmentation being performed multiple times, a GUE 872 encapsulator SHOULD use GUE fragmentation and not DTLS fragmentation. 874 DTLS usage is limited to a single DTLS session for any specific 875 tunnel encapsulator/decapsulator pair (identified by source and 876 destination IP addresses). Both IP addresses MUST be unicast 877 addresses - multicast traffic is not supported when DTLS is used. A 878 GUE tunnel decapsulator implementation that supports DTLS can 879 establish DTLS sessions with one or multiple tunnel encapsulators, 880 and likewise a GUE tunnel encapsulator implementation can establish 881 DTLS sessions with one or multiple decapsulators. 883 7. Remote checksum offload option 885 Remote checksum offload is mechanism that provides checksum offload 886 of encapsulated packets using rudimentary offload capabilities found 887 in most Network Interface Card (NIC) devices. Many NIC 888 implementations can only offload the outer UDP checksum in UDP 889 encapsulation. Remote checksum offload is described in [UDPENCAP]. 891 In remote checksum offload the outer header checksum, that in the 892 outer UDP header, is enabled in packets and, with some additional 893 meta information, a receiver is able to deduce the checksum to be set 894 for an inner encapsulated packet. Effectively this offloads the 895 computation of the inner checksum. Enabling the outer checksum in 896 encapsulation has the additional advantage that it covers more of the 897 packet, including the encapsulation headers, than an inner checksum. 899 7.1. Extension field format 901 The presence of the GUE remote checksum offload option is indicated 902 by the R bit in the GUE header. 904 The format of remote checksum offload field is: 906 0 1 2 3 907 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 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 | Checksum start | Checksum offset | 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 The fields of the option are: 914 o Checksum start: starting offset for checksum computation 915 relative to the start of the encapsulated payload. This is 916 typically the offset of a transport header (e.g. UDP or TCP). 918 o Checksum offset: Offset relative to the start of the 919 encapsulated packet where the derived checksum value is to be 920 written. This typically is the offset of the checksum field in 921 the transport header (e.g. UDP or TCP). 923 7.2. Usage 925 7.2.1. Transmitter operation 927 The typical actions to set remote checksum offload on transmit are: 929 1) Transport layer creates a packet and indicates in internal 930 packet meta data that checksum is to be offloaded to the NIC 931 (normal transport layer processing for checksum offload). The 932 checksum field is populated with the bitwise not of the 933 checksum of the pseudo header or zero as appropriate. 935 2) Encapsulation layer adds its headers to the packet including 936 the remote checksum offload option. The start offset and 937 checksum offset are set accordingly. 939 3) Encapsulation layer arranges for checksum offload of the outer 940 header checksum (e.g. UDP). 942 4) Packet is sent to the NIC. The NIC will perform transmit 943 checksum offload and set the checksum field in the outer 944 header. The inner header and rest of the packet are transmitted 945 without modification. 947 7.2.2. Receiver operation 949 The typical actions a host receiver does to support remote checksum 950 offload are: 952 1) Receive packet and validate outer checksum following normal 953 processing (i.e. validate non-zero UDP checksum). 955 2) Validate the remote checksum option. If checksum start is 956 greater than the length of the packet, then the packet MUST be 957 dropped. If checksum offset is greater then the length of the 958 packet minus two, then the packet MUST be dropped. 960 3) Deduce full checksum for the IP packet. If a NIC is capable of 961 receive checksum offload it will return either the full 962 checksum of the received packet or an indication that the UDP 963 checksum is correct. Either of these methods can be used to 964 deduce the checksum over the IP packet [UDPENCAP]. 966 4) From the packet checksum, subtract the checksum computed from 967 the start of the packet (outer IP header) to the offset in the 968 packet indicted by checksum start in the meta data. The result 969 is the deduced checksum to set in the checksum field of the 970 encapsulated transport packet. 972 In pseudo code: 974 csum: initialized to checksum computed from start (outer IP 975 header) to the end of the packet 976 start_of_packet: address of start of packet 977 encap_payload_offset: relative to start_of_packet 978 csum_start: value from the checksum start field 979 checksum(start, len): function to compute checksum from start 980 address for len bytes 982 csum -= checksum(start_of_packet, encap_payload_offset + 983 csum_start) 985 5) Write the resultant checksum value into the packet at the 986 offset provided by checksum offset in the meta data. 988 In pseudo code: 990 csum_offset: value from the checksum offset field 992 *(start_of_packet + encap_payload_offset + 993 csum_offset) = csum 995 6) Checksum is verified at the transport layer using normal 996 processing. This should not require any checksum computation 997 over the packet since the complete checksum has already been 998 provided. 1000 7.3. Security Considerations 1002 Remote checksum offload allows a means to change the GUE payload 1003 before being received at a decapsulator. In order to prevent misuse 1004 of this mechanism, a decapsulator MUST apply security checks on the 1005 GUE payload only after checksum remote offload has been processed. 1007 8. Checksum option 1009 The GUE checksum option provides a checksum that covers the GUE 1010 header, a GUE pseudo header, and optionally all or part of the GUE 1011 payload. The GUE pseudo header includes the corresponding IP 1012 addresses as well as the UDP ports of the encapsulating headers. This 1013 checksum should provide protection against address corruption in IPv6 1014 when the UDP checksum is zero. Additionally, the GUE checksum 1015 provides protection of the GUE header when the UDP checksum is set to 1016 zero with either IPv4 or IPv6. In particular, the GUE checksum can 1017 provide protection for some sensitive data, such as the virtual 1018 network identifier ([I.D.hy-nvo3-gue-4-nvo]), which when corrupted 1019 could lead to mis-delivery of a packet to the wrong virtual network. 1021 8.1. Extension field format 1023 The presence of the GUE checksum option is indicated by the K bit in 1024 the GUE header. 1026 The format of the checksum extension is: 1028 0 1 2 3 1029 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 1030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1031 | Checksum | Payload coverage | 1032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1034 The fields of the option are: 1036 o Checksum: Computed checksum value. This checksum covers the GUE 1037 header (including fields and private data covered by Hlen), the 1038 GUE pseudo header, and optionally all or part of the payload 1039 (encapsulated packet). 1041 o Payload coverage: Number of bytes of payload to cover in the 1042 checksum. Zero indicates that the checksum only covers the GUE 1043 header and GUE pseudo header. If the value is greater than the 1044 encapsulated payload length, the packet MUST be dropped. 1046 8.2. Requirements 1048 The GUE header checksum SHOULD be set on transmit when using a zero 1049 UDP checksum with IPv6. 1051 The GUE header checksum SHOULD be used when the UDP checksum is zero 1052 for IPv4 if the GUE header includes data that when corrupted can lead 1053 to misdelivery or other serious consequences, and there is no other 1054 mechanism that provides protection (no security field that checks 1055 integrity for instance). 1057 The GUE header checksum SHOULD NOT be set when the UDP checksum is 1058 non-zero. In this case the UDP checksum provides adequate protection 1059 and this avoids convolutions when a packet traverses NAT that does 1060 address translation (in that case the UDP checksum is required). 1062 8.3. GUE checksum pseudo header 1064 The GUE pseudo header checksum is included in the GUE checksum to 1065 provide protection for the IP and UDP header elements which when 1066 corrupted could lead to misdelivery of the GUE packet. The GUE pseudo 1067 header checksum is similar to the standard IP pseudo header defined 1068 in [RFC0768] and [RFC0793] for IPv4, and in [RFC8200] for IPv6. 1070 The GUE pseudo header for IPv4 is: 1072 0 1 2 3 1073 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 1074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1075 | Source Address | 1076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1077 | Destination Address | 1078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1079 | Source port | Destination port | 1080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1081 The GUE pseudo header for IPv6 is: 1083 0 1 2 3 1084 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 1085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1086 | | 1087 + + 1088 | | 1089 + Source Address + 1090 | | 1091 + + 1092 | | 1093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1094 | | 1095 + + 1096 | | 1097 + Destination Address + 1098 | | 1099 + + 1100 | | 1101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1102 | Source port | Destination port | 1103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1105 The GUE pseudo header does not include payload length or protocol as 1106 in the standard IP pseudo headers. The length field is deemed 1107 unnecessary for inclusion because a corrupted length field should not 1108 cause mis-delivery, the GUE checksum is applied after GUE 1109 fragmentation, and without the length field the GUE pseudo header 1110 checksum is the same for all packets of flow. 1112 8.4. Usage 1114 The GUE checksum is computed and verified following the standard 1115 process for computing the Internet checksum [RFC1071]. Checksum 1116 computation may be optimized per the mathematical properties 1117 including parallel computation and incremental updates. 1119 8.4.1. Transmitter operation 1121 The procedure for setting the GUE checksum on transmit is: 1123 1) Create the GUE header including the checksum and payload 1124 coverage fields. The checksum field is initially set to zero. 1126 2) Calculate the 1's complement checksum of the GUE header from 1127 the start of the GUE header through the its length as indicated 1128 in GUE Hlen. 1130 3) Calculate the checksum of the GUE pseudo header for IPv4 or 1131 IPv6. 1133 4) Calculate checksum of payload portion if payload coverage is 1134 enabled (payload coverage field is non-zero). If the length of 1135 the payload coverage is odd, logically append a single zero 1136 byte for the purposes of checksum calculation. 1138 5) Add and fold the computed checksums for the GUE header, GUE 1139 pseudo header, and payload coverage. 1141 6) Set the bitwise not of the resultant value in the GUE checksum 1142 field. 1144 8.4.2. Receiver operation 1146 If the GUE checksum option is present, the receiver MUST validate the 1147 checksum before processing any other fields or accepting the packet. 1149 The procedure for verifying the checksum is: 1151 1) If the payload coverage length is greater than the length of 1152 the encapsulated payload then drop the packet. 1154 2) Calculate the checksum of the GUE header from the start of the 1155 header to the end as indicated by Hlen. 1157 3) Calculate the checksum of the appropriate GUE pseudo header. 1159 4) Calculate the checksum of payload if payload coverage is 1160 enabled (payload coverage is non-zero). If the length of the 1161 payload coverage is odd logically append a single zero byte for 1162 the purposes of checksum calculation. 1164 5) Sum the computed checksums for the GUE header, GUE pseudo 1165 header, and payload coverage. If the result is all 1 bits (-0 1166 in 1's complement arithmetic), the checksum is valid and the 1167 packet is accepted; otherwise the checksum is considered 1168 invalid and the packet MUST be dropped. 1170 8.5. Corrupted flags 1172 Note that the GUE checksum does not protect against the checksum flag 1173 (K flag) being corrupted. If an encapsulator sets the checksum flag 1174 and option but the K bit flips to be zero, then a decapsulator will 1175 incorrectly process the GUE packet as not having a checksum field. 1177 To mitigate this issue an encapsulator and depcapsulator might agree 1178 that checksum is always required. This agreement could be established 1179 by configuration or GUE capability negotiation. 1181 8.6. Security Considerations 1183 The checksum option is only a mechanism for corruption detection, it 1184 is not a security mechanism. To provide integrity checks or 1185 authentication of the GUE header, the GUE security option SHOULD be 1186 used. 1188 9. NAT checksum address option 1190 The NAT address checksum (NAC) option contains the checksum computed 1191 over the IP addresses of the packet. The computed value can be used 1192 by a receiver to adjust a transport layer checksum that was affected 1193 by NAT changing the IP addresses. This option is only useful when GUE 1194 encapsulates a transport layer packet that has a checksum with a 1195 pseudo header that includes the IP addresses (such as TCP or UDP). 1197 9.1. Extension field format 1199 The presence of the NAT checksum address option is indicated by the N 1200 bit in the GUE header. 1202 The format of the NAT checksum address extension is: 1204 0 1 2 3 1205 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 1206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1207 | Checksum | Reserved | 1208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1210 The fields of the option are: 1212 o Checksum: Computed checksum value. This checksum covers the 1213 outer IP addresses. 1215 o Reserved: Must be zero on transmit. 1217 9.2. Usage 1219 The NAT address extension SHOULD be set on transmit when 1220 encapsulating a transport layer packet whose checksum might be 1221 affected by NAT being performed on the outer IP header. If this 1222 option is used then the UDP checksum MUST be used (sent with non-zero 1223 value). 1225 The NAT address checksum is computed using the Internet checksum 1227 [RFC1071]. 1229 9.2.1. Transmitter operation 1231 The procedure for setting the GUE checksum on transmit is: 1233 An encapsulator computes the checksum value over the IP addresses in 1234 the IP header. 1236 1) Compute the ones complement checksum over the source and 1237 destination IPv4 or IPv6 addresses. 1239 2) Set the resultant value in the Checksum field. 1241 For IPv4 the checksum is computed over: 1243 0 1 2 3 1244 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 1245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1246 | Source Address | 1247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1248 | Destination Address | 1249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1251 For IPv6 the checksum is computed over: 1253 0 1 2 3 1254 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 1255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1256 | | 1257 + + 1258 | | 1259 + Source Address + 1260 | | 1261 + + 1262 | | 1263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1264 | | 1265 + + 1266 | | 1267 + Destination Address + 1268 | | 1269 + + 1270 | | 1271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1273 9.2.2. Receiver operation 1275 1) Validate the UDP checksum is correct 1277 2) Compute the checksum over the IP address in the received packet 1279 3) Subtract the resultant from the checksum value in the NAC 1280 option. If the difference is non-zero then NAT has changed the 1281 addresses 1283 4) When processing a transport layer containing a checksum 1284 affected by NAT on the IP addresses, add the difference into 1285 the checksum calculation when verify the packet. 1287 In pseudo codes this is: 1289 actual = checksum(IP addresses) 1290 diff = actual - NAC_value 1291 verify = checksum(transport packet) + checksum(pseudo header) 1292 + diff 1294 if (verify == 0) 1295 packet is good 1297 10. Alternative checksum option 1299 The alternative checksum option contains a check over the GUE header 1300 and optionally all or part of the GUE payload. The alternative 1301 checksum can provide stronger protection against data corruption than 1302 provided by the one's complement checksum used in the UDP checksum or 1303 the GUE checksum (section 8). 1305 The alternative checksum flags are two bits which allow three methods 1306 to be defined. This specification proposes three: two 16-bit CRC 1307 variants and a 32-bit CRC method. 1309 10.1. Extension field format 1311 The format of the alternate checksum option is: 1313 0 1 2 3 1314 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 1315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1316 | | 1317 ~ Alternate checksum ~ 1318 | | 1319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1320 The fields of the option are: 1322 o Alternate checksum (variable length). Contains the checksum 1323 information. 1325 The presence of the alternate checksum option is indicated by the ACS 1326 bits in the GUE header. 1328 The values in the ACS flags are: 1330 o 00b - No alternate checksum field 1332 o 01b - CRC-16-CCITT 1334 o 10b - CRC-16 1336 0 11b - CRC-32 1338 10.1.1. CRC-16-CCITT and CRC-16 alternate checksums 1340 CRC-16-CCITT and CRC-16 have the same alternative checksum field 1341 format. The format is: 1343 0 1 2 3 1344 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 1345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1346 | CRC | Payload coverage | 1347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1349 The fields of the option are: 1351 o CRC: Computed CRC value. This CRC covers the GUE header 1352 (including fields and private data covered by Hlen) and 1353 optionally all or part of the payload (encapsulated packet). 1355 o Payload coverage: Number of bytes of payload to cover in the CRC 1356 calculation. Zero indicates that the checksum only covers the 1357 GUE header. If the value is greater than the encapsulated 1358 payload length, the packet MUST be dropped. 1360 The 16-bit alternative checksums do not include a pseudo header 1361 containing IP addresses or ports. 1363 CRC-16-CCITT is calculated using the polynomial: 1365 x^16 + x^12 + x^5 + 1 (polynomial representation 0x1021). 1367 CRC-16 is calculated using the polynomial: 1369 x^16 + x^15 + x^2 + 1 (polynomial representation 0x8005). 1371 10.1.2. 32-bit CRC alternate checksum 1373 The format of the 32-bit CRC alternative checksum field is: 1375 0 1 2 3 1376 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 1377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1378 | Reserved | Payload coverage | 1379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1380 | CRC | 1381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1383 The fields of the option are: 1385 o CRC: Computed CRC value. This CRC covers the GUE header 1386 (including fields and private data covered by Hlen) and 1387 optionally all or part of the payload (encapsulated packet). 1389 o Payload coverage: Number of bytes of payload to cover in the CRC 1390 calculation. Zero indicates that the checksum only covers the 1391 GUE header. If the value is greater than the encapsulated 1392 payload length, the packet MUST be dropped. 1394 The 32-bit alternative checksum does not include a pseudo header 1395 containing IP addresses or ports. 1397 CRC-32 is calculated using the polynomial: 1399 x^32 + x^26 + x^23 + x^22 + x^16 + x^12 +x ^10 + x^2 + x^7 + x^5 + 1400 x^4 +x^2 + x + 1 (polynomial 0x04C11DB7). 1402 10.2. Usage 1404 The usage of the alternate checksum is the same for both the 16-bit 1405 CRC and the 32-bit CRC methods except that the output CRC values have 1406 different sizes. 1408 10.2.1. Transmitter operation 1410 The procedure for setting the GUE alternative checksum on transmit 1411 is: 1413 1) Create the GUE header including the alternative checksum field. 1414 The CRC field is initialized to zero. 1416 2) Calculate the alternative checksum (either a 16-bit or 32-bit 1417 CRC) from the start of the GUE header through the its length as 1418 indicated in GUE Hlen. 1420 3) Continue the calculation to cover the payload portion if 1421 payload coverage is enabled (payload coverage field is non- 1422 zero). If the length of the payload coverage is not aligned per 1423 the algorithm (four bytes for CRC-32 and two bytes for CRC-16), 1424 logically append zero bytes up to the necessary alignment for 1425 the purposes of CRC calculation. 1427 4) Set the resultant value in the CRC field. 1429 10.2.2. Receiver operation 1431 If the GUE alternative checksum option is present, the receiver MUST 1432 validate the checksum before processing any other fields or accepting 1433 the packet. 1435 The procedure for verifying the alternate checksum is: 1437 1) If the payload coverage length is greater than the length of 1438 the encapsulated payload then drop the packet. 1440 2) Note value in the CRC field and set the CRC field to zero. 1442 3) Calculate the alternative checksum (either a 16-bit or 32-bit 1443 CRC) from the start of the GUE header through the its length as 1444 indicated in GUE Hlen. 1446 4) Continue the calculation to cover the payload portion if 1447 payload coverage is enabled (payload coverage field is non- 1448 zero). If the length of the payload coverage is not aligned per 1449 the algorithm (four bytes for CRC-32 and two bytes for CRC-16), 1450 logically append zero bytes up to the necessary alignment for 1451 the purposes of CRC calculation. 1453 5) Compare the computed value with the original value of the CRC 1454 field. If they are equal then that packet is accepted, if they 1455 are not equal then verification failed and the packet MUST be 1456 dropped. 1458 6) Restore the CRC field to its original value. 1460 10.3. Corrupted flags 1462 Similar to GUE checksum properties, the GUE alternate checksum does 1463 not protect against the alternative checksum flags (ACS flags) being 1464 corrupted. If an encapsulator sets the alternative checksum flags and 1465 option but the ACS bits flips to be zero, then a decapsulator will 1466 incorrectly process that packet as not having an alternate checksum 1467 field. 1469 To mitigate this issue an encapsulator and depcapsulator might agree 1470 that an alternate checksum is always required. This agreement could 1471 be established by configuration or GUE capability negotiation. 1473 10.4. Security Considerations 1475 The alternate checksum option is only a mechanism for corruption 1476 detection, it is not a security mechanism. To provide integrity 1477 checks or authentication of the GUE header, the GUE security option 1478 SHOULD be used. 1480 11. Processing order of options 1482 Options MUST be processed in a specific order for both transmission 1483 and reception. Note that some options, such as the checksum option, 1484 depend on other fields in the GUE header to be initialized. 1486 11.1. Processing order when sending 1488 When setting the security option (HMAC option in particular), the 1489 checksum option, and the alternate checksum option-- all the GUE 1490 fields being used must be present and properly set in the header. The 1491 checksum value in the checksum option or alternate checksum option 1492 MUST be initialized to zero to ensure consistent HMAC and checksum 1493 calculation. 1495 The order of processing options to send a GUE packet are: 1497 1) Fragment if necessary and set fragmentation option. If the 1498 group identifier is present it is copied into each fragment. If 1499 payload transformation will increase the size of the payload 1500 that MUST be accounted for when deciding how to fragment. Apply 1501 processing below for each fragment 1503 2) Set group identifier option (to the same value for each 1504 fragment) 1506 3) Perform payload transform (potentially on a fragment) and set 1507 payload transform option. 1509 4) Set Remote checksum offload. 1511 5) Set NAT address checksum option. 1513 6) Set security option per cookie or HMAC calculation. 1515 7) Calculate GUE checksum and set checksum option. 1517 8) Calculate GUE alternate checksum and set the alternate checksum 1518 option. 1520 11.2. Processing order when receiving 1522 On reception the order of actions is: 1524 1) Verifiy GUE alternate checksum. 1526 2) Verify GUE checksum. If the alternate checksum option is 1527 present, set its checksum fields to zero for computing the GUE 1528 checksum. After computation, restore the checksum value in the 1529 alternate checksum field. 1531 3) Verify security option. If the GUE checksum option or alternate 1532 checksum option are also present and HMAC computation is being 1533 done over the GUE header, then set the checksum fields to zero 1534 for computing the HMAC. After computation, restore the checksum 1535 values. 1537 4) Save the NAT address checksum value. It will be applied when 1538 processing the encapsulated packet. 1540 5) Adjust packet for remote checksum offload. 1542 6) Perform payload transformation (i.e. decrypt payload). 1544 7) Perform reassembly. 1546 8) Process packet (take group identifier into account if present). 1548 The relative processing order of GUE extensions and private fields is 1549 unspecified in this specification. 1551 12. Security Considerations 1553 Encapsulation of a network protocol in GUE should not increase 1554 security risk, nor provide additional security in itself. GUE 1555 requires that the source port for UDP packets SHOULD be randomly 1556 seeded to mitigate some possible denial service attacks. 1558 If the integrity and privacy of data packets being transported 1559 through GUE is a concern, GUE security option and payload encryption 1560 using the the transform option SHOULD be used to remove the concern. 1562 If the integrity is the only concern, the tunnel may consider use of 1563 GUE security only for optimization. Likewise, if privacy is the only 1564 concern, the tunnel may use GUE encryption function only. 1566 If GUE payload already provides secure mechanism, e.g., the payload 1567 is IPsec packets, it is still valuable to consider use of GUE 1568 security. 1570 GUE may rely on other secure tunnel mechanisms such as DTLS [RFC6347] 1571 over the whole UDP payload for securing the whole GUE packet or IPsec 1572 [RFC4301] to achieve the secure transport over an IP network or 1573 Internet. 1575 IPsec [RFC4301] was designed as a network security mechanism, and 1576 therefore it resides at the network layer. As such, if the tunnel is 1577 secured with IPsec, the UDP header would not be visible to 1578 intermediate routers in either IPsec tunnel or transport mode. This 1579 is a drawback since it prohibits intermediate routers to perform load 1580 balancing based on the flow entropy in UDP header. In addition, this 1581 method prohibits any middle box function on the path. 1583 By comparison, DTLS [RFC6347] was designed for application level 1584 security and can better preserve network and transport layer protocol 1585 information than IPsec [RFC4301]. Using DTLS over UDP to secure the 1586 GUE tunnel, both GUE header and payload will be encrypted. In order 1587 to differentiate plaintext GUE header from encrypted GUE header, the 1588 destination port of the UDP header between two must be different, 1589 which essentially requires another standard UDP port for GUE with 1590 DTLS. The drawback on this method is to prevent a middle box 1591 operation to GUE tunnel on the path. 1593 Use of two independent tunnel mechanisms such as GUE and DTLS over 1594 UDP to carry a network protocol over an IP network adds some overlap 1595 and complexity. For example, fragmentation will be done twice. 1597 As the result, a GUE tunnel SHOULD use the security mechanisms 1598 specified in this document to provide secure transport over an IP 1599 network or Internet when it is needed. GUE encapsulation can be used 1600 as a secure transport mechanism over an IP network and Internet. 1602 13. IANA Consideration 1604 IANA is requested to assign flags for the extensions defined in this 1605 specification. Specifically, an assignment is requested for the Group 1606 Identfier, Security, Fragmentation, Payload Transform, Remote 1607 Checksum Offload, Checksum, NAT Checksum, and Alternate Checksum 1608 extensions in the "GUE flag-fields" registry. 1610 +-------------+---------------+-------------+--------------------+ 1611 | Flags bits | Field size | Description | Reference | 1612 +-------------+---------------+-------------+--------------------+ 1613 | Bit 0 | 4 bytes | Group | This document | 1614 | | | identifier | | 1615 | | | | | 1616 | Bit 1..3 | 001->8 bytes | Security | This document | 1617 | | 010->16 bytes | | | 1618 | | 011->32 bytes | | | 1619 | | 100->40 bytes | | | 1620 | | | | | 1621 | Bit 4 | 8 bytes | Fragmen- | This document | 1622 | | | tation | | 1623 | | | | | 1624 | Bit 5 | 4 bytes | Payload | This document | 1625 | | | transform | | 1626 | | | | | 1627 | Bit 6 | 4 bytes | Remote | This document | 1628 | | | checksum | | 1629 | | | offload | | 1630 | | | | | 1631 | Bit 7 | 4 bytes | Checksum | This document | 1632 | | | | | 1633 | Bit 8 | 4 bytes | NAT | This document | 1634 | | | checksum | | 1635 | | | address | | 1636 | | | | | 1637 | Bit 9..10 | 01->4 bytes | Alternate | This document | 1638 | | 10->8 bytes | checksum | | 1639 | | | | | 1640 | Bit 11..15 | | Unassigned | | 1641 +-------------+---------------+-------------+--------------------+ 1643 IANA is requested to set up a registry for the GUE payload transform 1644 types. Payload transform types are 8 bit values. New values for 1645 control types 1-127 are assigned via Standards Action [RFC5226]. 1647 +----------------+------------------+---------------+ 1648 | Transform type | Description | Reference | 1649 +----------------+------------------+---------------+ 1650 | 0 | Reserved | This document | 1651 | | | | 1652 | 1 | DTLS | This document | 1653 | | | | 1654 | 2..127 | Unassigned | | 1655 | | | | 1656 | 128..255 | User defined | This document | 1657 +----------------+------------------+---------------+ 1659 14. References 1661 14.1. Normative References 1663 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1664 1981. 1666 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1667 (IPv6) Specification", STD 86, RFC 8200, DOI 1668 10.17487/RFC8200, July 2017, . 1671 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 1672 Communication Layers", STD 3, RFC 1122, October 1989. 1674 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1675 August 1980. 1677 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1678 IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 1679 10.17487/RFC5226, May 2008, . 1682 [I.D.ietf-gue] T. Herbert, L. Yong, and O. Zia, "Generic UDP 1683 Encapsulation" draft-ietf-intarea-gue-01 1685 14.2. Informative References 1687 [RFC3931] Lau, J., Townsley, W., et al, "Layer Two Tunneling Protocol 1688 - Version 3 (L2TPv3)", RFC3931, 1999 1690 [RFC2104] Kent, S. and R. Atkinson, "Security Architecture for the 1691 Internet Protocol" , RFC 2401, DOI 10.17487/RFC2401, 1692 November 1998, . 1694 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain of 1695 Interpretation" , RFC 6407, DOI 10.17487/RFC6407, October 1696 2011, . 1698 [RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the- 1699 Network Tunneling", RFC 4459, DOI 10.17487/RFC4459, April 1700 2006, . 1702 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 1703 Errors at High Data Rates", RFC 4963, DOI 10.17487/RFC4963, 1704 July 2007, . 1706 [RFC2764] B. Gleeson, A. Lin, J. Heinanen, G. Armitage, A. Malis, "A 1707 Framework for IP Based Virtual Private Networks", RFC2764, 1708 February 2000. 1710 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1711 Internet Protocol", RFC 4301, December 2005. 1713 [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security 1714 Considerations for IP Fragment Filtering", RFC 1858, 1715 October 1995. 1717 [RFC3128] Miller, I., "Protection Against a Variant of the Tiny 1718 Fragment Attack (RFC 1858)", RFC 3128, June 2001. 1720 [RFC6347] Rescoria, E., Modadugu, N., "Datagram Transport Layer 1721 Security Version 1.2", RFC6347, 2012. 1723 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 1724 793, DOI 10.17487/RFC0793, September 1981, . 1727 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 1728 for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 1729 6936, DOI 10.17487/RFC6936, April 2013, . 1732 [RFC1071] Braden, R., Borman, D., and C. Partridge, "Computing the 1733 Internet checksum", RFC1071, September 1988. 1735 [I.D.hy-nvo3-gue-4-nvo] Yong, L., Herbert, T., "Generic UDP 1736 Encapsulation (GUE) for Network Virtualization Overlay" 1737 draft-hy-nvo3-gue-4-nvo-03 1739 [I.D.previdi-6man-sr-header] Previdi S. et al, "IPv6 Segment Routing 1740 Header (SRH) draft-ietf-6man-segment-routing-header-02 1742 [I.D.templin-aerolink] F. Templin, "Transmission of IP Packets over 1743 AERO Links" draft-templin-aerolink-62 1745 [UDPENCAP] T. Herbert, "UDP Encapsulation in Linux", 1746 http://people.netfilter.org/pablo/netdev0.1/papers/UDP- 1747 Encapsulation-in-Linux.pdf 1749 [FIPS180-4] Secure Hash Standard (SHS), Nation Institute of Standards 1750 and Technology, 8/2015 1752 Authors' Addresses 1754 Tom Herbert 1755 Quantonium 1756 4701 Patrick Henry Dr. 1757 Santa Clara, CA 1758 USA 1760 EMail: tom@herbertland.com 1762 Lucy Yong 1763 Huawei USA 1764 5340 Legacy Dr. 1765 Plano, TX 75024 1766 USA 1768 Email: lucy.yong@huawei.com 1770 Fred L. Templin 1771 Boeing Research & Technology 1772 P.O. Box 3707 1773 Seattle, WA 98124 1774 USA 1776 Email: fltemplin@acm.org