idnits 2.17.1 draft-herbert-gue-extensions-01.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 223: '...y, the SEC flags MUST be set. Differen...' RFC 2119 keyword, line 318: '... HMAC MUST be based on a hash functi...' RFC 2119 keyword, line 325: '...pport multiple hash functions but MUST...' RFC 2119 keyword, line 479: '... packet MUST be dropped....' RFC 2119 keyword, line 532: '... Fragments MUST be non-overlapping. ...' (10 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 28, 2016) is 2730 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2104' is mentioned on line 297, but not defined == Missing Reference: 'FIPS180-4' is mentioned on line 326, but not defined == Missing Reference: 'RFC0793' is mentioned on line 1006, but not defined ** Obsolete undefined reference: RFC 793 (Obsoleted by RFC 9293) == Missing Reference: 'RFC5226' is mentioned on line 1217, but not defined ** Obsolete undefined reference: RFC 5226 (Obsoleted by RFC 8126) == Unused Reference: 'RFC1122' is defined on line 1238, but no explicit reference was found in the text == Unused Reference: 'RFC1624' is defined on line 1258, but no explicit reference was found in the text == Unused Reference: 'RFC1936' is defined on line 1261, but no explicit reference was found in the text == Unused Reference: 'RFC5925' is defined on line 1288, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 4 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT T. Herbert 3 Intended Status: Proposed Standard Facebook 4 Expires: May 1, 2017 L. Yong 5 Huawei 6 F. Templin 7 Boeing 9 October 28, 2016 11 Extensions for Generic UDP Encapsulation 12 draft-herbert-gue-extensions-01 14 Abstract 16 This specification defines a set of the fundamental optional 17 extensions for Generic UDP Encapsulation (GUE). The extensions 18 defined in this specification are the security option, payload 19 transform option, checksum option, fragmentation option, and the 20 remote checksum offload option. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as 30 Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/1id-abstracts.html 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 Copyright and License Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. GUE header format with optional extensions . . . . . . . . . . 4 62 3. Security option . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.1. Extension field format . . . . . . . . . . . . . . . . . . 6 64 3.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 3.3. Cookies . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 3.4. HMAC . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 3.4.1. Extension field format . . . . . . . . . . . . . . . . 7 68 3.4.2. Selecting a hash algorithm . . . . . . . . . . . . . . 8 69 3.4.3. Pre-shared key management . . . . . . . . . . . . . . . 8 70 3.5. Interaction with other optional extensions . . . . . . . . 9 71 4. Fragmentation option . . . . . . . . . . . . . . . . . . . . . 9 72 4.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 9 73 4.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 4.3. Extension field format . . . . . . . . . . . . . . . . . . 11 75 4.4. Fragmentation procedure . . . . . . . . . . . . . . . . . 12 76 4.5. Reassembly procedure . . . . . . . . . . . . . . . . . . . 14 77 4.6. Security Considerations . . . . . . . . . . . . . . . . . 16 78 5. Payload transform option . . . . . . . . . . . . . . . . . . . 16 79 5.1. Extension field format . . . . . . . . . . . . . . . . . . 16 80 5.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 17 81 5.3. Interaction with other optional extensions . . . . . . . . 17 82 5.4. DTLS transform . . . . . . . . . . . . . . . . . . . . . . 18 83 6. Remote checksum offload option . . . . . . . . . . . . . . . . 18 84 6.1. Extension field format . . . . . . . . . . . . . . . . . . 19 85 6.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 19 86 6.2.1. Transmitter operation . . . . . . . . . . . . . . . . . 19 87 6.2.2. Receiver operation . . . . . . . . . . . . . . . . . . 20 88 6.3. Security Considerations . . . . . . . . . . . . . . . . . 21 89 7. Checksum option . . . . . . . . . . . . . . . . . . . . . . . 21 90 7.1. Extension field format . . . . . . . . . . . . . . . . . . 21 91 7.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 22 92 7.3. GUE checksum pseudo header . . . . . . . . . . . . . . . . 22 93 7.4. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 24 94 7.4.1. Transmitter operation . . . . . . . . . . . . . . . . . 24 95 7.4.2.Receiver operation . . . . . . . . . . . . . . . . . . . 24 96 7.5. Security Considerations . . . . . . . . . . . . . . . . . 25 97 8. Processing order of options . . . . . . . . . . . . . . . . . 25 98 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 99 10. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 27 100 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 101 11.1. Normative References . . . . . . . . . . . . . . . . . . 27 102 11.2. Informative References . . . . . . . . . . . . . . . . . 28 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 105 1. Introduction 107 Generic UDP Encapsulation (GUE) [I.D.nvo3-gue] is a generic and 108 extensible encapsulation protocol. This specification defines a 109 fundamental set of optional extensions for version 0 of GUE. These 110 extensions are the security option, payload transform option, 111 checksum option, fragmentation option, and the remote checksum 112 offload option. 114 2. GUE header format with optional extensions 116 The format of a version 0 GUE header with the optional extensions 117 defined in this specification is: 119 0 1 2 3 120 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 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ 122 | Source port | Destination port | UDP 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ 124 | Length | Checksum | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | 0 |C| Hlen | Proto/ctype |V| SEC |F|T|R|K| Rsvd Flags | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | VNID (optional) | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | | 131 ~ Security (optional) ~ 132 | | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | | 135 + Fragmentation (optional) + 136 | | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | Payload transform (optional | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | Remote checksum offload (optional) | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | Checksum (optional) | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | | 145 ~ Private data (optional) ~ 146 | | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 The contents of the UDP header are described in [I.D.herbert-gue]. 151 The GUE header consists of: 153 o Ver: Version. Set to 0 to indicate GUE encapsulation header. 154 Note that version 1 does not allow options. 156 o C: C-bit. Indicates the GUE payload is a control message when 157 set, a data message when not set. GUE optional extensions can be 158 used with either control or data messages unless otherwise 159 specified in the option definition. 161 o Hlen: Length in 32-bit words of the GUE header, including 162 optional extension fields but not the first four bytes of the 163 header. Computed as (header_len - 4) / 4. The length of the 164 encapsulated packet is determined from the UDP length and the 165 Hlen: encapsulated_packet_length = UDP_Length - 12 - 4*Hlen. 167 o Proto/ctype: If the C-bit is not set this indicates IP protocol 168 number for the packet in the payload; if the C bit is set this 169 is the type of control message in the payload. The next header 170 begins at the offset provided by Hlen. When the payload 171 transform option or fragmentation option is used this field may 172 be set to protocol number 59 for a data message, or zero for a 173 control message, to indicate no next header for the payload. 175 o V: Indicates the network virtualization extension (VNID) field 176 is present. The VNID option is described in [I.D.hy-nvo3-gue-4- 177 nvo]. 179 o SEC: Indicates security extension field is present. The security 180 option is described in section 3. 182 o F: Indicates fragmentation extension field is present. The 183 fragmentation option is described in section 4. 185 o T: Indicates payload transform extension field is present. The 186 payload transform option is described in section 5. 188 o R: Indicates the remote checksum extension field is present. The 189 remote checksum offload option is described in section 6. 191 o K: Indicates checksum extension field is present. The checksum 192 option is described in section 7. 194 o Private data is described in [I.D.nvo3-gue]. 196 3. Security option 198 The GUE security option provides origin authentication and integrity 199 protection of the GUE header at tunnel end points to guarantee 200 isolation between tunnels and mitigate Denial of Service attacks. 202 3.1. Extension field format 204 The presence of the GUE security option is indicated in the SEC flag 205 bits of the GUE header. 207 The format of the security option is: 209 0 1 2 3 210 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 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | | 213 ~ Security ~ 214 | | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 The fields of the option are: 219 o Security (variable length). Contains the security information. 220 The specific semantics and format of this field is expected to 221 be negotiated between the two communicating nodes. 223 To provide security capability, the SEC flags MUST be set. Different 224 sizes are allowed to allow different methods and extensibility. The 225 use of the security field is expected to be negotiated out of band 226 between two tunnel end points. 228 The values in the SEC flags are: 230 o 000b - No security field 232 o 001b - 64 bit security field 234 o 010b - 128 bit security field 236 o 011b - 256 bit security field 238 o 100b - 388 bit security field (HMAC) 240 o 101b, 110b, 111b - Reserved values 242 3.2. Usage 244 The GUE security field should be used to provide integrity and 245 authentication of the GUE header. Security parameters (interpretation 246 of security field, key management, etc.) are expected to be 247 negotiated out of band between two communicating hosts. Two security 248 algorithms are defined below. 250 3.3. Cookies 252 The security field may be used as a cookie. This would be similar to 253 the cookie mechanism described in L2TP [RFC3931], and the general 254 properties should be the same. A cookie may be used to validate the 255 encapsulation. The cookie is a shared value between an encapsulator 256 and decapsulator which should be chosen randomly and may be changed 257 periodically. Different cookies may used for logical flows between 258 the encapsulator and decapsulator, for instance packets sent with 259 different VNIDs in network virtualization [I.D.hy-nvo3-gue-4-nvo] 260 might have different cookies. Cookies may be 64, 128, or 256 bits in 261 size. 263 3.4. HMAC 265 Key-hashed message authentication code (HMAC) is a strong method of 266 checking integrity and authentication of data. This sections defines 267 a GUE security option for HMAC. Note that this is based on the HMAC 268 TLV description in "IPv6 Segment Routing Header (SRH)" [I.D.previdi- 269 6man-sr-header]. 271 3.4.1. Extension field format 273 The HMAC option is a 288 bit field (36 octets). The security flags 274 are set to 100b to indicates the presence of a 288 bit security 275 field. 277 The format of the field 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 | HMAC Key-id | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | | 285 ~ HMAC (256 bits) ~ 286 | | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 Fields are: 291 o HMAC Key-id: opaque field to allow multiple hash algorithms or 292 key selection 294 o HMAC: Output of HMAC computation 296 The HMAC field is the output of the HMAC computation (per RFC 2104 297 [RFC2104]) using a pre-shared key identified by HMAC Key-id and of 298 the text which consists of the concatenation of: 300 o The IP addresses 302 o The GUE header including all private data and all optional 303 extensions that are present except for the security option 305 The purpose of the HMAC option is to verify the validity, the 306 integrity and the authorization of the GUE header itself. 308 The HMAC Key-id field allows for the simultaneous existence of 309 several hash algorithms (SHA-256, SHA3-256 ... or future ones) as 310 well as pre-shared keys. The HMAC Key-id field is opaque, i.e., it 311 has neither syntax nor semantic. Having an HMAC Key-id field allows 312 for pre-shared key roll-over when two pre-shared keys are supported 313 for a while GUE endpoints converge to a fresher pre-shared key. 315 3.4.2. Selecting a hash algorithm 317 The HMAC field in the HMAC option is 256 bit wide. Therefore, the 318 HMAC MUST be based on a hash function whose output is at least 256 319 bits. If the output of the hash function is 256, then this output is 320 simply inserted in the HMAC field. If the output of the hash function 321 is larger than 256 bits, then the output value is truncated to 256 by 322 taking the least-significant 256 bits and inserting them in the HMAC 323 field. 325 GUE implementations can support multiple hash functions but MUST 326 implement SHA-2 [FIPS180-4] in its SHA-256 variant. 328 3.4.3. Pre-shared key management 330 The field HMAC Key-id allows for: 332 o Key roll-over: when there is a need to change the key (the hash 333 pre-shared secret), then multiple pre-shared keys can be used 334 simultaneously. A decapsulator can have a table of for the currently active and future keys. 337 o Different algorithms: by extending the previous table to , the decapsulator can 339 also support simultaneously several hash algorithms (see section 340 Section 5.2.1) 342 The pre-shared secret distribution can be done: 344 o In the configuration of the endpoints 346 o Dynamically using a trusted key distribution such as [RFC6407] 348 The intent of this document is NOT to define yet-another-key- 349 distribution-protocol. 351 3.5. Interaction with other optional extensions 353 If GUE fragmentation (section 4) is used in concert with the GUE 354 security option, the security option processing is performed after 355 fragmentation at the encapsulator and before reassembly at the 356 decapsulator. 358 The GUE payload transform option (section 5) may be used in concert 359 with the GUE security option. The payload transform option could be 360 used to encrypt the GUE payload to provide privacy for an 361 encapsulated packet during transit. The security option provides 362 authentication and integrity for the GUE header (including the 363 payload transform field in the header). The two functions are 364 processed separately at tunnel end points. A GUE tunnel can use both 365 functions or use one of them. Section 5.3 details handling for when 366 both are used in a packet. 368 4. Fragmentation option 370 The fragmentation option allows an encapsulator to perform 371 fragmentation of packets being ingress to a tunnel. Procedures for 372 fragmentation and reassembly are defined in this section. This 373 specification adapts the procedures for IP fragmentation and 374 reassembly described in [RFC0791] and [RFC2460]. Fragmentation may be 375 performed on both data and control messages in GUE. 377 4.1. Motivation 379 This section describes the motivation for having a fragmentation 380 option in GUE. 382 MTU and fragmentation issues with In-the-Network Tunneling are 383 described in [RFC4459]. Considerations need to be made when a packet 384 is received at a tunnel ingress point which may be too large to 385 traverse the path between tunnel endpoints. 387 There are four suggested alternatives in [RFC4459] to deal with this: 389 1) Fragmentation and Reassembly by the Tunnel Endpoints 391 2) Signaling the Lower MTU to the Sources 392 3) Encapsulate Only When There is Free MTU 394 4) Fragmentation of the Inner Packet 396 Many tunneling protocol implementations have assumed that 397 fragmentation should be avoided, and in particular alternative #3 398 seems preferred for deployment. In this case, it is assumed that an 399 operator can configure the MTUs of links in the paths of tunnels to 400 ensure that they are large enough to accommodate any packets and 401 required encapsulation overhead. This method, however, may not be 402 feasible in certain deployments and may be prone to misconfiguration 403 in others. 405 Similarly, the other alternatives have drawbacks that are described 406 in [RFC4459]. Alternative #2 implies use of something like Path MTU 407 Discovery which is not known to be sufficiently reliable. Alternative 408 #4 is not permissible with IPv6 or when the DF bit is set for IPv4, 409 and it also introduces other known issues with IP fragmentation. 411 For alternative #1, fragmentation and reassembly at the tunnel 412 endpoints, there are two possibilities: encapsulate the large packet 413 and then perform IP fragmentation, or segment the packet and then 414 encapsulate each segment (a non-IP fragmentation approach). 416 Performing IP fragmentation on an encapsulated packet has the same 417 issues as that of normal IP fragmentation. Most significant of these 418 is that the Identification field is only sixteen bits in IPv4 which 419 introduces problems with wraparound as described in [RFC4963]. 421 The second possibility follows the suggestion expressed in [RFC2764] 422 and the fragmentation feature described in the AERO protocol 423 [I.D.templin-aerolink], that is for the tunneling protocol itself to 424 incorporate a segmentation and reassembly capability that operates at 425 the tunnel level. In this method fragmentation is part of the 426 encapsulation and an encapsulation header contains the information 427 for reassembly. This differs from IP fragmentation in that the IP 428 headers of the original packet are not replicated for each fragment. 430 Incorporating fragmentation into the encapsulation protocol has some 431 advantages: 433 o At least a 32 bit identifier can be defined to avoid issues of 434 the 16 bit Identification in IPv4. 436 o Encapsulation mechanisms for security and identification, such 437 as virtual network identifiers, can be applied to each segment. 439 o This allows the possibility of using alternate fragmentation and 440 reassembly algorithms (e.g. fragmentation with Forward Error 441 Correction). 443 o Fragmentation is transparent to the underlying network so it is 444 unlikely that fragmented packet will be unconditionally dropped 445 as might happen with IP fragmentation. 447 4.2. Scope 449 This specification describes the mechanics of fragmentation in 450 Generic UDP Encapsulation. The operational aspects and details for 451 higher layer implementation must be considered for deployment, but 452 are considered out of scope for this document. The AERO protocol 453 [I.D.templin-aerolink] defines one use case of fragmentation with 454 encapsulation. 456 4.3. Extension field format 458 The presence of the GUE fragmentation option is indicated by the F 459 bit in the GUE header. 461 The format of the fragmentation option is: 463 0 1 2 3 464 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 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Fragment offset |Res|M| Orig-proto | | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 468 | Identification | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 The fields of the option are: 473 o Fragment offset: This field indicates where in the datagram this 474 fragment belongs. The fragment offset is measured in units of 8 475 octets (64 bits). The first fragment has offset zero. 477 o Res: Two bit reserved field. Must be set to zero for 478 transmission. If set to non-zero in a received packet then the 479 packet MUST be dropped. 481 o M: More fragments bit. Set to 1 when there are more fragments 482 following in the datagram, set to 0 for the last fragment. 484 o Orig-proto: The control type (when C-bit is set) or the IP 485 protocol (when C-bit is not set) of the fragmented packet. 487 o Identification: 40 bits. Identifies fragments of a fragmented 488 packet. 490 Pertinent GUE header fields to fragmentation are: 492 o C-bit: This is set for each fragment based on the whether the 493 original packet being fragmented is a control or data message. 495 o Proto/ctype - For the first fragment (fragment offset is zero) 496 this is set to that of the original packet being fragmented 497 (either will be a control type or IP protocol). For other 498 fragments, this is set to zero for a control message being 499 fragmented, or to "No next header" (protocol number 59) for a 500 data message being fragmented. 502 o F bit - Set to indicate presence of the fragmentation extension 503 field. 505 4.4. Fragmentation procedure 507 If an encapsulator determines that a packet must be fragmented (eg. 508 the packet's size exceeds the Path MTU of the tunnel) it should 509 divide the packet into fragments and send each fragment as a separate 510 GUE packet, to be reassembled at the decapsulator (tunnel egress). 512 For every packet that is to be fragmented, the source node generates 513 an Identification value. The Identification must be different than 514 that of any other fragmented packet sent within the past 60 seconds 515 (Maximum Segment Lifetime) with the same tunnel identification-- that 516 is the same outer source and destination addresses, same UDP ports, 517 same orig-proto, and same virtual network identifier if present. 519 The initial, unfragmented, and unencapsulated packet is referred to 520 as the "original packet". This will be a layer 2 packet, layer 3 521 packet, or the payload of a GUE control message: 523 +-------------------------------//------------------------------+ 524 | Original packet | 525 | (e.g. an IPv4, IPv6, Ethernet packet) | 526 +------------------------------//-------------------------------+ 528 Fragmentation and encapsulation are performed on the original packet 529 in sequence. First the packet is divided up in to fragments, and then 530 each fragment is encapsulated. Each fragment, except possibly the 531 last ("rightmost") one, is an integer multiple of 8 octets long. 532 Fragments MUST be non-overlapping. The number of fragments should be 533 minimized, and all but the last fragment should be approximately 534 equal in length. 536 The fragments are transmitted in separate "fragment packets" as: 538 +--------------+--------------+---------------+--//--+----------+ 539 | first | second | third | | last | 540 | fragment | fragment | fragment | .... | fragment | 541 +--------------+--------------+---------------+--//--+----------+ 543 Each fragment is encapsulated as the payload of a GUE packet. This is 544 illustrated as: 546 +------------------+----------------+-----------------------+ 547 | IP/UDP header | GUE header | first | 548 | | w/ frag option | fragment | 549 +------------------+----------------+-----------------------+ 551 +------------------+----------------+-----------------------+ 552 | IP/UDP header | GUE header | second | 553 | | w/ frag option | fragment | 554 +------------------+----------------+-----------------------+ 555 o 556 o 557 +------------------+----------------+-----------------------+ 558 | IP/UDP header | GUE header | last | 559 | | w/ frag option | fragment | 560 +------------------+----------------+-----------------------+ 562 Each fragment packet is composed of: 564 (1) Outer IP and UDP headers as defined for GUE encapsulation. 566 o The IP addresses and UDP ports must be the same for all 567 fragments of a fragmented packet. 569 (2) A GUE header that contains: 571 o The C-bit which is set to the same value for all the 572 fragments of a fragmented packet based on whether a control 573 message or data message was fragmented. 575 o A proto/ctype. In the first fragment this is set to the 576 value corresponding to the next header of the original 577 packet and will be either an IP protocol or a control type. 578 For subsequent fragments, this field is set to 0 for a 579 fragmented control message or 59 (no next header) for a 580 fragmented data message. 582 o The F bit is set and fragment extension field is present. 584 o Other GUE options. Note that options apply to the individual 585 GUE packet. For instance, the security option would be 586 validated before reassembly. 588 (3) The GUE fragmentation option. The contents of the extension 589 field include: 591 o Orig-proto specifies the protocol of the original packet. 593 o A Fragment Offset containing the offset of the fragment, in 594 8-octet units, relative to the start of the of the original 595 packet. The Fragment Offset of the first ("leftmost") 596 fragment is 0. 598 o An M flag value of 0 if the fragment is the last 599 ("rightmost") one, else an M flag value of 1. 601 o The Identification value generated for the original packet. 603 (4) The fragment itself. 605 4.5. Reassembly procedure 607 At the destination, fragment packets are decapsulated and reassembled 608 into their original, unfragmented form, as illustrated: 610 +-------------------------------//------------------------------+ 611 | Original packet | 612 | (e.g. an IPv4, IPv6, Ethernet packet) | 613 +------------------------------//-------------------------------+ 615 The following rules govern reassembly: 617 The IP/UDP/GUE headers of each packet are retained until all 618 fragments have arrived. The reassembled packet is then composed 619 of the decapsulated payloads in the GUE packets, and the 620 IP/UDP/GUE headers are discarded. 622 When a GUE packet is received with the fragment extension, the 623 proto/ctype field in the GUE header must be validated. In the 624 case that the packet is a first fragment (fragment offset is 625 zero), the proto/ctype in the GUE header must equal the orig- 626 proto value in the fragmentation option. For subsequent 627 fragments (fragment offset is non-zero) the proto/ctype in the 628 GUE header must be 0 for a control message or 59 (no-next-hdr) 629 for a data message. If the proto/ctype value is invalid for a 630 received packet it MUST be dropped. 632 An original packet is reassembled only from GUE fragment packets 633 that have the same outer source address, destination address, 634 UDP source port, UDP destination port, GUE header C-bit, virtual 635 network identifier if present, orig-proto value in the 636 fragmentation option, and Fragment Identification. The protocol 637 type or control message type (depending on the C-bit) for the 638 reassembled packet is the value of the GUE header proto/ctype 639 field in the first fragment. 641 The following error conditions may arise when reassembling fragmented 642 packets with GUE encapsulation: 644 If insufficient fragments are received to complete reassembly of 645 a packet within 60 seconds (or a configurable period) of the 646 reception of the first-arriving fragment of that packet, 647 reassembly of that packet must be abandoned and all the 648 fragments that have been received for that packet must be 649 discarded. 651 If the payload length of a fragment is not a multiple of 8 652 octets and the M flag of that fragment is 1, then that fragment 653 must be discarded. 655 If the length and offset of a fragment are such that the payload 656 length of the packet reassembled from that fragment would exceed 657 65,535 octets, then that fragment must be discarded. 659 If a fragment overlaps another fragment already saved for 660 reassembly then the new fragment that overlaps the existing 661 fragment MUST be discarded. 663 If the first fragment is too small then it is possible that it 664 does not contain the necessary headers for a stateful firewall. 665 Sending small fragments like this has been used as an attack on 666 IP fragmentation. To mitigate this problem, an implementation 667 should ensure that the first fragment contains the headers of 668 the encapsulated packet at least through the transport header. 670 A GUE node must be able to accept a fragmented packet that, 671 after reassembly and decapsulation, is as large as 1500 octets. 672 This means that the node must configure a reassembly buffer that 673 is at least as large as 1500 octets plus the maximum-sized 674 encapsulation headers that may be inserted during encapsulation. 675 Implementations may find it more convenient and efficient to 676 configure a reassembly buffer size of 2KB which is large enough 677 to accommodate even the largest set of encapsulation headers and 678 provides a natural memory page size boundary. 680 4.6. Security Considerations 682 Exploits that have been identified with IP fragmentation are 683 conceptually applicable to GUE fragmentation. 685 Attacks on GUE fragmentation can be mitigated by: 687 o Hardened implementation that applies applicable techniques from 688 implementation of IP fragmentation. 690 o Application of GUE security (section 3) or IPsec [RFC4301]. 691 Security mechanisms can prevent spoofing of fragments from 692 unauthorized sources. 694 o Implement fragment filter techniques for GUE encapsulation as 695 described in [RFC1858] and [RFC3128]. 697 o Do not accepted data in overlapping segments. 699 o Enforce a minimum size for the first fragment. 701 5. Payload transform option 703 The payload transform option indicates that the GUE payload has been 704 transformed. Transforming a payload is done by running a function 705 over the data and possibly modifying it (encrypting it for instance). 706 The payload transform option indicates the method used to transform 707 the data so that a decapsulator is able to validate and reverse the 708 transformation to recover the original data. Payload transformations 709 could include encryption, authentication, CRC coverage, and 710 compression. This specification defines a transformation for DTLS. 712 5.1. Extension field format 714 The presence of the GUE payload transform option is indicated by the 715 T bit in the GUE header. 717 The format of Payload Transform Field is: 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 | Type | P_C_type | Data | 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 The fields of the option are: 725 Type: Payload Transform Type or Code point. Each payload transform 726 mechanism must have one code point registered in IANA. This 727 document specifies: 729 0x01: for DTLS [RFC6347] 731 0x80~0xFF: for private payload transform types 733 A private payload transform type can be used for 734 experimental purpose or vendor proprietary mechanisms. 736 P_C_type: Indicates the protocol or control type of the 737 untransformed payload. When payload transform option is 738 present, proto/ctype in the GUE header should set to 59 ("No 739 next header") for a data message and zero for a control 740 message. The IP protocol or control message type of the 741 untransformed payload must be encoded in this field. 743 The benefit of this rule is to prevent a middle box from 744 inspecting the encrypted payload according to GUE next 745 protocol. The assumption here is that a middle box may 746 understand GUE base header but does not understand GUE 747 option flag definitions. 749 Data: A field that can be set according to the requirements of 750 each payload transform type. If the specification for a 751 payload transform type does not specify how this field is to 752 be set, then the field MUST be set to zero. 754 5.2. Usage 756 The payload transform option provides a mechanism to transform or 757 interpret the payload of a GUE packet. The Type field provides the 758 method used to transform the payload, and the P_C_type field provides 759 the protocol or control message type of the of payload before being 760 transformed. The payload transformation option is generic so that it 761 can have both security related uses (such as DTLS) as well as non 762 security related uses (such as compression, CRC, etc.). 764 An encapsulator performs payload transformation before transmission, 765 and a decapsulator must perform the reverse transformation before 766 accepting a packet. For example, if an encapsulator transforms a 767 payload by encrypting it, the peer decaspsulator must decrypt the 768 payload before accepting the packet. If a decapsulator fails to 769 perform the reverse transformation or cannot validate the 770 transformation it MUST discard the packet and MAY generate an alert 771 to the management system. 773 5.3. Interaction with other optional extensions 775 If GUE fragmentation (section 4) is used in concert with the GUE 776 transform option, the transform option processing is performed after 777 fragmentation at the encapsulator and before reassembly at the 778 decapsulator. If the payload transform changes the size of the data 779 being fragmented this must be taken into account during 780 fragmentation. 782 If both the security option and the payload transform are used in a 783 GUE packet, an encapsulator must perform the payload transformation 784 first, set the payload transform option in the GUE header, and then 785 create the security option. A decapsulator does processing in 786 reverse-- the security option is processed (GUE header is validated) 787 and then the reverse payload transform is performed. 789 In order to get flow entropy from the payload, an encapsulator should 790 derive the flow entropy before performing a payload transform. 792 5.4. DTLS transform 794 The payload of a GUE packet can be secured using Datagram Transport 795 Layer Security [RFC6347]. An encapsulator would apply DTLS to the GUE 796 payload so that the payload packets are encrypted and the GUE header 797 remains in plaintext. The payload transform option is set to indicate 798 that the payload should be interpreted as a DTLS record. 800 The payload transform option for DLTS is: 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 | 1 | P_C_type | 0 | 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 DTLS [RFC6347] provides packet fragmentation capability. To avoid 807 packet fragmentation performed multiple times, a GUE encapsulator 808 SHOULD only perform the packet fragmentation at packet encapsulation 809 process, i.e., not in payload encryption process. 811 DTLS usage [RFC6347] is limited to a single DTLS session for any 812 specific tunnel encapsulator/decapsulator pair (identified by source 813 and destination IP addresses). Both IP addresses MUST be unicast 814 addresses - multicast traffic is not supported when DTLS is used. A 815 GUE tunnel decapsulator implementation that supports DTLS can 816 establish DTLS session(s) with one or multiple tunnel encapsulators, 817 and likewise a GUE tunnel encapsulator implementation can establish 818 DTLS session(s) with one or multiple decapsulators. 820 6. Remote checksum offload option 822 Remote checksum offload is mechanism that provides checksum offload 823 of encapsulated packets using rudimentary offload capabilities found 824 in most Network Interface Card (NIC) devices. Many NIC 825 implementations can only offload the outer UDP checksum in UDP 826 encapsulation. Remote checksum offload is described in [UDPENCAP]. 828 In remote checksum offload the outer header checksum, that in the 829 outer UDP header, is enabled in packets and, with some additional 830 meta information, a receiver is able to deduce the checksum to be set 831 for an inner encapsulated packet. Effectively this offloads the 832 computation of the inner checksum. Enabling the outer checksum in 833 encapsulation has the additional advantage that it covers more of the 834 packet than the inner checksum including the encapsulation headers. 836 6.1. Extension field format 838 The presence of the GUE remote checksum offload option is indicated 839 by the R bit in the GUE header. 841 The format of remote checksum offload field is: 843 0 1 2 3 844 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 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | Checksum start | Checksum offset | 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 The fields of the option are: 851 o Checksum start: starting offset for checksum computation 852 relative to the start of the encapsulated payload. This is 853 typically the offset of a transport header (e.g. UDP or TCP). 855 o Checksum offset: Offset relative to the start of the 856 encapsulated packet where the derived checksum value is to be 857 written. This typically is the offset of the checksum field in 858 the transport header (e.g. UDP or TCP). 860 6.2. Usage 862 6.2.1. Transmitter operation 864 The typical actions to set remote checksum offload on transmit are: 866 1) Transport layer creates a packet and indicates in internal 867 packet meta data that checksum is to be offloaded to the NIC 868 (normal transport layer processing for checksum offload). The 869 checksum field is populated with the bitwise not of the 870 checksum of the pseudo header or zero as appropriate. 872 2) Encapsulation layer adds its headers to the packet including 873 the remote checksum offload option. The start offset and 874 checksum offset are set accordingly. 876 3) Encapsulation layer arranges for checksum offload of the outer 877 header checksum (e.g. UDP). 879 4) Packet is sent to the NIC. The NIC will perform transmit 880 checksum offload and set the checksum field in the outer 881 header. The inner header and rest of the packet are transmitted 882 without modification. 884 6.2.2. Receiver operation 886 The typical actions a host receiver does to support remote checksum 887 offload are: 889 1) Receive packet and validate outer checksum following normal 890 processing (e.g. validate non-zero UDP checksum). 892 2) Validate the remote checksum option. If checksum start is 893 greater than the length of the packet, then the packet MUST be 894 dropped. If checksum offset is greater then the length of the 895 packet minus two, then the packet MUST be dropped. 897 3) Deduce full checksum for the IP packet. If a NIC is capable of 898 receive checksum offload it will return either the full 899 checksum of the received packet or an indication that the UDP 900 checksum is correct. Either of these methods can be used to 901 deduce the checksum over the IP packet [UDPENCAP]. 903 4) From the packet checksum, subtract the checksum computed from 904 the start of the packet (outer IP header) to the offset in the 905 packet indicted by checksum start in the meta data. The result 906 is the deduced checksum to set in the checksum field of the 907 encapsulated transport packet. 909 In pseudo code: 911 csum: initialized to checksum computed from start (outer IP 912 header) to the end of the packet 913 start_of_packet: address of start of packet 914 encap_payload_offset: relative to start_of_packet 915 csum_start: value from meta data 916 checksum(start, len): function to compute checksum from start 917 address for len bytes 919 csum -= checksum(start_of_packet, encap_payload_offset + 920 csum_start) 922 5) Write the resultant checksum value into the packet at the 923 offset provided by checksum offset in the meta data. 925 In pseudo code: 927 csum_offset: offset of checksum field 929 *(start_of_packet + encap_payload_offset + 930 csum_offset) = csum 932 6) Checksum is verified at the transport layer using normal 933 processing. This should not require any checksum computation 934 over the packet since the complete checksum has already been 935 provided. 937 6.3. Security Considerations 939 Remote checksum offload allows a means to change the GUE payload 940 before being received at a decapsulator. In order to prevent misuse 941 of this mechanism, a decapsulator should apply security checks on the 942 GUE payload only after checksum remote offload has been processed. 944 7. Checksum option 946 The GUE checksum option provides a checksum that covers the GUE 947 header, a GUE pseudo header, and optionally part or all of the GUE 948 payload. The GUE pseudo header includes the corresponding IP 949 addresses as well as the UDP ports of the encapsulating headers. This 950 checksum should provide adequate protection against address 951 corruption in IPv6 when the UDP checksum is zero. Additionally, the 952 GUE checksum provides protection of the GUE header when the UDP 953 checksum is set to zero with either IPv4 or IPv6. In particular, the 954 GUE checksum can provide protection for some sensitive data, such as 955 the virtual network identifier ([I.D.hy-nvo3-gue-4-nvo]), which when 956 corrupted could lead to mis-delivery of a packet to the wrong virtual 957 network. 959 7.1. Extension field format 961 The presence of the GUE checksum option is indicated by the K bit in 962 the GUE header. 964 The format of the checksum extension is: 966 0 1 2 3 967 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 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 | Checksum | Payload coverage | 970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 972 The fields of the option are: 974 o Checksum: Computed checksum value. This checksum covers the GUE 975 header (including fields and private data covered by Hlen), the 976 GUE pseudo header, and optionally all or part of the payload 977 (encapsulated packet). 979 o Payload coverage: Number of bytes of payload to cover in the 980 checksum. Zero indicates that the checksum only covers the GUE 981 header and GUE pseudo header. If the value is greater than the 982 encapsulated payload length, the packet must be dropped. 984 7.2. Requirements 986 The GUE header checksum should be set on transmit when using a zero 987 UDP checksum with IPv6. 989 The GUE header checksum should be used when the UDP checksum is zero 990 for IPv4 if the GUE header includes data that when corrupted can lead 991 to misdelivery or other serious consequences, and there is no other 992 mechanism that provides protection (no security field that checks 993 integrity for instance). 995 The GUE header checksum should not be set when the UDP checksum is 996 non-zero. In this case the UDP checksum provides adequate protection 997 and this avoids convolutions when a packet traverses NAT that does 998 address translation (in that case the UDP checksum is required). 1000 7.3. GUE checksum pseudo header 1002 The GUE pseudo header checksum is included in the GUE checksum to 1003 provide protection for the IP and UDP header elements which when 1004 corrupted could lead to misdelivery of the GUE packet. The GUE pseudo 1005 header checksum is similar to the standard IP pseudo header defined 1006 in [RFC0768] and [RFC0793] for IPv4, and in [RFC2460] for IPv6. 1008 The GUE pseudo header for IPv4 is: 1010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1011 | Source Address | 1012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1013 | Destination Address | 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 | Source port | Destination port | 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1018 The GUE pseudo header for IPv6 is: 1020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1021 | | 1022 + + 1023 | | 1024 + Source Address + 1025 | | 1026 + + 1027 | | 1028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1029 | | 1030 + + 1031 | | 1032 + Destination Address + 1033 | | 1034 + + 1035 | | 1036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1037 | Source port | Destination port | 1038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1040 Note that the GUE pseudo header does not include payload length or 1041 protocol as in the standard IP pseudo headers. The length field is 1042 deemed unnecessary because: 1044 o If the length is corrupted this will usually be detected by a 1045 checksum validation failure on the inner packet. 1047 o Fragmentation of packets in a tunnel should occur on the inner 1048 packet before being encapsulated or GUE fragmentation (section 1049 4) may be performed at tunnel ingress. GUE packets are not 1050 expected to be fragmented when using IPv6. See RFC6936 for 1051 considerations of payload length and IPv6 checksum. 1053 o A corrupted length field in itself should not lead to 1054 misdelivery of a packet. 1056 o Without the length field, the GUE pseudo header checksum is the 1057 same for all packets of flow. This is a useful property for 1058 optimizations such as TCP Segment Offload (TSO). 1060 7.4. Usage 1062 The GUE checksum is computed and verified following the standard 1063 process for computing the Internet checksum [RFC1071]. Checksum 1064 computation may be optimized per the mathematical properties 1065 including parallel computation and incremental updates. 1067 7.4.1. Transmitter operation 1069 The procedure for setting the GUE checksum on transmit is: 1071 1) Create the GUE header including the checksum and payload 1072 coverage fields. The checksum field is initially set to zero. 1074 2) Calculate the 1's complement checksum of the GUE header from 1075 the start of the GUE header through the its length as indicated 1076 in GUE Hlen. 1078 3) Calculate the checksum of the GUE pseudo header for IPv4 or 1079 IPv6. 1081 4) Calculate checksum of payload portion if payload coverage is 1082 enabled (payload coverage field is non-zero). If the length of 1083 the payload coverage is odd, logically append a single zero 1084 byte for the purposes of checksum calculation. 1086 5) Add and fold the computed checksums for the GUE header, GUE 1087 pseudo header and payload coverage. Set the bitwise not of the 1088 result in the GUE checksum field. 1090 7.4.2.Receiver operation 1092 If the GUE checksum option is present, the receiver must validate the 1093 checksum before processing any other fields or accepting the packet. 1095 The procedure for verifying the checksum is: 1097 1) If the payload coverage length is greater than the length of 1098 the encapsulated payload then drop the packet. 1100 2) Calculate the checksum of the GUE header from the start of the 1101 header to the end as indicated by Hlen. 1103 3) Calculate the checksum of the appropriate GUE pseudo header. 1105 4) Calculate the checksum of payload if payload coverage is 1106 enabled (payload coverage is non-zero). If the length of the 1107 payload coverage is odd logically append a single zero byte for 1108 the purposes of checksum calculation. 1110 5) Sum and fold the computed checksums for the GUE header, GUE 1111 pseudo header, and payload coverage. If the result is all 1 1112 bits (-0 in 1's complement arithmetic), the checksum is valid 1113 and the packet is accepted; otherwise the checksum is 1114 considered invalid and the packet must be dropped. 1116 7.5. Security Considerations 1118 The checksum option is only a mechanism for corruption detection, it 1119 is not a security mechanism. To provide integrity checks or 1120 authentication of the GUE header, the GUE security option should be 1121 used. 1123 8. Processing order of options 1125 Options must be processed in a specific order for both sending and 1126 receive. 1128 The order of processing options to send a GUE packet are: 1130 1) Set VNID option. 1132 2) Fragment if necessary and set fragmentation option. VNID is 1133 copied into each fragment. Note that if payload transformation 1134 will increase the size of the payload that must be accounted 1135 for when deciding how to fragment 1137 3) Perform payload transform (potentially on a fragment) and set 1138 payload transform option. 1140 4) Set Remote checksum offload. 1142 5) Set security option. 1144 6) Calculate GUE checksum and set checksum option. 1146 On reception the order of actions is reversed. 1148 1) Verify GUE checksum. 1150 2) Verify security option. 1152 3) Adjust packet for remote checksum offload. 1154 4) Perform payload transformation (i.e. decrypt payload) 1156 5) Perform reassembly. 1158 6) Receive on virtual network indicated by VNID. 1160 Note that the relative processing order of private fields is 1161 unspecified. 1163 9. Security Considerations 1165 If the integrity and privacy of data packets being transported 1166 through GUE is a concern, GUE security option and payload encryption 1167 using the the transform option SHOULD be used to remove the concern. 1168 If the integrity is the only concern, the tunnel may consider use of 1169 GUE security only for optimization. Likewise, if the privacy is the 1170 only concern, the tunnel may use GUE encryption function only. 1172 If GUE payload already provides secure mechanism, e.g., the payload 1173 is IPsec packets, it is still valuable to consider use of GUE 1174 security. 1176 GUE may rely on other secure tunnel mechanisms such as DTLS [RFC6347] 1177 over the whole UDP payload for securing the whole GUE packet or IPsec 1178 [RFC4301] to achieve the secure transport over an IP network or 1179 Internet. 1181 IPsec [RFC4301] was designed as a network security mechanism, and 1182 therefore it resides at the network layer. As such, if the tunnel is 1183 secured with IPsec, the UDP header would not be visible to 1184 intermediate routers in either IPsec tunnel or transport mode. The 1185 big drawback here prohibits intermediate routers to perform load 1186 balancing based on the flow entropy in UDP header. In addition, this 1187 method prohibits any middle box function on the path. 1189 By comparison, DTLS [RFC6347] was designed with application security 1190 and can better preserve network and transport layer protocol 1191 information than IPsec [RFC4301]. Using DTLS over UDP to secure the 1192 GUE tunnel, both GUE header and payload will be encrypted. In order 1193 to differentiate plaintext GUE header from encrypted GUE header, the 1194 destination port of the UDP header between two must be different, 1195 which essentially requires another standard UDP port for GUE with 1196 DTLS. The drawback on this method is to prevent a middle box 1197 operation to GUE tunnel on the path. 1199 Use of two independent tunnel mechanisms such as GUE and DTLS over 1200 UDP to carry a network protocol over an IP network adds some overlap 1201 and complexity. For example, fragmentation will be done twice. 1203 As the result, a GUE tunnel SHOULD use the security mechanisms 1204 specified in this document to provide secure transport over an IP 1205 network or Internet when it is needed. GUE encapsulation can be used 1206 as a secure transport mechanism over an IP network and Internet. 1208 10. IANA Consideration 1210 IANA is requested to assign flags for the extensions defined in this 1211 specification. Specifically, an assignment is requested for the V, 1212 SEC, F, T, R, and K flags in the "GUE flag-fields" registry (proposed 1213 in [I.D.nvo3-gue]). 1215 IANA is requested to set up a registry for the GUE payload transform 1216 types. Payload transform types are 8 bit values. New values for 1217 control types 1-127 are assigned via Standards Action [RFC5226]. 1219 +----------------+------------------+---------------+ 1220 | Transform type | Description | Reference | 1221 +----------------+------------------+---------------+ 1222 | 0 | Reserved | This document | 1223 | | | | 1224 | 1 | DTLS | This document | 1225 | | | | 1226 | 2..127 | Unassigned | | 1227 | | | | 1228 | 128..255 | User defined | This document | 1229 +----------------+------------------+---------------+ 1231 11. References 1233 11.1. Normative References 1235 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1236 1981. 1238 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 1239 Communication Layers", STD 3, RFC 1122, October 1989. 1241 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1242 August 1980. 1244 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1245 (IPv6) Specification", RFC 2460, December 1998. 1247 [I.D.nvo3-gue] T. Herbert, L. Yong, and O. Zia, "Generic UDP 1248 Encapsulation" draft-ietf-nvo3-gue-03 1250 11.2. Informative References 1252 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain of 1253 Interpretation", RFC 6407, DOI 10.17487/RFC6407, October 1254 2011, . 1255 [RFC1071] Braden, R., Borman, D., and C. Partridge, "Computing the 1256 Internet checksum", RFC1071, September 1988. 1258 [RFC1624] Rijsinghani, A., Ed., "Computation of the Internet Checksum 1259 via Incremental Update", RFC1624, May 1994. 1261 [RFC1936] Touch, J. and B. Parham, "Implementing the Internet 1262 Checksum in Hardware", RFC1936, April 1996. 1264 [RFC4459] MTU and Fragmentation Issues with In-the-Network Tunneling. 1265 P. Savola. April 2006. 1267 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 1268 Errors at High Data Rates", RFC 4963, DOI 10.17487/RFC4963, 1269 July 2007, . 1271 [RFC2764] B. Gleeson, A. Lin, J. Heinanen, G. Armitage, A. Malis, "A 1272 Framework for IP Based Virtual Private Networks", RFC2764, 1273 February 2000. 1275 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1276 Internet Protocol", RFC 4301, December 2005. 1278 [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security 1279 Considerations for IP Fragment Filtering", RFC 1858, 1280 October 1995. 1282 [RFC3128] Miller, I., "Protection Against a Variant of the Tiny 1283 Fragment Attack (RFC 1858)", RFC 3128, June 2001. 1285 [RFC3931] Lau, J., Townsley, W., et al, "Layer Two Tunneling Protocol 1286 - Version 3 (L2TPv3)", RFC3931, 1999 1288 [RFC5925] Touch, J., et al, "The TCP Authentication Option", RFC5925, 1289 June 2010. 1291 [RFC6347] Rescoria, E., Modadugu, N., "Datagram Transport Layer 1292 Security Version 1.2", RFC6347, 2012. 1294 [I.D.hy-nvo3-gue-4-nvo] Yong, L., Herbert, T., "Generic UDP 1295 Encapsulation (GUE) for Network Virtualization Overlay" 1297 [I.D.draft-mathis-frag-harmful] M. Mathis, J. Heffner, and B. 1298 Chandler, "Fragmentation Considered Very Harmful" 1300 [I.D.previdi-6man-sr-header] Previdi S. et al, "IPv6 Segment Routing 1301 Header (SRH) draft-ietf-6man-segment-routing-header-02 1303 [I.D.templin-aerolink] F. Templin, "Transmission of IP Packets over 1304 AERO Links" draft-templin-aerolink-62 1306 [I.D. 1307 [UDPENCAP] T. Herbert, "UDP Encapsulation in Linux", 1308 http://people.netfilter.org/pablo/netdev0.1/papers/UDP- 1309 Encapsulation-in-Linux.pdf 1311 Authors' Addresses 1313 Tom Herbert 1314 Facebook 1315 1 Hacker Way 1316 Menlo Park, CA 1317 USA 1319 EMail: tom@herbertland.com 1321 Lucy Yong 1322 Huawei USA 1323 5340 Legacy Dr. 1324 Plano, TX 75024 1325 USA 1327 Email: lucy.yong@huawei.com 1329 Fred L. Templin 1330 Boeing Research & Technology 1331 P.O. Box 3707 1332 Seattle, WA 98124 1333 USA 1335 Email: fltemplin@acm.org