idnits 2.17.1 draft-ietf-intarea-gue-extensions-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 231: '...termediate nodes SHOULD NOT attempt to...' RFC 2119 keyword, line 261: '...y, the SEC flags MUST be set. Differen...' RFC 2119 keyword, line 356: '... HMAC MUST be based on a hash functi...' RFC 2119 keyword, line 363: '...pport multiple hash functions but MUST...' RFC 2119 keyword, line 514: '... packet MUST be dropped....' (11 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 10, 2017) is 2542 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 334, but not defined == Missing Reference: 'FIPS180-4' is mentioned on line 364, but not defined == Missing Reference: 'RFC6407' is mentioned on line 383, but not defined == Missing Reference: 'RFC0793' is mentioned on line 1042, but not defined ** Obsolete undefined reference: RFC 793 (Obsoleted by RFC 9293) == Missing Reference: 'RFC5226' is mentioned on line 1259, but not defined ** Obsolete undefined reference: RFC 5226 (Obsoleted by RFC 8126) == Unused Reference: 'RFC1122' is defined on line 1280, but no explicit reference was found in the text == Unused Reference: 'RFC1624' is defined on line 1297, but no explicit reference was found in the text == Unused Reference: 'RFC1936' is defined on line 1300, but no explicit reference was found in the text == Unused Reference: 'RFC5925' is defined on line 1327, 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 (~~), 10 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 Quantonium 4 Expires: November 11, 2017 L. Yong 5 Huawei 6 F. Templin 7 Boeing 9 May 10, 2017 11 Extensions for Generic UDP Encapsulation 12 draft-ietf-intarea-gue-extensions-00 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 group identifier, security 19 option, payload transform option, checksum option, fragmentation 20 option, and the 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) 2017 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. Group identifier option . . . . . . . . . . . . . . . . . . . 5 63 3.1. Extension field format . . . . . . . . . . . . . . . . . . 6 64 3.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 4. Security option . . . . . . . . . . . . . . . . . . . . . . . 6 66 4.1. Extension field format . . . . . . . . . . . . . . . . . . 6 67 4.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 4.3. Cookies . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 4.4. HMAC . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 4.4.1. Extension field format . . . . . . . . . . . . . . . . 8 71 4.4.2. Selecting a hash algorithm . . . . . . . . . . . . . . 9 72 4.4.3. Pre-shared key management . . . . . . . . . . . . . . . 9 73 4.5. Interaction with other optional extensions . . . . . . . . 9 74 5. Fragmentation option . . . . . . . . . . . . . . . . . . . . . 10 75 5.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 10 76 5.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 5.3. Extension field format . . . . . . . . . . . . . . . . . . 12 78 5.4. Fragmentation procedure . . . . . . . . . . . . . . . . . 13 79 5.5. Reassembly procedure . . . . . . . . . . . . . . . . . . . 15 80 5.6. Security Considerations . . . . . . . . . . . . . . . . . 17 81 6. Payload transform option . . . . . . . . . . . . . . . . . . . 17 82 6.1. Extension field format . . . . . . . . . . . . . . . . . . 17 83 6.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 18 84 6.3. Interaction with other optional extensions . . . . . . . . 18 85 6.4. DTLS transform . . . . . . . . . . . . . . . . . . . . . . 19 86 7. Remote checksum offload option . . . . . . . . . . . . . . . . 19 87 7.1. Extension field format . . . . . . . . . . . . . . . . . . 20 88 7.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 20 89 7.2.1. Transmitter operation . . . . . . . . . . . . . . . . . 20 90 7.2.2. Receiver operation . . . . . . . . . . . . . . . . . . 21 91 7.3. Security Considerations . . . . . . . . . . . . . . . . . 22 92 8. Checksum option . . . . . . . . . . . . . . . . . . . . . . . 22 93 8.1. Extension field format . . . . . . . . . . . . . . . . . . 22 94 8.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 23 95 8.3. GUE checksum pseudo header . . . . . . . . . . . . . . . . 23 96 8.4. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 25 97 8.4.1. Transmitter operation . . . . . . . . . . . . . . . . . 25 98 8.4.2.Receiver operation . . . . . . . . . . . . . . . . . . . 25 99 8.5. Security Considerations . . . . . . . . . . . . . . . . . 26 100 9. Processing order of options . . . . . . . . . . . . . . . . . 26 101 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 102 11. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 28 103 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 104 12.1. Normative References . . . . . . . . . . . . . . . . . . 28 105 12.2. Informative References . . . . . . . . . . . . . . . . . 29 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 108 1. Introduction 110 Generic UDP Encapsulation (GUE) [I.D.ietf-gue] is a generic and 111 extensible encapsulation protocol. This specification defines a 112 fundamental set of optional extensions for version 0 of GUE. These 113 extensions are the group identifier, security option, payload 114 transform option, checksum option, fragmentation option, and the 115 remote checksum offload option. 117 2. GUE header format with optional extensions 119 The format of a version 0 GUE header with the optional extensions 120 defined in this specification is: 122 0 1 2 3 123 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 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ 125 | Source port | Destination port | UDP 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ 127 | Length | Checksum | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | 0 |C| Hlen | Proto/ctype |G| SEC |F|T|R|S| Rsvd Flags | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | Group identifier (optional) | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | | 134 ~ Security (optional) ~ 135 | | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | | 138 + Fragmentation (optional) + 139 | | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | Payload transform (optional | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | Remote checksum offload (optional) | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | Checksum (optional) | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | | 148 ~ Private data (optional) ~ 149 | | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 The contents of the UDP header are described in [I.D.ietf-gue]. 154 The GUE header consists of: 156 o Ver: Version. Set to 0 to indicate GUE encapsulation header. 157 Note that version 1 does not allow options. 159 o C: C-bit. Indicates the GUE payload is a control message when 160 set, a data message when not set. GUE optional extensions can be 161 used with either control or data messages unless otherwise 162 specified in the option definition. 164 o Hlen: Length in 32-bit words of the GUE header, including 165 optional extension fields but not the first four bytes of the 166 header. Computed as (header_len - 4) / 4. The length of the 167 encapsulated packet is determined from the UDP length and the 168 Hlen: encapsulated_packet_length = UDP_Length - 12 - 4*Hlen. 170 o Proto/ctype: If the C-bit is not set this indicates IP protocol 171 number for the packet in the payload; if the C bit is not set 172 this is the type of control message in the payload. The next 173 header begins at the offset provided by Hlen. When the payload 174 transform option or fragmentation option is used this field may 175 be set to protocol number 59 for a data message, or zero for a 176 control message, to indicate no next header for the payload. 178 o G: Indicates the the group identifier extension field is 179 present. The group identifier extensions is described in section 180 3. 182 o SEC: Indicates security extension field is present. The security 183 option is described in section 4. 185 o F: Indicates fragmentation extension field is present. The 186 fragmentation option is described in section 5. 188 o T: Indicates payload transform extension field is present. The 189 payload transform option is described in section 6. 191 o R: Indicates the remote checksum extension field is present. The 192 remote checksum offload option is described in section 7. 194 o K: Indicates checksum extension field is present. The checksum 195 option is described in section 8. 197 o Private data is described in [I.D.ietf-gue]. 199 3. Group identifier option 201 The group identifier classifies packet that logically belong to the 202 same group. Groups are arbitrarily defined for different purposes and 203 their definition is shared between the communicating end nodes. 205 3.1. Extension field format 207 The presence of the GUE group identifier option is indicated in the G 208 flag bit of the GUE header. 210 The format of the group identifier option is: 212 0 1 2 3 213 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 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Group identifier | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 The fields of the option are: 220 o Group identifier: Identifier value of a group. 222 3.2. Usage 224 The group identifier is set by an encapsulator to indicate to the 225 decapsulator that a packet belongs to a group. Groups may be 226 arbitrarily defined to classify packets. Specific use cases of the 227 group identifier may be defined in other documents ([I.D.hy-nvo3-gue- 228 4-nvo] defines a use of this field to contain a virtual networking 229 identifier for implementing network virtualization). 231 Intermediate nodes SHOULD NOT attempt to infer the meaning or 232 semantics of group identifiers. 234 4. Security option 236 The GUE security option provides origin authentication and integrity 237 protection of the GUE header at tunnel end points to guarantee 238 isolation between tunnels and mitigate Denial of Service attacks. 240 4.1. Extension field format 242 The presence of the GUE security option is indicated in the SEC flag 243 bits of the GUE header. 245 The format of the security option is: 247 0 1 2 3 248 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 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | | 251 ~ Security ~ 252 | | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 The fields of the option are: 257 o Security (variable length). Contains the security information. 258 The specific semantics and format of this field are expected to 259 be negotiated between the two communicating nodes. 261 To provide security capability, the SEC flags MUST be set. Different 262 sizes are allowed to allow different methods and extensibility. The 263 use of the security field is expected to be negotiated out of band 264 between two tunnel end points. 266 The values in the SEC flags are: 268 o 000b - No security field 270 o 001b - 64 bit security field 272 o 010b - 128 bit security field 274 o 011b - 256 bit security field 276 o 100b - 388 bit security field (HMAC) 278 o 101b, 110b, 111b - Reserved values 280 4.2. Usage 282 The GUE security field should be used to provide integrity and 283 authentication of the GUE header. Security parameters (interpretation 284 of security field, key management, etc.) are expected to be 285 negotiated out of band between two communicating hosts. Two security 286 algorithms are defined below. 288 4.3. Cookies 290 The security field may be used as a cookie. This would be similar to 291 the cookie mechanism described in L2TP [RFC3931], and the general 292 properties should be the same. A cookie may be used to validate the 293 encapsulation. The cookie is a shared value between an encapsulator 294 and decapsulator which should be chosen randomly and may be changed 295 periodically. Different cookies may used for logical flows between 296 the encapsulator and decapsulator, for instance packets sent with 297 different VNIs in network virtualization [I.D.hy-nvo3-gue-4-nvo] 298 might have different cookies. Cookies may be 64, 128, or 256 bits in 299 size. 301 4.4. HMAC 303 Key-hashed message authentication code (HMAC) is a strong method of 304 checking integrity and authentication of data. This sections defines 305 a GUE security option for HMAC. Note that this is based on the HMAC 306 TLV description in "IPv6 Segment Routing Header (SRH)" [I.D.previdi- 307 6man-sr-header]. 309 4.4.1. Extension field format 311 The HMAC option is a 288 bit field (36 octets). The security flags 312 are set to 100b to indicates the presence of a 288 bit security 313 field. 315 The format of the field is: 317 0 1 2 3 318 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 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | HMAC Key-id | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | | 323 ~ HMAC (256 bits) ~ 324 | | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 Fields are: 329 o HMAC Key-id: opaque field to allow multiple hash algorithms or 330 key selection 332 o HMAC: Output of HMAC computation 334 The HMAC field is the output of the HMAC computation (per [RFC2104]) 335 using a pre-shared key identified by HMAC Key-id and of the text 336 which consists of the concatenation of: 338 o The IP addresses 340 o The GUE header including all optional extensions except for the 341 security option 343 The purpose of the HMAC option is to verify the validity, the 344 integrity and the authentication of the GUE header itself. 346 The HMAC Key-id field allows for the simultaneous existence of 347 several hash algorithms (SHA-256, SHA3-256 ... or future ones) as 348 well as pre-shared keys. The HMAC Key-id field is opaque, i.e., it 349 has neither syntax nor semantic. Having an HMAC Key-id field allows 350 for pre-shared key roll-over when two pre-shared keys are supported 351 for a while when GUE endpoints converge to a fresher pre-shared key. 353 4.4.2. Selecting a hash algorithm 355 The HMAC field in the HMAC option is 256 bit wide. Therefore, the 356 HMAC MUST be based on a hash function whose output is at least 256 357 bits. If the output of the hash function is 256 bits, then this 358 output is simply inserted in the HMAC field. If the output of the 359 hash function is larger than 256 bits, then the output value is 360 truncated to 256 bits by taking the least-significant 256 bits and 361 inserting them in the HMAC field. 363 GUE implementations can support multiple hash functions but MUST 364 implement SHA-2 [FIPS180-4] in its SHA-256 variant. 366 4.4.3. Pre-shared key management 368 The field HMAC Key-id allows for: 370 o Key roll-over: when there is a need to change the key (the hash 371 pre-shared secret), then multiple pre-shared keys can be used 372 simultaneously. A decapsulator can have a table of for the currently active and future keys. 375 o Different algorithms: by extending the previous table to , the decapsulator can 377 also support simultaneously several hash algorithms 379 The pre-shared secret distribution can be done: 381 o In the configuration of the endpoints 383 o Dynamically using a trusted key distribution such as [RFC6407] 385 4.5. Interaction with other optional extensions 387 If GUE fragmentation (section 5) is used in concert with the GUE 388 security option, the security option processing is performed after 389 fragmentation at the encapsulator and before reassembly at the 390 decapsulator. 392 The GUE payload transform option (section 6) may be used in concert 393 with the GUE security option. The payload transform option could be 394 used to encrypt the GUE payload to provide privacy for an 395 encapsulated packet during transit. The security option provides 396 authentication and integrity for the GUE header (including the 397 payload transform field in the header). The two functions are 398 processed separately at tunnel end points. A GUE tunnel can use both 399 functions or use one of them. Section 6.3 details handling for when 400 both are used in a packet. 402 5. Fragmentation option 404 The fragmentation option allows an encapsulator to perform 405 fragmentation of packets being ingress to a tunnel. Procedures for 406 fragmentation and reassembly are defined in this section. This 407 specification adapts the procedures for IP fragmentation and 408 reassembly described in [RFC0791] and [RFC2460]. Fragmentation may be 409 performed on both data and control messages in GUE. 411 5.1. Motivation 413 This section describes the motivation for having a fragmentation 414 option in GUE. 416 MTU and fragmentation issues with In-the-Network Tunneling are 417 described in [RFC4459]. Considerations need to be made when a packet 418 is received at a tunnel ingress point which may be too large to 419 traverse the path between tunnel endpoints. 421 There are four suggested alternatives in [RFC4459] to deal with this: 423 1) Fragmentation and Reassembly by the Tunnel Endpoints 425 2) Signaling the Lower MTU to the Sources 427 3) Encapsulate Only When There is Free MTU 429 4) Fragmentation of the Inner Packet 431 Many tunneling protocol implementations have assumed that 432 fragmentation should be avoided, and in particular alternative #3 433 seems preferred for deployment. In this case, it is assumed that an 434 operator can configure the MTUs of links in the paths of tunnels to 435 ensure that they are large enough to accommodate any packets and 436 required encapsulation overhead. This method, however, may not be 437 feasible in certain deployments and may be prone to misconfiguration 438 in others. 440 Similarly, the other alternatives have drawbacks that are described 441 in [RFC4459]. Alternative #2 implies use of something like Path MTU 442 Discovery which is not known to be sufficiently reliable. Alternative 443 #4 is not permissible with IPv6 or when the DF bit is set for IPv4, 444 and it also introduces other known issues with IP fragmentation. 446 For alternative #1, fragmentation and reassembly at the tunnel 447 endpoints, there are two possibilities: encapsulate the large packet 448 and then perform IP fragmentation, or segment the packet and then 449 encapsulate each segment (a non-IP fragmentation approach). 451 Performing IP fragmentation on an encapsulated packet has the same 452 issues as that of normal IP fragmentation. Most significant of these 453 is that the Identification field is only sixteen bits in IPv4 which 454 introduces problems with wraparound as described in [RFC4963]. 456 Alternative #2 follows the suggestion expressed in [RFC2764] and the 457 fragmentation feature described in the AERO protocol [I.D.templin- 458 aerolink], that is for the tunneling protocol itself to incorporate a 459 segmentation and reassembly capability that operates at the tunnel 460 level. In this method fragmentation is part of the encapsulation and 461 an encapsulation header contains the information for reassembly. This 462 differs from IP fragmentation in that the IP headers of the original 463 packet are not replicated for each fragment. 465 Incorporating fragmentation into the encapsulation protocol has some 466 advantages: 468 o At least a 32 bit identifier can be defined to avoid issues of 469 the 16 bit Identification in IPv4. 471 o Encapsulation mechanisms for security and identification, such 472 as virtual network identifiers, can be applied to each segment. 474 o This allows the possibility of using alternate fragmentation and 475 reassembly algorithms (e.g. fragmentation with Forward Error 476 Correction). 478 o Fragmentation is transparent to the underlying network so it is 479 unlikely that fragmented packet will be unconditionally dropped 480 as might happen with IP fragmentation. 482 5.2. Scope 484 This specification describes the mechanics of fragmentation in 485 Generic UDP Encapsulation. The operational aspects and details for 486 higher layer implementation must be considered for deployment, but 487 are considered out of scope for this document. The AERO protocol 488 [I.D.templin-aerolink] defines one use case of fragmentation with 489 encapsulation. 491 5.3. Extension field format 493 The presence of the GUE fragmentation option is indicated by the F 494 bit in the GUE header. 496 The format of the fragmentation option is: 498 0 1 2 3 499 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 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | Fragment offset |Res|M| Orig-proto | | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 503 | Identification | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 The fields of the option are: 508 o Fragment offset: This field indicates where in the datagram this 509 fragment belongs. The fragment offset is measured in units of 8 510 octets (64 bits). The first fragment has offset zero. 512 o Res: Two bit reserved field. Must be set to zero for 513 transmission. If set to non-zero in a received packet then the 514 packet MUST be dropped. 516 o M: More fragments bit. Set to 1 when there are more fragments 517 following in the datagram, set to 0 for the last fragment. 519 o Orig-proto: The control type (when the C-bit in the GUE header 520 is set) or the IP protocol (when C-bit is not set) of the 521 fragmented packet. 523 o Identification: 40 bits. Identifies fragments of a fragmented 524 packet. 526 Pertinent GUE header fields to fragmentation are: 528 o C-bit: This is set for each fragment based on the whether the 529 original packet being fragmented is a control or data message. 531 o Proto/ctype - For the first fragment (fragment offset is zero) 532 this is set to that of the original packet being fragmented 533 (either will be a control type or IP protocol). For other 534 fragments, this is set to zero for a control message being 535 fragmented, or to "No next header" (protocol number 59) for a 536 data message being fragmented. 538 o F bit - Set to indicate presence of the fragmentation extension 539 field. 541 5.4. Fragmentation procedure 543 If an encapsulator determines that a packet must be fragmented (eg. 544 the packet's size exceeds the Path MTU of the tunnel) it should 545 divide the packet into fragments and send each fragment as a separate 546 GUE packet, to be reassembled at the decapsulator (tunnel egress). 548 For every packet that is to be fragmented, the source node generates 549 an Identification value. The Identification must be different than 550 that of any other fragmented packet sent within the past 60 seconds 551 (Maximum Segment Lifetime) with the same tunnel identification-- that 552 is the same outer source and destination addresses, same UDP ports, 553 same orig-proto, and same virtual network identifier if present. 555 The initial, unfragmented, and unencapsulated packet is referred to 556 as the "original packet". This will be a layer 2 packet, layer 3 557 packet, or the payload of a GUE control message: 559 +-------------------------------//------------------------------+ 560 | Original packet | 561 | (e.g. an IPv4, IPv6, Ethernet packet) | 562 +------------------------------//-------------------------------+ 564 Fragmentation and encapsulation are performed on the original packet 565 in sequence. First the packet is divided up in to fragments, and then 566 each fragment is encapsulated. Each fragment, except possibly the 567 last ("rightmost") one, is an integer multiple of 8 octets long. 568 Fragments MUST be non-overlapping. The number of fragments should be 569 minimized, and all but the last fragment should be approximately 570 equal in length. 572 The fragments are transmitted in separate "fragment packets" as: 574 +--------------+--------------+---------------+--//--+----------+ 575 | first | second | third | | last | 576 | fragment | fragment | fragment | .... | fragment | 577 +--------------+--------------+---------------+--//--+----------+ 579 Each fragment is encapsulated as the payload of a GUE packet. This is 580 illustrated as: 582 +------------------+----------------+-----------------------+ 583 | IP/UDP header | GUE header | first | 584 | | w/ frag option | fragment | 585 +------------------+----------------+-----------------------+ 587 +------------------+----------------+-----------------------+ 588 | IP/UDP header | GUE header | second | 589 | | w/ frag option | fragment | 590 +------------------+----------------+-----------------------+ 591 o 592 o 593 +------------------+----------------+-----------------------+ 594 | IP/UDP header | GUE header | last | 595 | | w/ frag option | fragment | 596 +------------------+----------------+-----------------------+ 598 Each fragment packet is composed of: 600 (1) Outer IP and UDP headers as defined for GUE encapsulation. 602 o The IP addresses and UDP ports must be the same for all 603 fragments of a fragmented packet. 605 (2) A GUE header that contains: 607 o The C-bit which is set to the same value for all the 608 fragments of a fragmented packet based on whether a control 609 message or data message was fragmented. 611 o A proto/ctype. In the first fragment this is set to the 612 value corresponding to the next header of the original 613 packet and will be either an IP protocol or a control type. 614 For subsequent fragments, this field is set to 0 for a 615 fragmented control message or 59 (no next header) for a 616 fragmented data message. 618 o The F bit is set and fragment extension field is present. 620 o Other GUE options. Note that options apply to the individual 621 GUE packet. For instance, the security option would be 622 validated before reassembly. The group identifier option 623 must be set to the save value for all fragments. 625 (3) The GUE fragmentation option. The contents of the extension 626 field include: 628 o Orig-proto specifies the protocol of the original packet. 630 o A Fragment Offset containing the offset of the fragment, in 631 8-octet units, relative to the start of the of the original 632 packet. The Fragment Offset of the first ("leftmost") 633 fragment is 0. 635 o An M flag value of 0 if the fragment is the last 636 ("rightmost") one, else an M flag value of 1. 638 o The Identification value generated for the original packet. 640 (4) The fragment itself. 642 5.5. Reassembly procedure 644 At the destination, fragment packets are decapsulated and reassembled 645 into their original, unfragmented form, as illustrated: 647 +-------------------------------//------------------------------+ 648 | Original packet | 649 | (e.g. an IPv4, IPv6, Ethernet packet) | 650 +------------------------------//-------------------------------+ 652 The following rules govern reassembly: 654 The IP/UDP/GUE headers of each packet are retained until all 655 fragments have arrived. The reassembled packet is then composed 656 of the decapsulated payloads in the GUE packets, and the 657 IP/UDP/GUE headers are discarded. 659 When a GUE packet is received with the fragment extension, the 660 proto/ctype field in the GUE header must be validated. In the 661 case that the packet is a first fragment (fragment offset is 662 zero), the proto/ctype in the GUE header must equal the orig- 663 proto value in the fragmentation option. For subsequent 664 fragments (fragment offset is non-zero) the proto/ctype in the 665 GUE header must be 0 for a control message or 59 (no-next-hdr) 666 for a data message. If the proto/ctype value is invalid for a 667 received packet it MUST be dropped. 669 An original packet is reassembled only from GUE fragment packets 670 that have the same outer source address, destination address, 671 UDP source port, UDP destination port, GUE header C-bit, group 672 identifier if present, orig-proto value in the fragmentation 673 option, and Fragment Identification. The protocol type or 674 control message type (depending on the C-bit) for the 675 reassembled packet is the value of the GUE header proto/ctype 676 field in the first fragment. 678 The following error conditions may arise when reassembling fragmented 679 packets with GUE encapsulation: 681 If insufficient fragments are received to complete reassembly of 682 a packet within 60 seconds (or a configurable period) of the 683 reception of the first-arriving fragment of that packet, 684 reassembly of that packet must be abandoned and all the 685 fragments that have been received for that packet must be 686 discarded. 688 If the payload length of a fragment is not a multiple of 8 689 octets and the M flag of that fragment is 1, then that fragment 690 must be discarded. 692 If the length and offset of a fragment are such that the payload 693 length of the packet reassembled from that fragment would exceed 694 65,535 octets, then that fragment must be discarded. 696 If a fragment overlaps another fragment already saved for 697 reassembly then the new fragment that overlaps the existing 698 fragment MUST be discarded. 700 If the first fragment is too small then it is possible that it 701 does not contain the necessary headers for a stateful firewall. 702 Sending small fragments like this has been used as an attack on 703 IP fragmentation. To mitigate this problem, an implementation 704 should ensure that the first fragment contains the headers of 705 the encapsulated packet at least through the transport header. 707 A GUE node must be able to accept a fragmented packet that, 708 after reassembly and decapsulation, is as large as 1500 octets. 709 This means that the node must configure a reassembly buffer that 710 is at least as large as 1500 octets plus the maximum-sized 711 encapsulation headers that may be inserted during encapsulation. 712 Implementations may find it more convenient and efficient to 713 configure a reassembly buffer size of 2KB which is large enough 714 to accommodate even the largest set of encapsulation headers and 715 provides a natural memory page size boundary. 717 5.6. Security Considerations 719 Exploits that have been identified with IP fragmentation are 720 conceptually applicable to GUE fragmentation. 722 Attacks on GUE fragmentation can be mitigated by: 724 o Hardened implementation that applies applicable techniques from 725 implementation of IP fragmentation. 727 o Application of GUE security (section 4) or IPsec [RFC4301]. 728 Security mechanisms can prevent spoofing of fragments from 729 unauthorized sources. 731 o Implement fragment filter techniques for GUE encapsulation as 732 described in [RFC1858] and [RFC3128]. 734 o Do not accepted data in overlapping segments. 736 o Enforce a minimum size for the first fragment. 738 6. Payload transform option 740 The payload transform option indicates that the GUE payload has been 741 transformed. Transforming a payload is done by running a function 742 over the data and possibly modifying it (encrypting it for instance). 743 The payload transform option indicates the method used to transform 744 the data so that a decapsulator is able to validate and reverse the 745 transformation to recover the original data. Payload transformations 746 could include encryption, authentication, CRC coverage, and 747 compression. This specification defines a transformation for DTLS. 749 6.1. Extension field format 751 The presence of the GUE payload transform option is indicated by the 752 T bit in the GUE header. 754 The format of Payload Transform Field is: 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 | Type | P_C_type | Data | 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 The fields of the option are: 762 Type: Payload Transform Type or Code point. Each payload transform 763 mechanism must have one code point registered in IANA. This 764 document specifies: 766 0x01: for DTLS [RFC6347] 768 0x80~0xFF: for private payload transform types 770 A private payload transform type can be used for 771 experimental purpose or vendor proprietary mechanisms. 773 P_C_type: Indicates the protocol or control type of the 774 untransformed payload. When payload transform option is 775 present, proto/ctype in the GUE header should set to 59 ("No 776 next header") for a data message and zero for a control 777 message. The IP protocol or control message type of the 778 untransformed payload must be encoded in this field. 780 The benefit of this rule is to prevent a middle box from 781 inspecting the encrypted payload according to GUE next 782 protocol. The assumption here is that a middle box may 783 understand GUE base header but does not understand GUE 784 option flag definitions. 786 Data: A field that can be set according to the requirements of 787 each payload transform type. If the specification for a 788 payload transform type does not specify how this field is to 789 be set, then the field MUST be set to zero. 791 6.2. Usage 793 The payload transform option provides a mechanism to transform or 794 interpret the payload of a GUE packet. The Type field provides the 795 method used to transform the payload, and the P_C_type field provides 796 the protocol or control message type of the of payload before being 797 transformed. The payload transformation option is generic so that it 798 can have both security related uses (such as DTLS) as well as non 799 security related uses (such as compression, CRC, etc.). 801 An encapsulator performs payload transformation before transmission, 802 and a decapsulator must perform the reverse transformation before 803 accepting a packet. For example, if an encapsulator transforms a 804 payload by encrypting it, the peer decaspsulator must decrypt the 805 payload before accepting the packet. If a decapsulator fails to 806 perform the reverse transformation or cannot validate the 807 transformation it MUST discard the packet and MAY generate an alert 808 to the management system. 810 6.3. Interaction with other optional extensions 811 If GUE fragmentation (section 5) is used in concert with the GUE 812 transform option, the transform option processing is performed after 813 fragmentation at the encapsulator and before reassembly at the 814 decapsulator. If the payload transform changes the size of the data 815 being fragmented this must be taken into account during 816 fragmentation. 818 If both the security option and the payload transform are used in a 819 GUE packet, an encapsulator must perform the payload transformation 820 first, set the payload transform option in the GUE header, and then 821 create the security option. A decapsulator does processing in 822 reverse-- the security option is processed (GUE header is validated) 823 and then the reverse payload transform is performed. 825 In order to get flow entropy from the payload, an encapsulator should 826 derive the flow entropy before performing a payload transform. 828 6.4. DTLS transform 830 The payload of a GUE packet can be secured using Datagram Transport 831 Layer Security [RFC6347]. An encapsulator would apply DTLS to the GUE 832 payload so that the payload packets are encrypted and the GUE header 833 remains in plaintext. The payload transform option is set to indicate 834 that the payload should be interpreted as a DTLS record. 836 The payload transform option for DLTS is: 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 | 1 | P_C_type | 0 | 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 DTLS [RFC6347] provides packet fragmentation capability. To avoid 843 packet fragmentation performed multiple times, a GUE encapsulator 844 SHOULD only perform the packet fragmentation at packet encapsulation 845 process, i.e., not in payload encryption process. 847 DTLS usage [RFC6347] is limited to a single DTLS session for any 848 specific tunnel encapsulator/decapsulator pair (identified by source 849 and destination IP addresses). Both IP addresses MUST be unicast 850 addresses - multicast traffic is not supported when DTLS is used. A 851 GUE tunnel decapsulator implementation that supports DTLS can 852 establish DTLS session(s) with one or multiple tunnel encapsulators, 853 and likewise a GUE tunnel encapsulator implementation can establish 854 DTLS session(s) with one or multiple decapsulators. 856 7. Remote checksum offload option 858 Remote checksum offload is mechanism that provides checksum offload 859 of encapsulated packets using rudimentary offload capabilities found 860 in most Network Interface Card (NIC) devices. Many NIC 861 implementations can only offload the outer UDP checksum in UDP 862 encapsulation. Remote checksum offload is described in [UDPENCAP]. 864 In remote checksum offload the outer header checksum, that in the 865 outer UDP header, is enabled in packets and, with some additional 866 meta information, a receiver is able to deduce the checksum to be set 867 for an inner encapsulated packet. Effectively this offloads the 868 computation of the inner checksum. Enabling the outer checksum in 869 encapsulation has the additional advantage that it covers more of the 870 packet than the inner checksum including the encapsulation headers. 872 7.1. Extension field format 874 The presence of the GUE remote checksum offload option is indicated 875 by the R bit in the GUE header. 877 The format of remote checksum offload field is: 879 0 1 2 3 880 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 881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 | Checksum start | Checksum offset | 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 The fields of the option are: 887 o Checksum start: starting offset for checksum computation 888 relative to the start of the encapsulated payload. This is 889 typically the offset of a transport header (e.g. UDP or TCP). 891 o Checksum offset: Offset relative to the start of the 892 encapsulated packet where the derived checksum value is to be 893 written. This typically is the offset of the checksum field in 894 the transport header (e.g. UDP or TCP). 896 7.2. Usage 898 7.2.1. Transmitter operation 900 The typical actions to set remote checksum offload on transmit are: 902 1) Transport layer creates a packet and indicates in internal 903 packet meta data that checksum is to be offloaded to the NIC 904 (normal transport layer processing for checksum offload). The 905 checksum field is populated with the bitwise not of the 906 checksum of the pseudo header or zero as appropriate. 908 2) Encapsulation layer adds its headers to the packet including 909 the remote checksum offload option. The start offset and 910 checksum offset are set accordingly. 912 3) Encapsulation layer arranges for checksum offload of the outer 913 header checksum (e.g. UDP). 915 4) Packet is sent to the NIC. The NIC will perform transmit 916 checksum offload and set the checksum field in the outer 917 header. The inner header and rest of the packet are transmitted 918 without modification. 920 7.2.2. Receiver operation 922 The typical actions a host receiver does to support remote checksum 923 offload are: 925 1) Receive packet and validate outer checksum following normal 926 processing (e.g. validate non-zero UDP checksum). 928 2) Validate the remote checksum option. If checksum start is 929 greater than the length of the packet, then the packet MUST be 930 dropped. If checksum offset is greater then the length of the 931 packet minus two, then the packet MUST be dropped. 933 3) Deduce full checksum for the IP packet. If a NIC is capable of 934 receive checksum offload it will return either the full 935 checksum of the received packet or an indication that the UDP 936 checksum is correct. Either of these methods can be used to 937 deduce the checksum over the IP packet [UDPENCAP]. 939 4) From the packet checksum, subtract the checksum computed from 940 the start of the packet (outer IP header) to the offset in the 941 packet indicted by checksum start in the meta data. The result 942 is the deduced checksum to set in the checksum field of the 943 encapsulated transport packet. 945 In pseudo code: 947 csum: initialized to checksum computed from start (outer IP 948 header) to the end of the packet 949 start_of_packet: address of start of packet 950 encap_payload_offset: relative to start_of_packet 951 csum_start: value from the checksum start field 952 checksum(start, len): function to compute checksum from start 953 address for len bytes 955 csum -= checksum(start_of_packet, encap_payload_offset + 956 csum_start) 958 5) Write the resultant checksum value into the packet at the 959 offset provided by checksum offset in the meta data. 961 In pseudo code: 963 csum_offset: value from the checksum offset field 965 *(start_of_packet + encap_payload_offset + 966 csum_offset) = csum 968 6) Checksum is verified at the transport layer using normal 969 processing. This should not require any checksum computation 970 over the packet since the complete checksum has already been 971 provided. 973 7.3. Security Considerations 975 Remote checksum offload allows a means to change the GUE payload 976 before being received at a decapsulator. In order to prevent misuse 977 of this mechanism, a decapsulator should apply security checks on the 978 GUE payload only after checksum remote offload has been processed. 980 8. Checksum option 982 The GUE checksum option provides a checksum that covers the GUE 983 header, a GUE pseudo header, and optionally part or all of the GUE 984 payload. The GUE pseudo header includes the corresponding IP 985 addresses as well as the UDP ports of the encapsulating headers. This 986 checksum should provide adequate protection against address 987 corruption in IPv6 when the UDP checksum is zero. Additionally, the 988 GUE checksum provides protection of the GUE header when the UDP 989 checksum is set to zero with either IPv4 or IPv6. In particular, the 990 GUE checksum can provide protection for some sensitive data, such as 991 the virtual network identifier ([I.D.hy-nvo3-gue-4-nvo]), which when 992 corrupted could lead to mis-delivery of a packet to the wrong virtual 993 network. 995 8.1. Extension field format 997 The presence of the GUE checksum option is indicated by the K bit in 998 the GUE header. 1000 The format of the checksum extension is: 1002 0 1 2 3 1003 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 1004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1005 | Checksum | Payload coverage | 1006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1008 The fields of the option are: 1010 o Checksum: Computed checksum value. This checksum covers the GUE 1011 header (including fields and private data covered by Hlen), the 1012 GUE pseudo header, and optionally all or part of the payload 1013 (encapsulated packet). 1015 o Payload coverage: Number of bytes of payload to cover in the 1016 checksum. Zero indicates that the checksum only covers the GUE 1017 header and GUE pseudo header. If the value is greater than the 1018 encapsulated payload length, the packet must be dropped. 1020 8.2. Requirements 1022 The GUE header checksum should be set on transmit when using a zero 1023 UDP checksum with IPv6. 1025 The GUE header checksum should be used when the UDP checksum is zero 1026 for IPv4 if the GUE header includes data that when corrupted can lead 1027 to misdelivery or other serious consequences, and there is no other 1028 mechanism that provides protection (no security field that checks 1029 integrity for instance). 1031 The GUE header checksum should not be set when the UDP checksum is 1032 non-zero. In this case the UDP checksum provides adequate protection 1033 and this avoids convolutions when a packet traverses NAT that does 1034 address translation (in that case the UDP checksum is required). 1036 8.3. GUE checksum pseudo header 1038 The GUE pseudo header checksum is included in the GUE checksum to 1039 provide protection for the IP and UDP header elements which when 1040 corrupted could lead to misdelivery of the GUE packet. The GUE pseudo 1041 header checksum is similar to the standard IP pseudo header defined 1042 in [RFC0768] and [RFC0793] for IPv4, and in [RFC2460] for IPv6. 1044 The GUE pseudo header for IPv4 is: 1046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1047 | Source Address | 1048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1049 | Destination Address | 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1051 | Source port | Destination port | 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1054 The GUE pseudo header for IPv6 is: 1056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1057 | | 1058 + + 1059 | | 1060 + Source Address + 1061 | | 1062 + + 1063 | | 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 | | 1066 + + 1067 | | 1068 + Destination Address + 1069 | | 1070 + + 1071 | | 1072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1073 | Source port | Destination port | 1074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1076 Note that the GUE pseudo header does not include payload length or 1077 protocol as in the standard IP pseudo headers. The length field is 1078 deemed unnecessary because: 1080 o If the length is corrupted this will usually be detected by a 1081 checksum validation failure on the inner packet. 1083 o Fragmentation of packets in a tunnel should occur on the inner 1084 packet before being encapsulated or GUE fragmentation (section 1085 4) may be performed at tunnel ingress. GUE packets are not 1086 expected to be fragmented when using IPv6. See RFC6936 for 1087 considerations of payload length and IPv6 checksum. 1089 o A corrupted length field in itself should not lead to 1090 misdelivery of a packet. 1092 o Without the length field, the GUE pseudo header checksum is the 1093 same for all packets of flow. This is a useful property for 1094 optimizations such as TCP Segment Offload (TSO). 1096 8.4. Usage 1098 The GUE checksum is computed and verified following the standard 1099 process for computing the Internet checksum [RFC1071]. Checksum 1100 computation may be optimized per the mathematical properties 1101 including parallel computation and incremental updates. 1103 8.4.1. Transmitter operation 1105 The procedure for setting the GUE checksum on transmit is: 1107 1) Create the GUE header including the checksum and payload 1108 coverage fields. The checksum field is initially set to zero. 1110 2) Calculate the 1's complement checksum of the GUE header from 1111 the start of the GUE header through the its length as indicated 1112 in GUE Hlen. 1114 3) Calculate the checksum of the GUE pseudo header for IPv4 or 1115 IPv6. 1117 4) Calculate checksum of payload portion if payload coverage is 1118 enabled (payload coverage field is non-zero). If the length of 1119 the payload coverage is odd, logically append a single zero 1120 byte for the purposes of checksum calculation. 1122 5) Add and fold the computed checksums for the GUE header, GUE 1123 pseudo header and payload coverage. Set the bitwise not of the 1124 result in the GUE checksum field. 1126 8.4.2.Receiver operation 1128 If the GUE checksum option is present, the receiver must validate the 1129 checksum before processing any other fields or accepting the packet. 1131 The procedure for verifying the checksum is: 1133 1) If the payload coverage length is greater than the length of 1134 the encapsulated payload then drop the packet. 1136 2) Calculate the checksum of the GUE header from the start of the 1137 header to the end as indicated by Hlen. 1139 3) Calculate the checksum of the appropriate GUE pseudo header. 1141 4) Calculate the checksum of payload if payload coverage is 1142 enabled (payload coverage is non-zero). If the length of the 1143 payload coverage is odd logically append a single zero byte for 1144 the purposes of checksum calculation. 1146 5) Sum the computed checksums for the GUE header, GUE pseudo 1147 header, and payload coverage. If the result is all 1 bits (-0 1148 in 1's complement arithmetic), the checksum is valid and the 1149 packet is accepted; otherwise the checksum is considered 1150 invalid and the packet must be dropped. 1152 8.5. Security Considerations 1154 The checksum option is only a mechanism for corruption detection, it 1155 is not a security mechanism. To provide integrity checks or 1156 authentication of the GUE header, the GUE security option should be 1157 used. 1159 9. Processing order of options 1161 Options must be processed in a specific order for both sending and 1162 receive. Note that some options, such as the checksum option, depend 1163 on other fields in the GUE header to be set. 1165 The order of processing options to send a GUE packet are: 1167 1) Set group identifier option. 1169 2) Fragment if necessary and set fragmentation option. Group 1170 identifier is copied into each fragment. Note that if payload 1171 transformation will increase the size of the payload that must 1172 be accounted for when deciding how to fragment 1174 3) Perform payload transform (potentially on a fragment) and set 1175 payload transform option. 1177 4) Set Remote checksum offload. 1179 5) Set security option. 1181 6) Calculate GUE checksum and set checksum option. 1183 On reception the order of actions is reversed. 1185 1) Verify GUE checksum. 1187 2) Verify security option. 1189 3) Adjust packet for remote checksum offload. 1191 4) Perform payload transformation (i.e. decrypt payload) 1193 5) Perform reassembly. 1195 6) Process packet (take group identifier into account if present). 1197 Note that the relative processing order of private fields is 1198 unspecified. 1200 10. Security Considerations 1202 Encapsulation of network protocol in GUE should not increase security 1203 risk, nor provide additional security in itself. GUE requires that 1204 the source port for UDP packets should be randomly seeded to mitigate 1205 some possible denial service attacks. 1207 If the integrity and privacy of data packets being transported 1208 through GUE is a concern, GUE security option and payload encryption 1209 using the the transform option SHOULD be used to remove the concern. 1210 If the integrity is the only concern, the tunnel may consider use of 1211 GUE security only for optimization. Likewise, if privacy is the only 1212 concern, the tunnel may use GUE encryption function only. 1214 If GUE payload already provides secure mechanism, e.g., the payload 1215 is IPsec packets, it is still valuable to consider use of GUE 1216 security. 1218 GUE may rely on other secure tunnel mechanisms such as DTLS [RFC6347] 1219 over the whole UDP payload for securing the whole GUE packet or IPsec 1220 [RFC4301] to achieve the secure transport over an IP network or 1221 Internet. 1223 IPsec [RFC4301] was designed as a network security mechanism, and 1224 therefore it resides at the network layer. As such, if the tunnel is 1225 secured with IPsec, the UDP header would not be visible to 1226 intermediate routers in either IPsec tunnel or transport mode. The 1227 big drawback here prohibits intermediate routers to perform load 1228 balancing based on the flow entropy in UDP header. In addition, this 1229 method prohibits any middle box function on the path. 1231 By comparison, DTLS [RFC6347] was designed with application security 1232 and can better preserve network and transport layer protocol 1233 information than IPsec [RFC4301]. Using DTLS over UDP to secure the 1234 GUE tunnel, both GUE header and payload will be encrypted. In order 1235 to differentiate plaintext GUE header from encrypted GUE header, the 1236 destination port of the UDP header between two must be different, 1237 which essentially requires another standard UDP port for GUE with 1238 DTLS. The drawback on this method is to prevent a middle box 1239 operation to GUE tunnel on the path. 1241 Use of two independent tunnel mechanisms such as GUE and DTLS over 1242 UDP to carry a network protocol over an IP network adds some overlap 1243 and complexity. For example, fragmentation will be done twice. 1245 As the result, a GUE tunnel SHOULD use the security mechanisms 1246 specified in this document to provide secure transport over an IP 1247 network or Internet when it is needed. GUE encapsulation can be used 1248 as a secure transport mechanism over an IP network and Internet. 1250 11. IANA Consideration 1252 IANA is requested to assign flags for the extensions defined in this 1253 specification. Specifically, an assignment is requested for the G, 1254 SEC, F, T, R, and K flags in the "GUE flag-fields" registry (proposed 1255 in [I.D.ietf-gue]). 1257 IANA is requested to set up a registry for the GUE payload transform 1258 types. Payload transform types are 8 bit values. New values for 1259 control types 1-127 are assigned via Standards Action [RFC5226]. 1261 +----------------+------------------+---------------+ 1262 | Transform type | Description | Reference | 1263 +----------------+------------------+---------------+ 1264 | 0 | Reserved | This document | 1265 | | | | 1266 | 1 | DTLS | This document | 1267 | | | | 1268 | 2..127 | Unassigned | | 1269 | | | | 1270 | 128..255 | User defined | This document | 1271 +----------------+------------------+---------------+ 1273 12. References 1275 12.1. Normative References 1277 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1278 1981. 1280 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 1281 Communication Layers", STD 3, RFC 1122, October 1989. 1283 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1284 August 1980. 1286 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1287 (IPv6) Specification", RFC 2460, December 1998. 1289 [I.D.ietf-gue] T. Herbert, L. Yong, and O. Zia, "Generic UDP 1290 Encapsulation" draft-ietf-intarea-gue-01 1292 12.2. Informative References 1294 [RFC1071] Braden, R., Borman, D., and C. Partridge, "Computing the 1295 Internet checksum", RFC1071, September 1988. 1297 [RFC1624] Rijsinghani, A., Ed., "Computation of the Internet Checksum 1298 via Incremental Update", RFC1624, May 1994. 1300 [RFC1936] Touch, J. and B. Parham, "Implementing the Internet 1301 Checksum in Hardware", RFC1936, April 1996. 1303 [RFC4459] MTU and Fragmentation Issues with In-the-Network Tunneling. 1304 P. Savola. April 2006. 1306 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 1307 Errors at High Data Rates", RFC 4963, DOI 10.17487/RFC4963, 1308 July 2007, . 1310 [RFC2764] B. Gleeson, A. Lin, J. Heinanen, G. Armitage, A. Malis, "A 1311 Framework for IP Based Virtual Private Networks", RFC2764, 1312 February 2000. 1314 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1315 Internet Protocol", RFC 4301, December 2005. 1317 [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security 1318 Considerations for IP Fragment Filtering", RFC 1858, 1319 October 1995. 1321 [RFC3128] Miller, I., "Protection Against a Variant of the Tiny 1322 Fragment Attack (RFC 1858)", RFC 3128, June 2001. 1324 [RFC3931] Lau, J., Townsley, W., et al, "Layer Two Tunneling Protocol 1325 - Version 3 (L2TPv3)", RFC3931, 1999 1327 [RFC5925] Touch, J., et al, "The TCP Authentication Option", RFC5925, 1328 June 2010. 1330 [RFC6347] Rescoria, E., Modadugu, N., "Datagram Transport Layer 1331 Security Version 1.2", RFC6347, 2012. 1333 [I.D.hy-nvo3-gue-4-nvo] Yong, L., Herbert, T., "Generic UDP 1334 Encapsulation (GUE) for Network Virtualization Overlay" 1335 draft-hy-nvo3-gue-4-nvo-03 1337 [I.D.draft-mathis-frag-harmful] M. Mathis, J. Heffner, and B. 1338 Chandler, "Fragmentation Considered Very Harmful" 1340 [I.D.previdi-6man-sr-header] Previdi S. et al, "IPv6 Segment Routing 1341 Header (SRH) draft-ietf-6man-segment-routing-header-02 1343 [I.D.templin-aerolink] F. Templin, "Transmission of IP Packets over 1344 AERO Links" draft-templin-aerolink-62 1346 [I.D. 1347 [UDPENCAP] T. Herbert, "UDP Encapsulation in Linux", 1348 http://people.netfilter.org/pablo/netdev0.1/papers/UDP- 1349 Encapsulation-in-Linux.pdf 1351 Authors' Addresses 1353 Tom Herbert 1354 Quantonium 1355 4701 Patrick Henry Dr. 1356 Santa Clara, CA 1357 USA 1359 EMail: tom@herbertland.com 1361 Lucy Yong 1362 Huawei USA 1363 5340 Legacy Dr. 1364 Plano, TX 75024 1365 USA 1367 Email: lucy.yong@huawei.com 1369 Fred L. Templin 1370 Boeing Research & Technology 1371 P.O. Box 3707 1372 Seattle, WA 98124 1373 USA 1375 Email: fltemplin@acm.org