idnits 2.17.1 draft-ietf-intarea-gue-extensions-06.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 199: '... SHOULD be set to protocol numb...' RFC 2119 keyword, line 261: '...termediate nodes MAY apply semantics t...' RFC 2119 keyword, line 293: '...y, the SEC flags MUST be set. Differen...' RFC 2119 keyword, line 320: '...present in a packet, the receiver MUST...' RFC 2119 keyword, line 324: '... MUST drop the packet as failing sec...' (52 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 8, 2019) is 1877 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) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS180-4' -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. 'RFC2104') (Obsoleted by RFC 4301) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 4 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 9, 2019 L. Yong 5 Independent 6 F. Templin 7 Boeing 8 March 8, 2019 10 Extensions for Generic UDP Encapsulation 11 draft-ietf-intarea-gue-extensions-06 13 Abstract 15 This specification defines a set of the initial optional extensions 16 for Generic UDP Encapsulation (GUE). 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/1id-abstracts.html 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 Copyright and License Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. GUE header format with optional extensions . . . . . . . . . . 4 58 3. Group identifier option . . . . . . . . . . . . . . . . . . . 6 59 3.1. Extension field format . . . . . . . . . . . . . . . . . . 6 60 3.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 4. Security option . . . . . . . . . . . . . . . . . . . . . . . 6 62 4.1. Extension field format . . . . . . . . . . . . . . . . . . 7 63 4.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 4.3. Cookies . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 4.4.1. Extension field format . . . . . . . . . . . . . . . . 9 66 4.3.1. Operation . . . . . . . . . . . . . . . . . . . . . . . 8 67 4.3.1.1. Transmitter operation . . . . . . . . . . . . . . . 8 68 4.3.1.2. Receiver operation . . . . . . . . . . . . . . . . 9 69 4.4. HMAC . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 4.4.1. Extension field format . . . . . . . . . . . . . . . . 9 71 4.4.2. Selecting a hash algorithm . . . . . . . . . . . . . . 10 72 4.4.3. Pre-shared key management . . . . . . . . . . . . . . . 11 73 4.4.4. Operation . . . . . . . . . . . . . . . . . . . . . . . 11 74 4.4.4.1. Transmitter operation . . . . . . . . . . . . . . . 11 75 4.4.4.2. Receiver operation . . . . . . . . . . . . . . . . 11 76 4.5. Interaction with other optional extensions . . . . . . . . 12 77 5. Fragmentation option . . . . . . . . . . . . . . . . . . . . . 12 78 5.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 13 79 5.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 5.3. Extension field format . . . . . . . . . . . . . . . . . . 14 81 5.4. Fragmentation procedure . . . . . . . . . . . . . . . . . 15 82 5.5. Reassembly procedure . . . . . . . . . . . . . . . . . . . 17 83 5.6. Security Considerations . . . . . . . . . . . . . . . . . 19 84 6. Payload transform option . . . . . . . . . . . . . . . . . . . 19 85 6.1. Extension field format . . . . . . . . . . . . . . . . . . 19 86 6.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 20 87 6.3. Interaction with other optional extensions . . . . . . . . 21 88 6.4. DTLS transform . . . . . . . . . . . . . . . . . . . . . . 21 89 7. Remote checksum offload option . . . . . . . . . . . . . . . . 22 90 7.1. Extension field format . . . . . . . . . . . . . . . . . . 22 91 7.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 22 92 7.2.1. Transmitter operation . . . . . . . . . . . . . . . . . 22 93 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 checksum flag . . . . . . . . . . . . . . . . . 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 alternate checksum flag . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . 39 126 1. Introduction 128 Generic UDP Encapsulation (GUE) [I.D.ietf-gue] is a generic and 129 extensible encapsulation protocol. This specification defines an 130 initial 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 | | GUE 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 optional 180 extensions. 182 o C: C-bit. Indicates the GUE payload is a control message when 183 set, a data message when not set. GUE optional extensions can be 184 used with either control or data messages unless otherwise 185 stated in the specification of the extension. 187 o Hlen: Length in 32-bit words of the GUE header, including 188 optional extension fields and private data but not the first 189 four bytes of the header. Computed as (header_len - 4) / 4. The 190 length of the encapsulated packet is determined from the UDP 191 length and the Hlen: encapsulated_packet_length = UDP_Length - 192 12 - 4 * Hlen. 194 o Proto/ctype: If the C-bit is not set this indicates the IP 195 protocol number for the packet in the payload; if the C bit is 196 set this is the type of control message in the payload. The next 197 header begins at the offset provided by Hlen. When the payload 198 transform option or fragmentation option is used this field 199 SHOULD be set to protocol number 59 for a data message, or zero 200 for a control message, to indicate there is no parsable protocol 201 in the payload. 203 o G: Indicates the the group identifier extension field is 204 present. The group identifier option is described in section 3. 206 o SEC: Indicates security extension field is present. The security 207 option is described in section 4. 209 o F: Indicates fragmentation extension field is present. The 210 fragmentation option is described in section 5. 212 o T: Indicates payload transform extension field is present. The 213 payload transform option is described in section 6. 215 o R: Indicates the remote checksum extension field is present. The 216 remote checksum offload option is described in section 7. 218 o K: Indicates checksum extension field is present. The checksum 219 option is described in section 8. 221 o N: Indicates NAT address checksum field is present. The NAT 222 address checksum option is described in section 9. 224 o A: Indicates alternative checksum field is present. The 225 alternative checksum option is described in section 10. 227 o Private data is described in [I.D.ietf-gue]. 229 3. Group identifier option 231 A group identifier classifies packets that logically belong to the 232 same group. Groups are arbitrarily defined for different purposes and 233 their definition is shared between the communicating end nodes. 235 3.1. Extension field format 237 The presence of the GUE group identifier option is indicated by the G 238 flag bit of the GUE header. 240 The format of the group identifier option is: 242 0 1 2 3 243 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 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Group identifier | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 The fields of the option are: 250 o Group identifier: Identifier value of a group. 252 3.2. Usage 254 The group identifier is set by an encapsulator to indicate that a 255 packet belongs to a group. Groups may be arbitrarily defined to 256 classify packets. Specific use cases of the group identifier may be 257 defined in other documents ([I.D.hy-nvo3-gue-4-nvo] defines a use of 258 this field to contain a virtual networking identifier for 259 implementing network virtualization). 261 Intermediate nodes MAY apply semantics to group identifiers if group 262 identifier information is shared and made global within a network. 263 For instance, a firewall could block packets based on a group 264 identifier that serves as a virtual identifier for a tenant. 266 4. Security option 268 The GUE security option provides origin authentication and integrity 269 protection of the GUE header at tunnel end points to guarantee 270 isolation between tunnels and mitigate Denial of Service attacks. 272 4.1. Extension field format 274 The presence of the GUE security option is indicated by the SEC flag 275 bits of the GUE header. 277 The format of the security option is: 279 0 1 2 3 280 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 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | | 283 ~ Security ~ 284 | | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 The fields of the option are: 289 o Security (variable length). Contains the security information. 290 The specific semantics and format of this field are expected to 291 be negotiated between the two communicating nodes. 293 To provide security capability, the SEC flags MUST be set. Different 294 field sizes allow different methods and extensibility. The use of the 295 security field is expected to be negotiated out-of-band between two 296 tunnel end points. 298 The values in the SEC flags are: 300 o 000b - No security field 302 o 001b - 64 bit security field 304 o 010b - 128 bit security field 306 o 011b - 256 bit security field 308 o 100b - 320 bit security field (HMAC) 310 o 101b, 110b, 111b - Reserved values 312 4.2. Usage 314 The GUE security option is used to provide integrity and 315 authentication of the GUE header. Security parameters (interpretation 316 of security field, key management, etc.) are expected to be 317 negotiated out-of-band between two communicating hosts. Two security 318 algorithms are defined below. 320 If the GUE security option is present in a packet, the receiver MUST 321 validate the security before processing other fields or accepting the 322 packet. If the security option is not present, but the encapsulator 323 and decapsulator have agreed that security is required, the receiver 324 MUST drop the packet as failing security checks. Note that this 325 provision covers the case where the security flags bits are corrupted 326 such that they are reset to zero which would be interpreted as no 327 security field being present. 329 4.3. Cookies 331 The security field may be used as a cookie. This would be similar to 332 the cookie mechanism described in L2TP [RFC3931], and the general 333 properties should be the same. A cookie MAY be used to validate the 334 encapsulation. A cookie is a shared value between an encapsulator and 335 decapsulator which SHOULD be chosen randomly and MAY be changed 336 periodically. Different cookies MAY be used for logical flows between 337 the encapsulator and decapsulator; for instance packets sent with 338 different VNIs in network virtualization [I.D.hy-nvo3-gue-4-nvo] 339 might have different cookies. Cookies can be 64, 128, or 256 bits in 340 size. 342 4.4.1. Extension field format 344 The cookie security option is a 64, 128, or 256 bit field. The 345 security flags are set to 001b, 010b, 011b respectively for the 346 corresponding field size. 348 The format of the field is: 350 0 1 2 3 351 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 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | | 354 ~ Cookie ~ 355 | | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 Fields are: 360 o Cookie: Shared cookie value between encapsulator and 361 decapsulator 363 4.3.1. Operation 365 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 indicates no 419 payload data in used in the calculation. 421 o HMAC: Output of HMAC computation 423 The HMAC field is the output of the HMAC computation (per [RFC2104]) 424 using a pre-shared key identified by HMAC Key-id and of the text 425 which consists of the concatenation of: 427 o The IP addresses 429 o The GUE header including all optional extensions and any private 430 data. For the purposes of calculating the HMAC value, the HMAC 431 value is set all zeroes. 433 o Optionally some or all of GUE payload. The portion of payload 434 covered is indicated by an offset into the payload and a length 435 relative to the offset. 437 The purpose of the HMAC option is to verify the validity, the 438 integrity, and the authentication of the GUE header itself and 439 optionally some or all of the GUE payload. 441 The HMAC Key-id field allows for the simultaneous existence of 442 several hash algorithms (SHA-256, SHA3-256 ... or future ones) as 443 well as pre-shared keys. The HMAC Key-id field is opaque, i.e., it 444 has neither syntax nor semantic. Having an HMAC Key-id field allows 445 for pre-shared key roll-over when two pre-shared keys are supported 446 for a while when GUE endpoints converge to a fresher pre-shared key. 448 4.4.2. Selecting a hash algorithm 450 The HMAC field in the HMAC option is 256 bits wide. Therefore, the 451 HMAC MUST be based on a hash function whose output is at least 256 452 bits. If the output of the hash function is 256 bits, then this 453 output is simply inserted in the HMAC field. If the output of the 454 hash function is larger than 256 bits, then the output value is 455 truncated to 256 bits by taking the least-significant 256 bits and 456 inserting them in the HMAC field. 458 GUE implementations can support multiple hash functions but MUST 459 implement SHA-2 [FIPS180-4] and its SHA-256 variant. 461 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 508 The procedure for verifying the HMAC security option is: 510 1) If the payload offset plus the payload coverage length is 511 greater than the length of the encapsulated payload then drop 512 the packet. 514 2) Note value in the HMAC field and set the HMAC field to zero. 516 3) Calculate the HMAC hash over the concatenation of the IP source 517 and destination addresses. The particular hash and keys are 518 agreed between the encpasulator and decapsulator out of band, 519 and the key for input to the hash is the one indicated by the 520 Key-Id amongst the set of shared keys. 522 4) Continue the HMAC hash calculation from the start of the GUE 523 header through the its length as indicated in GUE Hlen. 525 5) Continue the calculation to cover the payload portion if 526 payload coverage is enabled (payload length field is non-zero). 527 The calculation continues at the payload offset for payload 528 length bytes. 530 6) Compare the computed HMAC value with the original value of the 531 HMAC field. If they are equal then the packet is accepted, if 532 they are not equal then verification failed and the packet MUST 533 be dropped. 535 7) Restore the HMAC field to its original value. 537 4.5. Interaction with other optional extensions 539 If GUE fragmentation (section 5) is used in concert with the GUE 540 security option, the security option processing is performed after 541 fragmentation at the encapsulator and before reassembly at the 542 decapsulator. 544 The GUE payload transform option (section 6) may be used in concert 545 with the GUE security option. The payload transform option could be 546 used to encrypt the GUE payload to provide privacy for an 547 encapsulated packet during transit. The security option provides 548 authentication and integrity for the GUE header (including the 549 payload transform field in the header). The two functions are 550 processed separately at tunnel end points. A GUE tunnel can use both 551 functions or use one of them. Section 6.3 details handling when both 552 are used in a packet. 554 5. Fragmentation option 555 The fragmentation option allows an encapsulator to perform 556 fragmentation of packets being ingress to a tunnel. Procedures for 557 fragmentation and reassembly are defined in this section. This 558 specification adapts the procedures for IP fragmentation and 559 reassembly described in [RFC0791] and [RFC8200]. Fragmentation can be 560 performed on both data and control messages in GUE. 562 5.1. Motivation 564 This section describes the motivation for having a fragmentation 565 option in GUE. 567 MTU and fragmentation issues with In-the-Network Tunneling are 568 described in [RFC4459]. Considerations need to be made when a packet 569 is received at a tunnel ingress point which may be too large to 570 traverse the path between tunnel endpoints. 572 There are four suggested alternatives in [RFC4459] to deal with this: 574 1) Fragmentation and Reassembly by the Tunnel Endpoints 576 2) Signaling the Lower MTU to the Sources 578 3) Encapsulate Only When There is Free MTU 580 4) Fragmentation of the Inner Packet 582 Many tunneling protocol implementations have assumed that 583 fragmentation should be avoided, and in particular alternative #3 584 seems preferred for deployment. In this case, it is assumed that an 585 operator can configure the MTUs of links in the paths of tunnels to 586 ensure that they are large enough to accommodate any packets and 587 required encapsulation overhead. This method, however, may not be 588 feasible in certain deployments and may be prone to misconfiguration 589 in others. 591 Similarly, the other alternatives have drawbacks that are described 592 in [RFC4459]. Alternative #2 implies use of something like Path MTU 593 Discovery which is not known to be sufficiently reliable. Alternative 594 #4 is not permissible with IPv6 or when the DF bit is set for IPv4, 595 and it also introduces other known issues with IP fragmentation. 597 For alternative #1, fragmentation and reassembly at the tunnel 598 endpoints, there are two possibilities: encapsulate the large packet 599 and then perform IP fragmentation, or segment the packet and then 600 encapsulate each segment (a non-IP fragmentation approach). 602 Performing IP fragmentation on an encapsulated packet has the same 603 issues as that of normal IP fragmentation. Most significant of these 604 is that the Identification field is only sixteen bits in IPv4 which 605 introduces problems with wraparound as described in [RFC4963]. 607 The second possibility of alternative #1 follows the suggestion 608 expressed in [RFC2764] and the fragmentation feature described in the 609 AERO protocol [I.D.templin-aerolink]; that is for the tunneling 610 protocol itself to incorporate a fragmentation and reassembly 611 capability. In this method, fragmentation is part of the 612 encapsulation and an encapsulation header contains the information 613 for reassembly. This differs from IP fragmentation in that the IP 614 headers of the original packet are not replicated for each fragment. 616 Incorporating fragmentation into the encapsulation protocol has some 617 advantages: 619 o At least a 32 bit identifier can be defined to avoid issues of 620 the 16 bit Identification in IPv4. 622 o Encapsulation mechanisms for security and identification, such 623 as group identifiers, can be applied to each segment. 625 o This allows the possibility of using alternate fragmentation and 626 reassembly algorithms (e.g. fragmentation with Forward Error 627 Correction). 629 o Fragmentation is transparent to the underlying network so it is 630 unlikely that fragmented packet will be unconditionally dropped 631 as might happen with IP fragmentation. 633 5.2. Scope 635 This specification describes the mechanics of fragmentation in 636 Generic UDP Encapsulation. The operational aspects and details for 637 higher layer implementation must be considered for deployment, but 638 are considered out of scope for this document. The AERO protocol 639 [I.D.templin-aerolink] defines one use case of fragmentation with 640 encapsulation. 642 5.3. Extension field format 644 The presence of the GUE fragmentation option is indicated by the F 645 bit in the GUE header. 647 The format of the fragmentation option is: 649 0 1 2 3 650 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 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | Fragment offset |Res|M| Orig-proto | | 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 654 | Identification | 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 The fields of the option are: 659 o Fragment offset: This field indicates where in the datagram this 660 fragment belongs. The fragment offset is measured in units of 8 661 octets (64 bits). The first fragment has offset zero. 663 o Res: Two bit reserved field. MUST be set to zero for 664 transmission. If set to non-zero in a received packet then the 665 packet MUST be dropped. 667 o M: More fragments bit. Set to 1 when there are more fragments 668 following in the datagram, set to 0 for the last fragment. 670 o Orig-proto: The control type (when the C-bit in the GUE header 671 is set) or the IP protocol (when C-bit is not set) of the 672 fragmented packet. 674 o Identification: 40 bits. Identifies fragments of a fragmented 675 packet. 677 Pertinent GUE header fields to fragmentation are: 679 o C-bit: This is set for each fragment based on the whether the 680 original packet being fragmented is a control or data message. 682 o Proto/ctype - For the first fragment (fragment offset is zero) 683 this is set to that of the original packet being fragmented 684 (either will be a control type or IP protocol). For other 685 fragments, this is set to zero for a control message being 686 fragmented, or to "No next header" (protocol number 59) for a 687 data message being fragmented. 689 o F bit - Set to indicate presence of the fragmentation extension 690 field. 692 5.4. Fragmentation procedure 694 If an encapsulator determines that a packet must be fragmented (e.g. 695 the packet's size exceeds the Path MTU of the tunnel) it should 696 divide the packet into fragments and send each fragment as a separate 697 GUE packet, to be reassembled at the decapsulator (tunnel egress). 699 For every packet that is to be fragmented, the source node generates 700 an Identification value. The Identification MUST be different than 701 that of any other fragmented packet sent within the past 60 seconds 702 (Maximum Segment Lifetime) or configured time with the same tunnel 703 identification-- that is the same outer source and destination 704 addresses, same UDP ports, same orig-proto, and same group identifier 705 if present. 707 The initial, unfragmented, and unencapsulated packet is referred to 708 as the "original packet". This will be a layer 2 packet, layer 3 709 packet, or the payload of a GUE control message: 711 +-------------------------------//------------------------------+ 712 | Original packet | 713 | (e.g. an IPv4, IPv6, Ethernet packet) | 714 +------------------------------//-------------------------------+ 716 Fragmentation and encapsulation are performed on the original packet 717 in sequence. First the packet is divided up in to fragments, and then 718 each fragment is encapsulated. Each fragment, except possibly the 719 last ("rightmost") one, is an integer multiple of eight octets long. 720 Fragments MUST be non-overlapping. The number of fragments SHOULD be 721 minimized, and all but the last fragment should be approximately 722 equal in length. 724 The fragments are transmitted in separate "fragment packets" as: 726 +--------------+--------------+---------------+--//--+----------+ 727 | first | second | third | | last | 728 | fragment | fragment | fragment | .... | fragment | 729 +--------------+--------------+---------------+--//--+----------+ 731 Each fragment is encapsulated as the payload of a GUE packet. This is 732 illustrated as: 734 +------------------+----------------+-----------------------+ 735 | IP/UDP header | GUE header | first | 736 | | w/ frag option | fragment | 737 +------------------+----------------+-----------------------+ 739 +------------------+----------------+-----------------------+ 740 | IP/UDP header | GUE header | second | 741 | | w/ frag option | fragment | 742 +------------------+----------------+-----------------------+ 743 o 744 o 746 +------------------+----------------+-----------------------+ 747 | IP/UDP header | GUE header | last | 748 | | w/ frag option | fragment | 749 +------------------+----------------+-----------------------+ 751 Each fragment packet is composed of: 753 (1) Outer IP and UDP headers as defined for GUE encapsulation. The 754 IP addresses and UDP ports MUST be the same for all fragments 755 of a fragmented packet. 757 (2) A GUE header that indicates the fragmentation option is 758 present. The C-bit and and proto/ctype are set appropriately 759 as described above. 761 (3) The GUE fragmentation option. Orig-protocol is set to the 762 protocol of the original packet. The M-bit is set for all 763 fragments except the last one. Fragment offset is set as the 764 offset of each fragment in the original packet. 766 (4) Other GUE extensions. 768 (5) The fragment itself as payload of the GUE packet. 770 5.5. Reassembly procedure 772 At the destination, fragment packets are decapsulated and reassembled 773 into their original, unfragmented form, as illustrated: 775 +-------------------------------//------------------------------+ 776 | Original packet | 777 | (e.g. an IPv4, IPv6, Ethernet packet) | 778 +------------------------------//-------------------------------+ 780 The following rules govern reassembly: 782 The IP/UDP/GUE headers of each packet are retained until all 783 fragments have arrived. The reassembled packet is then composed 784 of the decapsulated payloads in the GUE packets, and the 785 IP/UDP/GUE headers are discarded. 787 When a GUE packet is received with the fragment extension, the 788 proto/ctype field in the GUE header MUST be validated. In the 789 case that the packet is a first fragment (fragment offset is 790 zero), the proto/ctype in the GUE header MUST equal the orig- 791 proto value in the fragmentation option. For subsequent 792 fragments, (fragment offset is non-zero) the proto/ctype in the 793 GUE header MUST be 0 for a control message or 59 (no-next-hdr) 794 for a data message. If the proto/ctype value is invalid for a 795 received packet it MUST be dropped. 797 An original packet is reassembled only from GUE fragment packets 798 that have the same outer source address, destination address, 799 UDP source port, UDP destination port, GUE header C-bit, group 800 identifier if present, orig-proto value in the fragmentation 801 option, and Fragment Identification. The protocol type or 802 control message type (depending on the C-bit) for the 803 reassembled packet is the value of the GUE header proto/ctype 804 field in the first fragment. 806 The following error conditions can arise when reassembling fragmented 807 packets with GUE encapsulation: 809 If insufficient fragments are received to complete reassembly of 810 a packet within 60 seconds (or a configurable period) of the 811 reception of the first-arriving fragment of that packet, 812 reassembly of that packet MUST be abandoned and all the 813 fragments that have been received for that packet MUST be 814 discarded. 816 If the payload length of a fragment is not a multiple of 8 817 octets and the M flag of that fragment is 1, then that fragment 818 MUST be discarded. 820 If the length and offset of a fragment are such that the payload 821 length of the packet reassembled from that fragment would exceed 822 65,535 octets, then that fragment MUST be discarded. 824 If a fragment overlaps another fragment already saved for 825 reassembly then the new fragment that overlaps the existing 826 fragment MUST be discarded. 828 If the first fragment is too small then it is possible that it does 829 not contain the necessary headers for a stateful firewall. Sending 830 small fragments like this has been used as an attack on IP 831 fragmentation. To mitigate this problem, an implementation SHOULD 832 ensure that the first fragment contains the headers of the 833 encapsulated packet at least through the transport header. 835 A GUE node MUST be able to accept a fragmented packet that, after 836 reassembly and decapsulation, is as large as 1500 octets. This means 837 that the node must configure a reassembly buffer that is at least as 838 large as 1500 octets plus the maximum-sized encapsulation headers 839 that may be inserted during encapsulation. Implementations may find 840 it more convenient and efficient to configure a reassembly buffer 841 size of 2KB which should be large enough to accommodate even the 842 largest set of encapsulation headers and provides a natural memory 843 page size boundary. 845 5.6. Security Considerations 847 Exploits that have been identified with IP fragmentation are 848 conceptually applicable to GUE fragmentation. 850 Attacks on GUE fragmentation can be mitigated by: 852 o Hardened implementation that applies applicable techniques from 853 implementation of IP fragmentation. 855 o Application of GUE security (section 4) or IPsec [RFC4301]. 856 Security mechanisms can prevent spoofing of fragments from 857 unauthorized sources. 859 o Implement fragment filter techniques for GUE encapsulation as 860 described in [RFC1858] and [RFC3128]. 862 o Do not accept data in overlapping segments. 864 o Enforce a minimum size for the first fragment. 866 6. Payload transform option 868 The payload transform option indicates that the GUE payload has been 869 transformed. Transforming a payload is done by running a function 870 over the data and possibly modifying it (encrypting it for instance). 871 The payload transform option indicates the method used to transform 872 the data so that a decapsulator is able to validate and reverse the 873 transformation to recover the original data. Payload transformations 874 include encryption, authentication, CRC coverage, and compression. 875 This specification defines a transformation for DTLS. 877 6.1. Extension field format 879 The presence of the GUE payload transform option is indicated by the 880 T bit in the GUE header. 882 The format of Payload Transform Field is: 884 0 1 2 3 885 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 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 | Type | P_C_type | Info | 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 889 The fields of the option are: 891 Type: Payload Transform Type or Code point. Each payload transform 892 mechanism must have one code point registered in IANA. This 893 document specifies: 895 0x01: for DTLS [RFC6347] 897 0x80~0xFF: for private payload transform types 899 A private payload transform type can be used for 900 experimental purposes or proprietary mechanisms. 902 P_C_type: Indicates the protocol or control type of the 903 untransformed payload. When payload transform option is 904 present, proto/ctype in the GUE header is set to 59 ("No 905 next header") for a data message and zero for a control 906 message. The IP protocol or control message type of the 907 untransformed payload MUST be encoded in this field. The 908 benefit of this rule is to prevent a middle box from 909 inspecting the encrypted payload according to GUE next 910 protocol. The assumption here is that a middle box may 911 understand GUE base header but does not understand GUE 912 option flag definitions. 914 Info: A field that can be set according to the requirements of 915 each payload transform type. If the specification for a 916 payload transform type does not specify how this field is to 917 be set, then the field MUST be set to zero. 919 6.2. Usage 921 The payload transform option provides a mechanism to transform or 922 interpret the payload of a GUE packet. The Type field provides the 923 method used to transform the payload, and the P_C_type field provides 924 the protocol or control message type of the payload before being 925 transformed. The payload transformation option is generic so that it 926 can have both security related uses (such as DTLS) as well as non 927 security related uses (such as compression, CRC, etc.). 929 An encapsulator performs payload transformation before transmission, 930 and a decapsulator performs the reverse transformation before 931 accepting a packet. For example, if an encapsulator transforms a 932 payload by encrypting it, the peer decaspsulator MUST decrypt the 933 payload before accepting the packet. If a decapsulator fails to 934 perform the reverse transformation or cannot validate the 935 transformation it MUST discard the packet and MAY generate an alert 936 to the management system. 938 6.3. Interaction with other optional extensions 940 If GUE fragmentation (section 5) is used in concert with the GUE 941 transform option, the transform option processing is performed after 942 fragmentation at the encapsulator and before reassembly at the 943 decapsulator. If the payload transform changes the size of the data 944 being fragmented this must be taken into account during 945 fragmentation. 947 If both the security option and the payload transform are used in a 948 GUE packet, an encapsulator MUST perform the payload transformation 949 first, set the payload transform option in the GUE header, and then 950 create the security option. A decapsulator does processing in 951 reverse-- the security option is processed (GUE header is validated) 952 and then the reverse payload transform is performed. 954 In order to get flow entropy from the payload, an encapsulator should 955 derive the flow entropy before performing a payload transform. 957 6.4. DTLS transform 959 The payload of a GUE packet can be secured using Datagram Transport 960 Layer Security (DTLS) [RFC6347]. An encapsulator would apply DTLS to 961 the GUE payload so that the payload packets are encrypted and the GUE 962 header remains in plaintext. The payload transform option is set to 963 indicate that the payload is interpreted as a DTLS record. 965 The payload transform option for DTLS is: 967 0 1 2 3 968 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 969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 970 | 1 | P_C_type | 0 | 971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 DTLS [RFC6347] provides a packet fragmentation capability. To avoid 974 packet fragmentation being performed multiple times, a GUE 975 encapsulator SHOULD use GUE fragmentation and not DTLS fragmentation. 977 DTLS usage is limited to a single DTLS session for any specific 978 tunnel encapsulator/decapsulator pair (identified by source and 979 destination IP addresses). Both IP addresses MUST be unicast 980 addresses - multicast traffic is not supported when DTLS is used. A 981 GUE tunnel decapsulator implementation that supports DTLS can 982 establish DTLS sessions with one or multiple tunnel encapsulators, 983 and likewise a GUE tunnel encapsulator implementation can establish 984 DTLS sessions with one or multiple decapsulators. 986 7. Remote checksum offload option 988 Remote checksum offload is mechanism that provides checksum offload 989 of encapsulated packets using rudimentary offload capabilities found 990 in most Network Interface Card (NIC) devices. Many NIC 991 implementations can only offload the outer UDP checksum in UDP 992 encapsulation. Remote checksum offload is described in [UDPENCAP]. 994 In remote checksum offload the outer header checksum, that in the 995 outer UDP header, is enabled in packets and, with some additional 996 meta information, a receiver is able to deduce the checksum to be set 997 for an inner encapsulated packet. Effectively this offloads the 998 computation of the inner checksum. Enabling the outer checksum in 999 encapsulation has the additional advantage that it covers more of the 1000 packet, including the encapsulation headers, than an inner checksum. 1002 7.1. Extension field format 1004 The presence of the GUE remote checksum offload option is indicated 1005 by the R bit in the GUE header. 1007 The format of remote checksum offload field is: 1009 0 1 2 3 1010 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 1011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1012 | Checksum start | Checksum offset | 1013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 The fields of the option are: 1017 o Checksum start: starting offset for checksum computation 1018 relative to the start of the encapsulated payload. This is 1019 typically the offset of a transport header (e.g. UDP or TCP). 1021 o Checksum offset: Offset relative to the start of the 1022 encapsulated packet where the derived checksum value is to be 1023 written. This typically is the offset of the checksum field in 1024 the transport header (e.g. UDP or TCP). 1026 7.2. Usage 1028 7.2.1. Transmitter operation 1030 The typical actions to set remote checksum offload on transmit are: 1032 1) Transport layer creates a packet and indicates in internal 1033 packet meta data that checksum is to be offloaded to the NIC 1034 (normal transport layer processing for checksum offload). The 1035 checksum field is populated with the bitwise "not" of the 1036 checksum of the pseudo header or zero as appropriate. 1038 2) Encapsulation layer adds its headers to the packet including 1039 the remote checksum offload option. The start offset and 1040 checksum offset are set accordingly. 1042 3) Encapsulation layer arranges for checksum offload of the outer 1043 header checksum (i.e. UDP checksum). 1045 4) Packet is sent to the NIC. The NIC will perform transmit 1046 checksum offload and set the checksum field in the outer 1047 header. The inner header and rest of the packet are transmitted 1048 without modification. 1050 7.2.2. Receiver operation 1052 The typical actions a host receiver does to support remote checksum 1053 offload are: 1055 1) Receive packet and validate outer checksum following normal 1056 processing (i.e. validate non-zero UDP checksum). 1058 2) Validate the remote checksum option. If checksum start is 1059 greater than the length of the packet, then the packet MUST be 1060 dropped. If checksum offset is greater then the length of the 1061 packet minus two, then the packet MUST be dropped. 1063 3) Deduce full checksum for the IP packet. If a NIC is capable of 1064 receive checksum offload it will return either the full 1065 checksum of the received packet or an indication that the UDP 1066 checksum is correct. Either of these methods can be used to 1067 deduce the checksum over the IP packet [UDPENCAP]. 1069 4) From the packet checksum subtract the checksum computed from 1070 the start of the packet (outer IP header) to the offset in the 1071 packet indicted by checksum start in the meta data. The result 1072 is the deduced checksum to set in the checksum field of the 1073 encapsulated transport packet. 1075 In pseudo code: 1077 csum: initialized to checksum computed from start (outer IP 1078 header) to the end of the packet 1079 start_of_packet: address of start of packet 1080 encap_payload_offset: relative to start_of_packet 1081 csum_start: value from the checksum start field 1082 checksum(start, len): function to compute checksum from start 1083 address for len bytes 1085 csum -= checksum(start_of_packet, encap_payload_offset + 1086 csum_start) 1088 5) Write the resultant checksum value into the packet at the 1089 offset provided by checksum offset in the meta data. 1091 In pseudo code: 1093 csum_offset: value from the checksum offset field 1095 *(start_of_packet + encap_payload_offset + 1096 csum_offset) = csum 1098 6) Checksum is verified at the transport layer using normal 1099 processing. This should not require any checksum computation 1100 over the packet since the complete checksum has already been 1101 provided. 1103 7.3. Security Considerations 1105 Remote checksum offload allows a means to change the GUE payload 1106 before being received at a decapsulator. In order to prevent misuse 1107 of this mechanism, a decapsulator MUST apply security checks on the 1108 GUE payload only after checksum remote offload has been processed. 1110 8. Checksum option 1112 The GUE checksum option provides a checksum that covers the GUE 1113 header, a GUE pseudo header, and optionally all or part of the GUE 1114 payload. The GUE pseudo header includes the corresponding IP 1115 addresses as well as the UDP ports of the encapsulating headers. This 1116 checksum should provide protection against address corruption in IPv6 1117 when the UDP checksum is zero. Additionally, the GUE checksum 1118 provides protection of the GUE header when the UDP checksum is set to 1119 zero with either IPv4 or IPv6. In particular, the GUE checksum can 1120 provide protection for some sensitive data, such as the virtual 1121 network identifier ([I.D.hy-nvo3-gue-4-nvo]), which when corrupted 1122 could lead to mis-delivery of a packet to the wrong virtual network. 1124 8.1. Extension field format 1126 The presence of the GUE checksum option is indicated by the K bit in 1127 the GUE header. 1129 The format of the checksum extension is: 1131 0 1 2 3 1132 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 1133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1134 | Checksum | Payload coverage | 1135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1137 The fields of the option are: 1139 o Checksum: Computed checksum value. This checksum covers the GUE 1140 header (including fields and private data covered by Hlen), the 1141 GUE pseudo header, and optionally all or part of the payload 1142 (encapsulated packet). 1144 o Payload coverage: Number of bytes of payload to cover in the 1145 checksum. Zero indicates that the checksum only covers the GUE 1146 header and GUE pseudo header. If the value is greater than the 1147 encapsulated payload length, the packet MUST be dropped. 1149 8.2. Requirements 1151 The GUE header checksum SHOULD be set on transmit when using a zero 1152 UDP checksum with IPv6. 1154 The GUE header checksum SHOULD be used when the UDP checksum is zero 1155 for IPv4 if the GUE header includes data that when corrupted can lead 1156 to misdelivery or other serious consequences, and there is no other 1157 mechanism that provides protection (no security field that checks 1158 integrity for instance). 1160 The GUE header checksum SHOULD NOT be set when the UDP checksum is 1161 non-zero. In this case the UDP checksum provides adequate protection 1162 and this avoids convolutions when a packet traverses NAT that does 1163 address translation (in that case the UDP checksum is required). 1165 8.3. GUE checksum pseudo header 1167 The GUE pseudo header checksum is included in the GUE checksum to 1168 provide protection for the IP and UDP header elements which when 1169 corrupted could lead to misdelivery of the GUE packet. The GUE pseudo 1170 header checksum is similar to the standard IP pseudo header defined 1171 in [RFC0768] and [RFC0793] for IPv4, and in [RFC8200] for IPv6. 1173 The GUE pseudo header for IPv4 is: 1175 0 1 2 3 1176 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 1177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1178 | Source Address | 1179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1180 | Destination Address | 1181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1182 | Source port | Destination port | 1183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1185 The GUE pseudo header for IPv6 is: 1187 0 1 2 3 1188 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 1189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1190 | | 1191 + + 1192 | | 1193 + Source Address + 1194 | | 1195 + + 1196 | | 1197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1198 | | 1199 + + 1200 | | 1201 + Destination Address + 1202 | | 1203 + + 1204 | | 1205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1206 | Source port | Destination port | 1207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1209 The GUE pseudo header does not include payload length or protocol as 1210 in the standard IP pseudo headers. The length field is deemed 1211 unnecessary for inclusion because a corrupted length field should not 1212 cause mis-delivery, the GUE checksum is applied after GUE 1213 fragmentation, and without the length field the GUE pseudo header 1214 checksum is the same for all packets of flow. 1216 8.4. Usage 1218 The GUE checksum is computed and verified following the standard 1219 process for computing the Internet checksum [RFC1071]. Checksum 1220 computation may be optimized per the mathematical properties 1221 including parallel computation and incremental updates. 1223 8.4.1. Transmitter operation 1225 The procedure for setting the GUE checksum on transmit is: 1227 1) Create the GUE header including the checksum and payload 1228 coverage fields. The checksum field is initially set to zero. 1230 2) Calculate the 1's complement checksum of the GUE header from 1231 the start of the header through the its length as indicated in 1232 GUE Hlen. 1234 3) Calculate the checksum of the GUE pseudo header for IPv4 or 1235 IPv6. 1237 4) Calculate checksum of payload portion if payload coverage is 1238 enabled (payload coverage field is non-zero). If the length of 1239 the payload coverage is odd, logically append a single zero 1240 byte for the purposes of checksum calculation. 1242 5) Add and fold the computed checksums for the GUE header, GUE 1243 pseudo header, and payload coverage. 1245 6) Set the bitwise not of the resultant value in the GUE checksum 1246 field. 1248 8.4.2. Receiver operation 1250 If the GUE checksum option is present, the receiver MUST validate the 1251 checksum before processing any other fields or accepting the packet. 1253 The procedure for verifying the checksum is: 1255 1) If the payload coverage length is greater than the length of 1256 the encapsulated payload then drop the packet. 1258 2) Calculate the checksum of the GUE header from the start of the 1259 header to the end as indicated by Hlen. 1261 3) Calculate the checksum of the GUE pseudo header for IPv4 or 1262 IPv6. 1264 4) Calculate the checksum of payload if payload coverage is 1265 enabled (payload coverage is non-zero). If the length of the 1266 payload coverage is odd logically append a single zero byte for 1267 the purposes of checksum calculation. 1269 5) Sum the computed checksums for the GUE header, GUE pseudo 1270 header, and payload coverage. If the result is all 1 bits (-0 1271 in 1's complement arithmetic), the checksum is valid and the 1272 packet is accepted; otherwise the checksum is considered 1273 invalid and the packet MUST be dropped. 1275 8.5. Corrupted checksum flag 1277 Note that the GUE checksum does not protect against the checksum flag 1278 (K flag) being corrupted. If an encapsulator sets the checksum flag 1279 and option but the K bit flips to be zero, then a decapsulator will 1280 incorrectly process the GUE packet as not having a checksum field. 1282 To mitigate this issue an encapsulator and depcapsulator might agree 1283 that checksum is always required. This agreement could be established 1284 by configuration or capability negotiation. 1286 8.6. Security Considerations 1288 The checksum option is only a mechanism for corruption detection, it 1289 is not a security mechanism. To provide integrity checks or 1290 authentication of the GUE header, the GUE security option SHOULD be 1291 used. 1293 9. NAT checksum address option 1295 The NAT address checksum (NAC) option contains the checksum computed 1296 over the IP addresses of the packet. The computed value can be used 1297 by a receiver to adjust a transport layer checksum that was affected 1298 by NAT changing the IP addresses. This option is only useful when GUE 1299 encapsulates a transport layer packet that has a checksum with a 1300 pseudo header that includes the IP addresses (such as TCP or UDP). 1302 9.1. Extension field format 1304 The presence of the NAT address checksum option is indicated by the N 1305 bit in the GUE header. 1307 The format of the NAT checksum address extension is: 1309 0 1 2 3 1310 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 1311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1312 | Checksum | Reserved | 1313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1314 The fields of the option are: 1316 o Checksum: Computed checksum value. This checksum covers the 1317 outer IP addresses. 1319 o Reserved: Must be zero on transmit. 1321 9.2. Usage 1323 The NAT address extension SHOULD be set on transmit when 1324 encapsulating a transport layer packet whose checksum might be 1325 affected by NAT being performed on the outer IP header. If this 1326 option is used then the UDP checksum MUST be used (sent with non-zero 1327 value). 1329 The NAT address checksum is computed using the Internet checksum 1330 [RFC1071]. 1332 9.2.1. Transmitter operation 1334 The procedure for setting the GUE checksum on transmit is: 1336 An encapsulator computes the checksum value over the IP addresses in 1337 the IP header. 1339 1) Compute the ones complement checksum over the source and 1340 destination IPv4 or IPv6 addresses. 1342 2) Set the resultant value in the Checksum field. 1344 For IPv4 the checksum is computed over: 1346 0 1 2 3 1347 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 1348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1349 | Source Address | 1350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1351 | Destination Address | 1352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1353 For IPv6 the checksum is computed over: 1355 0 1 2 3 1356 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 1357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1358 | | 1359 + + 1360 | | 1361 + Source Address + 1362 | | 1363 + + 1364 | | 1365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1366 | | 1367 + + 1368 | | 1369 + Destination Address + 1370 | | 1371 + + 1372 | | 1373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1375 9.2.2. Receiver operation 1377 1) Validate the UDP checksum is correct 1379 2) Compute the checksum over the IP addresses in the received 1380 packet 1382 3) Subtract the resultant from the checksum value in the NAC 1383 option. If the difference is non-zero then NAT has changed the 1384 addresses 1386 4) When processing a transport layer containing a checksum 1387 affected by NAT on the IP addresses, add the difference into 1388 the checksum calculation when verifying the packet. 1390 In pseudo codes this is: 1392 actual = checksum(IP addresses) 1393 diff = actual - NAC_value 1394 verify = checksum(transport packet) + checksum(pseudo header) 1395 + diff 1397 if (verify == 0) 1398 packet is good 1400 10. Alternative checksum option 1401 The alternative checksum option contains a check over the GUE header 1402 and optionally all or part of the GUE payload. The algorithm used is 1403 CRC-32C which is the same as that used by iSCSI and SCTP. The 1404 alternative checksum can provide stronger protection against data 1405 corruption than that provided by the one's complement checksum used 1406 in the UDP checksum or the GUE checksum (section 8). 1408 10.1. Extension field format 1410 The presence of the GUE alternate checksum option is indicated by the 1411 A bit in the GUE header. 1413 The format of alternate checksum field is: 1415 0 1 2 3 1416 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 1417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1418 | Reserved | Payload coverage | 1419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1420 | CRC | 1421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1423 The fields of the option are: 1425 o CRC: Computed CRC value. This CRC covers the GUE header 1426 (including fields and private data covered by Hlen) and 1427 optionally all or part of the payload (encapsulated packet). 1429 o Payload coverage: Number of bytes of payload to cover in the CRC 1430 calculation. Zero indicates that the checksum only covers the 1431 GUE header. If the value is greater than the encapsulated 1432 payload length, the packet MUST be dropped. 1434 10.2. Usage 1436 The 32-bit alternative checksum does not include a pseudo header 1437 containing IP addresses or ports. 1439 CRC-32C is calculated using the 0x1EDC6F41 polynomial: 1441 x^32 + x^28 + x^27 + x^26 + x^25 + x^23 + x^22 + x^20 + x^19 + 1442 x^18 + x^14 +x^13 + +x^11 + x^10 +x^9 +x^8 + x + 1 1444 The procedure for setting the GUE alternative checksum on transmit 1445 is: 1447 1) Create the GUE header including the alternative checksum field. 1448 The CRC field is initialized to zero. 1450 2) Calculate the CRC using the CRC-32C algorithm from the start of 1451 the GUE header through the its length as indicated in GUE Hlen. 1453 3) Continue the calculation to cover the payload portion if 1454 payload coverage is enabled (payload coverage field is non- 1455 zero). If the length of the payload coverage is not aligned to 1456 four bytes, logically append zero bytes up to the necessary 1457 alignment for the purposes of CRC calculation. 1459 4) Set the resultant value in the CRC field. 1461 10.2.2. Receiver operation 1463 If the GUE alternative checksum option is present, the receiver MUST 1464 validate the checksum before processing any other fields, except the 1465 GUE checksum, or accepting the packet. 1467 The procedure for verifying the alternate checksum is: 1469 1) If the payload coverage length is greater than the length of 1470 the encapsulated payload then drop the packet. 1472 2) Note value in the CRC field and set the CRC field to zero. 1474 3) Calculate the CRC using the CRC-32C algorithm from the start of 1475 the GUE header through the its length as indicated in GUE Hlen. 1477 4) Continue the calculation to cover the payload portion if 1478 payload coverage is enabled (payload coverage field is non- 1479 zero). If the length of the payload coverage is not aligned to 1480 four bytes, logically append zero bytes up to the necessary 1481 alignment for the purposes of CRC calculation. 1483 5) Compare the computed value with the original value of the CRC 1484 field. If they are equal then that packet is accepted, if they 1485 are not equal then verification failed and the packet MUST be 1486 dropped. 1488 6) Restore the CRC field to its original value. 1490 10.3. Corrupted alternate checksum flag 1492 Similar to the GUE checksum, the GUE alternate checksum does not 1493 protect against the alternative checksum flag (A flag) being 1494 corrupted. If an encapsulator sets the alternative checksum flags and 1495 option but the A bit flips to be zero, then a decapsulator will 1496 incorrectly process that packet as not having an alternate checksum 1497 field. 1499 To mitigate this issue an encapsulator and depcapsulator might agree 1500 that an alternate checksum is always required. This agreement could 1501 be established by configuration or GUE capability negotiation. 1503 10.4. Security Considerations 1505 The alternate checksum option is only a mechanism for corruption 1506 detection, it is not a security mechanism. To provide integrity 1507 checks or authentication of the GUE header, the GUE security option 1508 SHOULD be used. 1510 11. Processing order of options 1512 Options MUST be processed in a specific order for both transmission 1513 and reception. Note that some options, such as the checksum option, 1514 depend on other fields in the GUE header to be initialized. 1516 11.1. Processing order when sending 1518 When setting the security option (HMAC option in particular), the 1519 checksum option, or the alternate checksum option-- all the GUE 1520 fields being used must be present and properly set in the header. The 1521 checksum value in the checksum option or alternate checksum option 1522 MUST be initialized to zero to ensure consistent HMAC and checksum 1523 calculation. 1525 The order of processing options to send a GUE packet are: 1527 1) Fragment if necessary and set fragmentation option. If the 1528 group identifier is present it is copied into each fragment. If 1529 payload transformation will increase the size of the payload 1530 that MUST be accounted for when deciding how to fragment. Apply 1531 processing below for each fragment 1533 2) Set group identifier option (to the same value for each 1534 fragment) 1536 3) Perform payload transform (potentially on a fragment) and set 1537 payload transform option. 1539 4) Set Remote checksum offload. 1541 5) Set NAT address checksum option. 1543 6) Set security option per cookie or HMAC calculation. 1545 7) Calculate GUE alternate checksum and set the alternate checksum 1546 option. 1548 8) Calculate GUE checksum and set checksum option. 1550 11.2. Processing order when receiving 1552 On reception the order of actions is: 1554 1) Verify GUE checksum. 1556 2) Verify alternate checksum. If the GUE checksum option is 1557 present, set its checksum fields to zero for computing the 1558 alternate checksum. After computation, restore the checksum 1559 value in the GUE checksum field. 1561 3) Verify security option. If the GUE checksum option or alternate 1562 checksum option are also present and HMAC computation is being 1563 done over the GUE header, then set the checksum fields to zero 1564 for computing the HMAC. After computation, restore the checksum 1565 values. 1567 4) Save the NAT address checksum value. It will be applied when 1568 processing the encapsulated packet. 1570 5) Adjust packet for remote checksum offload. 1572 6) Perform payload transformation (i.e. decrypt payload). 1574 7) Perform reassembly. 1576 8) Process packet (take group identifier into account if present). 1578 The relative processing order between GUE extensions and private 1579 fields is unspecified in this specification. Any processing order 1580 requirements regarding private data must be agreed upon between an 1581 ecapsulator and decapsulator. 1583 12. Security Considerations 1585 Encapsulation of a network protocol in GUE should not increase 1586 security risk, nor provide additional security in itself. GUE 1587 requires that the source port for UDP packets SHOULD be randomly 1588 seeded to mitigate some possible denial service attacks. 1590 If the integrity and privacy of data packets being transported 1591 through GUE is a concern, the GUE security option and payload 1592 encryption using the the transform option SHOULD be used to remove 1593 the concern. If the integrity is the only concern, the tunnel may 1594 consider use of GUE security only for optimization. Likewise, if 1595 privacy is the only concern, the tunnel may use a GUE transform for 1596 encryption only. 1598 If a GUE payload already provides secure mechanism, e.g., the payload 1599 is an IPsec packet, it is still valuable to consider use of GUE 1600 security. 1602 GUE may rely on other secure tunnel mechanisms such as DTLS [RFC6347] 1603 over the whole UDP payload for securing the whole GUE packet or IPsec 1604 [RFC4301] to achieve the secure transport over an IP network or 1605 Internet. 1607 IPsec [RFC4301] was designed as a network security mechanism, and 1608 therefore resides at the network layer. As such, if the tunnel is 1609 secured with IPsec, the UDP header would not be visible to 1610 intermediate routers in either IPsec tunnel or transport mode. This 1611 is a drawback since it prohibits intermediate routers to perform load 1612 balancing based on the flow entropy in UDP header. In addition, this 1613 method prohibits some middle box functions on the path. 1615 By comparison, DTLS [RFC6347] was designed for application level 1616 security and can better preserve network and transport layer protocol 1617 information than IPsec [RFC4301]. Using DTLS over UDP to secure the 1618 GUE tunnel, both GUE header and payload will be encrypted. In order 1619 to differentiate plaintext GUE header from the encrypted GUE header, 1620 the destination port of the UDP header between two must be different, 1621 which essentially requires another standard UDP port for GUE with 1622 DTLS. The drawback on this method is to prevent a middle box 1623 operation to GUE tunnel on the path. 1625 Use of two independent tunnel mechanisms such as GUE and DTLS over 1626 UDP to carry a network protocol over an IP network adds some overlap 1627 and complexity. For example, fragmentation will be done twice. 1629 As the result, a GUE tunnel SHOULD use the security mechanisms 1630 specified in this document to provide secure transport over an IP 1631 network or Internet when it is needed. GUE encapsulation can be used 1632 as a secure transport mechanism over an IP network and Internet. 1634 13. IANA Consideration 1636 IANA is requested to create a "GUE flag-fields" registry to allocate 1637 flags and extension fields used with GUE. This shall be a registry of 1638 bit assignments for flags, length of extension fields for 1639 corresponding flags, and descriptive strings. There are sixteen bits 1640 for primary GUE header flags (bit number 0-15). New values are 1641 assigned in accordance with RFC Required policy [RFC5226]. New flags 1642 should be allocated from high to low order bit contiguously without 1643 holes. This document requests an initial assignment of flags in the 1644 registry. 1646 IANA is requested to assign flags for the extensions defined in this 1647 specification. Specifically, an assignment is requested for the Group 1648 Identfier, Security, Fragmentation, Payload Transform, Remote 1649 Checksum Offload, Checksum, NAT Checksum, and Alternate Checksum 1650 extensions in the "GUE flag-fields" registry. 1652 +-------------+---------------+-------------+--------------------+ 1653 | Flags bits | Field size | Description | Reference | 1654 +-------------+---------------+-------------+--------------------+ 1655 | Bit 0 | 4 bytes | Group | This document | 1656 | | | identifier | | 1657 | | | | | 1658 | Bit 1..3 | 001->8 bytes | Security | This document | 1659 | | 010->16 bytes | | | 1660 | | 011->32 bytes | | | 1661 | | 100->40 bytes | | | 1662 | | | | | 1663 | Bit 4 | 8 bytes | Fragmen- | This document | 1664 | | | tation | | 1665 | | | | | 1666 | Bit 5 | 4 bytes | Payload | This document | 1667 | | | transform | | 1668 | | | | | 1669 | Bit 6 | 4 bytes | Remote | This document | 1670 | | | checksum | | 1671 | | | offload | | 1672 | | | | | 1673 | Bit 7 | 4 bytes | Checksum | This document | 1674 | | | | | 1675 | Bit 8 | 4 bytes | NAT | This document | 1676 | | | checksum | | 1677 | | | address | | 1678 | | | | | 1679 | Bit 9 | 4 bytes | Alternate | This document | 1680 | | | checksum | | 1681 | | | | | 1682 | Bit 10..15 | | Unassigned | | 1683 +-------------+---------------+-------------+--------------------+ 1685 IANA is requested to set up a registry for the GUE payload transform 1686 types. Payload transform types are 8 bit values. New values for 1687 control types 1-127 are assigned via Standards Action [RFC5226]. 1689 +----------------+------------------+---------------+ 1690 | Transform type | Description | Reference | 1691 +----------------+------------------+---------------+ 1692 | 0 | Reserved | This document | 1693 | | | | 1694 | 1 | DTLS | This document | 1695 | | | | 1696 | 2..127 | Unassigned | | 1697 | | | | 1698 | 128..255 | User defined | This document | 1699 +----------------+------------------+---------------+ 1701 14. References 1703 14.1. Normative References 1705 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1706 1981. 1708 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1709 (IPv6) Specification", STD 86, RFC 8200, DOI 1710 10.17487/RFC8200, July 2017, . 1713 [RFC6347] Rescoria, E., Modadugu, N., "Datagram Transport Layer 1714 Security Version 1.2", RFC6347, 2012. 1716 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1717 August 1980. 1719 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 1720 793, DOI 10.17487/RFC0793, September 1981, . 1723 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1724 IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 1725 10.17487/RFC5226, May 2008, . 1728 [I.D.ietf-gue] T. Herbert, L. Yong, and O. Zia, "Generic UDP 1729 Encapsulation" draft-ietf-intarea-gue-01 1731 [FIPS180-4] Secure Hash Standard (SHS), Nation Institute of Standards 1732 and Technology, 8/2015 1734 14.2. Informative References 1736 [RFC3931] Lau, J., Townsley, W., et al, "Layer Two Tunneling Protocol 1737 - Version 3 (L2TPv3)", RFC3931, 1999 1739 [RFC2104] Kent, S. and R. Atkinson, "Security Architecture for the 1740 Internet Protocol" , RFC 2401, DOI 10.17487/RFC2401, 1741 November 1998, . 1743 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain of 1744 Interpretation" , RFC 6407, DOI 10.17487/RFC6407, October 1745 2011, . 1747 [RFC4459] Savola, ., "MTU and Fragmentation Issues with In-the- 1748 Network Tunneling", RFC 4459, DOI 10.17487/RFC4459, April 1749 2006, . 1751 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 1752 Errors at High Data Rates", RFC 4963, DOI 10.17487/RFC4963, 1753 July 2007, . 1755 [RFC2764] B. Gleeson, A. Lin, J. Heinanen, G. Armitage, A. Malis, "A 1756 Framework for IP Based Virtual Private Networks", RFC2764, 1757 February 2000. 1759 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1760 Internet Protocol", RFC 4301, December 2005. 1762 [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security 1763 Considerations for IP Fragment Filtering", RFC 1858, 1764 October 1995. 1766 [RFC3128] Miller, I., "Protection Against a Variant of the Tiny 1767 Fragment Attack (RFC 1858)", RFC 3128, June 2001. 1769 [RFC1071] Braden, R., Borman, D., and C. Partridge, "Computing the 1770 Internet checksum", RFC1071, September 1988. 1772 [I.D.hy-nvo3-gue-4-nvo] Yong, L., Herbert, T., "Generic UDP 1773 Encapsulation (GUE) for Network Virtualization Overlay" 1774 draft-hy-nvo3-gue-4-nvo-03 1776 [I.D.previdi-6man-sr-header] Previdi S. et al, "IPv6 Segment Routing 1777 Header (SRH) draft-ietf-6man-segment-routing-header-02 1779 [I.D.templin-aerolink] F. Templin, "Transmission of IP Packets over 1780 AERO Links" draft-templin-aerolink-62 1782 [UDPENCAP] T. Herbert, "UDP Encapsulation in Linux", 1783 http://people.netfilter.org/pablo/netdev0.1/papers/UDP- 1784 Encapsulation-in-Linux.pdf 1786 Authors' Addresses 1788 Tom Herbert 1789 Quantonium 1790 4701 Patrick Henry Dr. 1791 Santa Clara, CA 1792 USA 1794 EMail: tom@herbertland.com 1796 Lucy Yong 1797 Austin, TX 1798 USA 1800 Email: lucy.yong@huawei.com 1802 Fred L. Templin 1803 Boeing Research & Technology 1804 P.O. Box 3707 1805 Seattle, WA 98124 1806 USA 1808 Email: fltemplin@acm.org