idnits 2.17.1 draft-ietf-intarea-gue-extensions-04.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 198: '... SHOULD be set to protocol numb...' RFC 2119 keyword, line 260: '...termediate nodes MAY apply semantics t...' RFC 2119 keyword, line 292: '...y, the SEC flags MUST be set. Differen...' RFC 2119 keyword, line 319: '...s present in packet, the receiver MUST...' RFC 2119 keyword, line 323: '... MUST drop the packet as failing sec...' (51 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 27, 2018) is 2193 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 1701, but no explicit reference was found in the text == Unused Reference: 'RFC6936' is defined on line 1757, 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: September 28, 2018 L. Yong 5 Huawei 6 F. Templin 7 Boeing 9 March 27, 2018 11 Extensions for Generic UDP Encapsulation 12 draft-ietf-intarea-gue-extensions-04 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.1. Extension field format . . . . . . . . . . . . . . . . 9 67 4.3.1. Operation . . . . . . . . . . . . . . . . . . . . . . . 8 68 4.3.1.1. Transmitter operation . . . . . . . . . . . . . . . 8 69 4.3.1.2. Receiver operation . . . . . . . . . . . . . . . . 9 70 4.4. HMAC . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 4.4.1. Extension field format . . . . . . . . . . . . . . . . 9 72 4.4.2. Selecting a hash algorithm . . . . . . . . . . . . . . 10 73 4.4.3. Pre-shared key management . . . . . . . . . . . . . . . 10 74 4.4.4. Operation . . . . . . . . . . . . . . . . . . . . . . . 11 75 4.4.4.1. Transmitter operation . . . . . . . . . . . . . . . 11 76 4.4.4.2. Receiver operation . . . . . . . . . . . . . . . . 11 77 4.5. Interaction with other optional extensions . . . . . . . . 12 78 5. Fragmentation option . . . . . . . . . . . . . . . . . . . . . 12 79 5.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 13 80 5.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 14 81 5.3. Extension field format . . . . . . . . . . . . . . . . . . 14 82 5.4. Fragmentation procedure . . . . . . . . . . . . . . . . . 15 83 5.5. Reassembly procedure . . . . . . . . . . . . . . . . . . . 17 84 5.6. Security Considerations . . . . . . . . . . . . . . . . . 19 85 6. Payload transform option . . . . . . . . . . . . . . . . . . . 19 86 6.1. Extension field format . . . . . . . . . . . . . . . . . . 19 87 6.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 20 88 6.3. Interaction with other optional extensions . . . . . . . . 21 89 6.4. DTLS transform . . . . . . . . . . . . . . . . . . . . . . 21 90 7. Remote checksum offload option . . . . . . . . . . . . . . . . 22 91 7.1. Extension field format . . . . . . . . . . . . . . . . . . 22 92 7.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 22 93 7.2.1. Transmitter operation . . . . . . . . . . . . . . . . . 22 94 7.2.2. Receiver operation . . . . . . . . . . . . . . . . . . 23 95 7.3. Security Considerations . . . . . . . . . . . . . . . . . 24 96 8. Checksum option . . . . . . . . . . . . . . . . . . . . . . . 24 97 8.1. Extension field format . . . . . . . . . . . . . . . . . . 24 98 8.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 25 99 8.3. GUE checksum pseudo header . . . . . . . . . . . . . . . . 25 100 8.4. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 26 101 8.4.1. Transmitter operation . . . . . . . . . . . . . . . . . 27 102 8.4.2. Receiver operation . . . . . . . . . . . . . . . . . . 27 103 8.5. Corrupted flags . . . . . . . . . . . . . . . . . . . . . 28 104 8.6. Security Considerations . . . . . . . . . . . . . . . . . 28 105 9. NAT checksum address option . . . . . . . . . . . . . . . . . 28 106 9.1. Extension field format . . . . . . . . . . . . . . . . . . 28 107 9.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 29 108 9.2.1. Transmitter operation . . . . . . . . . . . . . . . . . 29 109 9.2.2. Receiver operation . . . . . . . . . . . . . . . . . . 30 110 10. Alternative checksum option . . . . . . . . . . . . . . . . . 30 111 10.1. Extension field format . . . . . . . . . . . . . . . . . . 31 112 10.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 31 113 10.2.2. Receiver operation . . . . . . . . . . . . . . . . . . 32 114 10.3. Corrupted flags . . . . . . . . . . . . . . . . . . . . . 32 115 10.4. Security Considerations . . . . . . . . . . . . . . . . . 33 116 11. Processing order of options . . . . . . . . . . . . . . . . . 33 117 11.1. Processing order when sending . . . . . . . . . . . . . . 33 118 11.2. Processing order when receiving . . . . . . . . . . . . . 34 119 12. Security Considerations . . . . . . . . . . . . . . . . . . . 34 120 13. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 35 121 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 122 14.1. Normative References . . . . . . . . . . . . . . . . . . . 37 123 14.2. Informative References . . . . . . . . . . . . . . . . . . 37 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 126 1. Introduction 128 Generic UDP Encapsulation (GUE) [I.D.ietf-gue] is a generic and 129 extensible encapsulation protocol. This specification defines a 130 fundamental set of optional extensions for variant 0 of GUE. These 131 extensions are the group identifier, security, fragmentation, payload 132 transform, remote checksum offload, checksum, NAT address checksum, 133 and alternate checksum. 135 2. GUE header format with optional extensions 137 The format of a variant 0 GUE header with optional extensions is: 139 0 1 2 3 140 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 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ 142 | Source port | Destination port | | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP 144 | Length | Checksum | | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ 146 | 0 |C| Hlen | Proto/ctype |G| SEC |F|T|R|K|N|A| Rsvd | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | Group identifier (optional) | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | | 151 ~ Security (optional) ~ 152 | | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | | 155 + Fragmentation (optional) + 156 | | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Payload transform (optional) | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | Remote checksum offload (optional) | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Checksum (optional) | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | NAT Address Checksum (optional) | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | | 167 + Alternate checksum (optional) + 168 | | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | | 171 ~ Private data (optional) ~ 172 | | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 The contents of the UDP header are described in [I.D.ietf-gue]. 176 The GUE header consists of: 178 o Variant: Set to 0 to indicate GUE encapsulation header. Note 179 that variant 1 (direct IP encapsulation) does not allow options. 181 o C: C-bit. Indicates the GUE payload is a control message when 182 set, a data message when not set. GUE optional extensions can be 183 used with either control or data messages unless otherwise 184 specified in the extension definition. 186 o Hlen: Length in 32-bit words of the GUE header, including 187 optional extension fields and private data but not the first 188 four bytes of the header. Computed as (header_len - 4) / 4. The 189 length of the encapsulated packet is determined from the UDP 190 length and the Hlen: encapsulated_packet_length = UDP_Length - 191 12 - 4 * Hlen. 193 o Proto/ctype: If the C-bit is not set this indicates IP protocol 194 number for the packet in the payload; if the C bit is set this 195 is the type of control message in the payload. The next header 196 begins at the offset provided by Hlen. When the payload 197 transform option or fragmentation option is used this field 198 SHOULD be set to protocol number 59 for a data message, or zero 199 for a control message, to indicate no next header for the 200 payload. 202 o G: Indicates the the group identifier extension field is 203 present. The group identifier option is described in section 3. 205 o SEC: Indicates security extension field is present. The security 206 option is described in section 4. 208 o F: Indicates fragmentation extension field is present. The 209 fragmentation option is described in section 5. 211 o T: Indicates payload transform extension field is present. The 212 payload transform option is described in section 6. 214 o R: Indicates the remote checksum extension field is present. The 215 remote checksum offload option is described in section 7. 217 o K: Indicates checksum extension field is present. The checksum 218 option is described in section 8. 220 o N: Indicates NAT address checksum field is present. The NAT 221 address checksum option is described in section 9. 223 o A: Indicates alternative checksum field is present. The 224 alternative checksum option is described in section 10. 226 o Private data is described in [I.D.ietf-gue]. 228 3. Group identifier option 230 A group identifier classifies packets that logically belong to the 231 same group. Groups are arbitrarily defined for different purposes and 232 their definition is shared between the communicating end nodes. 234 3.1. Extension field format 236 The presence of the GUE group identifier option is indicated in the G 237 flag bit of the GUE header. 239 The format of the group identifier option is: 241 0 1 2 3 242 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 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Group identifier | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 The fields of the option are: 249 o Group identifier: Identifier value of a group. 251 3.2. Usage 253 The group identifier is set by an encapsulator to indicate that a 254 packet belongs to a group. Groups may be arbitrarily defined to 255 classify packets. Specific use cases of the group identifier may be 256 defined in other documents ([I.D.hy-nvo3-gue-4-nvo] defines a use of 257 this field to contain a virtual networking identifier for 258 implementing network virtualization). 260 Intermediate nodes MAY apply semantics to group identifiers if group 261 identifier information is shared and made global within a network. 262 For instance, a firewall could block packets based on a group 263 identifier that serves as a virtual identifier for a tenant. 265 4. Security option 267 The GUE security option provides origin authentication and integrity 268 protection of the GUE header at tunnel end points to guarantee 269 isolation between tunnels and mitigate Denial of Service attacks. 271 4.1. Extension field format 273 The presence of the GUE security option is indicated in the SEC flag 274 bits of the GUE header. 276 The format of the security option is: 278 0 1 2 3 279 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 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | | 282 ~ Security ~ 283 | | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 The fields of the option are: 288 o Security (variable length). Contains the security information. 289 The specific semantics and format of this field are expected to 290 be negotiated between the two communicating nodes. 292 To provide security capability, the SEC flags MUST be set. Different 293 field sizes allow different methods and extensibility. The use of the 294 security field is expected to be negotiated out of band between two 295 tunnel end points. 297 The values in the SEC flags are: 299 o 000b - No security field 301 o 001b - 64 bit security field 303 o 010b - 128 bit security field 305 o 011b - 256 bit security field 307 o 100b - 320 bit security field (HMAC) 309 o 101b, 110b, 111b - Reserved values 311 4.2. Usage 313 The GUE security option is used to provide integrity and 314 authentication of the GUE header. Security parameters (interpretation 315 of security field, key management, etc.) are expected to be 316 negotiated out of band between two communicating hosts. Two security 317 algorithms are defined below. 319 If the GUE security option is present in packet, the receiver MUST 320 validate the security before processing other fields or accepting the 321 packet. If the security option is not present but the encapsulator 322 and decapsulator have agreed that security is required, the receiver 323 MUST drop the packet as failing security checks. Note that this 324 provision covers the case where the security flags bits are corrupted 325 such that they are reset to zero which would be interpreted as no 326 security field being present. 328 4.3. Cookies 330 The security field may be used as a cookie. This would be similar to 331 the cookie mechanism described in L2TP [RFC3931], and the general 332 properties should be the same. A cookie MAY be used to validate the 333 encapsulation. A cookie is a shared value between an encapsulator and 334 decapsulator which SHOULD be chosen randomly and MAY be changed 335 periodically. Different cookies MAY be used for logical flows between 336 the encapsulator and decapsulator; for instance packets sent with 337 different VNIs in network virtualization [I.D.hy-nvo3-gue-4-nvo] 338 might have different cookies. Cookies can be 64, 128, or 256 bits in 339 size. 341 4.4.1. Extension field format 343 The cookie security option is a 64, 128, or 256 bit field. The 344 security flags are set to 001b, 010b, 011b respectively for the 345 corresponding field size. 347 The format of the field is: 349 0 1 2 3 350 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 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | | 353 ~ Cookie ~ 354 | | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 Fields are: 359 o Cookie: Shared cookie value between encapsulator and 360 decapsulator 362 4.3.1. Operation 364 4.3.1.1. Transmitter operation 366 The procedure for setting the GUE security cookie option on transmit 367 is: 369 1) Create the GUE header including the security field with the 370 selected length for the cookie. Set the cookie to the value 371 that is shared with decapsulator. 373 4.3.1.2. Receiver operation 375 The procedure for verifying the security cookie is: 377 1) Compare the received cookie to the expected shared cookie. If 378 both the lengths are equal and the cookie values are equal then 379 that packet is accepted, if the lengths or values are not equal 380 then verification failed and the packet MUST be dropped. 382 4.4. HMAC 384 Key-hashed message authentication code (HMAC) is a strong method of 385 checking integrity and authentication of data. This sections defines 386 a GUE security option for HMAC. Note that this is based on the HMAC 387 TLV description in "IPv6 Segment Routing Header (SRH)" [I.D.previdi- 388 6man-sr-header]. 390 4.4.1. Extension field format 392 The HMAC option is a 320 bit field (40 octets). The security flags 393 are set to 100b to indicate the presence of a 320 bit security field. 395 The format of the field is: 397 0 1 2 3 398 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 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | HMAC Key-id | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Payload offset | Payload length | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | | 405 ~ HMAC (256 bits) ~ 406 | | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 Fields are: 411 o HMAC Key-id: opaque field to allow multiple hash algorithms or 412 key selection 414 o Payload offset: offset in payload that indicates the first octet 415 of payload data included in the HMAC. 417 o Payload length: length of payload data starting from the payload 418 offset to be included in the HMAC calculation. Zero 419 indicates no payload data in used in the 420 calculation. 422 o HMAC: Output of HMAC computation 424 The HMAC field is the output of the HMAC computation (per [RFC2104]) 425 using a pre-shared key identified by HMAC Key-id and of the text 426 which consists of the concatenation of: 428 o The IP addresses 430 o The GUE header including all optional extensions. For the 431 purposes of calculating the HMAC value, the HMAC value is set 432 all zeroes. 434 o Optionally some or all of GUE payload. The portion of payload 435 covered is indicated by an offset into the payload and a length 436 relative to the offset. 438 The purpose of the HMAC option is to verify the validity, the 439 integrity and the authentication of the GUE header itself and 440 optionally some or all of the GUE payload. 442 The HMAC Key-id field allows for the simultaneous existence of 443 several hash algorithms (SHA-256, SHA3-256 ... or future ones) as 444 well as pre-shared keys. The HMAC Key-id field is opaque, i.e., it 445 has neither syntax nor semantic. Having an HMAC Key-id field allows 446 for pre-shared key roll-over when two pre-shared keys are supported 447 for a while when GUE endpoints converge to a fresher pre-shared key. 449 4.4.2. Selecting a hash algorithm 451 The HMAC field in the HMAC option is 256 bit wide. Therefore, the 452 HMAC MUST be based on a hash function whose output is at least 256 453 bits. If the output of the hash function is 256 bits, then this 454 output is simply inserted in the HMAC field. If the output of the 455 hash function is larger than 256 bits, then the output value is 456 truncated to 256 bits by taking the least-significant 256 bits and 457 inserting them in the HMAC field. 459 GUE implementations can support multiple hash functions but MUST 460 implement SHA-2 [FIPS180-4] in its SHA-256 variant. 462 4.4.3. Pre-shared key management 463 The field HMAC Key-id allows for: 465 o Key roll-over: when there is a need to change the key (the hash 466 pre-shared secret), then multiple pre-shared keys can be used 467 simultaneously. A decapsulator can have a table of for the currently active and future keys. 470 o Different algorithms: by extending the previous table to , the decapsulator can 472 also support simultaneously several hash algorithms 474 The pre-shared secret distribution can be done: 476 o In the configuration of the endpoints 478 o Dynamically using a trusted key distribution such as [RFC6407] 480 4.4.4. Operation 482 4.4.4.1. Transmitter operation 484 The procedure for setting the GUE HMAC option on transmit is: 486 1) Create the GUE header including the 320 bit security field to 487 hold the HMAC option. Set the HMAC Key-Id, payload length, and 488 payload offset appropriately. The 16 byte HMAC field is 489 initialized to zero. 491 2) Calculate the HMAC hash over the concatenation of the IP source 492 and destination addresses. The particular hash and keys are 493 agreed between the encpasulator and decapsulator out of band, 494 and the key for input to the hash is the one indicated by the 495 Key-Id amongst the set of shared keys. 497 3) Continue the the HMAC hash calculation from the start of the 498 GUE header through the its length as indicated in GUE Hlen. 500 4) Continue the calculation to cover the payload portion if 501 payload coverage is enabled (payload coverage field is non- 502 zero). The calculation continues at the payload offset for 503 payload length bytes. 505 5) Set the resultant hash value in the HMAC field. 507 4.4.4.2. Receiver operation 509 The procedure for verifying the HMAC security option is: 511 1) If the payload offset plus the payload coverage length is 512 greater than the length of the encapsulated payload then drop 513 the packet. 515 2) Note value in the HMAC field and set the HMAC field to zero. 517 3) Calculate the HMAC hash over the concatenation of the IP source 518 and destination addresses. The particular hash and keys are 519 agreed between the encpasulator and decapsulator out of band, 520 and the key for input to the hash is the one indicated by the 521 Key-Id amongst the set of shared keys. 523 4) Continue the the HMAC hash calculation from the start of the 524 GUE header through the its length as indicated in GUE Hlen. 526 5) Continue the calculation to cover the payload portion if 527 payload coverage is enabled (payload length field is non-zero). 528 The calculation continues at the payload offset for payload 529 length bytes. 531 6) Compare the computed HMAC value with the original value of the 532 HMAC field. If they are equal then the packet is accepted, if 533 they are not equal then verification failed and the packet MUST 534 be dropped. 536 7) Restore the HMAC field to its original value. 538 4.5. Interaction with other optional extensions 540 If GUE fragmentation (section 5) is used in concert with the GUE 541 security option, the security option processing is performed after 542 fragmentation at the encapsulator and before reassembly at the 543 decapsulator. 545 The GUE payload transform option (section 6) may be used in concert 546 with the GUE security option. The payload transform option could be 547 used to encrypt the GUE payload to provide privacy for an 548 encapsulated packet during transit. The security option provides 549 authentication and integrity for the GUE header (including the 550 payload transform field in the header). The two functions are 551 processed separately at tunnel end points. A GUE tunnel can use both 552 functions or use one of them. Section 6.3 details handling when both 553 are used in a packet. 555 5. Fragmentation option 557 The fragmentation option allows an encapsulator to perform 558 fragmentation of packets being ingress to a tunnel. Procedures for 559 fragmentation and reassembly are defined in this section. This 560 specification adapts the procedures for IP fragmentation and 561 reassembly described in [RFC0791] and [RFC8200]. Fragmentation can be 562 performed on both data and control messages in GUE. 564 5.1. Motivation 566 This section describes the motivation for having a fragmentation 567 option in GUE. 569 MTU and fragmentation issues with In-the-Network Tunneling are 570 described in [RFC4459]. Considerations need to be made when a packet 571 is received at a tunnel ingress point which may be too large to 572 traverse the path between tunnel endpoints. 574 There are four suggested alternatives in [RFC4459] to deal with this: 576 1) Fragmentation and Reassembly by the Tunnel Endpoints 578 2) Signaling the Lower MTU to the Sources 580 3) Encapsulate Only When There is Free MTU 582 4) Fragmentation of the Inner Packet 584 Many tunneling protocol implementations have assumed that 585 fragmentation should be avoided, and in particular alternative #3 586 seems preferred for deployment. In this case, it is assumed that an 587 operator can configure the MTUs of links in the paths of tunnels to 588 ensure that they are large enough to accommodate any packets and 589 required encapsulation overhead. This method, however, may not be 590 feasible in certain deployments and may be prone to misconfiguration 591 in others. 593 Similarly, the other alternatives have drawbacks that are described 594 in [RFC4459]. Alternative #2 implies use of something like Path MTU 595 Discovery which is not known to be sufficiently reliable. Alternative 596 #4 is not permissible with IPv6 or when the DF bit is set for IPv4, 597 and it also introduces other known issues with IP fragmentation. 599 For alternative #1, fragmentation and reassembly at the tunnel 600 endpoints, there are two possibilities: encapsulate the large packet 601 and then perform IP fragmentation, or segment the packet and then 602 encapsulate each segment (a non-IP fragmentation approach). 604 Performing IP fragmentation on an encapsulated packet has the same 605 issues as that of normal IP fragmentation. Most significant of these 606 is that the Identification field is only sixteen bits in IPv4 which 607 introduces problems with wraparound as described in [RFC4963]. 609 The second possibility of alternative #1 follows the suggestion 610 expressed in [RFC2764] and the fragmentation feature described in the 611 AERO protocol [I.D.templin-aerolink]; that is for the tunneling 612 protocol itself to incorporate a segmentation and reassembly 613 capability. In this method, fragmentation is part of the 614 encapsulation and an encapsulation header contains the information 615 for reassembly. This differs from IP fragmentation in that the IP 616 headers of the original packet are not replicated for each fragment. 618 Incorporating fragmentation into the encapsulation protocol has some 619 advantages: 621 o At least a 32 bit identifier can be defined to avoid issues of 622 the 16 bit Identification in IPv4. 624 o Encapsulation mechanisms for security and identification, such 625 as group identifiers, can be applied to each segment. 627 o This allows the possibility of using alternate fragmentation and 628 reassembly algorithms (e.g. fragmentation with Forward Error 629 Correction). 631 o Fragmentation is transparent to the underlying network so it is 632 unlikely that fragmented packet will be unconditionally dropped 633 as might happen with IP fragmentation. 635 5.2. Scope 637 This specification describes the mechanics of fragmentation in 638 Generic UDP Encapsulation. The operational aspects and details for 639 higher layer implementation must be considered for deployment, but 640 are considered out of scope for this document. The AERO protocol 641 [I.D.templin-aerolink] defines one use case of fragmentation with 642 encapsulation. 644 5.3. Extension field format 646 The presence of the GUE fragmentation option is indicated by the F 647 bit in the GUE header. 649 The format of the fragmentation option is: 651 0 1 2 3 652 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 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 | Fragment offset |Res|M| Orig-proto | | 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 656 | Identification | 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 The fields of the option are: 661 o Fragment offset: This field indicates where in the datagram this 662 fragment belongs. The fragment offset is measured in units of 8 663 octets (64 bits). The first fragment has offset zero. 665 o Res: Two bit reserved field. MUST be set to zero for 666 transmission. If set to non-zero in a received packet then the 667 packet MUST be dropped. 669 o M: More fragments bit. Set to 1 when there are more fragments 670 following in the datagram, set to 0 for the last fragment. 672 o Orig-proto: The control type (when the C-bit in the GUE header 673 is set) or the IP protocol (when C-bit is not set) of the 674 fragmented packet. 676 o Identification: 40 bits. Identifies fragments of a fragmented 677 packet. 679 Pertinent GUE header fields to fragmentation are: 681 o C-bit: This is set for each fragment based on the whether the 682 original packet being fragmented is a control or data message. 684 o Proto/ctype - For the first fragment (fragment offset is zero) 685 this is set to that of the original packet being fragmented 686 (either will be a control type or IP protocol). For other 687 fragments, this is set to zero for a control message being 688 fragmented, or to "No next header" (protocol number 59) for a 689 data message being fragmented. 691 o F bit - Set to indicate presence of the fragmentation extension 692 field. 694 5.4. Fragmentation procedure 696 If an encapsulator determines that a packet must be fragmented (e.g. 698 the packet's size exceeds the Path MTU of the tunnel) it should 699 divide the packet into fragments and send each fragment as a separate 700 GUE packet, to be reassembled at the decapsulator (tunnel egress). 702 For every packet that is to be fragmented, the source node generates 703 an Identification value. The Identification MUST be different than 704 that of any other fragmented packet sent within the past 60 seconds 705 (Maximum Segment Lifetime) with the same tunnel identification-- that 706 is the same outer source and destination addresses, same UDP ports, 707 same orig-proto, and same group identifier if present. 709 The initial, unfragmented, and unencapsulated packet is referred to 710 as the "original packet". This will be a layer 2 packet, layer 3 711 packet, or the payload of a GUE control message: 713 +-------------------------------//------------------------------+ 714 | Original packet | 715 | (e.g. an IPv4, IPv6, Ethernet packet) | 716 +------------------------------//-------------------------------+ 718 Fragmentation and encapsulation are performed on the original packet 719 in sequence. First the packet is divided up in to fragments, and then 720 each fragment is encapsulated. Each fragment, except possibly the 721 last ("rightmost") one, is an integer multiple of 8 octets long. 722 Fragments MUST be non-overlapping. The number of fragments SHOULD be 723 minimized, and all but the last fragment should be approximately 724 equal in length. 726 The fragments are transmitted in separate "fragment packets" as: 728 +--------------+--------------+---------------+--//--+----------+ 729 | first | second | third | | last | 730 | fragment | fragment | fragment | .... | fragment | 731 +--------------+--------------+---------------+--//--+----------+ 733 Each fragment is encapsulated as the payload of a GUE packet. This is 734 illustrated as: 736 +------------------+----------------+-----------------------+ 737 | IP/UDP header | GUE header | first | 738 | | w/ frag option | fragment | 739 +------------------+----------------+-----------------------+ 741 +------------------+----------------+-----------------------+ 742 | IP/UDP header | GUE header | second | 743 | | w/ frag option | fragment | 744 +------------------+----------------+-----------------------+ 745 o 746 o 747 +------------------+----------------+-----------------------+ 748 | IP/UDP header | GUE header | last | 749 | | w/ frag option | fragment | 750 +------------------+----------------+-----------------------+ 752 Each fragment packet is composed of: 754 (1) Outer IP and UDP headers as defined for GUE encapsulation. The 755 IP addresses and UDP ports MUST be the same for all fragments 756 of a fragmented packet. 758 (2) A GUE header that indicates the fragmentation option is 759 present. The C-bit and and proto/ctype are set appropriately 760 as described above. 762 (3) The GUE fragmentation option. Orig-protocol is set to the 763 protocol of the original packet. The M-bit is set for all 764 fragments except the last one. Fragment offset is set as the 765 offset of each fragment in the original packet. 767 (4) Other GUE extensions. 769 (5) The fragment itself as payload of the GUE packet. 771 5.5. Reassembly procedure 773 At the destination, fragment packets are decapsulated and reassembled 774 into their original, unfragmented form, as illustrated: 776 +-------------------------------//------------------------------+ 777 | Original packet | 778 | (e.g. an IPv4, IPv6, Ethernet packet) | 779 +------------------------------//-------------------------------+ 781 The following rules govern reassembly: 783 The IP/UDP/GUE headers of each packet are retained until all 784 fragments have arrived. The reassembled packet is then composed 785 of the decapsulated payloads in the GUE packets, and the 786 IP/UDP/GUE headers are discarded. 788 When a GUE packet is received with the fragment extension, the 789 proto/ctype field in the GUE header MUST be validated. In the 790 case that the packet is a first fragment (fragment offset is 791 zero), the proto/ctype in the GUE header MUST equal the orig- 792 proto value in the fragmentation option. For subsequent 793 fragments, (fragment offset is non-zero) the proto/ctype in the 794 GUE header must be 0 for a control message or 59 (no-next-hdr) 795 for a data message. If the proto/ctype value is invalid for a 796 received packet it MUST be dropped. 798 An original packet is reassembled only from GUE fragment packets 799 that have the same outer source address, destination address, 800 UDP source port, UDP destination port, GUE header C-bit, group 801 identifier if present, orig-proto value in the fragmentation 802 option, and Fragment Identification. The protocol type or 803 control message type (depending on the C-bit) for the 804 reassembled packet is the value of the GUE header proto/ctype 805 field in the first fragment. 807 The following error conditions can arise when reassembling fragmented 808 packets with GUE encapsulation: 810 If insufficient fragments are received to complete reassembly of 811 a packet within 60 seconds (or a configurable period) of the 812 reception of the first-arriving fragment of that packet, 813 reassembly of that packet MUST be abandoned and all the 814 fragments that have been received for that packet MUST be 815 discarded. 817 If the payload length of a fragment is not a multiple of 8 818 octets and the M flag of that fragment is 1, then that fragment 819 MUST be discarded. 821 If the length and offset of a fragment are such that the payload 822 length of the packet reassembled from that fragment would exceed 823 65,535 octets, then that fragment MUST be discarded. 825 If a fragment overlaps another fragment already saved for 826 reassembly then the new fragment that overlaps the existing 827 fragment MUST be discarded. 829 If the first fragment is too small then it is possible that it does 830 not contain the necessary headers for a stateful firewall. Sending 831 small fragments like this has been used as an attack on IP 832 fragmentation. To mitigate this problem, an implementation SHOULD 833 ensure that the first fragment contains the headers of the 834 encapsulated packet at least through the transport header. 836 A GUE node MUST be able to accept a fragmented packet that, after 837 reassembly and decapsulation, is as large as 1500 octets. This means 838 that the node must configure a reassembly buffer that is at least as 839 large as 1500 octets plus the maximum-sized encapsulation headers 840 that may be inserted during encapsulation. Implementations may find 841 it more convenient and efficient to configure a reassembly buffer 842 size of 2KB which is large enough to accommodate even the largest set 843 of encapsulation headers and provides a natural memory page size 844 boundary. 846 5.6. Security Considerations 848 Exploits that have been identified with IP fragmentation are 849 conceptually applicable to GUE fragmentation. 851 Attacks on GUE fragmentation can be mitigated by: 853 o Hardened implementation that applies applicable techniques from 854 implementation of IP fragmentation. 856 o Application of GUE security (section 4) or IPsec [RFC4301]. 857 Security mechanisms can prevent spoofing of fragments from 858 unauthorized sources. 860 o Implement fragment filter techniques for GUE encapsulation as 861 described in [RFC1858] and [RFC3128]. 863 o Do not accept data in overlapping segments. 865 o Enforce a minimum size for the first fragment. 867 6. Payload transform option 869 The payload transform option indicates that the GUE payload has been 870 transformed. Transforming a payload is done by running a function 871 over the data and possibly modifying it (encrypting it for instance). 872 The payload transform option indicates the method used to transform 873 the data so that a decapsulator is able to validate and reverse the 874 transformation to recover the original data. Payload transformations 875 could include encryption, authentication, CRC coverage, and 876 compression. This specification defines a transformation for DTLS. 878 6.1. Extension field format 880 The presence of the GUE payload transform option is indicated by the 881 T bit in the GUE header. 883 The format of Payload Transform Field is: 885 0 1 2 3 886 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 887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 | Type | P_C_type | Info | 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 The fields of the option are: 892 Type: Payload Transform Type or Code point. Each payload transform 893 mechanism must have one code point registered in IANA. This 894 document specifies: 896 0x01: for DTLS [RFC6347] 898 0x80~0xFF: for private payload transform types 900 A private payload transform type can be used for 901 experimental purposes or proprietary mechanisms. 903 P_C_type: Indicates the protocol or control type of the 904 untransformed payload. When payload transform option is 905 present, proto/ctype in the GUE header is set to 59 ("No 906 next header") for a data message and zero for a control 907 message. The IP protocol or control message type of the 908 untransformed payload MUST be encoded in this field. 910 The benefit of this rule is to prevent a middle box from 911 inspecting the encrypted payload according to GUE next 912 protocol. The assumption here is that a middle box may 913 understand GUE base header but does not understand GUE 914 option flag definitions. 916 Info: A field that can be set according to the requirements of 917 each payload transform type. If the specification for a 918 payload transform type does not specify how this field is to 919 be set, then the field MUST be set to zero. 921 6.2. Usage 923 The payload transform option provides a mechanism to transform or 924 interpret the payload of a GUE packet. The Type field provides the 925 method used to transform the payload, and the P_C_type field provides 926 the protocol or control message type of the of payload before being 927 transformed. The payload transformation option is generic so that it 928 can have both security related uses (such as DTLS) as well as non 929 security related uses (such as compression, CRC, etc.). 931 An encapsulator performs payload transformation before transmission, 932 and a decapsulator performs the reverse transformation before 933 accepting a packet. For example, if an encapsulator transforms a 934 payload by encrypting it, the peer decaspsulator MUST decrypt the 935 payload before accepting the packet. If a decapsulator fails to 936 perform the reverse transformation or cannot validate the 937 transformation it MUST discard the packet and MAY generate an alert 938 to the management system. 940 6.3. Interaction with other optional extensions 942 If GUE fragmentation (section 5) is used in concert with the GUE 943 transform option, the transform option processing is performed after 944 fragmentation at the encapsulator and before reassembly at the 945 decapsulator. If the payload transform changes the size of the data 946 being fragmented this must be taken into account during 947 fragmentation. 949 If both the security option and the payload transform are used in a 950 GUE packet, an encapsulator MUST perform the payload transformation 951 first, set the payload transform option in the GUE header, and then 952 create the security option. A decapsulator does processing in 953 reverse-- the security option is processed (GUE header is validated) 954 and then the reverse payload transform is performed. 956 In order to get flow entropy from the payload, an encapsulator should 957 derive the flow entropy before performing a payload transform. 959 6.4. DTLS transform 961 The payload of a GUE packet can be secured using Datagram Transport 962 Layer Security [RFC6347]. An encapsulator would apply DTLS to the GUE 963 payload so that the payload packets are encrypted and the GUE header 964 remains in plaintext. The payload transform option is set to indicate 965 that the payload is interpreted as a DTLS record. 967 The payload transform option for DTLS is: 969 0 1 2 3 970 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 971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 972 | 1 | P_C_type | 0 | 973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 DTLS [RFC6347] provides a packet fragmentation capability. To avoid 976 packet fragmentation being performed multiple times, a GUE 977 encapsulator SHOULD use GUE fragmentation and not DTLS fragmentation. 979 DTLS usage is limited to a single DTLS session for any specific 980 tunnel encapsulator/decapsulator pair (identified by source and 981 destination IP addresses). Both IP addresses MUST be unicast 982 addresses - multicast traffic is not supported when DTLS is used. A 983 GUE tunnel decapsulator implementation that supports DTLS can 984 establish DTLS sessions with one or multiple tunnel encapsulators, 985 and likewise a GUE tunnel encapsulator implementation can establish 986 DTLS sessions with one or multiple decapsulators. 988 7. Remote checksum offload option 990 Remote checksum offload is mechanism that provides checksum offload 991 of encapsulated packets using rudimentary offload capabilities found 992 in most Network Interface Card (NIC) devices. Many NIC 993 implementations can only offload the outer UDP checksum in UDP 994 encapsulation. Remote checksum offload is described in [UDPENCAP]. 996 In remote checksum offload the outer header checksum, that in the 997 outer UDP header, is enabled in packets and, with some additional 998 meta information, a receiver is able to deduce the checksum to be set 999 for an inner encapsulated packet. Effectively this offloads the 1000 computation of the inner checksum. Enabling the outer checksum in 1001 encapsulation has the additional advantage that it covers more of the 1002 packet, including the encapsulation headers, than an inner checksum. 1004 7.1. Extension field format 1006 The presence of the GUE remote checksum offload option is indicated 1007 by the R bit in the GUE header. 1009 The format of remote checksum offload field is: 1011 0 1 2 3 1012 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 1013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1014 | Checksum start | Checksum offset | 1015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1017 The fields of the option are: 1019 o Checksum start: starting offset for checksum computation 1020 relative to the start of the encapsulated payload. This is 1021 typically the offset of a transport header (e.g. UDP or TCP). 1023 o Checksum offset: Offset relative to the start of the 1024 encapsulated packet where the derived checksum value is to be 1025 written. This typically is the offset of the checksum field in 1026 the transport header (e.g. UDP or TCP). 1028 7.2. Usage 1030 7.2.1. Transmitter operation 1032 The typical actions to set remote checksum offload on transmit are: 1034 1) Transport layer creates a packet and indicates in internal 1035 packet meta data that checksum is to be offloaded to the NIC 1036 (normal transport layer processing for checksum offload). The 1037 checksum field is populated with the bitwise not of the 1038 checksum of the pseudo header or zero as appropriate. 1040 2) Encapsulation layer adds its headers to the packet including 1041 the remote checksum offload option. The start offset and 1042 checksum offset are set accordingly. 1044 3) Encapsulation layer arranges for checksum offload of the outer 1045 header checksum (e.g. UDP). 1047 4) Packet is sent to the NIC. The NIC will perform transmit 1048 checksum offload and set the checksum field in the outer 1049 header. The inner header and rest of the packet are transmitted 1050 without modification. 1052 7.2.2. Receiver operation 1054 The typical actions a host receiver does to support remote checksum 1055 offload are: 1057 1) Receive packet and validate outer checksum following normal 1058 processing (i.e. validate non-zero UDP checksum). 1060 2) Validate the remote checksum option. If checksum start is 1061 greater than the length of the packet, then the packet MUST be 1062 dropped. If checksum offset is greater then the length of the 1063 packet minus two, then the packet MUST be dropped. 1065 3) Deduce full checksum for the IP packet. If a NIC is capable of 1066 receive checksum offload it will return either the full 1067 checksum of the received packet or an indication that the UDP 1068 checksum is correct. Either of these methods can be used to 1069 deduce the checksum over the IP packet [UDPENCAP]. 1071 4) From the packet checksum, subtract the checksum computed from 1072 the start of the packet (outer IP header) to the offset in the 1073 packet indicted by checksum start in the meta data. The result 1074 is the deduced checksum to set in the checksum field of the 1075 encapsulated transport packet. 1077 In pseudo code: 1079 csum: initialized to checksum computed from start (outer IP 1080 header) to the end of the packet 1081 start_of_packet: address of start of packet 1082 encap_payload_offset: relative to start_of_packet 1083 csum_start: value from the checksum start field 1084 checksum(start, len): function to compute checksum from start 1085 address for len bytes 1087 csum -= checksum(start_of_packet, encap_payload_offset + 1088 csum_start) 1090 5) Write the resultant checksum value into the packet at the 1091 offset provided by checksum offset in the meta data. 1093 In pseudo code: 1095 csum_offset: value from the checksum offset field 1097 *(start_of_packet + encap_payload_offset + 1098 csum_offset) = csum 1100 6) Checksum is verified at the transport layer using normal 1101 processing. This should not require any checksum computation 1102 over the packet since the complete checksum has already been 1103 provided. 1105 7.3. Security Considerations 1107 Remote checksum offload allows a means to change the GUE payload 1108 before being received at a decapsulator. In order to prevent misuse 1109 of this mechanism, a decapsulator MUST apply security checks on the 1110 GUE payload only after checksum remote offload has been processed. 1112 8. Checksum option 1114 The GUE checksum option provides a checksum that covers the GUE 1115 header, a GUE pseudo header, and optionally all or part of the GUE 1116 payload. The GUE pseudo header includes the corresponding IP 1117 addresses as well as the UDP ports of the encapsulating headers. This 1118 checksum should provide protection against address corruption in IPv6 1119 when the UDP checksum is zero. Additionally, the GUE checksum 1120 provides protection of the GUE header when the UDP checksum is set to 1121 zero with either IPv4 or IPv6. In particular, the GUE checksum can 1122 provide protection for some sensitive data, such as the virtual 1123 network identifier ([I.D.hy-nvo3-gue-4-nvo]), which when corrupted 1124 could lead to mis-delivery of a packet to the wrong virtual network. 1126 8.1. Extension field format 1128 The presence of the GUE checksum option is indicated by the K bit in 1129 the GUE header. 1131 The format of the checksum extension is: 1133 0 1 2 3 1134 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 1135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1136 | Checksum | Payload coverage | 1137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1139 The fields of the option are: 1141 o Checksum: Computed checksum value. This checksum covers the GUE 1142 header (including fields and private data covered by Hlen), the 1143 GUE pseudo header, and optionally all or part of the payload 1144 (encapsulated packet). 1146 o Payload coverage: Number of bytes of payload to cover in the 1147 checksum. Zero indicates that the checksum only covers the GUE 1148 header and GUE pseudo header. If the value is greater than the 1149 encapsulated payload length, the packet MUST be dropped. 1151 8.2. Requirements 1153 The GUE header checksum SHOULD be set on transmit when using a zero 1154 UDP checksum with IPv6. 1156 The GUE header checksum SHOULD be used when the UDP checksum is zero 1157 for IPv4 if the GUE header includes data that when corrupted can lead 1158 to misdelivery or other serious consequences, and there is no other 1159 mechanism that provides protection (no security field that checks 1160 integrity for instance). 1162 The GUE header checksum SHOULD NOT be set when the UDP checksum is 1163 non-zero. In this case the UDP checksum provides adequate protection 1164 and this avoids convolutions when a packet traverses NAT that does 1165 address translation (in that case the UDP checksum is required). 1167 8.3. GUE checksum pseudo header 1169 The GUE pseudo header checksum is included in the GUE checksum to 1170 provide protection for the IP and UDP header elements which when 1171 corrupted could lead to misdelivery of the GUE packet. The GUE pseudo 1172 header checksum is similar to the standard IP pseudo header defined 1173 in [RFC0768] and [RFC0793] for IPv4, and in [RFC8200] for IPv6. 1175 The GUE pseudo header for IPv4 is: 1177 0 1 2 3 1178 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 1179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1180 | Source Address | 1181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1182 | Destination Address | 1183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1184 | Source port | Destination port | 1185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1187 The GUE pseudo header for IPv6 is: 1189 0 1 2 3 1190 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 1191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1192 | | 1193 + + 1194 | | 1195 + Source Address + 1196 | | 1197 + + 1198 | | 1199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1200 | | 1201 + + 1202 | | 1203 + Destination Address + 1204 | | 1205 + + 1206 | | 1207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1208 | Source port | Destination port | 1209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1211 The GUE pseudo header does not include payload length or protocol as 1212 in the standard IP pseudo headers. The length field is deemed 1213 unnecessary for inclusion because a corrupted length field should not 1214 cause mis-delivery, the GUE checksum is applied after GUE 1215 fragmentation, and without the length field the GUE pseudo header 1216 checksum is the same for all packets of flow. 1218 8.4. Usage 1220 The GUE checksum is computed and verified following the standard 1221 process for computing the Internet checksum [RFC1071]. Checksum 1222 computation may be optimized per the mathematical properties 1223 including parallel computation and incremental updates. 1225 8.4.1. Transmitter operation 1227 The procedure for setting the GUE checksum on transmit is: 1229 1) Create the GUE header including the checksum and payload 1230 coverage fields. The checksum field is initially set to zero. 1232 2) Calculate the 1's complement checksum of the GUE header from 1233 the start of the GUE header through the its length as indicated 1234 in GUE Hlen. 1236 3) Calculate the checksum of the GUE pseudo header for IPv4 or 1237 IPv6. 1239 4) Calculate checksum of payload portion if payload coverage is 1240 enabled (payload coverage field is non-zero). If the length of 1241 the payload coverage is odd, logically append a single zero 1242 byte for the purposes of checksum calculation. 1244 5) Add and fold the computed checksums for the GUE header, GUE 1245 pseudo header, and payload coverage. 1247 6) Set the bitwise not of the resultant value in the GUE checksum 1248 field. 1250 8.4.2. Receiver operation 1252 If the GUE checksum option is present, the receiver MUST validate the 1253 checksum before processing any other fields or accepting the packet. 1255 The procedure for verifying the checksum is: 1257 1) If the payload coverage length is greater than the length of 1258 the encapsulated payload then drop the packet. 1260 2) Calculate the checksum of the GUE header from the start of the 1261 header to the end as indicated by Hlen. 1263 3) Calculate the checksum of the appropriate GUE pseudo header. 1265 4) Calculate the checksum of payload if payload coverage is 1266 enabled (payload coverage is non-zero). If the length of the 1267 payload coverage is odd logically append a single zero byte for 1268 the purposes of checksum calculation. 1270 5) Sum the computed checksums for the GUE header, GUE pseudo 1271 header, and payload coverage. If the result is all 1 bits (-0 1272 in 1's complement arithmetic), the checksum is valid and the 1273 packet is accepted; otherwise the checksum is considered 1274 invalid and the packet MUST be dropped. 1276 8.5. Corrupted flags 1278 Note that the GUE checksum does not protect against the checksum flag 1279 (K flag) being corrupted. If an encapsulator sets the checksum flag 1280 and option but the K bit flips to be zero, then a decapsulator will 1281 incorrectly process the GUE packet as not having a checksum field. 1283 To mitigate this issue an encapsulator and depcapsulator might agree 1284 that checksum is always required. This agreement could be established 1285 by configuration or GUE capability negotiation. 1287 8.6. Security Considerations 1289 The checksum option is only a mechanism for corruption detection, it 1290 is not a security mechanism. To provide integrity checks or 1291 authentication of the GUE header, the GUE security option SHOULD be 1292 used. 1294 9. NAT checksum address option 1296 The NAT address checksum (NAC) option contains the checksum computed 1297 over the IP addresses of the packet. The computed value can be used 1298 by a receiver to adjust a transport layer checksum that was affected 1299 by NAT changing the IP addresses. This option is only useful when GUE 1300 encapsulates a transport layer packet that has a checksum with a 1301 pseudo header that includes the IP addresses (such as TCP or UDP). 1303 9.1. Extension field format 1305 The presence of the NAT checksum address option is indicated by the N 1306 bit in the GUE header. 1308 The format of the NAT checksum address extension is: 1310 0 1 2 3 1311 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 1312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1313 | Checksum | Reserved | 1314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1316 The fields of the option are: 1318 o Checksum: Computed checksum value. This checksum covers the 1319 outer IP addresses. 1321 o Reserved: Must be zero on transmit. 1323 9.2. Usage 1325 The NAT address extension SHOULD be set on transmit when 1326 encapsulating a transport layer packet whose checksum might be 1327 affected by NAT being performed on the outer IP header. If this 1328 option is used then the UDP checksum MUST be used (sent with non-zero 1329 value). 1331 The NAT address checksum is computed using the Internet checksum 1332 [RFC1071]. 1334 9.2.1. Transmitter operation 1336 The procedure for setting the GUE checksum on transmit is: 1338 An encapsulator computes the checksum value over the IP addresses in 1339 the IP header. 1341 1) Compute the ones complement checksum over the source and 1342 destination IPv4 or IPv6 addresses. 1344 2) Set the resultant value in the Checksum field. 1346 For IPv4 the checksum is computed over: 1348 0 1 2 3 1349 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 1350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1351 | Source Address | 1352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1353 | Destination Address | 1354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1355 For IPv6 the checksum is computed over: 1357 0 1 2 3 1358 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 1359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1360 | | 1361 + + 1362 | | 1363 + Source Address + 1364 | | 1365 + + 1366 | | 1367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1368 | | 1369 + + 1370 | | 1371 + Destination Address + 1372 | | 1373 + + 1374 | | 1375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1377 9.2.2. Receiver operation 1379 1) Validate the UDP checksum is correct 1381 2) Compute the checksum over the IP address in the received packet 1383 3) Subtract the resultant from the checksum value in the NAC 1384 option. If the difference is non-zero then NAT has changed the 1385 addresses 1387 4) When processing a transport layer containing a checksum 1388 affected by NAT on the IP addresses, add the difference into 1389 the checksum calculation when verify the packet. 1391 In pseudo codes this is: 1393 actual = checksum(IP addresses) 1394 diff = actual - NAC_value 1395 verify = checksum(transport packet) + checksum(pseudo header) 1396 + diff 1398 if (verify == 0) 1399 packet is good 1401 10. Alternative checksum option 1402 The alternative checksum option contains a check over the GUE header 1403 and optionally all or part of the GUE payload. The algorithm used is 1404 CRC-32C which is the same as that used by iSCSI and SCTP. The 1405 alternative checksum can provide stronger protection against data 1406 corruption than provided by the one's complement checksum used in the 1407 UDP checksum or the GUE checksum (section 8). 1409 10.1. Extension field format 1411 The presence of the GUE alternate checksum option is indicated by the 1412 A bit in the GUE header. 1414 The format of alternate checksum field is: 1416 0 1 2 3 1417 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 1418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1419 | Reserved | Payload coverage | 1420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1421 | CRC | 1422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1424 The fields of the option are: 1426 o CRC: Computed CRC value. This CRC covers the GUE header 1427 (including fields and private data covered by Hlen) and 1428 optionally all or part of the payload (encapsulated packet). 1430 o Payload coverage: Number of bytes of payload to cover in the CRC 1431 calculation. Zero indicates that the checksum only covers the 1432 GUE header. If the value is greater than the encapsulated 1433 payload length, the packet MUST be dropped. 1435 10.2. Usage 1437 The 32-bit alternative checksum does not include a pseudo header 1438 containing IP addresses or ports. 1440 CRC-32C is calculated using the 0x1EDC6F41 polynomial: 1442 x^32 + x^28 + x^27 + x^26 + x^25 + x^23 + x^22 + x^20 + x^19 + 1443 x^18 + x^14 +x^13 + +x^11 + x^10 +x^9 +x ^8 +x^ + 1 1445 The procedure for setting the GUE alternative checksum on transmit 1446 is: 1448 1) Create the GUE header including the alternative checksum field. 1449 The CRC field is initialized to zero. 1451 2) Calculate the CRC using the CRC-32C algorithm from the start of 1452 the GUE header through the its length as indicated in GUE Hlen. 1454 3) Continue the calculation to cover the payload portion if 1455 payload coverage is enabled (payload coverage field is non- 1456 zero). If the length of the payload coverage is not aligned to 1457 four bytes, logically append zero bytes up to the necessary 1458 alignment for the purposes of CRC calculation. 1460 4) Set the resultant value in the CRC field. 1462 10.2.2. Receiver operation 1464 If the GUE alternative checksum option is present, the receiver MUST 1465 validate the checksum before processing any other fields or accepting 1466 the packet. 1468 The procedure for verifying the alternate checksum is: 1470 1) If the payload coverage length is greater than the length of 1471 the encapsulated payload then drop the packet. 1473 2) Note value in the CRC field and set the CRC field to zero. 1475 3) Calculate the CRC using the CRC-32C algorithm from the start of 1476 the GUE header through the its length as indicated in GUE Hlen. 1478 4) Continue the calculation to cover the payload portion if 1479 payload coverage is enabled (payload coverage field is non- 1480 zero). If the length of the payload coverage is not aligned to 1481 four bytes, logically append zero bytes up to the necessary 1482 alignment for the purposes of CRC calculation. 1484 5) Compare the computed value with the original value of the CRC 1485 field. If they are equal then that packet is accepted, if they 1486 are not equal then verification failed and the packet MUST be 1487 dropped. 1489 6) Restore the CRC field to its original value. 1491 10.3. Corrupted flags 1493 Similar to GUE checksum properties, the GUE alternate checksum does 1494 not protect against the alternative checksum flag (A flag) being 1495 corrupted. If an encapsulator sets the alternative checksum flags and 1496 option but the A bit flips to be zero, then a decapsulator will 1497 incorrectly process that packet as not having an alternate checksum 1498 field. 1500 To mitigate this issue an encapsulator and depcapsulator might agree 1501 that an alternate checksum is always required. This agreement could 1502 be established by configuration or GUE capability negotiation. 1504 10.4. Security Considerations 1506 The alternate checksum option is only a mechanism for corruption 1507 detection, it is not a security mechanism. To provide integrity 1508 checks or authentication of the GUE header, the GUE security option 1509 SHOULD be used. 1511 11. Processing order of options 1513 Options MUST be processed in a specific order for both transmission 1514 and reception. Note that some options, such as the checksum option, 1515 depend on other fields in the GUE header to be initialized. 1517 11.1. Processing order when sending 1519 When setting the security option (HMAC option in particular), the 1520 checksum option, and the alternate checksum option-- all the GUE 1521 fields being used must be present and properly set in the header. The 1522 checksum value in the checksum option or alternate checksum option 1523 MUST be initialized to zero to ensure consistent HMAC and checksum 1524 calculation. 1526 The order of processing options to send a GUE packet are: 1528 1) Fragment if necessary and set fragmentation option. If the 1529 group identifier is present it is copied into each fragment. If 1530 payload transformation will increase the size of the payload 1531 that MUST be accounted for when deciding how to fragment. Apply 1532 processing below for each fragment 1534 2) Set group identifier option (to the same value for each 1535 fragment) 1537 3) Perform payload transform (potentially on a fragment) and set 1538 payload transform option. 1540 4) Set Remote checksum offload. 1542 5) Set NAT address checksum option. 1544 6) Set security option per cookie or HMAC calculation. 1546 7) Calculate GUE alternate checksum and set the alternate checksum 1547 option. 1549 8) Calculate GUE checksum and set checksum option. 1551 11.2. Processing order when receiving 1553 On reception the order of actions is: 1555 1) Verify GUE checksum. 1557 2) Verify alternate checksum. If the GUE checksum option is 1558 present, set its checksum fields to zero for computing the 1559 alternate checksum. After computation, restore the checksum 1560 value in the GUE checksum field. 1562 3) Verify security option. If the GUE checksum option or alternate 1563 checksum option are also present and HMAC computation is being 1564 done over the GUE header, then set the checksum fields to zero 1565 for computing the HMAC. After computation, restore the checksum 1566 values. 1568 4) Save the NAT address checksum value. It will be applied when 1569 processing the encapsulated packet. 1571 5) Adjust packet for remote checksum offload. 1573 6) Perform payload transformation (i.e. decrypt payload). 1575 7) Perform reassembly. 1577 8) Process packet (take group identifier into account if present). 1579 The relative processing order of GUE extensions and private fields is 1580 unspecified in this specification. 1582 12. Security Considerations 1584 Encapsulation of a network protocol in GUE should not increase 1585 security risk, nor provide additional security in itself. GUE 1586 requires that the source port for UDP packets SHOULD be randomly 1587 seeded to mitigate some possible denial service attacks. 1589 If the integrity and privacy of data packets being transported 1590 through GUE is a concern, GUE security option and payload encryption 1591 using the the transform option SHOULD be used to remove the concern. 1592 If the integrity is the only concern, the tunnel may consider use of 1593 GUE security only for optimization. Likewise, if privacy is the only 1594 concern, the tunnel may use a GUE transform for encryption only. 1596 If GUE payload already provides secure mechanism, e.g., the payload 1597 is IPsec packets, it is still valuable to consider use of GUE 1598 security. 1600 GUE may rely on other secure tunnel mechanisms such as DTLS [RFC6347] 1601 over the whole UDP payload for securing the whole GUE packet or IPsec 1602 [RFC4301] to achieve the secure transport over an IP network or 1603 Internet. 1605 IPsec [RFC4301] was designed as a network security mechanism, and 1606 therefore it resides at the network layer. As such, if the tunnel is 1607 secured with IPsec, the UDP header would not be visible to 1608 intermediate routers in either IPsec tunnel or transport mode. This 1609 is a drawback since it prohibits intermediate routers to perform load 1610 balancing based on the flow entropy in UDP header. In addition, this 1611 method prohibits any middle box function on the path. 1613 By comparison, DTLS [RFC6347] was designed for application level 1614 security and can better preserve network and transport layer protocol 1615 information than IPsec [RFC4301]. Using DTLS over UDP to secure the 1616 GUE tunnel, both GUE header and payload will be encrypted. In order 1617 to differentiate plaintext GUE header from encrypted GUE header, the 1618 destination port of the UDP header between two must be different, 1619 which essentially requires another standard UDP port for GUE with 1620 DTLS. The drawback on this method is to prevent a middle box 1621 operation to GUE tunnel on the path. 1623 Use of two independent tunnel mechanisms such as GUE and DTLS over 1624 UDP to carry a network protocol over an IP network adds some overlap 1625 and complexity. For example, fragmentation will be done twice. 1627 As the result, a GUE tunnel SHOULD use the security mechanisms 1628 specified in this document to provide secure transport over an IP 1629 network or Internet when it is needed. GUE encapsulation can be used 1630 as a secure transport mechanism over an IP network and Internet. 1632 13. IANA Consideration 1634 IANA is requested to assign flags for the extensions defined in this 1635 specification. Specifically, an assignment is requested for the Group 1636 Identfier, Security, Fragmentation, Payload Transform, Remote 1637 Checksum Offload, Checksum, NAT Checksum, and Alternate Checksum 1638 extensions in the "GUE flag-fields" registry. 1640 +-------------+---------------+-------------+--------------------+ 1641 | Flags bits | Field size | Description | Reference | 1642 +-------------+---------------+-------------+--------------------+ 1643 | Bit 0 | 4 bytes | Group | This document | 1644 | | | identifier | | 1645 | | | | | 1646 | Bit 1..3 | 001->8 bytes | Security | This document | 1647 | | 010->16 bytes | | | 1648 | | 011->32 bytes | | | 1649 | | 100->40 bytes | | | 1650 | | | | | 1651 | Bit 4 | 8 bytes | Fragmen- | This document | 1652 | | | tation | | 1653 | | | | | 1654 | Bit 5 | 4 bytes | Payload | This document | 1655 | | | transform | | 1656 | | | | | 1657 | Bit 6 | 4 bytes | Remote | This document | 1658 | | | checksum | | 1659 | | | offload | | 1660 | | | | | 1661 | Bit 7 | 4 bytes | Checksum | This document | 1662 | | | | | 1663 | Bit 8 | 4 bytes | NAT | This document | 1664 | | | checksum | | 1665 | | | address | | 1666 | | | | | 1667 | Bit 9 | 4 bytes | Alternate | This document | 1668 | | | checksum | | 1669 | | | | | 1670 | Bit 10..15 | | Unassigned | | 1671 +-------------+---------------+-------------+--------------------+ 1673 IANA is requested to set up a registry for the GUE payload transform 1674 types. Payload transform types are 8 bit values. New values for 1675 control types 1-127 are assigned via Standards Action [RFC5226]. 1677 +----------------+------------------+---------------+ 1678 | Transform type | Description | Reference | 1679 +----------------+------------------+---------------+ 1680 | 0 | Reserved | This document | 1681 | | | | 1682 | 1 | DTLS | This document | 1683 | | | | 1684 | 2..127 | Unassigned | | 1685 | | | | 1686 | 128..255 | User defined | This document | 1687 +----------------+------------------+---------------+ 1689 14. References 1691 14.1. Normative References 1693 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1694 1981. 1696 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1697 (IPv6) Specification", STD 86, RFC 8200, DOI 1698 10.17487/RFC8200, July 2017, . 1701 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 1702 Communication Layers", STD 3, RFC 1122, October 1989. 1704 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1705 August 1980. 1707 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1708 IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 1709 10.17487/RFC5226, May 2008, . 1712 [I.D.ietf-gue] T. Herbert, L. Yong, and O. Zia, "Generic UDP 1713 Encapsulation" draft-ietf-intarea-gue-01 1715 14.2. Informative References 1717 [RFC3931] Lau, J., Townsley, W., et al, "Layer Two Tunneling Protocol 1718 - Version 3 (L2TPv3)", RFC3931, 1999 1720 [RFC2104] Kent, S. and R. Atkinson, "Security Architecture for the 1721 Internet Protocol" , RFC 2401, DOI 10.17487/RFC2401, 1722 November 1998, . 1724 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain of 1725 Interpretation" , RFC 6407, DOI 10.17487/RFC6407, October 1726 2011, . 1728 [RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the- 1729 Network Tunneling", RFC 4459, DOI 10.17487/RFC4459, April 1730 2006, . 1732 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 1733 Errors at High Data Rates", RFC 4963, DOI 10.17487/RFC4963, 1734 July 2007, . 1736 [RFC2764] B. Gleeson, A. Lin, J. Heinanen, G. Armitage, A. Malis, "A 1737 Framework for IP Based Virtual Private Networks", RFC2764, 1738 February 2000. 1740 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1741 Internet Protocol", RFC 4301, December 2005. 1743 [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security 1744 Considerations for IP Fragment Filtering", RFC 1858, 1745 October 1995. 1747 [RFC3128] Miller, I., "Protection Against a Variant of the Tiny 1748 Fragment Attack (RFC 1858)", RFC 3128, June 2001. 1750 [RFC6347] Rescoria, E., Modadugu, N., "Datagram Transport Layer 1751 Security Version 1.2", RFC6347, 2012. 1753 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 1754 793, DOI 10.17487/RFC0793, September 1981, . 1757 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 1758 for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 1759 6936, DOI 10.17487/RFC6936, April 2013, . 1762 [RFC1071] Braden, R., Borman, D., and C. Partridge, "Computing the 1763 Internet checksum", RFC1071, September 1988. 1765 [I.D.hy-nvo3-gue-4-nvo] Yong, L., Herbert, T., "Generic UDP 1766 Encapsulation (GUE) for Network Virtualization Overlay" 1767 draft-hy-nvo3-gue-4-nvo-03 1769 [I.D.previdi-6man-sr-header] Previdi S. et al, "IPv6 Segment Routing 1770 Header (SRH) draft-ietf-6man-segment-routing-header-02 1772 [I.D.templin-aerolink] F. Templin, "Transmission of IP Packets over 1773 AERO Links" draft-templin-aerolink-62 1775 [UDPENCAP] T. Herbert, "UDP Encapsulation in Linux", 1776 http://people.netfilter.org/pablo/netdev0.1/papers/UDP- 1777 Encapsulation-in-Linux.pdf 1779 [FIPS180-4] Secure Hash Standard (SHS), Nation Institute of Standards 1780 and Technology, 8/2015 1782 Authors' Addresses 1784 Tom Herbert 1785 Quantonium 1786 4701 Patrick Henry Dr. 1787 Santa Clara, CA 1788 USA 1790 EMail: tom@herbertland.com 1792 Lucy Yong 1793 Huawei USA 1794 5340 Legacy Dr. 1795 Plano, TX 75024 1796 USA 1798 Email: lucy.yong@huawei.com 1800 Fred L. Templin 1801 Boeing Research & Technology 1802 P.O. Box 3707 1803 Seattle, WA 98124 1804 USA 1806 Email: fltemplin@acm.org