idnits 2.17.1 draft-ietf-intarea-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 174: '...entation option is used this field MAY...' RFC 2119 keyword, line 230: '...termediate nodes SHOULD NOT attempt to...' RFC 2119 keyword, line 260: '...y, the SEC flags MUST be set. Differen...' RFC 2119 keyword, line 291: '...e same. A cookie MAY be used to valida...' RFC 2119 keyword, line 293: '...capsulator which SHOULD be chosen rand...' (45 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 18, 2017) is 2536 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC1122' is defined on line 1338, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. 'RFC2104') (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT T. Herbert 3 Intended Status: Proposed Standard Quantonium 4 Expires: November 19, 2017 L. Yong 5 Huawei 6 F. Templin 7 Boeing 9 May 18, 2017 11 Extensions for Generic UDP Encapsulation 12 draft-ietf-intarea-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 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 . . . . . . . . 10 74 5. Fragmentation option . . . . . . . . . . . . . . . . . . . . . 10 75 5.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 10 76 5.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . 19 85 6.4. DTLS transform . . . . . . . . . . . . . . . . . . . . . . 19 86 7. Remote checksum offload option . . . . . . . . . . . . . . . . 20 87 7.1. Extension field format . . . . . . . . . . . . . . . . . . 20 88 7.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 21 89 7.2.1. Transmitter operation . . . . . . . . . . . . . . . . . 21 90 7.2.2. Receiver operation . . . . . . . . . . . . . . . . . . 21 91 7.3. Security Considerations . . . . . . . . . . . . . . . . . 22 92 8. Checksum option . . . . . . . . . . . . . . . . . . . . . . . 22 93 8.1. Extension field format . . . . . . . . . . . . . . . . . . 23 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 . . . . . . . . . . . . . . . . . . . . . . . . . 29 104 12.1. Normative References . . . . . . . . . . . . . . . . . . 29 105 12.2. Informative References . . . . . . . . . . . . . . . . . 30 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 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 extension 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 set this 172 is the type of control message in the payload. The next header 173 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 option is described in section 3. 181 o SEC: Indicates security extension field is present. The security 182 option is described in section 4. 184 o F: Indicates fragmentation extension field is present. The 185 fragmentation option is described in section 5. 187 o T: Indicates payload transform extension field is present. The 188 payload transform option is described in section 6. 190 o R: Indicates the remote checksum extension field is present. The 191 remote checksum offload option is described in section 7. 193 o K: Indicates checksum extension field is present. The checksum 194 option is described in section 8. 196 o Private data is described in [I.D.ietf-gue]. 198 3. Group identifier option 200 The group identifier classifies packet that logically belong to the 201 same group. Groups are arbitrarily defined for different purposes and 202 their definition is shared between the communicating end nodes. 204 3.1. Extension field format 206 The presence of the GUE group identifier option is indicated in the G 207 flag bit of the GUE header. 209 The format of the group identifier option is: 211 0 1 2 3 212 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 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | Group identifier | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 The fields of the option are: 219 o Group identifier: Identifier value of a group. 221 3.2. Usage 223 The group identifier is set by an encapsulator to indicate to the 224 decapsulator that a packet belongs to a group. Groups may be 225 arbitrarily defined to classify packets. Specific use cases of the 226 group identifier may be defined in other documents ([I.D.hy-nvo3-gue- 227 4-nvo] defines a use of this field to contain a virtual networking 228 identifier for implementing network virtualization). 230 Intermediate nodes SHOULD NOT attempt to infer the meaning or 231 semantics of group identifiers. 233 4. Security option 235 The GUE security option provides origin authentication and integrity 236 protection of the GUE header at tunnel end points to guarantee 237 isolation between tunnels and mitigate Denial of Service attacks. 239 4.1. Extension field format 241 The presence of the GUE security option is indicated in the SEC flag 242 bits of the GUE header. 244 The format of the security option is: 246 0 1 2 3 247 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 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | | 250 ~ Security ~ 251 | | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 The fields of the option are: 256 o Security (variable length). Contains the security information. 257 The specific semantics and format of this field are expected to 258 be negotiated between the two communicating nodes. 260 To provide security capability, the SEC flags MUST be set. Different 261 sizes are allowed to allow different methods and extensibility. The 262 use of the security field is expected to be negotiated out of band 263 between two tunnel end points. 265 The values in the SEC flags are: 267 o 000b - No security field 269 o 001b - 64 bit security field 271 o 010b - 128 bit security field 273 o 011b - 256 bit security field 275 o 100b - 388 bit security field (HMAC) 277 o 101b, 110b, 111b - Reserved values 279 4.2. Usage 281 The GUE security option is used to provide integrity and 282 authentication of the GUE header. Security parameters (interpretation 283 of security field, key management, etc.) are expected to be 284 negotiated out of band between two communicating hosts. Two security 285 algorithms are defined below. 287 4.3. Cookies 289 The security field may be used as a cookie. This would be similar to 290 the cookie mechanism described in L2TP [RFC3931], and the general 291 properties should be the same. A cookie MAY be used to validate the 292 encapsulation. The cookie is a shared value between an encapsulator 293 and decapsulator which SHOULD be chosen randomly and may be changed 294 periodically. Different cookies MAY be used for logical flows between 295 the encapsulator and decapsulator, for instance packets sent with 296 different VNIs in network virtualization [I.D.hy-nvo3-gue-4-nvo] 297 might have different cookies. Cookies can b be 64, 128, or 256 bits 298 in size. 300 4.4. HMAC 302 Key-hashed message authentication code (HMAC) is a strong method of 303 checking integrity and authentication of data. This sections defines 304 a GUE security option for HMAC. Note that this is based on the HMAC 305 TLV description in "IPv6 Segment Routing Header (SRH)" [I.D.previdi- 306 6man-sr-header]. 308 4.4.1. Extension field format 310 The HMAC option is a 320 bit field (40 octets). The security flags 311 are set to 100b to indicates the presence of a 320 bit security 312 field. 314 The format of the field is: 316 0 1 2 3 317 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 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | HMAC Key-id | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Payload offset | Payload length | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | | 324 ~ HMAC (256 bits) ~ 325 | | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 Fields are: 330 o HMAC Key-id: opaque field to allow multiple hash algorithms or 331 key selection 333 o Payload offset: offset in payload that indicates the first octet 334 of payload data included in the HMAC. 336 o Payload length: length of payload data starting from the payload 337 offset to be included in the HMAC calculation. Zero 338 indicates no payload data in used in the 339 calculation. 341 o HMAC: Output of HMAC computation 343 The HMAC field is the output of the HMAC computation (per [RFC2104]) 344 using a pre-shared key identified by HMAC Key-id and of the text 345 which consists of the concatenation of: 347 o The IP addresses 349 o The GUE header including all optional extensions except for the 350 security option 352 o Optionally some or all of GUE payload. The portion of payload 353 covered is indicated by an offset into the payload and a length 354 relative to the offset. 356 The purpose of the HMAC option is to verify the validity, the 357 integrity and the authentication of the GUE header itself and 358 optionally some or all of the GUE payload. 360 The HMAC Key-id field allows for the simultaneous existence of 361 several hash algorithms (SHA-256, SHA3-256 ... or future ones) as 362 well as pre-shared keys. The HMAC Key-id field is opaque, i.e., it 363 has neither syntax nor semantic. Having an HMAC Key-id field allows 364 for pre-shared key roll-over when two pre-shared keys are supported 365 for a while when GUE endpoints converge to a fresher pre-shared key. 367 A portion of the GUE payload MAY be included in the HMAC calculation. 368 The payload coverage is indicated in the option in the payload offset 369 and payload length fields. If no payload data is included in the HMAC 370 then the payload length field is set to zero. On reception, if the 371 sum of the payload offset and the payload length is greater than the 372 total length of the payload, then the packet MUST be dropped. 374 4.4.2. Selecting a hash algorithm 376 The HMAC field in the HMAC option is 256 bit wide. Therefore, the 377 HMAC MUST be based on a hash function whose output is at least 256 378 bits. If the output of the hash function is 256 bits, then this 379 output is simply inserted in the HMAC field. If the output of the 380 hash function is larger than 256 bits, then the output value is 381 truncated to 256 bits by taking the least-significant 256 bits and 382 inserting them in the HMAC field. 384 GUE implementations can support multiple hash functions but MUST 385 implement SHA-2 [FIPS180-4] in its SHA-256 variant. 387 4.4.3. Pre-shared key management 388 The field HMAC Key-id allows for: 390 o Key roll-over: when there is a need to change the key (the hash 391 pre-shared secret), then multiple pre-shared keys can be used 392 simultaneously. A decapsulator can have a table of for the currently active and future keys. 395 o Different algorithms: by extending the previous table to , the decapsulator can 397 also support simultaneously several hash algorithms 399 The pre-shared secret distribution can be done: 401 o In the configuration of the endpoints 403 o Dynamically using a trusted key distribution such as [RFC6407] 405 4.5. Interaction with other optional extensions 407 If GUE fragmentation (section 5) is used in concert with the GUE 408 security option, the security option processing is performed after 409 fragmentation at the encapsulator and before reassembly at the 410 decapsulator. 412 The GUE payload transform option (section 6) may be used in concert 413 with the GUE security option. The payload transform option could be 414 used to encrypt the GUE payload to provide privacy for an 415 encapsulated packet during transit. The security option provides 416 authentication and integrity for the GUE header (including the 417 payload transform field in the header). The two functions are 418 processed separately at tunnel end points. A GUE tunnel can use both 419 functions or use one of them. Section 6.3 details handling for when 420 both are used in a packet. 422 5. Fragmentation option 424 The fragmentation option allows an encapsulator to perform 425 fragmentation of packets being ingress to a tunnel. Procedures for 426 fragmentation and reassembly are defined in this section. This 427 specification adapts the procedures for IP fragmentation and 428 reassembly described in [RFC0791] and [RFC2460]. Fragmentation can be 429 performed on both data and control messages in GUE. 431 5.1. Motivation 433 This section describes the motivation for having a fragmentation 434 option in GUE. 436 MTU and fragmentation issues with In-the-Network Tunneling are 437 described in [RFC4459]. Considerations need to be made when a packet 438 is received at a tunnel ingress point which may be too large to 439 traverse the path between tunnel endpoints. 441 There are four suggested alternatives in [RFC4459] to deal with this: 443 1) Fragmentation and Reassembly by the Tunnel Endpoints 445 2) Signaling the Lower MTU to the Sources 447 3) Encapsulate Only When There is Free MTU 449 4) Fragmentation of the Inner Packet 451 Many tunneling protocol implementations have assumed that 452 fragmentation should be avoided, and in particular alternative #3 453 seems preferred for deployment. In this case, it is assumed that an 454 operator can configure the MTUs of links in the paths of tunnels to 455 ensure that they are large enough to accommodate any packets and 456 required encapsulation overhead. This method, however, may not be 457 feasible in certain deployments and may be prone to misconfiguration 458 in others. 460 Similarly, the other alternatives have drawbacks that are described 461 in [RFC4459]. Alternative #2 implies use of something like Path MTU 462 Discovery which is not known to be sufficiently reliable. Alternative 463 #4 is not permissible with IPv6 or when the DF bit is set for IPv4, 464 and it also introduces other known issues with IP fragmentation. 466 For alternative #1, fragmentation and reassembly at the tunnel 467 endpoints, there are two possibilities: encapsulate the large packet 468 and then perform IP fragmentation, or segment the packet and then 469 encapsulate each segment (a non-IP fragmentation approach). 471 Performing IP fragmentation on an encapsulated packet has the same 472 issues as that of normal IP fragmentation. Most significant of these 473 is that the Identification field is only sixteen bits in IPv4 which 474 introduces problems with wraparound as described in [RFC4963]. 476 The second possibility of alternative #1 follows the suggestion 477 expressed in [RFC2764] and the fragmentation feature described in the 478 AERO protocol [I.D.templin-aerolink]; that is for the tunneling 479 protocol itself to incorporate a segmentation and reassembly 480 capability that operates at the tunnel level. In this method 481 fragmentation is part of the encapsulation and an encapsulation 482 header contains the information for reassembly. This differs from IP 483 fragmentation in that the IP headers of the original packet are not 484 replicated for each fragment. 486 Incorporating fragmentation into the encapsulation protocol has some 487 advantages: 489 o At least a 32 bit identifier can be defined to avoid issues of 490 the 16 bit Identification in IPv4. 492 o Encapsulation mechanisms for security and identification, such 493 as virtual network identifiers, can be applied to each segment. 495 o This allows the possibility of using alternate fragmentation and 496 reassembly algorithms (e.g. fragmentation with Forward Error 497 Correction). 499 o Fragmentation is transparent to the underlying network so it is 500 unlikely that fragmented packet will be unconditionally dropped 501 as might happen with IP fragmentation. 503 5.2. Scope 505 This specification describes the mechanics of fragmentation in 506 Generic UDP Encapsulation. The operational aspects and details for 507 higher layer implementation must be considered for deployment, but 508 are considered out of scope for this document. The AERO protocol 509 [I.D.templin-aerolink] defines one use case of fragmentation with 510 encapsulation. 512 5.3. Extension field format 514 The presence of the GUE fragmentation option is indicated by the F 515 bit in the GUE header. 517 The format of the fragmentation option is: 519 0 1 2 3 520 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 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | Fragment offset |Res|M| Orig-proto | | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 524 | Identification | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 The fields of the option are: 529 o Fragment offset: This field indicates where in the datagram this 530 fragment belongs. The fragment offset is measured in units of 8 531 octets (64 bits). The first fragment has offset zero. 533 o Res: Two bit reserved field. MUST be set to zero for 534 transmission. If set to non-zero in a received packet then the 535 packet MUST be dropped. 537 o M: More fragments bit. Set to 1 when there are more fragments 538 following in the datagram, set to 0 for the last fragment. 540 o Orig-proto: The control type (when the C-bit in the GUE header 541 is set) or the IP protocol (when C-bit is not set) of the 542 fragmented packet. 544 o Identification: 40 bits. Identifies fragments of a fragmented 545 packet. 547 Pertinent GUE header fields to fragmentation are: 549 o C-bit: This is set for each fragment based on the whether the 550 original packet being fragmented is a control or data message. 552 o Proto/ctype - For the first fragment (fragment offset is zero) 553 this is set to that of the original packet being fragmented 554 (either will be a control type or IP protocol). For other 555 fragments, this is set to zero for a control message being 556 fragmented, or to "No next header" (protocol number 59) for a 557 data message being fragmented. 559 o F bit - Set to indicate presence of the fragmentation extension 560 field. 562 5.4. Fragmentation procedure 564 If an encapsulator determines that a packet must be fragmented (eg. 565 the packet's size exceeds the Path MTU of the tunnel) it should 566 divide the packet into fragments and send each fragment as a separate 567 GUE packet, to be reassembled at the decapsulator (tunnel egress). 569 For every packet that is to be fragmented, the source node generates 570 an Identification value. The Identification MUST be different than 571 that of any other fragmented packet sent within the past 60 seconds 572 (Maximum Segment Lifetime) with the same tunnel identification-- that 573 is the same outer source and destination addresses, same UDP ports, 574 same orig-proto, and same virtual network identifier if present. 576 The initial, unfragmented, and unencapsulated packet is referred to 577 as the "original packet". This will be a layer 2 packet, layer 3 578 packet, or the payload of a GUE control message: 580 +-------------------------------//------------------------------+ 581 | Original packet | 582 | (e.g. an IPv4, IPv6, Ethernet packet) | 583 +------------------------------//-------------------------------+ 585 Fragmentation and encapsulation are performed on the original packet 586 in sequence. First the packet is divided up in to fragments, and then 587 each fragment is encapsulated. Each fragment, except possibly the 588 last ("rightmost") one, is an integer multiple of 8 octets long. 589 Fragments MUST be non-overlapping. The number of fragments should be 590 minimized, and all but the last fragment should be approximately 591 equal in length. 593 The fragments are transmitted in separate "fragment packets" as: 595 +--------------+--------------+---------------+--//--+----------+ 596 | first | second | third | | last | 597 | fragment | fragment | fragment | .... | fragment | 598 +--------------+--------------+---------------+--//--+----------+ 600 Each fragment is encapsulated as the payload of a GUE packet. This is 601 illustrated as: 603 +------------------+----------------+-----------------------+ 604 | IP/UDP header | GUE header | first | 605 | | w/ frag option | fragment | 606 +------------------+----------------+-----------------------+ 608 +------------------+----------------+-----------------------+ 609 | IP/UDP header | GUE header | second | 610 | | w/ frag option | fragment | 611 +------------------+----------------+-----------------------+ 612 o 613 o 614 +------------------+----------------+-----------------------+ 615 | IP/UDP header | GUE header | last | 616 | | w/ frag option | fragment | 617 +------------------+----------------+-----------------------+ 619 Each fragment packet is composed of: 621 (1) Outer IP and UDP headers as defined for GUE encapsulation. 623 o The IP addresses and UDP ports MUST be the same for all 624 fragments of a fragmented packet. 626 (2) A GUE header that contains: 628 o The C-bit which is set to the same value for all the 629 fragments of a fragmented packet based on whether a control 630 message or data message was fragmented. 632 o A proto/ctype. In the first fragment this is set to the 633 value corresponding to the next header of the original 634 packet and will be either an IP protocol or a control type. 635 For subsequent fragments, this field is set to 0 for a 636 fragmented control message or 59 (no next header) for a 637 fragmented data message. 639 o The F bit is set and fragment extension field is present. 641 o Other GUE options. Note that options apply to the individual 642 GUE packet. For instance, the security option would be 643 validated before reassembly. The group identifier option 644 MUST be set to the same value for all fragments. 646 (3) The GUE fragmentation option. The contents of the extension 647 field include: 649 o Orig-proto specifies the protocol of the original packet. 651 o A Fragment Offset containing the offset of the fragment, in 652 8-octet units, relative to the start of the of the original 653 packet. The Fragment Offset of the first ("leftmost") 654 fragment is 0. 656 o An M flag value of 0 if the fragment is the last 657 ("rightmost") one, else an M flag value of 1. 659 o The Identification value generated for the original packet. 661 (4) The fragment itself. 663 5.5. Reassembly procedure 665 At the destination, fragment packets are decapsulated and reassembled 666 into their original, unfragmented form, as illustrated: 668 +-------------------------------//------------------------------+ 669 | Original packet | 670 | (e.g. an IPv4, IPv6, Ethernet packet) | 671 +------------------------------//-------------------------------+ 673 The following rules govern reassembly: 675 The IP/UDP/GUE headers of each packet are retained until all 676 fragments have arrived. The reassembled packet is then composed 677 of the decapsulated payloads in the GUE packets, and the 678 IP/UDP/GUE headers are discarded. 680 When a GUE packet is received with the fragment extension, the 681 proto/ctype field in the GUE header MUST be validated. In the 682 case that the packet is a first fragment (fragment offset is 683 zero), the proto/ctype in the GUE header MUST equal the orig- 684 proto value in the fragmentation option. For subsequent 685 fragments (fragment offset is non-zero) the proto/ctype in the 686 GUE header must be 0 for a control message or 59 (no-next-hdr) 687 for a data message. If the proto/ctype value is invalid for a 688 received packet it MUST be dropped. 690 An original packet is reassembled only from GUE fragment packets 691 that have the same outer source address, destination address, 692 UDP source port, UDP destination port, GUE header C-bit, group 693 identifier if present, orig-proto value in the fragmentation 694 option, and Fragment Identification. The protocol type or 695 control message type (depending on the C-bit) for the 696 reassembled packet is the value of the GUE header proto/ctype 697 field in the first fragment. 699 The following error conditions can arise when reassembling fragmented 700 packets with GUE encapsulation: 702 If insufficient fragments are received to complete reassembly of 703 a packet within 60 seconds (or a configurable period) of the 704 reception of the first-arriving fragment of that packet, 705 reassembly of that packet MUST be abandoned and all the 706 fragments that have been received for that packet MUST be 707 discarded. 709 If the payload length of a fragment is not a multiple of 8 710 octets and the M flag of that fragment is 1, then that fragment 711 MUST be discarded. 713 If the length and offset of a fragment are such that the payload 714 length of the packet reassembled from that fragment would exceed 715 65,535 octets, then that fragment MUST be discarded. 717 If a fragment overlaps another fragment already saved for 718 reassembly then the new fragment that overlaps the existing 719 fragment MUST be discarded. 721 If the first fragment is too small then it is possible that it 722 does not contain the necessary headers for a stateful firewall. 724 Sending small fragments like this has been used as an attack on 725 IP fragmentation. To mitigate this problem, an implementation 726 SHOULD ensure that the first fragment contains the headers of 727 the encapsulated packet at least through the transport header. 729 A GUE node MUST be able to accept a fragmented packet that, 730 after reassembly and decapsulation, is as large as 1500 octets. 731 This means that the node must configure a reassembly buffer that 732 is at least as large as 1500 octets plus the maximum-sized 733 encapsulation headers that may be inserted during encapsulation. 734 Implementations may find it more convenient and efficient to 735 configure a reassembly buffer size of 2KB which is large enough 736 to accommodate even the largest set of encapsulation headers and 737 provides a natural memory page size boundary. 739 5.6. Security Considerations 741 Exploits that have been identified with IP fragmentation are 742 conceptually applicable to GUE fragmentation. 744 Attacks on GUE fragmentation can be mitigated by: 746 o Hardened implementation that applies applicable techniques from 747 implementation of IP fragmentation. 749 o Application of GUE security (section 4) or IPsec [RFC4301]. 750 Security mechanisms can prevent spoofing of fragments from 751 unauthorized sources. 753 o Implement fragment filter techniques for GUE encapsulation as 754 described in [RFC1858] and [RFC3128]. 756 o Do not accepted data in overlapping segments. 758 o Enforce a minimum size for the first fragment. 760 6. Payload transform option 762 The payload transform option indicates that the GUE payload has been 763 transformed. Transforming a payload is done by running a function 764 over the data and possibly modifying it (encrypting it for instance). 765 The payload transform option indicates the method used to transform 766 the data so that a decapsulator is able to validate and reverse the 767 transformation to recover the original data. Payload transformations 768 could include encryption, authentication, CRC coverage, and 769 compression. This specification defines a transformation for DTLS. 771 6.1. Extension field format 772 The presence of the GUE payload transform option is indicated by the 773 T bit in the GUE header. 775 The format of Payload Transform Field is: 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 | Type | P_C_type | Data | 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 The fields of the option are: 783 Type: Payload Transform Type or Code point. Each payload transform 784 mechanism must have one code point registered in IANA. This 785 document specifies: 787 0x01: for DTLS [RFC6347] 789 0x80~0xFF: for private payload transform types 791 A private payload transform type can be used for 792 experimental purpose or vendor proprietary mechanisms. 794 P_C_type: Indicates the protocol or control type of the 795 untransformed payload. When payload transform option is 796 present, proto/ctype in the GUE header is set to 59 ("No 797 next header") for a data message and zero for a control 798 message. The IP protocol or control message type of the 799 untransformed payload MUST be encoded in this field. 801 The benefit of this rule is to prevent a middle box from 802 inspecting the encrypted payload according to GUE next 803 protocol. The assumption here is that a middle box may 804 understand GUE base header but does not understand GUE 805 option flag definitions. 807 Data: A field that can be set according to the requirements of 808 each payload transform type. If the specification for a 809 payload transform type does not specify how this field is to 810 be set, then the field MUST be set to zero. 812 6.2. Usage 814 The payload transform option provides a mechanism to transform or 815 interpret the payload of a GUE packet. The Type field provides the 816 method used to transform the payload, and the P_C_type field provides 817 the protocol or control message type of the of payload before being 818 transformed. The payload transformation option is generic so that it 819 can have both security related uses (such as DTLS) as well as non 820 security related uses (such as compression, CRC, etc.). 822 An encapsulator performs payload transformation before transmission, 823 and a decapsulator performs the reverse transformation before 824 accepting a packet. For example, if an encapsulator transforms a 825 payload by encrypting it, the peer decaspsulator MUST decrypt the 826 payload before accepting the packet. If a decapsulator fails to 827 perform the reverse transformation or cannot validate the 828 transformation it MUST discard the packet and MAY generate an alert 829 to the management system. 831 6.3. Interaction with other optional extensions 833 If GUE fragmentation (section 5) is used in concert with the GUE 834 transform option, the transform option processing is performed after 835 fragmentation at the encapsulator and before reassembly at the 836 decapsulator. If the payload transform changes the size of the data 837 being fragmented this must be taken into account during 838 fragmentation. 840 If both the security option and the payload transform are used in a 841 GUE packet, an encapsulator MUST perform the payload transformation 842 first, set the payload transform option in the GUE header, and then 843 create the security option. A decapsulator does processing in 844 reverse-- the security option is processed (GUE header is validated) 845 and then the reverse payload transform is performed. 847 In order to get flow entropy from the payload, an encapsulator should 848 derive the flow entropy before performing a payload transform. 850 6.4. DTLS transform 852 The payload of a GUE packet can be secured using Datagram Transport 853 Layer Security [RFC6347]. An encapsulator would apply DTLS to the GUE 854 payload so that the payload packets are encrypted and the GUE header 855 remains in plaintext. The payload transform option is set to indicate 856 that the payload is interpreted as a DTLS record. 858 The payload transform option for DLTS is: 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 | 1 | P_C_type | 0 | 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 DTLS [RFC6347] provides packet fragmentation capability. To avoid 865 packet fragmentation performed multiple times, a GUE encapsulator 866 SHOULD only perform the packet fragmentation at packet encapsulation 867 process, i.e., not in the payload encryption process. 869 DTLS usage [RFC6347] is limited to a single DTLS session for any 870 specific tunnel encapsulator/decapsulator pair (identified by source 871 and destination IP addresses). Both IP addresses MUST be unicast 872 addresses - multicast traffic is not supported when DTLS is used. A 873 GUE tunnel decapsulator implementation that supports DTLS can 874 establish DTLS session(s) with one or multiple tunnel encapsulators, 875 and likewise a GUE tunnel encapsulator implementation can establish 876 DTLS session(s) with one or multiple decapsulators. 878 7. Remote checksum offload option 880 Remote checksum offload is mechanism that provides checksum offload 881 of encapsulated packets using rudimentary offload capabilities found 882 in most Network Interface Card (NIC) devices. Many NIC 883 implementations can only offload the outer UDP checksum in UDP 884 encapsulation. Remote checksum offload is described in [UDPENCAP]. 886 In remote checksum offload the outer header checksum, that in the 887 outer UDP header, is enabled in packets and, with some additional 888 meta information, a receiver is able to deduce the checksum to be set 889 for an inner encapsulated packet. Effectively this offloads the 890 computation of the inner checksum. Enabling the outer checksum in 891 encapsulation has the additional advantage that it covers more of the 892 packet, including the encapsulation headers, than an inner checksum. 894 7.1. Extension field format 896 The presence of the GUE remote checksum offload option is indicated 897 by the R bit in the GUE header. 899 The format of remote checksum offload field is: 901 0 1 2 3 902 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 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 | Checksum start | Checksum offset | 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 The fields of the option are: 909 o Checksum start: starting offset for checksum computation 910 relative to the start of the encapsulated payload. This is 911 typically the offset of a transport header (e.g. UDP or TCP). 913 o Checksum offset: Offset relative to the start of the 914 encapsulated packet where the derived checksum value is to be 915 written. This typically is the offset of the checksum field in 916 the transport header (e.g. UDP or TCP). 918 7.2. Usage 920 7.2.1. Transmitter operation 922 The typical actions to set remote checksum offload on transmit are: 924 1) Transport layer creates a packet and indicates in internal 925 packet meta data that checksum is to be offloaded to the NIC 926 (normal transport layer processing for checksum offload). The 927 checksum field is populated with the bitwise not of the 928 checksum of the pseudo header or zero as appropriate. 930 2) Encapsulation layer adds its headers to the packet including 931 the remote checksum offload option. The start offset and 932 checksum offset are set accordingly. 934 3) Encapsulation layer arranges for checksum offload of the outer 935 header checksum (e.g. UDP). 937 4) Packet is sent to the NIC. The NIC will perform transmit 938 checksum offload and set the checksum field in the outer 939 header. The inner header and rest of the packet are transmitted 940 without modification. 942 7.2.2. Receiver operation 944 The typical actions a host receiver does to support remote checksum 945 offload are: 947 1) Receive packet and validate outer checksum following normal 948 processing (e.g. validate non-zero UDP checksum). 950 2) Validate the remote checksum option. If checksum start is 951 greater than the length of the packet, then the packet MUST be 952 dropped. If checksum offset is greater then the length of the 953 packet minus two, then the packet MUST be dropped. 955 3) Deduce full checksum for the IP packet. If a NIC is capable of 956 receive checksum offload it will return either the full 957 checksum of the received packet or an indication that the UDP 958 checksum is correct. Either of these methods can be used to 959 deduce the checksum over the IP packet [UDPENCAP]. 961 4) From the packet checksum, subtract the checksum computed from 962 the start of the packet (outer IP header) to the offset in the 963 packet indicted by checksum start in the meta data. The result 964 is the deduced checksum to set in the checksum field of the 965 encapsulated transport packet. 967 In pseudo code: 969 csum: initialized to checksum computed from start (outer IP 970 header) to the end of the packet 971 start_of_packet: address of start of packet 972 encap_payload_offset: relative to start_of_packet 973 csum_start: value from the checksum start field 974 checksum(start, len): function to compute checksum from start 975 address for len bytes 977 csum -= checksum(start_of_packet, encap_payload_offset + 978 csum_start) 980 5) Write the resultant checksum value into the packet at the 981 offset provided by checksum offset in the meta data. 983 In pseudo code: 985 csum_offset: value from the checksum offset field 987 *(start_of_packet + encap_payload_offset + 988 csum_offset) = csum 990 6) Checksum is verified at the transport layer using normal 991 processing. This should not require any checksum computation 992 over the packet since the complete checksum has already been 993 provided. 995 7.3. Security Considerations 997 Remote checksum offload allows a means to change the GUE payload 998 before being received at a decapsulator. In order to prevent misuse 999 of this mechanism, a decapsulator MUST apply security checks on the 1000 GUE payload only after checksum remote offload has been processed. 1002 8. Checksum option 1004 The GUE checksum option provides a checksum that covers the GUE 1005 header, a GUE pseudo header, and optionally part or all of the GUE 1006 payload. The GUE pseudo header includes the corresponding IP 1007 addresses as well as the UDP ports of the encapsulating headers. This 1008 checksum should provide adequate protection against address 1009 corruption in IPv6 when the UDP checksum is zero. Additionally, the 1010 GUE checksum provides protection of the GUE header when the UDP 1011 checksum is set to zero with either IPv4 or IPv6. In particular, the 1012 GUE checksum can provide protection for some sensitive data, such as 1013 the virtual network identifier ([I.D.hy-nvo3-gue-4-nvo]), which when 1014 corrupted could lead to mis-delivery of a packet to the wrong virtual 1015 network. 1017 8.1. Extension field format 1019 The presence of the GUE checksum option is indicated by the K bit in 1020 the GUE header. 1022 The format of the checksum extension is: 1024 0 1 2 3 1025 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 1026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1027 | Checksum | Payload coverage | 1028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1030 The fields of the option are: 1032 o Checksum: Computed checksum value. This checksum covers the GUE 1033 header (including fields and private data covered by Hlen), the 1034 GUE pseudo header, and optionally all or part of the payload 1035 (encapsulated packet). 1037 o Payload coverage: Number of bytes of payload to cover in the 1038 checksum. Zero indicates that the checksum only covers the GUE 1039 header and GUE pseudo header. If the value is greater than the 1040 encapsulated payload length, the packet MUST be dropped. 1042 8.2. Requirements 1044 The GUE header checksum SHOULD be set on transmit when using a zero 1045 UDP checksum with IPv6. 1047 The GUE header checksum SHOULD be used when the UDP checksum is zero 1048 for IPv4 if the GUE header includes data that when corrupted can lead 1049 to misdelivery or other serious consequences, and there is no other 1050 mechanism that provides protection (no security field that checks 1051 integrity for instance). 1053 The GUE header checksum SHOULD NOT be set when the UDP checksum is 1054 non-zero. In this case the UDP checksum provides adequate protection 1055 and this avoids convolutions when a packet traverses NAT that does 1056 address translation (in that case the UDP checksum is required). 1058 8.3. GUE checksum pseudo header 1060 The GUE pseudo header checksum is included in the GUE checksum to 1061 provide protection for the IP and UDP header elements which when 1062 corrupted could lead to misdelivery of the GUE packet. The GUE pseudo 1063 header checksum is similar to the standard IP pseudo header defined 1064 in [RFC0768] and [RFC0793] for IPv4, and in [RFC2460] for IPv6. 1066 The GUE pseudo header for IPv4 is: 1068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1069 | Source Address | 1070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1071 | Destination Address | 1072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1073 | Source port | Destination port | 1074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1076 The GUE pseudo header for IPv6 is: 1078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1079 | | 1080 + + 1081 | | 1082 + Source Address + 1083 | | 1084 + + 1085 | | 1086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1087 | | 1088 + + 1089 | | 1090 + Destination Address + 1091 | | 1092 + + 1093 | | 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 | Source port | Destination port | 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1098 Note that the GUE pseudo header does not include payload length or 1099 protocol as in the standard IP pseudo headers. The length field is 1100 deemed unnecessary because: 1102 o If the length is corrupted this will usually be detected by a 1103 checksum validation failure on the inner packet. 1105 o Fragmentation of packets in a tunnel should occur on the inner 1106 packet before being encapsulated or GUE fragmentation (section 1107 4) MAY be performed at tunnel ingress. GUE packets are not 1108 expected to be fragmented when using IPv6. See [RFC6936] for 1109 considerations of payload length and IPv6 checksum. 1111 o A corrupted length field in itself should not lead to 1112 misdelivery of a packet. 1114 o Without the length field, the GUE pseudo header checksum is the 1115 same for all packets of flow. This is a useful property for 1116 optimizations such as TCP Segment Offload (TSO). 1118 8.4. Usage 1120 The GUE checksum is computed and verified following the standard 1121 process for computing the Internet checksum [RFC1071]. Checksum 1122 computation may be optimized per the mathematical properties 1123 including parallel computation and incremental updates. 1125 8.4.1. Transmitter operation 1127 The procedure for setting the GUE checksum on transmit is: 1129 1) Create the GUE header including the checksum and payload 1130 coverage fields. The checksum field is initially set to zero. 1132 2) Calculate the 1's complement checksum of the GUE header from 1133 the start of the GUE header through the its length as indicated 1134 in GUE Hlen. 1136 3) Calculate the checksum of the GUE pseudo header for IPv4 or 1137 IPv6. 1139 4) Calculate checksum of payload portion if payload coverage is 1140 enabled (payload coverage field is non-zero). If the length of 1141 the payload coverage is odd, logically append a single zero 1142 byte for the purposes of checksum calculation. 1144 5) Add and fold the computed checksums for the GUE header, GUE 1145 pseudo header and payload coverage. Set the bitwise not of the 1146 result in the GUE checksum field. 1148 8.4.2.Receiver operation 1150 If the GUE checksum option is present, the receiver MUST validate the 1151 checksum before processing any other fields or accepting the packet. 1153 The procedure for verifying the checksum is: 1155 1) If the payload coverage length is greater than the length of 1156 the encapsulated payload then drop the packet. 1158 2) Calculate the checksum of the GUE header from the start of the 1159 header to the end as indicated by Hlen. 1161 3) Calculate the checksum of the appropriate GUE pseudo header. 1163 4) Calculate the checksum of payload if payload coverage is 1164 enabled (payload coverage is non-zero). If the length of the 1165 payload coverage is odd logically append a single zero byte for 1166 the purposes of checksum calculation. 1168 5) Sum the computed checksums for the GUE header, GUE pseudo 1169 header, and payload coverage. If the result is all 1 bits (-0 1170 in 1's complement arithmetic), the checksum is valid and the 1171 packet is accepted; otherwise the checksum is considered 1172 invalid and the packet MUST be dropped. 1174 8.5. Security Considerations 1176 The checksum option is only a mechanism for corruption detection, it 1177 is not a security mechanism. To provide integrity checks or 1178 authentication of the GUE header, the GUE security option SHOULD be 1179 used. 1181 9. Processing order of options 1183 Options MUST be processed in a specific order for both sending and 1184 receive. Note that some options, such as the checksum option, depend 1185 on other fields in the GUE header to be set. 1187 The order of processing options to send a GUE packet are: 1189 1) Set group identifier option. 1191 2) Fragment if necessary and set fragmentation option. If the 1192 group identifier is present it is copied into each fragment. 1193 Note that if payload transformation will increase the size of 1194 the payload that MUST be accounted for when deciding how to 1195 fragment 1197 3) Perform payload transform (potentially on a fragment) and set 1198 payload transform option. 1200 4) Set Remote checksum offload. 1202 5) Set security option. If the checksum option field is also 1203 present, the checksum value and the payload coverage MUST be 1204 set to zero if computing an HMAC over the GUE header. 1206 6) Calculate GUE checksum and set checksum option. 1208 On reception the order of actions is reversed. 1210 1) Verify GUE checksum. 1212 2) Verify security option. If the GUE checksum is also present and 1213 HMAC computation is being done over the GUE header, set the 1214 checksum and payload fields in the checksum option to zero 1215 before computing the HMAC. 1217 3) Adjust packet for remote checksum offload. 1219 4) Perform payload transformation (i.e. decrypt payload). 1221 5) Perform reassembly. 1223 6) Process packet (take group identifier into account if present). 1225 Note that the relative processing order of private fields is 1226 unspecified. 1228 10. Security Considerations 1230 Encapsulation of network protocol in GUE should not increase security 1231 risk, nor provide additional security in itself. GUE requires that 1232 the source port for UDP packets SHOULD be randomly seeded to mitigate 1233 some possible denial service attacks. 1235 If the integrity and privacy of data packets being transported 1236 through GUE is a concern, GUE security option and payload encryption 1237 using the the transform option SHOULD be used to remove the concern. 1238 If the integrity is the only concern, the tunnel may consider use of 1239 GUE security only for optimization. Likewise, if privacy is the only 1240 concern, the tunnel may use GUE encryption function only. 1242 If GUE payload already provides secure mechanism, e.g., the payload 1243 is IPsec packets, it is still valuable to consider use of GUE 1244 security. 1246 GUE may rely on other secure tunnel mechanisms such as DTLS [RFC6347] 1247 over the whole UDP payload for securing the whole GUE packet or IPsec 1248 [RFC4301] to achieve the secure transport over an IP network or 1249 Internet. 1251 IPsec [RFC4301] was designed as a network security mechanism, and 1252 therefore it resides at the network layer. As such, if the tunnel is 1253 secured with IPsec, the UDP header would not be visible to 1254 intermediate routers in either IPsec tunnel or transport mode. The 1255 big drawback here prohibits intermediate routers to perform load 1256 balancing based on the flow entropy in UDP header. In addition, this 1257 method prohibits any middle box function on the path. 1259 By comparison, DTLS [RFC6347] was designed with application security 1260 and can better preserve network and transport layer protocol 1261 information than IPsec [RFC4301]. Using DTLS over UDP to secure the 1262 GUE tunnel, both GUE header and payload will be encrypted. In order 1263 to differentiate plaintext GUE header from encrypted GUE header, the 1264 destination port of the UDP header between two must be different, 1265 which essentially requires another standard UDP port for GUE with 1266 DTLS. The drawback on this method is to prevent a middle box 1267 operation to GUE tunnel on the path. 1269 Use of two independent tunnel mechanisms such as GUE and DTLS over 1270 UDP to carry a network protocol over an IP network adds some overlap 1271 and complexity. For example, fragmentation will be done twice. 1273 As the result, a GUE tunnel SHOULD use the security mechanisms 1274 specified in this document to provide secure transport over an IP 1275 network or Internet when it is needed. GUE encapsulation can be used 1276 as a secure transport mechanism over an IP network and Internet. 1278 11. IANA Consideration 1280 IANA is requested to assign flags for the extensions defined in this 1281 specification. Specifically, an assignment is requested for the Group 1282 Identfier, Security, Fragmentation, Payload Transform, Remote 1283 Checksum Offload, and Checksum extensions in the "GUE flag-fields" 1284 registry. 1286 +-------------+---------------+-------------+--------------------+ 1287 | Flags bits | Field size | Description | Reference | 1288 +-------------+---------------+-------------+--------------------+ 1289 | Bit 0 | 4 bytes | Group | This document | 1290 | | | identifier | | 1291 | | | | | 1292 | Bit 1..3 | 001->8 bytes | Security | This document | 1293 | | 010->16 bytes | | | 1294 | | 011->32 bytes | | | 1295 | | 100->40 bytes | | | 1296 | | | | | 1297 | Bit 4 | 8 bytes | Fragmen- | This document | 1298 | | | tation | | 1299 | | | | | 1300 | Bit 5 | 4 bytes | Payload | This document | 1301 | | | transform | | 1302 | | | | | 1303 | Bit 6 | 4 bytes | Remote | This document | 1304 | | | checksum | | 1305 | | | offload | | 1306 | | | | | 1307 | Bit 7 | 4 bytes | Checksum | This document | 1308 | | | | | 1309 | Bit 8..15 | | Unassigned | | 1310 +-------------+---------------+-------------+--------------------+ 1312 IANA is requested to set up a registry for the GUE payload transform 1313 types. Payload transform types are 8 bit values. New values for 1314 control types 1-127 are assigned via Standards Action [RFC5226]. 1316 +----------------+------------------+---------------+ 1317 | Transform type | Description | Reference | 1318 +----------------+------------------+---------------+ 1319 | 0 | Reserved | This document | 1320 | | | | 1321 | 1 | DTLS | This document | 1322 | | | | 1323 | 2..127 | Unassigned | | 1324 | | | | 1325 | 128..255 | User defined | This document | 1326 +----------------+------------------+---------------+ 1328 12. References 1330 12.1. Normative References 1332 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1333 1981. 1335 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1336 (IPv6) Specification", RFC 2460, December 1998. 1338 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 1339 Communication Layers", STD 3, RFC 1122, October 1989. 1341 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1342 August 1980. 1344 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1345 IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 1346 10.17487/RFC5226, May 2008, . 1349 [I.D.ietf-gue] T. Herbert, L. Yong, and O. Zia, "Generic UDP 1350 Encapsulation" draft-ietf-intarea-gue-01 1352 12.2. Informative References 1354 [RFC3931] Lau, J., Townsley, W., et al, "Layer Two Tunneling Protocol 1355 - Version 3 (L2TPv3)", RFC3931, 1999 1357 [RFC2104] Kent, S. and R. Atkinson, "Security Architecture for the 1358 Internet Protocol" , RFC 2401, DOI 10.17487/RFC2401, 1359 November 1998, . 1361 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain of 1362 Interpretation" , RFC 6407, DOI 10.17487/RFC6407, October 1363 2011, . 1365 [RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the- 1366 Network Tunneling", RFC 4459, DOI 10.17487/RFC4459, April 1367 2006, . 1369 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 1370 Errors at High Data Rates", RFC 4963, DOI 10.17487/RFC4963, 1371 July 2007, . 1373 [RFC2764] B. Gleeson, A. Lin, J. Heinanen, G. Armitage, A. Malis, "A 1374 Framework for IP Based Virtual Private Networks", RFC2764, 1375 February 2000. 1377 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1378 Internet Protocol", RFC 4301, December 2005. 1380 [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security 1381 Considerations for IP Fragment Filtering", RFC 1858, 1382 October 1995. 1384 [RFC3128] Miller, I., "Protection Against a Variant of the Tiny 1385 Fragment Attack (RFC 1858)", RFC 3128, June 2001. 1387 [RFC6347] Rescoria, E., Modadugu, N., "Datagram Transport Layer 1388 Security Version 1.2", RFC6347, 2012. 1390 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 1391 793, DOI 10.17487/RFC0793, September 1981, . 1394 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 1395 for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 1396 6936, DOI 10.17487/RFC6936, April 2013, . 1399 [RFC1071] Braden, R., Borman, D., and C. Partridge, "Computing the 1400 Internet checksum", RFC1071, September 1988. 1402 [I.D.hy-nvo3-gue-4-nvo] Yong, L., Herbert, T., "Generic UDP 1403 Encapsulation (GUE) for Network Virtualization Overlay" 1404 draft-hy-nvo3-gue-4-nvo-03 1406 [I.D.previdi-6man-sr-header] Previdi S. et al, "IPv6 Segment Routing 1407 Header (SRH) draft-ietf-6man-segment-routing-header-02 1409 [I.D.templin-aerolink] F. Templin, "Transmission of IP Packets over 1410 AERO Links" draft-templin-aerolink-62 1412 [UDPENCAP] T. Herbert, "UDP Encapsulation in Linux", 1413 http://people.netfilter.org/pablo/netdev0.1/papers/UDP- 1414 Encapsulation-in-Linux.pdf 1416 [FIPS180-4] Secure Hash Standard (SHS), Nation Institute of Standards 1417 and Technology, 8/2015 1419 Authors' Addresses 1421 Tom Herbert 1422 Quantonium 1423 4701 Patrick Henry Dr. 1424 Santa Clara, CA 1425 USA 1427 EMail: tom@herbertland.com 1429 Lucy Yong 1430 Huawei USA 1431 5340 Legacy Dr. 1432 Plano, TX 75024 1433 USA 1435 Email: lucy.yong@huawei.com 1437 Fred L. Templin 1438 Boeing Research & Technology 1439 P.O. Box 3707 1440 Seattle, WA 98124 1441 USA 1443 Email: fltemplin@acm.org