| draft-ietf-intarea-gue-extensions-05.txt | draft-ietf-intarea-gue-extensions-06.txt | |||
|---|---|---|---|---|
| INTERNET-DRAFT T. Herbert | INTERNET-DRAFT T. Herbert | |||
| Intended Status: Proposed Standard Quantonium | Intended Status: Proposed Standard Quantonium | |||
| Expires: March 4, 2019 L. Yong | Expires: September 9, 2019 L. Yong | |||
| Huawei | Independent | |||
| F. Templin | F. Templin | |||
| Boeing | Boeing | |||
| August 31, 2018 | March 8, 2019 | |||
| Extensions for Generic UDP Encapsulation | Extensions for Generic UDP Encapsulation | |||
| draft-ietf-intarea-gue-extensions-05 | draft-ietf-intarea-gue-extensions-06 | |||
| Abstract | Abstract | |||
| This specification defines a set of the initial optional extensions | This specification defines a set of the initial optional extensions | |||
| for Generic UDP Encapsulation (GUE). | for Generic UDP Encapsulation (GUE). | |||
| Status of this Memo | Status of this Memo | |||
| This Internet-Draft is submitted to IETF in full conformance with the | This Internet-Draft is submitted to IETF in full conformance with the | |||
| provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
| skipping to change at page 1, line 42 ¶ | skipping to change at page 1, line 42 ¶ | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
| http://www.ietf.org/1id-abstracts.html | http://www.ietf.org/1id-abstracts.html | |||
| The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
| http://www.ietf.org/shadow.html | http://www.ietf.org/shadow.html | |||
| Copyright and License Notice | Copyright and License Notice | |||
| Copyright (c) 2018 IETF Trust and the persons identified as the | Copyright (c) 2019 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
| (http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
| publication of this document. Please review these documents | publication of this document. Please review these documents | |||
| carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
| to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
| include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
| the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
| skipping to change at page 2, line 29 ¶ | skipping to change at page 2, line 29 ¶ | |||
| 4.1. Extension field format . . . . . . . . . . . . . . . . . . 7 | 4.1. Extension field format . . . . . . . . . . . . . . . . . . 7 | |||
| 4.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 4.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
| 4.3. Cookies . . . . . . . . . . . . . . . . . . . . . . . . . 8 | 4.3. Cookies . . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 4.4.1. Extension field format . . . . . . . . . . . . . . . . 9 | 4.4.1. Extension field format . . . . . . . . . . . . . . . . 9 | |||
| 4.3.1. Operation . . . . . . . . . . . . . . . . . . . . . . . 8 | 4.3.1. Operation . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 4.3.1.1. Transmitter operation . . . . . . . . . . . . . . . 8 | 4.3.1.1. Transmitter operation . . . . . . . . . . . . . . . 8 | |||
| 4.3.1.2. Receiver operation . . . . . . . . . . . . . . . . 9 | 4.3.1.2. Receiver operation . . . . . . . . . . . . . . . . 9 | |||
| 4.4. HMAC . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 | 4.4. HMAC . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
| 4.4.1. Extension field format . . . . . . . . . . . . . . . . 9 | 4.4.1. Extension field format . . . . . . . . . . . . . . . . 9 | |||
| 4.4.2. Selecting a hash algorithm . . . . . . . . . . . . . . 10 | 4.4.2. Selecting a hash algorithm . . . . . . . . . . . . . . 10 | |||
| 4.4.3. Pre-shared key management . . . . . . . . . . . . . . . 10 | 4.4.3. Pre-shared key management . . . . . . . . . . . . . . . 11 | |||
| 4.4.4. Operation . . . . . . . . . . . . . . . . . . . . . . . 11 | 4.4.4. Operation . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
| 4.4.4.1. Transmitter operation . . . . . . . . . . . . . . . 11 | 4.4.4.1. Transmitter operation . . . . . . . . . . . . . . . 11 | |||
| 4.4.4.2. Receiver operation . . . . . . . . . . . . . . . . 11 | 4.4.4.2. Receiver operation . . . . . . . . . . . . . . . . 11 | |||
| 4.5. Interaction with other optional extensions . . . . . . . . 12 | 4.5. Interaction with other optional extensions . . . . . . . . 12 | |||
| 5. Fragmentation option . . . . . . . . . . . . . . . . . . . . . 12 | 5. Fragmentation option . . . . . . . . . . . . . . . . . . . . . 12 | |||
| 5.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 13 | 5.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
| 5.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 14 | 5.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
| 5.3. Extension field format . . . . . . . . . . . . . . . . . . 14 | 5.3. Extension field format . . . . . . . . . . . . . . . . . . 14 | |||
| 5.4. Fragmentation procedure . . . . . . . . . . . . . . . . . 15 | 5.4. Fragmentation procedure . . . . . . . . . . . . . . . . . 15 | |||
| 5.5. Reassembly procedure . . . . . . . . . . . . . . . . . . . 17 | 5.5. Reassembly procedure . . . . . . . . . . . . . . . . . . . 17 | |||
| skipping to change at page 3, line 34 ¶ | skipping to change at page 3, line 34 ¶ | |||
| 10.3. Corrupted alternate checksum flag . . . . . . . . . . . . 32 | 10.3. Corrupted alternate checksum flag . . . . . . . . . . . . 32 | |||
| 10.4. Security Considerations . . . . . . . . . . . . . . . . . 33 | 10.4. Security Considerations . . . . . . . . . . . . . . . . . 33 | |||
| 11. Processing order of options . . . . . . . . . . . . . . . . . 33 | 11. Processing order of options . . . . . . . . . . . . . . . . . 33 | |||
| 11.1. Processing order when sending . . . . . . . . . . . . . . 33 | 11.1. Processing order when sending . . . . . . . . . . . . . . 33 | |||
| 11.2. Processing order when receiving . . . . . . . . . . . . . 34 | 11.2. Processing order when receiving . . . . . . . . . . . . . 34 | |||
| 12. Security Considerations . . . . . . . . . . . . . . . . . . . 34 | 12. Security Considerations . . . . . . . . . . . . . . . . . . . 34 | |||
| 13. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 35 | 13. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 35 | |||
| 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 | 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 | |||
| 14.1. Normative References . . . . . . . . . . . . . . . . . . . 37 | 14.1. Normative References . . . . . . . . . . . . . . . . . . . 37 | |||
| 14.2. Informative References . . . . . . . . . . . . . . . . . . 37 | 14.2. Informative References . . . . . . . . . . . . . . . . . . 37 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 | |||
| 1. Introduction | 1. Introduction | |||
| Generic UDP Encapsulation (GUE) [I.D.ietf-gue] is a generic and | Generic UDP Encapsulation (GUE) [I.D.ietf-gue] is a generic and | |||
| extensible encapsulation protocol. This specification defines an | extensible encapsulation protocol. This specification defines an | |||
| initial set of optional extensions for variant 0 of GUE. These | initial set of optional extensions for variant 0 of GUE. These | |||
| extensions are the group identifier, security, fragmentation, payload | extensions are the Group Identifier, Security, Fragmentation, Payload | |||
| transform, remote checksum offload, checksum, NAT address checksum, | Transform, Remote Checksum Offload, Checksum, NAT Address Checksum, | |||
| and alternate checksum. | and Alternate Checksum. | |||
| 2. GUE header format with optional extensions | 2. GUE header format with optional extensions | |||
| The format of a variant 0 GUE header with optional extensions is: | The format of a variant 0 GUE header with optional extensions is: | |||
| 0 1 2 3 | 0 1 2 3 | |||
| 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 | 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 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ | |||
| | Source port | Destination port | | | | Source port | Destination port | | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP | |||
| | Length | Checksum | | | | Length | Checksum | | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ | |||
| | 0 |C| Hlen | Proto/ctype |G| SEC |F|T|R|K|N|A| Rsvd | | | 0 |C| Hlen | Proto/ctype |G| SEC |F|T|R|K|N|A| Rsvd |\ | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | |||
| | Group identifier (optional) | | | Group identifier (optional) | | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | |||
| | | | | | | | |||
| ~ Security (optional) ~ | ~ Security (optional) ~ | | |||
| | | | | | | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | |||
| | | | | | | | |||
| + Fragmentation (optional) + | + Fragmentation (optional) + | | |||
| | | | | | GUE | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | |||
| | Payload transform (optional) | | | Payload transform (optional) | | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | |||
| | Remote checksum offload (optional) | | | Remote checksum offload (optional) | | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | |||
| | Checksum (optional) | | | Checksum (optional) | | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | |||
| | NAT Address Checksum (optional) | | | NAT Address Checksum (optional) | | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | |||
| | | | | | | | |||
| + Alternate checksum (optional) + | + Alternate checksum (optional) + | | |||
| | | | | | | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | |||
| | | | | | | | |||
| ~ Private data (optional) ~ | ~ Private data (optional) ~ | | |||
| | | | | | | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ | |||
| The contents of the UDP header are described in [I.D.ietf-gue]. | The contents of the UDP header are described in [I.D.ietf-gue]. | |||
| The GUE header consists of: | The GUE header consists of: | |||
| o Variant: Set to 0 to indicate GUE encapsulation header. Note | o Variant: Set to 0 to indicate GUE encapsulation header. Note | |||
| that variant 1 (direct IP encapsulation) does not allow options. | that variant 1 (direct IP encapsulation) does not allow optional | |||
| extensions. | ||||
| o C: C-bit. Indicates the GUE payload is a control message when | o C: C-bit. Indicates the GUE payload is a control message when | |||
| set, a data message when not set. GUE optional extensions can be | set, a data message when not set. GUE optional extensions can be | |||
| used with either control or data messages unless otherwise | used with either control or data messages unless otherwise | |||
| specified in the extension definition. | stated in the specification of the extension. | |||
| o Hlen: Length in 32-bit words of the GUE header, including | o Hlen: Length in 32-bit words of the GUE header, including | |||
| optional extension fields and private data but not the first | optional extension fields and private data but not the first | |||
| four bytes of the header. Computed as (header_len - 4) / 4. The | four bytes of the header. Computed as (header_len - 4) / 4. The | |||
| length of the encapsulated packet is determined from the UDP | length of the encapsulated packet is determined from the UDP | |||
| length and the Hlen: encapsulated_packet_length = UDP_Length - | length and the Hlen: encapsulated_packet_length = UDP_Length - | |||
| 12 - 4 * Hlen. | 12 - 4 * Hlen. | |||
| o Proto/ctype: If the C-bit is not set this indicates IP protocol | o Proto/ctype: If the C-bit is not set this indicates the IP | |||
| number for the packet in the payload; if the C bit is set this | protocol number for the packet in the payload; if the C bit is | |||
| is the type of control message in the payload. The next header | set this is the type of control message in the payload. The next | |||
| begins at the offset provided by Hlen. When the payload | header begins at the offset provided by Hlen. When the payload | |||
| transform option or fragmentation option is used this field | transform option or fragmentation option is used this field | |||
| SHOULD be set to protocol number 59 for a data message, or zero | SHOULD be set to protocol number 59 for a data message, or zero | |||
| for a control message, to indicate there is no parsable protocol | for a control message, to indicate there is no parsable protocol | |||
| in the payload. | in the payload. | |||
| o G: Indicates the the group identifier extension field is | o G: Indicates the the group identifier extension field is | |||
| present. The group identifier option is described in section 3. | present. The group identifier option is described in section 3. | |||
| o SEC: Indicates security extension field is present. The security | o SEC: Indicates security extension field is present. The security | |||
| option is described in section 4. | option is described in section 4. | |||
| skipping to change at page 8, line 5 ¶ | skipping to change at page 8, line 6 ¶ | |||
| o 101b, 110b, 111b - Reserved values | o 101b, 110b, 111b - Reserved values | |||
| 4.2. Usage | 4.2. Usage | |||
| The GUE security option is used to provide integrity and | The GUE security option is used to provide integrity and | |||
| authentication of the GUE header. Security parameters (interpretation | authentication of the GUE header. Security parameters (interpretation | |||
| of security field, key management, etc.) are expected to be | of security field, key management, etc.) are expected to be | |||
| negotiated out-of-band between two communicating hosts. Two security | negotiated out-of-band between two communicating hosts. Two security | |||
| algorithms are defined below. | algorithms are defined below. | |||
| If the GUE security option is present in packet, the receiver MUST | If the GUE security option is present in a packet, the receiver MUST | |||
| validate the security before processing other fields or accepting the | validate the security before processing other fields or accepting the | |||
| packet. If the security option is not present, but the encapsulator | packet. If the security option is not present, but the encapsulator | |||
| and decapsulator have agreed that security is required, the receiver | and decapsulator have agreed that security is required, the receiver | |||
| MUST drop the packet as failing security checks. Note that this | MUST drop the packet as failing security checks. Note that this | |||
| provision covers the case where the security flags bits are corrupted | provision covers the case where the security flags bits are corrupted | |||
| such that they are reset to zero which would be interpreted as no | such that they are reset to zero which would be interpreted as no | |||
| security field being present. | security field being present. | |||
| 4.3. Cookies | 4.3. Cookies | |||
| skipping to change at page 9, line 49 ¶ | skipping to change at page 9, line 50 ¶ | |||
| | Payload offset | Payload length | | | Payload offset | Payload length | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | | |||
| ~ HMAC (256 bits) ~ | ~ HMAC (256 bits) ~ | |||
| | | | | | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Fields are: | Fields are: | |||
| o HMAC Key-id: opaque field to allow multiple hash algorithms or | o HMAC Key-id: opaque field to allow multiple hash algorithms or | |||
| key selection | key selection | |||
| o Payload offset: offset in payload that indicates the first octet | o Payload offset: offset in payload that indicates the first octet | |||
| of payload data included in the HMAC. | of payload data included in the HMAC. | |||
| o Payload length: length of payload data starting from the payload | o Payload length: length of payload data starting from the payload | |||
| offset to be included in the HMAC calculation. Zero | offset to be included in the HMAC calculation. Zero indicates no | |||
| indicates no payload data in used in the | payload data in used in the calculation. | |||
| calculation. | ||||
| o HMAC: Output of HMAC computation | o HMAC: Output of HMAC computation | |||
| The HMAC field is the output of the HMAC computation (per [RFC2104]) | The HMAC field is the output of the HMAC computation (per [RFC2104]) | |||
| using a pre-shared key identified by HMAC Key-id and of the text | using a pre-shared key identified by HMAC Key-id and of the text | |||
| which consists of the concatenation of: | which consists of the concatenation of: | |||
| o The IP addresses | o The IP addresses | |||
| o The GUE header including all optional extensions and any private | o The GUE header including all optional extensions and any private | |||
| data. For the purposes of calculating the HMAC value, the HMAC | data. For the purposes of calculating the HMAC value, the HMAC | |||
| value is set all zeroes. | value is set all zeroes. | |||
| o Optionally some or all of GUE payload. The portion of payload | o Optionally some or all of GUE payload. The portion of payload | |||
| covered is indicated by an offset into the payload and a length | covered is indicated by an offset into the payload and a length | |||
| relative to the offset. | relative to the offset. | |||
| The purpose of the HMAC option is to verify the validity, the | The purpose of the HMAC option is to verify the validity, the | |||
| integrity and the authentication of the GUE header itself and | integrity, and the authentication of the GUE header itself and | |||
| optionally some or all of the GUE payload. | optionally some or all of the GUE payload. | |||
| The HMAC Key-id field allows for the simultaneous existence of | The HMAC Key-id field allows for the simultaneous existence of | |||
| several hash algorithms (SHA-256, SHA3-256 ... or future ones) as | several hash algorithms (SHA-256, SHA3-256 ... or future ones) as | |||
| well as pre-shared keys. The HMAC Key-id field is opaque, i.e., it | well as pre-shared keys. The HMAC Key-id field is opaque, i.e., it | |||
| has neither syntax nor semantic. Having an HMAC Key-id field allows | has neither syntax nor semantic. Having an HMAC Key-id field allows | |||
| for pre-shared key roll-over when two pre-shared keys are supported | for pre-shared key roll-over when two pre-shared keys are supported | |||
| for a while when GUE endpoints converge to a fresher pre-shared key. | for a while when GUE endpoints converge to a fresher pre-shared key. | |||
| 4.4.2. Selecting a hash algorithm | 4.4.2. Selecting a hash algorithm | |||
| The HMAC field in the HMAC option is 256 bit wide. Therefore, the | The HMAC field in the HMAC option is 256 bits wide. Therefore, the | |||
| HMAC MUST be based on a hash function whose output is at least 256 | HMAC MUST be based on a hash function whose output is at least 256 | |||
| bits. If the output of the hash function is 256 bits, then this | bits. If the output of the hash function is 256 bits, then this | |||
| output is simply inserted in the HMAC field. If the output of the | output is simply inserted in the HMAC field. If the output of the | |||
| hash function is larger than 256 bits, then the output value is | hash function is larger than 256 bits, then the output value is | |||
| truncated to 256 bits by taking the least-significant 256 bits and | truncated to 256 bits by taking the least-significant 256 bits and | |||
| inserting them in the HMAC field. | inserting them in the HMAC field. | |||
| GUE implementations can support multiple hash functions but MUST | GUE implementations can support multiple hash functions but MUST | |||
| implement SHA-2 [FIPS180-4] in its SHA-256 variant. | implement SHA-2 [FIPS180-4] and its SHA-256 variant. | |||
| 4.4.3. Pre-shared key management | 4.4.3. Pre-shared key management | |||
| The field HMAC Key-id allows for: | The field HMAC Key-id allows for: | |||
| o Key roll-over: when there is a need to change the key (the hash | o Key roll-over: when there is a need to change the key (the hash | |||
| pre-shared secret), then multiple pre-shared keys can be used | pre-shared secret), then multiple pre-shared keys can be used | |||
| simultaneously. A decapsulator can have a table of <HMAC Key- | simultaneously. A decapsulator can have a table of <HMAC Key- | |||
| id, pre-shared secret> for the currently active and future keys. | id, pre-shared secret> for the currently active and future keys. | |||
| o Different algorithms: by extending the previous table to <HMAC | o Different algorithms: by extending the previous table to <HMAC | |||
| Key-id, hash function, pre-shared secret>, the decapsulator can | Key-id, hash function, pre-shared secret>, the decapsulator can | |||
| also support simultaneously several hash algorithms | also support simultaneously several hash algorithms | |||
| skipping to change at page 12, line 17 ¶ | skipping to change at page 12, line 18 ¶ | |||
| the packet. | the packet. | |||
| 2) Note value in the HMAC field and set the HMAC field to zero. | 2) Note value in the HMAC field and set the HMAC field to zero. | |||
| 3) Calculate the HMAC hash over the concatenation of the IP source | 3) Calculate the HMAC hash over the concatenation of the IP source | |||
| and destination addresses. The particular hash and keys are | and destination addresses. The particular hash and keys are | |||
| agreed between the encpasulator and decapsulator out of band, | agreed between the encpasulator and decapsulator out of band, | |||
| and the key for input to the hash is the one indicated by the | and the key for input to the hash is the one indicated by the | |||
| Key-Id amongst the set of shared keys. | Key-Id amongst the set of shared keys. | |||
| 4) Continue the the HMAC hash calculation from the start of the | 4) Continue the HMAC hash calculation from the start of the GUE | |||
| GUE header through the its length as indicated in GUE Hlen. | header through the its length as indicated in GUE Hlen. | |||
| 5) Continue the calculation to cover the payload portion if | 5) Continue the calculation to cover the payload portion if | |||
| payload coverage is enabled (payload length field is non-zero). | payload coverage is enabled (payload length field is non-zero). | |||
| The calculation continues at the payload offset for payload | The calculation continues at the payload offset for payload | |||
| length bytes. | length bytes. | |||
| 6) Compare the computed HMAC value with the original value of the | 6) Compare the computed HMAC value with the original value of the | |||
| HMAC field. If they are equal then the packet is accepted, if | HMAC field. If they are equal then the packet is accepted, if | |||
| they are not equal then verification failed and the packet MUST | they are not equal then verification failed and the packet MUST | |||
| be dropped. | be dropped. | |||
| skipping to change at page 14, line 9 ¶ | skipping to change at page 14, line 11 ¶ | |||
| encapsulate each segment (a non-IP fragmentation approach). | encapsulate each segment (a non-IP fragmentation approach). | |||
| Performing IP fragmentation on an encapsulated packet has the same | Performing IP fragmentation on an encapsulated packet has the same | |||
| issues as that of normal IP fragmentation. Most significant of these | issues as that of normal IP fragmentation. Most significant of these | |||
| is that the Identification field is only sixteen bits in IPv4 which | is that the Identification field is only sixteen bits in IPv4 which | |||
| introduces problems with wraparound as described in [RFC4963]. | introduces problems with wraparound as described in [RFC4963]. | |||
| The second possibility of alternative #1 follows the suggestion | The second possibility of alternative #1 follows the suggestion | |||
| expressed in [RFC2764] and the fragmentation feature described in the | expressed in [RFC2764] and the fragmentation feature described in the | |||
| AERO protocol [I.D.templin-aerolink]; that is for the tunneling | AERO protocol [I.D.templin-aerolink]; that is for the tunneling | |||
| protocol itself to incorporate a segmentation and reassembly | protocol itself to incorporate a fragmentation and reassembly | |||
| capability. In this method, fragmentation is part of the | capability. In this method, fragmentation is part of the | |||
| encapsulation and an encapsulation header contains the information | encapsulation and an encapsulation header contains the information | |||
| for reassembly. This differs from IP fragmentation in that the IP | for reassembly. This differs from IP fragmentation in that the IP | |||
| headers of the original packet are not replicated for each fragment. | headers of the original packet are not replicated for each fragment. | |||
| Incorporating fragmentation into the encapsulation protocol has some | Incorporating fragmentation into the encapsulation protocol has some | |||
| advantages: | advantages: | |||
| o At least a 32 bit identifier can be defined to avoid issues of | o At least a 32 bit identifier can be defined to avoid issues of | |||
| the 16 bit Identification in IPv4. | the 16 bit Identification in IPv4. | |||
| skipping to change at page 16, line 4 ¶ | skipping to change at page 15, line 51 ¶ | |||
| fragments, this is set to zero for a control message being | fragments, this is set to zero for a control message being | |||
| fragmented, or to "No next header" (protocol number 59) for a | fragmented, or to "No next header" (protocol number 59) for a | |||
| data message being fragmented. | data message being fragmented. | |||
| o F bit - Set to indicate presence of the fragmentation extension | o F bit - Set to indicate presence of the fragmentation extension | |||
| field. | field. | |||
| 5.4. Fragmentation procedure | 5.4. Fragmentation procedure | |||
| If an encapsulator determines that a packet must be fragmented (e.g. | If an encapsulator determines that a packet must be fragmented (e.g. | |||
| the packet's size exceeds the Path MTU of the tunnel) it should | the packet's size exceeds the Path MTU of the tunnel) it should | |||
| divide the packet into fragments and send each fragment as a separate | divide the packet into fragments and send each fragment as a separate | |||
| GUE packet, to be reassembled at the decapsulator (tunnel egress). | GUE packet, to be reassembled at the decapsulator (tunnel egress). | |||
| For every packet that is to be fragmented, the source node generates | For every packet that is to be fragmented, the source node generates | |||
| an Identification value. The Identification MUST be different than | an Identification value. The Identification MUST be different than | |||
| that of any other fragmented packet sent within the past 60 seconds | that of any other fragmented packet sent within the past 60 seconds | |||
| (Maximum Segment Lifetime) with the same tunnel identification-- that | (Maximum Segment Lifetime) or configured time with the same tunnel | |||
| is the same outer source and destination addresses, same UDP ports, | identification-- that is the same outer source and destination | |||
| same orig-proto, and same group identifier if present. | addresses, same UDP ports, same orig-proto, and same group identifier | |||
| if present. | ||||
| The initial, unfragmented, and unencapsulated packet is referred to | The initial, unfragmented, and unencapsulated packet is referred to | |||
| as the "original packet". This will be a layer 2 packet, layer 3 | as the "original packet". This will be a layer 2 packet, layer 3 | |||
| packet, or the payload of a GUE control message: | packet, or the payload of a GUE control message: | |||
| +-------------------------------//------------------------------+ | +-------------------------------//------------------------------+ | |||
| | Original packet | | | Original packet | | |||
| | (e.g. an IPv4, IPv6, Ethernet packet) | | | (e.g. an IPv4, IPv6, Ethernet packet) | | |||
| +------------------------------//-------------------------------+ | +------------------------------//-------------------------------+ | |||
| Fragmentation and encapsulation are performed on the original packet | Fragmentation and encapsulation are performed on the original packet | |||
| in sequence. First the packet is divided up in to fragments, and then | in sequence. First the packet is divided up in to fragments, and then | |||
| each fragment is encapsulated. Each fragment, except possibly the | each fragment is encapsulated. Each fragment, except possibly the | |||
| last ("rightmost") one, is an integer multiple of 8 octets long. | last ("rightmost") one, is an integer multiple of eight octets long. | |||
| Fragments MUST be non-overlapping. The number of fragments SHOULD be | Fragments MUST be non-overlapping. The number of fragments SHOULD be | |||
| minimized, and all but the last fragment should be approximately | minimized, and all but the last fragment should be approximately | |||
| equal in length. | equal in length. | |||
| The fragments are transmitted in separate "fragment packets" as: | The fragments are transmitted in separate "fragment packets" as: | |||
| +--------------+--------------+---------------+--//--+----------+ | +--------------+--------------+---------------+--//--+----------+ | |||
| | first | second | third | | last | | | first | second | third | | last | | |||
| | fragment | fragment | fragment | .... | fragment | | | fragment | fragment | fragment | .... | fragment | | |||
| +--------------+--------------+---------------+--//--+----------+ | +--------------+--------------+---------------+--//--+----------+ | |||
| skipping to change at page 19, line 4 ¶ | skipping to change at page 18, line 51 ¶ | |||
| fragmentation. To mitigate this problem, an implementation SHOULD | fragmentation. To mitigate this problem, an implementation SHOULD | |||
| ensure that the first fragment contains the headers of the | ensure that the first fragment contains the headers of the | |||
| encapsulated packet at least through the transport header. | encapsulated packet at least through the transport header. | |||
| A GUE node MUST be able to accept a fragmented packet that, after | A GUE node MUST be able to accept a fragmented packet that, after | |||
| reassembly and decapsulation, is as large as 1500 octets. This means | reassembly and decapsulation, is as large as 1500 octets. This means | |||
| that the node must configure a reassembly buffer that is at least as | that the node must configure a reassembly buffer that is at least as | |||
| large as 1500 octets plus the maximum-sized encapsulation headers | large as 1500 octets plus the maximum-sized encapsulation headers | |||
| that may be inserted during encapsulation. Implementations may find | that may be inserted during encapsulation. Implementations may find | |||
| it more convenient and efficient to configure a reassembly buffer | it more convenient and efficient to configure a reassembly buffer | |||
| size of 2KB which is large enough to accommodate even the largest set | size of 2KB which should be large enough to accommodate even the | |||
| of encapsulation headers and provides a natural memory page size | largest set of encapsulation headers and provides a natural memory | |||
| boundary. | page size boundary. | |||
| 5.6. Security Considerations | 5.6. Security Considerations | |||
| Exploits that have been identified with IP fragmentation are | Exploits that have been identified with IP fragmentation are | |||
| conceptually applicable to GUE fragmentation. | conceptually applicable to GUE fragmentation. | |||
| Attacks on GUE fragmentation can be mitigated by: | Attacks on GUE fragmentation can be mitigated by: | |||
| o Hardened implementation that applies applicable techniques from | o Hardened implementation that applies applicable techniques from | |||
| implementation of IP fragmentation. | implementation of IP fragmentation. | |||
| skipping to change at page 19, line 37 ¶ | skipping to change at page 19, line 36 ¶ | |||
| o Enforce a minimum size for the first fragment. | o Enforce a minimum size for the first fragment. | |||
| 6. Payload transform option | 6. Payload transform option | |||
| The payload transform option indicates that the GUE payload has been | The payload transform option indicates that the GUE payload has been | |||
| transformed. Transforming a payload is done by running a function | transformed. Transforming a payload is done by running a function | |||
| over the data and possibly modifying it (encrypting it for instance). | over the data and possibly modifying it (encrypting it for instance). | |||
| The payload transform option indicates the method used to transform | The payload transform option indicates the method used to transform | |||
| the data so that a decapsulator is able to validate and reverse the | the data so that a decapsulator is able to validate and reverse the | |||
| transformation to recover the original data. Payload transformations | transformation to recover the original data. Payload transformations | |||
| could include encryption, authentication, CRC coverage, and | include encryption, authentication, CRC coverage, and compression. | |||
| compression. This specification defines a transformation for DTLS. | This specification defines a transformation for DTLS. | |||
| 6.1. Extension field format | 6.1. Extension field format | |||
| The presence of the GUE payload transform option is indicated by the | The presence of the GUE payload transform option is indicated by the | |||
| T bit in the GUE header. | T bit in the GUE header. | |||
| The format of Payload Transform Field is: | The format of Payload Transform Field is: | |||
| 0 1 2 3 | 0 1 2 3 | |||
| 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 | 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 | |||
| skipping to change at page 20, line 22 ¶ | skipping to change at page 20, line 22 ¶ | |||
| 0x80~0xFF: for private payload transform types | 0x80~0xFF: for private payload transform types | |||
| A private payload transform type can be used for | A private payload transform type can be used for | |||
| experimental purposes or proprietary mechanisms. | experimental purposes or proprietary mechanisms. | |||
| P_C_type: Indicates the protocol or control type of the | P_C_type: Indicates the protocol or control type of the | |||
| untransformed payload. When payload transform option is | untransformed payload. When payload transform option is | |||
| present, proto/ctype in the GUE header is set to 59 ("No | present, proto/ctype in the GUE header is set to 59 ("No | |||
| next header") for a data message and zero for a control | next header") for a data message and zero for a control | |||
| message. The IP protocol or control message type of the | message. The IP protocol or control message type of the | |||
| untransformed payload MUST be encoded in this field. | untransformed payload MUST be encoded in this field. The | |||
| benefit of this rule is to prevent a middle box from | ||||
| The benefit of this rule is to prevent a middle box from | ||||
| inspecting the encrypted payload according to GUE next | inspecting the encrypted payload according to GUE next | |||
| protocol. The assumption here is that a middle box may | protocol. The assumption here is that a middle box may | |||
| understand GUE base header but does not understand GUE | understand GUE base header but does not understand GUE | |||
| option flag definitions. | option flag definitions. | |||
| Info: A field that can be set according to the requirements of | Info: A field that can be set according to the requirements of | |||
| each payload transform type. If the specification for a | each payload transform type. If the specification for a | |||
| payload transform type does not specify how this field is to | payload transform type does not specify how this field is to | |||
| be set, then the field MUST be set to zero. | be set, then the field MUST be set to zero. | |||
| skipping to change at page 21, line 28 ¶ | skipping to change at page 21, line 27 ¶ | |||
| create the security option. A decapsulator does processing in | create the security option. A decapsulator does processing in | |||
| reverse-- the security option is processed (GUE header is validated) | reverse-- the security option is processed (GUE header is validated) | |||
| and then the reverse payload transform is performed. | and then the reverse payload transform is performed. | |||
| In order to get flow entropy from the payload, an encapsulator should | In order to get flow entropy from the payload, an encapsulator should | |||
| derive the flow entropy before performing a payload transform. | derive the flow entropy before performing a payload transform. | |||
| 6.4. DTLS transform | 6.4. DTLS transform | |||
| The payload of a GUE packet can be secured using Datagram Transport | The payload of a GUE packet can be secured using Datagram Transport | |||
| Layer Security [RFC6347]. An encapsulator would apply DTLS to the GUE | Layer Security (DTLS) [RFC6347]. An encapsulator would apply DTLS to | |||
| payload so that the payload packets are encrypted and the GUE header | the GUE payload so that the payload packets are encrypted and the GUE | |||
| remains in plaintext. The payload transform option is set to indicate | header remains in plaintext. The payload transform option is set to | |||
| that the payload is interpreted as a DTLS record. | indicate that the payload is interpreted as a DTLS record. | |||
| The payload transform option for DTLS is: | The payload transform option for DTLS is: | |||
| 0 1 2 3 | 0 1 2 3 | |||
| 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 | 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 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | 1 | P_C_type | 0 | | | 1 | P_C_type | 0 | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| DTLS [RFC6347] provides a packet fragmentation capability. To avoid | DTLS [RFC6347] provides a packet fragmentation capability. To avoid | |||
| skipping to change at page 23, line 8 ¶ | skipping to change at page 23, line 5 ¶ | |||
| 7.2. Usage | 7.2. Usage | |||
| 7.2.1. Transmitter operation | 7.2.1. Transmitter operation | |||
| The typical actions to set remote checksum offload on transmit are: | The typical actions to set remote checksum offload on transmit are: | |||
| 1) Transport layer creates a packet and indicates in internal | 1) Transport layer creates a packet and indicates in internal | |||
| packet meta data that checksum is to be offloaded to the NIC | packet meta data that checksum is to be offloaded to the NIC | |||
| (normal transport layer processing for checksum offload). The | (normal transport layer processing for checksum offload). The | |||
| checksum field is populated with the bitwise not of the | checksum field is populated with the bitwise "not" of the | |||
| checksum of the pseudo header or zero as appropriate. | checksum of the pseudo header or zero as appropriate. | |||
| 2) Encapsulation layer adds its headers to the packet including | 2) Encapsulation layer adds its headers to the packet including | |||
| the remote checksum offload option. The start offset and | the remote checksum offload option. The start offset and | |||
| checksum offset are set accordingly. | checksum offset are set accordingly. | |||
| 3) Encapsulation layer arranges for checksum offload of the outer | 3) Encapsulation layer arranges for checksum offload of the outer | |||
| header checksum (e.g. UDP). | header checksum (i.e. UDP checksum). | |||
| 4) Packet is sent to the NIC. The NIC will perform transmit | 4) Packet is sent to the NIC. The NIC will perform transmit | |||
| checksum offload and set the checksum field in the outer | checksum offload and set the checksum field in the outer | |||
| header. The inner header and rest of the packet are transmitted | header. The inner header and rest of the packet are transmitted | |||
| without modification. | without modification. | |||
| 7.2.2. Receiver operation | 7.2.2. Receiver operation | |||
| The typical actions a host receiver does to support remote checksum | The typical actions a host receiver does to support remote checksum | |||
| offload are: | offload are: | |||
| skipping to change at page 23, line 42 ¶ | skipping to change at page 23, line 39 ¶ | |||
| greater than the length of the packet, then the packet MUST be | greater than the length of the packet, then the packet MUST be | |||
| dropped. If checksum offset is greater then the length of the | dropped. If checksum offset is greater then the length of the | |||
| packet minus two, then the packet MUST be dropped. | packet minus two, then the packet MUST be dropped. | |||
| 3) Deduce full checksum for the IP packet. If a NIC is capable of | 3) Deduce full checksum for the IP packet. If a NIC is capable of | |||
| receive checksum offload it will return either the full | receive checksum offload it will return either the full | |||
| checksum of the received packet or an indication that the UDP | checksum of the received packet or an indication that the UDP | |||
| checksum is correct. Either of these methods can be used to | checksum is correct. Either of these methods can be used to | |||
| deduce the checksum over the IP packet [UDPENCAP]. | deduce the checksum over the IP packet [UDPENCAP]. | |||
| 4) From the packet checksum, subtract the checksum computed from | 4) From the packet checksum subtract the checksum computed from | |||
| the start of the packet (outer IP header) to the offset in the | the start of the packet (outer IP header) to the offset in the | |||
| packet indicted by checksum start in the meta data. The result | packet indicted by checksum start in the meta data. The result | |||
| is the deduced checksum to set in the checksum field of the | is the deduced checksum to set in the checksum field of the | |||
| encapsulated transport packet. | encapsulated transport packet. | |||
| In pseudo code: | In pseudo code: | |||
| csum: initialized to checksum computed from start (outer IP | csum: initialized to checksum computed from start (outer IP | |||
| header) to the end of the packet | header) to the end of the packet | |||
| start_of_packet: address of start of packet | start_of_packet: address of start of packet | |||
| skipping to change at page 28, line 40 ¶ | skipping to change at page 28, line 40 ¶ | |||
| The NAT address checksum (NAC) option contains the checksum computed | The NAT address checksum (NAC) option contains the checksum computed | |||
| over the IP addresses of the packet. The computed value can be used | over the IP addresses of the packet. The computed value can be used | |||
| by a receiver to adjust a transport layer checksum that was affected | by a receiver to adjust a transport layer checksum that was affected | |||
| by NAT changing the IP addresses. This option is only useful when GUE | by NAT changing the IP addresses. This option is only useful when GUE | |||
| encapsulates a transport layer packet that has a checksum with a | encapsulates a transport layer packet that has a checksum with a | |||
| pseudo header that includes the IP addresses (such as TCP or UDP). | pseudo header that includes the IP addresses (such as TCP or UDP). | |||
| 9.1. Extension field format | 9.1. Extension field format | |||
| The presence of the NAT checksum address option is indicated by the N | The presence of the NAT address checksum option is indicated by the N | |||
| bit in the GUE header. | bit in the GUE header. | |||
| The format of the NAT checksum address extension is: | The format of the NAT checksum address extension is: | |||
| 0 1 2 3 | 0 1 2 3 | |||
| 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 | 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 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Checksum | Reserved | | | Checksum | Reserved | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| The fields of the option are: | The fields of the option are: | |||
| o Checksum: Computed checksum value. This checksum covers the | o Checksum: Computed checksum value. This checksum covers the | |||
| outer IP addresses. | outer IP addresses. | |||
| o Reserved: Must be zero on transmit. | o Reserved: Must be zero on transmit. | |||
| 9.2. Usage | 9.2. Usage | |||
| The NAT address extension SHOULD be set on transmit when | The NAT address extension SHOULD be set on transmit when | |||
| skipping to change at page 30, line 39 ¶ | skipping to change at page 30, line 39 ¶ | |||
| 2) Compute the checksum over the IP addresses in the received | 2) Compute the checksum over the IP addresses in the received | |||
| packet | packet | |||
| 3) Subtract the resultant from the checksum value in the NAC | 3) Subtract the resultant from the checksum value in the NAC | |||
| option. If the difference is non-zero then NAT has changed the | option. If the difference is non-zero then NAT has changed the | |||
| addresses | addresses | |||
| 4) When processing a transport layer containing a checksum | 4) When processing a transport layer containing a checksum | |||
| affected by NAT on the IP addresses, add the difference into | affected by NAT on the IP addresses, add the difference into | |||
| the checksum calculation when verify the packet. | the checksum calculation when verifying the packet. | |||
| In pseudo codes this is: | In pseudo codes this is: | |||
| actual = checksum(IP addresses) | actual = checksum(IP addresses) | |||
| diff = actual - NAC_value | diff = actual - NAC_value | |||
| verify = checksum(transport packet) + checksum(pseudo header) | verify = checksum(transport packet) + checksum(pseudo header) | |||
| + diff | + diff | |||
| if (verify == 0) | if (verify == 0) | |||
| packet is good | packet is good | |||
| skipping to change at page 32, line 19 ¶ | skipping to change at page 32, line 19 ¶ | |||
| payload coverage is enabled (payload coverage field is non- | payload coverage is enabled (payload coverage field is non- | |||
| zero). If the length of the payload coverage is not aligned to | zero). If the length of the payload coverage is not aligned to | |||
| four bytes, logically append zero bytes up to the necessary | four bytes, logically append zero bytes up to the necessary | |||
| alignment for the purposes of CRC calculation. | alignment for the purposes of CRC calculation. | |||
| 4) Set the resultant value in the CRC field. | 4) Set the resultant value in the CRC field. | |||
| 10.2.2. Receiver operation | 10.2.2. Receiver operation | |||
| If the GUE alternative checksum option is present, the receiver MUST | If the GUE alternative checksum option is present, the receiver MUST | |||
| validate the checksum before processing any other fields or accepting | validate the checksum before processing any other fields, except the | |||
| the packet. | GUE checksum, or accepting the packet. | |||
| The procedure for verifying the alternate checksum is: | The procedure for verifying the alternate checksum is: | |||
| 1) If the payload coverage length is greater than the length of | 1) If the payload coverage length is greater than the length of | |||
| the encapsulated payload then drop the packet. | the encapsulated payload then drop the packet. | |||
| 2) Note value in the CRC field and set the CRC field to zero. | 2) Note value in the CRC field and set the CRC field to zero. | |||
| 3) Calculate the CRC using the CRC-32C algorithm from the start of | 3) Calculate the CRC using the CRC-32C algorithm from the start of | |||
| the GUE header through the its length as indicated in GUE Hlen. | the GUE header through the its length as indicated in GUE Hlen. | |||
| skipping to change at page 34, line 48 ¶ | skipping to change at page 34, line 48 ¶ | |||
| ecapsulator and decapsulator. | ecapsulator and decapsulator. | |||
| 12. Security Considerations | 12. Security Considerations | |||
| Encapsulation of a network protocol in GUE should not increase | Encapsulation of a network protocol in GUE should not increase | |||
| security risk, nor provide additional security in itself. GUE | security risk, nor provide additional security in itself. GUE | |||
| requires that the source port for UDP packets SHOULD be randomly | requires that the source port for UDP packets SHOULD be randomly | |||
| seeded to mitigate some possible denial service attacks. | seeded to mitigate some possible denial service attacks. | |||
| If the integrity and privacy of data packets being transported | If the integrity and privacy of data packets being transported | |||
| through GUE is a concern, GUE security option and payload encryption | through GUE is a concern, the GUE security option and payload | |||
| using the the transform option SHOULD be used to remove the concern. | encryption using the the transform option SHOULD be used to remove | |||
| If the integrity is the only concern, the tunnel may consider use of | the concern. If the integrity is the only concern, the tunnel may | |||
| GUE security only for optimization. Likewise, if privacy is the only | consider use of GUE security only for optimization. Likewise, if | |||
| concern, the tunnel may use a GUE transform for encryption only. | privacy is the only concern, the tunnel may use a GUE transform for | |||
| encryption only. | ||||
| If GUE payload already provides secure mechanism, e.g., the payload | If a GUE payload already provides secure mechanism, e.g., the payload | |||
| is IPsec packets, it is still valuable to consider use of GUE | is an IPsec packet, it is still valuable to consider use of GUE | |||
| security. | security. | |||
| GUE may rely on other secure tunnel mechanisms such as DTLS [RFC6347] | GUE may rely on other secure tunnel mechanisms such as DTLS [RFC6347] | |||
| over the whole UDP payload for securing the whole GUE packet or IPsec | over the whole UDP payload for securing the whole GUE packet or IPsec | |||
| [RFC4301] to achieve the secure transport over an IP network or | [RFC4301] to achieve the secure transport over an IP network or | |||
| Internet. | Internet. | |||
| IPsec [RFC4301] was designed as a network security mechanism, and | IPsec [RFC4301] was designed as a network security mechanism, and | |||
| therefore it resides at the network layer. As such, if the tunnel is | therefore resides at the network layer. As such, if the tunnel is | |||
| secured with IPsec, the UDP header would not be visible to | secured with IPsec, the UDP header would not be visible to | |||
| intermediate routers in either IPsec tunnel or transport mode. This | intermediate routers in either IPsec tunnel or transport mode. This | |||
| is a drawback since it prohibits intermediate routers to perform load | is a drawback since it prohibits intermediate routers to perform load | |||
| balancing based on the flow entropy in UDP header. In addition, this | balancing based on the flow entropy in UDP header. In addition, this | |||
| method prohibits any middle box function on the path. | method prohibits some middle box functions on the path. | |||
| By comparison, DTLS [RFC6347] was designed for application level | By comparison, DTLS [RFC6347] was designed for application level | |||
| security and can better preserve network and transport layer protocol | security and can better preserve network and transport layer protocol | |||
| information than IPsec [RFC4301]. Using DTLS over UDP to secure the | information than IPsec [RFC4301]. Using DTLS over UDP to secure the | |||
| GUE tunnel, both GUE header and payload will be encrypted. In order | GUE tunnel, both GUE header and payload will be encrypted. In order | |||
| to differentiate plaintext GUE header from encrypted GUE header, the | to differentiate plaintext GUE header from the encrypted GUE header, | |||
| destination port of the UDP header between two must be different, | the destination port of the UDP header between two must be different, | |||
| which essentially requires another standard UDP port for GUE with | which essentially requires another standard UDP port for GUE with | |||
| DTLS. The drawback on this method is to prevent a middle box | DTLS. The drawback on this method is to prevent a middle box | |||
| operation to GUE tunnel on the path. | operation to GUE tunnel on the path. | |||
| Use of two independent tunnel mechanisms such as GUE and DTLS over | Use of two independent tunnel mechanisms such as GUE and DTLS over | |||
| UDP to carry a network protocol over an IP network adds some overlap | UDP to carry a network protocol over an IP network adds some overlap | |||
| and complexity. For example, fragmentation will be done twice. | and complexity. For example, fragmentation will be done twice. | |||
| As the result, a GUE tunnel SHOULD use the security mechanisms | As the result, a GUE tunnel SHOULD use the security mechanisms | |||
| specified in this document to provide secure transport over an IP | specified in this document to provide secure transport over an IP | |||
| skipping to change at page 37, line 29 ¶ | skipping to change at page 37, line 29 ¶ | |||
| 14.1. Normative References | 14.1. Normative References | |||
| [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September | [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September | |||
| 1981. | 1981. | |||
| [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 | [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 | |||
| (IPv6) Specification", STD 86, RFC 8200, DOI | (IPv6) Specification", STD 86, RFC 8200, DOI | |||
| 10.17487/RFC8200, July 2017, <https://www.rfc- | 10.17487/RFC8200, July 2017, <https://www.rfc- | |||
| editor.org/info/rfc8200>. | editor.org/info/rfc8200>. | |||
| [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - | [RFC6347] Rescoria, E., Modadugu, N., "Datagram Transport Layer | |||
| Communication Layers", STD 3, RFC 1122, October 1989. | Security Version 1.2", RFC6347, 2012. | |||
| [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, | [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, | |||
| August 1980. | August 1980. | |||
| [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC | ||||
| 793, DOI 10.17487/RFC0793, September 1981, <http://www.rfc- | ||||
| editor.org/info/rfc793>. | ||||
| [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an | [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an | |||
| IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI | IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI | |||
| 10.17487/RFC5226, May 2008, <http://www.rfc- | 10.17487/RFC5226, May 2008, <http://www.rfc- | |||
| editor.org/info/rfc5226>. | editor.org/info/rfc5226>. | |||
| [I.D.ietf-gue] T. Herbert, L. Yong, and O. Zia, "Generic UDP | [I.D.ietf-gue] T. Herbert, L. Yong, and O. Zia, "Generic UDP | |||
| Encapsulation" draft-ietf-intarea-gue-01 | Encapsulation" draft-ietf-intarea-gue-01 | |||
| [FIPS180-4] Secure Hash Standard (SHS), Nation Institute of Standards | ||||
| and Technology, 8/2015 | ||||
| 14.2. Informative References | 14.2. Informative References | |||
| [RFC3931] Lau, J., Townsley, W., et al, "Layer Two Tunneling Protocol | [RFC3931] Lau, J., Townsley, W., et al, "Layer Two Tunneling Protocol | |||
| - Version 3 (L2TPv3)", RFC3931, 1999 | - Version 3 (L2TPv3)", RFC3931, 1999 | |||
| [RFC2104] Kent, S. and R. Atkinson, "Security Architecture for the | [RFC2104] Kent, S. and R. Atkinson, "Security Architecture for the | |||
| Internet Protocol" , RFC 2401, DOI 10.17487/RFC2401, | Internet Protocol" , RFC 2401, DOI 10.17487/RFC2401, | |||
| November 1998, <http://www.rfc-editor.org/info/rfc2401>. | November 1998, <http://www.rfc-editor.org/info/rfc2401>. | |||
| [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain of | [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain of | |||
| Interpretation" , RFC 6407, DOI 10.17487/RFC6407, October | Interpretation" , RFC 6407, DOI 10.17487/RFC6407, October | |||
| 2011, <http://www.rfc-editor.org/info/rfc6407>. | 2011, <http://www.rfc-editor.org/info/rfc6407>. | |||
| [RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the- | [RFC4459] Savola, ., "MTU and Fragmentation Issues with In-the- | |||
| Network Tunneling", RFC 4459, DOI 10.17487/RFC4459, April | Network Tunneling", RFC 4459, DOI 10.17487/RFC4459, April | |||
| 2006, <http://www.rfc-editor.org/info/rfc4459>. | 2006, <http://www.rfc-editor.org/info/rfc4459>. | |||
| [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly | [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly | |||
| Errors at High Data Rates", RFC 4963, DOI 10.17487/RFC4963, | Errors at High Data Rates", RFC 4963, DOI 10.17487/RFC4963, | |||
| July 2007, <http://www.rfc-editor.org/info/rfc4963>. | July 2007, <http://www.rfc-editor.org/info/rfc4963>. | |||
| [RFC2764] B. Gleeson, A. Lin, J. Heinanen, G. Armitage, A. Malis, "A | [RFC2764] B. Gleeson, A. Lin, J. Heinanen, G. Armitage, A. Malis, "A | |||
| Framework for IP Based Virtual Private Networks", RFC2764, | Framework for IP Based Virtual Private Networks", RFC2764, | |||
| February 2000. | February 2000. | |||
| skipping to change at page 38, line 29 ¶ | skipping to change at page 38, line 36 ¶ | |||
| [RFC4301] Kent, S. and K. Seo, "Security Architecture for the | [RFC4301] Kent, S. and K. Seo, "Security Architecture for the | |||
| Internet Protocol", RFC 4301, December 2005. | Internet Protocol", RFC 4301, December 2005. | |||
| [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security | [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security | |||
| Considerations for IP Fragment Filtering", RFC 1858, | Considerations for IP Fragment Filtering", RFC 1858, | |||
| October 1995. | October 1995. | |||
| [RFC3128] Miller, I., "Protection Against a Variant of the Tiny | [RFC3128] Miller, I., "Protection Against a Variant of the Tiny | |||
| Fragment Attack (RFC 1858)", RFC 3128, June 2001. | Fragment Attack (RFC 1858)", RFC 3128, June 2001. | |||
| [RFC6347] Rescoria, E., Modadugu, N., "Datagram Transport Layer | ||||
| Security Version 1.2", RFC6347, 2012. | ||||
| [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC | ||||
| 793, DOI 10.17487/RFC0793, September 1981, <http://www.rfc- | ||||
| editor.org/info/rfc793>. | ||||
| [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement | ||||
| for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC | ||||
| 6936, DOI 10.17487/RFC6936, April 2013, <http://www.rfc- | ||||
| editor.org/info/rfc6936>. | ||||
| [RFC1071] Braden, R., Borman, D., and C. Partridge, "Computing the | [RFC1071] Braden, R., Borman, D., and C. Partridge, "Computing the | |||
| Internet checksum", RFC1071, September 1988. | Internet checksum", RFC1071, September 1988. | |||
| [I.D.hy-nvo3-gue-4-nvo] Yong, L., Herbert, T., "Generic UDP | [I.D.hy-nvo3-gue-4-nvo] Yong, L., Herbert, T., "Generic UDP | |||
| Encapsulation (GUE) for Network Virtualization Overlay" | Encapsulation (GUE) for Network Virtualization Overlay" | |||
| draft-hy-nvo3-gue-4-nvo-03 | draft-hy-nvo3-gue-4-nvo-03 | |||
| [I.D.previdi-6man-sr-header] Previdi S. et al, "IPv6 Segment Routing | [I.D.previdi-6man-sr-header] Previdi S. et al, "IPv6 Segment Routing | |||
| Header (SRH) draft-ietf-6man-segment-routing-header-02 | Header (SRH) draft-ietf-6man-segment-routing-header-02 | |||
| [I.D.templin-aerolink] F. Templin, "Transmission of IP Packets over | [I.D.templin-aerolink] F. Templin, "Transmission of IP Packets over | |||
| AERO Links" draft-templin-aerolink-62 | AERO Links" draft-templin-aerolink-62 | |||
| [UDPENCAP] T. Herbert, "UDP Encapsulation in Linux", | [UDPENCAP] T. Herbert, "UDP Encapsulation in Linux", | |||
| http://people.netfilter.org/pablo/netdev0.1/papers/UDP- | http://people.netfilter.org/pablo/netdev0.1/papers/UDP- | |||
| Encapsulation-in-Linux.pdf | Encapsulation-in-Linux.pdf | |||
| [FIPS180-4] Secure Hash Standard (SHS), Nation Institute of Standards | ||||
| and Technology, 8/2015 | ||||
| Authors' Addresses | Authors' Addresses | |||
| Tom Herbert | Tom Herbert | |||
| Quantonium | Quantonium | |||
| 4701 Patrick Henry Dr. | 4701 Patrick Henry Dr. | |||
| Santa Clara, CA | Santa Clara, CA | |||
| USA | USA | |||
| EMail: tom@herbertland.com | EMail: tom@herbertland.com | |||
| Lucy Yong | Lucy Yong | |||
| Huawei USA | Austin, TX | |||
| 5340 Legacy Dr. | ||||
| Plano, TX 75024 | ||||
| USA | USA | |||
| Email: lucy.yong@huawei.com | Email: lucy.yong@huawei.com | |||
| Fred L. Templin | Fred L. Templin | |||
| Boeing Research & Technology | Boeing Research & Technology | |||
| P.O. Box 3707 | P.O. Box 3707 | |||
| Seattle, WA 98124 | Seattle, WA 98124 | |||
| USA | USA | |||
| End of changes. 47 change blocks. | ||||
| 113 lines changed or deleted | 103 lines changed or added | |||
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||