--- 1/draft-ietf-intarea-gue-04.txt 2017-12-30 11:13:16.519133690 -0800 +++ 2/draft-ietf-intarea-gue-05.txt 2017-12-30 11:13:16.599135575 -0800 @@ -1,21 +1,21 @@ Internet Area WG T. Herbert Internet-Draft Quantonium Intended status: Standard track L. Yong -Expires November 19, 2017 Huawei USA +Expires June 30, 2017 Huawei USA O. Zia Microsoft - May 18, 2017 + December 30, 2017 Generic UDP Encapsulation - draft-ietf-intarea-gue-04 + draft-ietf-intarea-gue-05 Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. @@ -24,21 +24,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html - This Internet-Draft will expire on November 11, 2017. + This Internet-Draft will expire on June 30, 2018. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -67,37 +67,37 @@ constructed. GUE is extensible by allowing optional data fields as part of the encapsulation, and is generic in that it can encapsulate packets of various IP protocols. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Terminology and acronyms . . . . . . . . . . . . . . . . . 5 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 6 2. Base packet format . . . . . . . . . . . . . . . . . . . . . . 7 - 2.1. GUE version . . . . . . . . . . . . . . . . . . . . . . . . 7 - 3. Version 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 2.1. GUE variant . . . . . . . . . . . . . . . . . . . . . . . . 7 + 3. Variant 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Header format . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Proto/ctype field . . . . . . . . . . . . . . . . . . . . . 9 3.2.1 Proto field . . . . . . . . . . . . . . . . . . . . . . 9 3.2.2 Ctype field . . . . . . . . . . . . . . . . . . . . . . 10 3.3. Flags and extension fields . . . . . . . . . . . . . . . . 10 3.3.1. Requirements . . . . . . . . . . . . . . . . . . . . . 10 3.3.2. Example GUE header with extension fields . . . . . . . 11 3.4. Private data . . . . . . . . . . . . . . . . . . . . . . . 12 3.5. Message types . . . . . . . . . . . . . . . . . . . . . . . 12 3.5.1. Control messages . . . . . . . . . . . . . . . . . . . 12 3.5.2. Data messages . . . . . . . . . . . . . . . . . . . . . 13 3.6. Hiding the transport layer protocol number . . . . . . . . 13 - 4. Version 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 4. Variant 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.1. Direct encapsulation of IPv4 . . . . . . . . . . . . . . . 14 - 4.2. Direct encapsulation of IPv6 . . . . . . . . . . . . . . . 14 + 4.2. Direct encapsulation of IPv6 . . . . . . . . . . . . . . . 15 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.1. Network tunnel encapsulation . . . . . . . . . . . . . . . 16 5.2. Transport layer encapsulation . . . . . . . . . . . . . . . 16 5.3. Encapsulator operation . . . . . . . . . . . . . . . . . . 16 5.4. Decapsulator operation . . . . . . . . . . . . . . . . . . 17 5.4.1. Processing a received data message . . . . . . . . . . 17 5.4.2. Processing a received control message . . . . . . . . . 18 5.5. Router and switch operation . . . . . . . . . . . . . . . . 18 5.6. Middlebox interactions . . . . . . . . . . . . . . . . . . 18 5.6.1. Inferring connection semantics . . . . . . . . . . . . 19 @@ -112,27 +112,27 @@ 5.11. Flow entropy for ECMP . . . . . . . . . . . . . . . . . . 22 5.11.1. Flow classification . . . . . . . . . . . . . . . . . 22 5.11.2. Flow entropy properties . . . . . . . . . . . . . . . 23 5.12 Negotiation of acceptable flags and extension fields . . . 24 6. Motivation for GUE . . . . . . . . . . . . . . . . . . . . . . 24 6.1. Benefits of GUE . . . . . . . . . . . . . . . . . . . . . . 24 6.2 Comparison of GUE to other encapsulations . . . . . . . . . 25 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 26 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 27 8.1. UDP source port . . . . . . . . . . . . . . . . . . . . . . 27 - 8.2. GUE version number . . . . . . . . . . . . . . . . . . . . 28 + 8.2. GUE variant number . . . . . . . . . . . . . . . . . . . . 28 8.3. Control types . . . . . . . . . . . . . . . . . . . . . . . 28 8.4. Flag-fields . . . . . . . . . . . . . . . . . . . . . . . . 28 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 10.1. Normative References . . . . . . . . . . . . . . . . . . . 29 - 10.2. Informative References . . . . . . . . . . . . . . . . . . 29 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 30 Appendix A: NIC processing for GUE . . . . . . . . . . . . . . . . 32 A.1. Receive multi-queue . . . . . . . . . . . . . . . . . . . . 32 A.2. Checksum offload . . . . . . . . . . . . . . . . . . . . . 33 A.2.1. Transmit checksum offload . . . . . . . . . . . . . . . 33 A.2.2. Receive checksum offload . . . . . . . . . . . . . . . 34 A.3. Transmit Segmentation Offload . . . . . . . . . . . . . . . 34 A.4. Large Receive Offload . . . . . . . . . . . . . . . . . . . 35 Appendix B: Implementation considerations . . . . . . . . . . . . 36 B.1. Priveleged ports . . . . . . . . . . . . . . . . . . . . . 36 B.2. Setting flow entropy as a route selector . . . . . . . . . 36 @@ -153,37 +153,40 @@ GUE provides an extensible header format for including optional data in the encapsulation header. This data potentially covers items such as the virtual networking identifier, security data for validating or authenticating the GUE header, congestion control data, etc. GUE also allows private optional data in the encapsulation header. This feature can be used by a site or implementation to define local custom optional data, and allows experimentation of options that may eventually become standard. - This document does not define any specific GUE extensions. - [GUEEXTENS] specifies a set of core extensions. + This document does not define any specific GUE extensions. [GUEEXTEN] + specifies a set of core extensions. The motivation for the GUE protocol is described in section 6. 1.1. Terminology and acronyms GUE Generic UDP Encapsulation GUE Header A variable length protocol header that is composed of a primary four byte header and zero or more four byte words for optional header data GUE packet A UDP/IP packet that contains a GUE header and GUE payload within the UDP payload - Encapsulator A network node that encapsulates a packet in GUE + GUE variant A version of the GUE protocol or an alternate form + of a version + + Encapsulator A network node that encapsulates packets in GUE Decapsulator A network node that decapsulates and processes packets encapsulated in GUE Data message An encapsulated packet in the GUE payload that is addressed to the protocol stack for an associated protocol Control message A formatted message in the GUE payload that is implicitly addressed to the decapsulator to monitor @@ -244,35 +247,37 @@ |-------------------------------| | | | Encapsulated packet | | or control message | | | +-------------------------------+ The GUE header is variable length as determined by the presence of optional extension fields. -2.1. GUE version +2.1. GUE variant - The first two bits of the GUE header contain the GUE protocol version - number. The rest of the fields after the GUE version number are - defined based on the version number. Versions 0 and 1 are described - in this specification; versions 2 and 3 are reserved. + The first two bits of the GUE header contain the GUE protocol variant + number. The variant number can indicate the version of the GUE + protocol as well as alternate forms of a version. -3. Version 0 + Variants 0 and 1 are described in this specification; variants 2 and + 3 are reserved. - Version 0 of GUE defines a generic extensible format to encapsulate - packets by Internet protocol number. +3. Variant 0 + + Variant 0 indicates version 0 of GUE. This variant defines a generic + extensible format to encapsulate packets by Internet protocol number. 3.1. Header format - The header format for version 0 of GUE in UDP is: + The header format for variant 0 of GUE in UDP is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ | Source port | Destination port | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP | Length | Checksum | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ | 0 |C| Hlen | Proto/ctype | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -300,30 +305,30 @@ set to the GUE assigned port number, 6080. o Length: Canonical length of the UDP packet (length of UDP header and payload). o Checksum: Standard UDP checksum (handling is described in section 5.7). The GUE header consists of: - o Ver: GUE protocol version (0). + o Variant: 0 indicates GUE protocol version 0 with a header. o C: C-bit: When set indicates a control message, not set indicates a data message. o Hlen: Length in 32-bit words of the GUE header, including optional extension fields but not the first four bytes of the - header. Computed as (header_len - 4) / 4 where header_len is the - total header length in bytes. All GUE headers are a multiple of - four bytes in length. Maximum header length is 128 bytes. + header. Computed as (header_len - 4) / 4, where header_len is + the total header length in bytes. All GUE headers are a multiple + of four bytes in length. Maximum header length is 128 bytes. o Proto/ctype: When the C-bit is set, this field contains a control message type for the payload (section 3.2.2). When the C-bit is not set, the field holds the Internet protocol number for the encapsulated packet in the payload (section 3.2.1). The control message or encapsulated packet begins at the offset provided by Hlen. o Flags: Header flags that may be allocated for various purposes and may indicate presence of extension fields. Undefined header @@ -419,21 +424,21 @@ flags MUST be well defined. Extension fields are placed in order of the flags. New flags are to be allocated from high to low order bit contiguously without holes. Flags allow random access, for instance to inspect the field corresponding to the Nth flag bit, an implementation only considers the previous N-1 flags to determine the offset. Flags after the Nth flag are not pertinent in calculating the offset of the Nth flag. Random access of flags and fields permits processing of optional extensions in an order that is independent of their position in the - packet. The processing order of extensions defined in [GUEEXTENS] + packet. The processing order of extensions defined in [GUEEXTEN] demonstrates this property. Flags (or paired flags) are idempotent such that new flags MUST NOT cause reinterpretation of old flags. Also, new flags MUST NOT alter interpretation of other elements in the GUE header nor how the message is parsed (for instance, in a data message the proto/ctype field always holds an IP protocol number as an invariant). The set of available flags can be extended in the future by defining a "flag extensions bit" that refers to a field containing a new set @@ -529,55 +534,55 @@ The payload of a data message is interpreted as an encapsulated packet of an Internet protocol indicated in the proto/ctype field. The packet immediately follows the GUE header. 3.6. Hiding the transport layer protocol number The GUE header indicates the Internet protocol of the encapsulated packet. A protocol number is either contained in the Proto/ctype field of the primary GUE header or in the Payload Type field of a GUE Transform extension field (used to encrypt the payload with DTLS, - [GUEEXTENS]). If the transport protocol number needs to be hidden - from the network, then a trivial destination options can be used. + [GUEEXTEN]). If the transport protocol number needs to be hidden from + the network, then a trivial destination options can be used. The PadN destination option [RFC2460] can be used to encode the transport protocol as a next header of an extension header (and maintain alignment of encapsulated transport headers). The Proto/ctype field or Payload Type field of the GUE Transform field is set to 60 to indicate that the first encapsulated header is a destination options extension header. The format of the extension header is below: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | 2 | 1 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For IPv4, it is permitted in GUE to used this precise destination option to contain the obfuscated protocol number. In this case next header MUST refer to a valid IP protocol for IPv4. No other extension headers or destination options are permitted with IPv4. -4. Version 1 +4. Variant 1 - Version 1 of GUE allows direct encapsulation of IPv4 and IPv6 in UDP. - In this version there is no GUE header; a UDP packet carries an IP + Variant 1 of GUE allows direct encapsulation of IPv4 and IPv6 in UDP. + In this varinant there is no GUE header; a UDP packet carries an IP packet. The first two bits of the UDP payload for GUE are the GUE - version and coincide with the first two bits of the version number in + variant and coincide with the first two bits of the version number in the IP header. The first two version bits of IPv4 and IPv6 are 01, so - we use GUE version 1 for direct IP encapsulation which makes two bits - of GUE version to also be 01. + we use GUE variant 1 for direct IP encapsulation which makes two bits + of GUE variant to also be 01. - This technique is effectively a means to compress out the GUE header - when encapsulating IPv4 or IPv6 packets and there are no flags or - extension fields present. This method is compatible to use on the - same port number as packets with the GUE header (GUE version 0 + This technique is effectively a means to compress out the version 0 + GUE header when encapsulating IPv4 or IPv6 packets and there are no + flags or extension fields present. This method is compatible to use + on the same port number as packets with the GUE header (GUE variant 0 packets). This technique saves encapsulation overhead on costly links for the common use of IP encapsulation, and also obviates the need to allocate a separate port number for IP-over-UDP encapsulation. 4.1. Direct encapsulation of IPv4 The format for encapsulating IPv4 directly in UDP is: 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 @@ -590,24 +595,26 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Note that 0100 value IP version field express the GUE version as 1 - (bits 01) and IP version as 4 (bits 0100). + Note that the 0100 value in the first four bits of the the UDP + payload expresses the GUE variant as 1 (bits 01) and IP version as 4 + (bits 0100). 4.2. Direct encapsulation of IPv6 + The format for encapsulating IPv6 directly in UDP is demonstrated below: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ | Source port | Destination port | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP | Length | Checksum | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ @@ -625,22 +632,23 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination IPv6 Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Note that 0110 value IP version field expresses the GUE version as 1 - (bits 01) and IP version as 6 (bits 0110). + Note that the 0110 value in the first four bits of the the UDP + payload expresses the GUE variant as 1 (bits 01) and IP version as 6 + (bits 0110). 5. Operation The figure below illustrates the use of GUE encapsulation between two hosts. Host 1 is sending packets to Host 2. An encapsulator performs encapsulation of packets from Host 1. These encapsulated packets traverse the network as UDP packets. At the decapsulator, packets are decapsulated and sent on to Host 2. Packet flow in the reverse direction need not be symmetric; GUE encapsulation is not required in the reverse path. @@ -700,21 +708,21 @@ encapsualated in GUE then diffserv interaction [RFC2983] and ECN propagation for tunnels [RFC6040] SHOULD be followed. 5.4. Decapsulator operation A decapsulator performs decapsulation of GUE packets. A decapsulator is addressed by the outer destination IP address of a GUE packet. The decapsulator validates packets, including fields of the GUE header. - If a decapsulator receives a GUE packet with an unsupported version, + If a decapsulator receives a GUE packet with an unsupported variant, unknown flag, bad header length (too small for included extension fields), unknown control message type, bad protocol number, an unsupported payload type, or an otherwise malformed header, it MUST drop the packet. Such events MAY be logged subject to configuration and rate limiting of logging messages. No error message is returned back to the encapsulator. Note that set flags in a GUE header that are unknown to a decapsulator MUST NOT be ignored. If a GUE packet is received by a decapsulator with unknown flags, the packet MUST be dropped. @@ -750,21 +758,21 @@ | IP header and packet | +-------------------------------------+ This packet is then resubmitted into the protocol stack to be processed as an IPIP packet. 5.4.2. Processing a received control message If a valid control message is received, the packet MUST be processed as a control message. The specific processing to be performed depends - on the ctype in the GUE header. + on the value in the ctype field of the GUE header. 5.5. Router and switch operation Routers and switches SHOULD forward GUE packets as standard UDP/IP packets. The outer five-tuple should contain sufficient information to perform flow classification corresponding to the flow of the inner packet. A router does not normally need to parse a GUE header, and none of the flags or extension fields in the GUE header are expected to affect routing. In cases where the outer five-tuple does not provide sufficient entropy for flow classification, for instance UDP @@ -830,42 +838,42 @@ on devices incapable of computing the UDP checksum for packet. This section discusses the requirements around checksum and alternatives that might be used when an endpoint does not support UDP checksum. 5.7.1. Requirements One of the following requirements MUST be met: o UDP checksums are enabled (for IPv4 or IPv6). - o The GUE header checksum is used (defined in [GUEEXTENS]). + o The GUE header checksum is used (defined in [GUEEXTEN]). o Use zero UDP checksums. This is always permissible with IPv4; in IPv6, they can only be used in accordance with applicable requirements in [RFC8086], [RFC6935], and [RFC6936]. 5.7.2. UDP Checksum with IPv4 For UDP in IPv4, the UDP checksum MUST be processed as specified in [RFC768] and [RFC1122] for both transmit and receive. An encapsulator MAY set the UDP checksum to zero for performance or implementation considerations. The IPv4 header includes a checksum that protects against mis-delivery of the packet due to corruption of IP addresses. The UDP checksum potentially provides protection against corruption of the UDP header, GUE header, and GUE payload. Enabling or disabling the use of checksums is a deployment consideration that should take into account the risk and effects of packet corruption, and whether the packets in the network are already adequately protected by other, possibly stronger mechanisms such as the Ethernet CRC. If an encapsulator sets a zero UDP checksum for IPv4, it SHOULD use the GUE header checksum as - described in [GUEEXTENS] assuming there are no other mechanisms used + described in [GUEEXTEN] assuming there are no other mechanisms used to protect the GUE packet. When a decapsulator receives a packet, the UDP checksum field MUST be processed. If the UDP checksum is non-zero, the decapsulator MUST verify the checksum before accepting the packet. By default, a decapsulator SHOULD accept UDP packets with a zero checksum. A node MAY be configured to disallow zero checksums per [RFC1122]. Configuration of zero checksums can be selective. For instance, zero checksums might be disallowed from certain hosts that are known to be traversing paths subject to packet corruption. If verification of @@ -874,21 +882,21 @@ received and the decapsulator is configured to disallow, the packet MUST be dropped. 5.7.3. UDP Checksum with IPv6 In IPv6, there is no checksum in the IPv6 header that protects against mis-delivery due to address corruption. Therefore, when GUE is used over IPv6, either the UDP checksum or the GUE header checksum SHOULD be used unless there are alternative mechanisms in use that protect against misdelivery. The UDP checksum and GUE - header checksum SHOULD not be used at the same time since that would + header checksum SHOULD NOT be used at the same time since that would be mostly redundant. If neither the UDP checksum or the GUE header checksum is used, then the requirements for using zero IPv6 UDP checksums in [RFC6935] and [RFC6936] MUST be met. When a decapsulator receives a packet, the UDP checksum field MUST be processed. If the UDP checksum is non-zero, the decapsulator MUST verify the checksum before accepting the packet. By default a decapsulator MUST only accept UDP packets with a zero checksum if @@ -904,39 +912,39 @@ (encapsulation of layer 2 or layer 3 packets) SHOULD be followed. Details are described in MTU and Fragmentation Issues with In-the- Network Tunneling [RFC4459]. If a packet is fragmented before encapsulation in GUE, all the related fragments MUST be encapsulated using the same UDP source port. An operator SHOULD set MTU to account for encapsulation overhead and reduce the likelihood of fragmentation. Alternative to IP fragmentation, the GUE fragmentation extension can - be used. GUE fragmentation is described in [GUEEXTENS]. + be used. GUE fragmentation is described in [GUEEXTEN]. 5.9. Congestion control Per requirements of [RFC5405], if the IP traffic encapsulated with GUE implements proper congestion control no additional mechanisms should be required. In the case that the encapsulated traffic does not implement any or sufficient control, or it is not known whether a transmitter will consistently implement proper congestion control, then congestion control at the encapsulation layer MUST be provided per [RFC5405]. Note that this case applies to a significant use case in network virtualization in which guests run third party networking stacks that cannot be implicitly trusted to implement conformant congestion control. Out of band mechanisms such as rate limiting, Managed Circuit - Breaker [CIRCBRK], or traffic isolation MAY be used to provide + Breaker [RFC8084], or traffic isolation MAY be used to provide rudimentary congestion control. For finer-grained congestion control that allows alternate congestion control algorithms, reaction time within an RTT, and interaction with ECN, in-band mechanisms might be warranted. 5.10. Multicast GUE packets can be multicast to decapsulators using a multicast destination address in the encapsulating IP headers. Each receiving host will decapsulate the packet independently following normal @@ -1034,39 +1042,39 @@ packet, SPI from an ESP packet, or other flow related state in the encapsulator that is not necessarily conveyed in the packet. o The assignment function for flow entropy SHOULD be randomly seeded to mitigate denial of service attacks. The seed SHOULD be changed periodically. 5.12 Negotiation of acceptable flags and extension fields An encapsulator and decapsulator need to achieve agreement about GUE - parameters will be used in communications. Parameters include GUE - version, flags and extension fields that can be used, security - algorithms and keys, supported protocols and control messages, etc. - This document proposes different general methods to accomplish this, - however the details of implementing these are considered out of - scope. + parameters that will be used in communications. Parameters include + supported GUE variants, flags and extension fields that can be used, + security algorithms and keys, supported protocols and control + messages, etc. This document proposes different general methods to + accomplish this, however the details of implementing these are + considered out of scope. General methods for this are: o Configuration. The parameters used for a tunnel are configured at each endpoint. o Negotiation. A tunnel negotiation can be performed. This could be accomplished in-band of GUE using control messages or private data. o Via a control plane. Parameters for communicating with a tunnel endpoint can be set in a control plane protocol (such as that - needed for nvo3). + needed for network virtualization). o Via security negotiation. Use of security typically implies a key exchange between endpoints. Other GUE parameters may be conveyed as part of that process. 6. Motivation for GUE This section presents the motivation for GUE with respect to other encapsulation methods. @@ -1104,24 +1112,24 @@ provides layer 2 tunneling of Ethernet frames over IP. GRE [RFC2784], MPLS [RFC4023], and L2TP [RFC2661] provide methods for tunneling layer 2 and layer 3 packets over IP. NVGRE [RFC7637] and VXLAN [RFC7348] are proposals for encapsulation of layer 2 packets for network virtualization. IPIP [RFC2003] and Generic packet tunneling in IPv6 [RFC2473] provide methods for tunneling IP packets over IP. Several proposals exist for encapsulating packets over UDP including ESP over UDP [RFC3948], TCP directly over UDP [TCPUDP], VXLAN [RFC7348], LISP [RFC6830] which encapsulates layer 3 packets, - MPLS/UDP [RFC7510], and Generic UDP Encapsulation for IP Tunneling - (GRE over UDP)[RFC8086]. Generic UDP tunneling [GUT] is a proposal - similar to GUE in that it aims to tunnel packets of IP protocols over - UDP. + MPLS/UDP [RFC7510], GENEVE [GENEVE], and Generic UDP Encapsulation + for IP Tunneling (GRE over UDP)[RFC8086]. Generic UDP tunneling [GUT] + is a proposal similar to GUE in that it aims to tunnel packets of IP + protocols over UDP. GUE has the following discriminating features: o UDP encapsulation leverages specialized network device processing for efficient transport. The semantics for using the UDP source port for flow entropy as input to ECMP are defined in section 5.11. o GUE permits encapsulation of arbitrary IP protocols, which includes layer 2 3, and 4 protocols. @@ -1141,40 +1149,37 @@ to parse the full encapsulation header. o Private data in the encapsulation header allows local customization and experimentation while being compatible with processing in network nodes (routers and middleboxes). o GUE includes both data messages (encapsulation of packets) and control messages (such as OAM). o The flags-field model facilitates efficient implementation of - extensibility in hardware. - - For instance a TCAM can be use to parse a known set of N flags - where the number of entries in the TCAM is 2^N. - - By comparison, the number of TCAM entries needed to parse a set - of N arbitrarily ordered TLVS is approximately e*N!. + extensibility in hardware. For instance, a TCAM can be use to + parse a known set of N flags where the number of entries in the + TCAM is 2^N. By comparison, the number of TCAM entries needed to + parse a set of N arbitrarily ordered TLVS is approximately e*N!. 7. Security Considerations There are two important considerations of security with respect to GUE. o Authentication and integrity of the GUE header. o Authentication, integrity, and confidentiality of the GUE payload. GUE security is provided by extensions for security defined in - [GUEEXTENS]. These extensions include methods to authenticate the GUE + [GUEEXTEN]. These extensions include methods to authenticate the GUE header and encrypt the GUE payload. The GUE header can be authenticated using a security extension for an HMAC. Securing the GUE payload can be accomplished use of the GUE Payload Transform. This extension can be used to perform DTLS in the payload of a GUE packet to encrypt the payload. A hash function for computing flow entropy (section 5.11) SHOULD be randomly seeded to mitigate some possible denial service attacks. @@ -1188,36 +1193,39 @@ Transport Protocol(s): UDP Assignee: Tom Herbert Contact: Tom Herbert Description: Generic UDP Encapsulation Reference: draft-herbert-gue Port Number: 6080 Service Code: N/A Known Unauthorized Uses: N/A Assignment Notes: N/A -8.2. GUE version number +8.2. GUE variant number - IANA is requested to set up a registry for the GUE version number. - The GUE version number is 2 bits containing four possible values. + IANA is requested to set up a registry for the GUE variant number. + The GUE variant number is 2 bits containing four possible values. This document defines version 0 and 1. New values are assigned in accordance with RFC Required policy [RFC5226]. - +----------------+-------------+---------------+ - | Version number | Description | Reference | - +----------------+-------------+---------------+ - | 0 | Version 0 | This document | + +----------------+----------------+---------------+ + | Variant number | Description | Reference | + +----------------+----------------+---------------+ + | 0 | GUE Version 0 | This document | + | | with header | | | | | | - | 1 | Version 1 | This document | + | 1 | GUE Version 0 | This document | + | | with direct IP | | + | | encapsulation | | | | | | | 2..3 | Unassigned | | - +----------------+-------------+---------------+ + +----------------+----------------+---------------+ 8.3. Control types IANA is requested to set up a registry for the GUE control types. Control types are 8 bit values. New values for control types 1-127 are assigned in accordance with RFC Required policy [RFC5226]. +----------------+------------------+---------------+ | Control type | Description | Reference | +----------------+------------------+---------------+ @@ -1231,21 +1239,21 @@ 8.4. Flag-fields IANA is requested to create a "GUE flag-fields" registry to allocate flags and extension fields used with GUE. This shall be a registry of bit assignments for flags, length of extension fields for corresponding flags, and descriptive strings. There are sixteen bits for primary GUE header flags (bit number 0-15). New values are assigned in accordance with RFC Required policy [RFC5226]. New flags should be allocated from high to low order bit contiguously without - holes. [GUEXTENS] requests in initial set of flag assignments. + holes. [GUEXTENS] requests an initial set of flag assignments. 9. Acknowledgements The authors would like to thank David Liu, Erik Nordmark, Fred Templin, Adrian Farrel, Bob Briscoe, and Murray Kucherawy for valuable input on this draft. 10. References 10.1. Normative References @@ -1376,43 +1384,48 @@ [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005, . [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, DOI 10.17487/RFC2661, August 1999, . - [GUEEXTENS] Herbert, T., Yong, L., and Templin, F., "Extensions for + [RFC8084] Fairhurst, G., "Network Transport Circuit Breakers", BCP + 208, RFC 8084, DOI 10.17487/RFC8084, March 2017, + . + + [GUEEXTEN] Herbert, T., Yong, L., and Templin, F., "Extensions for Generic UDP Encapsulation" draft-herbert-gue-extensions-00 - [GUE4NVO3] Yong, L., Herbert, T., Zia, O., "Generic UDP - Encapsulation (GUE) for Network Virtualization Overlay" - draft-hy-nvo3-gue-4-nvo-03 + [GUE4NVO3] Yong, L., Herbert, T., Zia, O., "Generic UDP Encapsulation + (GUE) for Network Virtualization Overlay" draft-hy-nvo3- + gue-4-nvo-03 - [GUESEC] Yong, L., Herbert, T., "Generic UDP Encapsulation (GUE) for - Secure Transport" draft-hy-gue-4-secure-transport-03 + [GUESEC] Yong, L., Herbert, T., "Generic UDP Encapsulation (GUE) + for Secure Transport" draft-hy-gue-4-secure-transport-03 [TCPUDP] Chesire, S., Graessley, J., and McGuire, R., "Encapsulation of TCP and other Transport Protocols over UDP" draft-cheshire-tcp-over-udp-00 [TOU] Herbert, T., "Transport layer protocols over UDP" draft- herbert-transports-over-udp-00 + [GENEVE] Gross, J., Ed., Ganga, I. Ed., and Sridhar, T., "Geneve: + Generic Network Virtualization Encapsulation", draft-ietf- + nvo3-geneve-05 + [GUT] Manner, J., Varia, N., and Briscoe, B., "Generic UDP Tunnelling (GUT) draft-manner-tsvwg-gut-02.txt" - [CIRCBRK] Fairhurst, G., "Network Transport Circuit Breakers", - draft-ietf-tsvwg-circuit-breaker-15 - [LCO] Cree, E., https://www.kernel.org/doc/Documentation/ networking/checksum-offloads.txt Appendix A: NIC processing for GUE This appendix provides some guidelines for Network Interface Cards (NICs) to implement common offloads and accelerations to support GUE. Note that most of this discussion is generally applicable to other methods of UDP based encapsulation. @@ -1466,21 +1479,21 @@ In the case of GUE, the checksum for an encapsulated transport layer packet, a TCP packet for instance, can be offloaded by setting the appropriate checksum parameters. NICs typically can offload only one transmit checksum per packet, so simultaneously offloading both an inner transport packet's checksum and the outer UDP checksum is likely not possible. If an encapsulator is co-resident with a host, then checksum offload may be performed using remote checksum offload (described in - [GUEEXTENS]). Remote checksum offload relies on NIC offload of the + [GUEEXTEN]). Remote checksum offload relies on NIC offload of the simple UDP/IP checksum which is commonly supported even in legacy devices. In remote checksum offload, the outer UDP checksum is set and the GUE header includes an option indicating the start and offset of the inner "offloaded" checksum. The inner checksum is initialized to the pseudo header checksum. When a decapsulator receives a GUE packet with the remote checksum offload option, it completes the offload operation by determining the packet checksum from the indicated start point to the end of the packet, and then adds this into the checksum field at the offset given in the option. Computing the checksum from the start to end of packet is efficient if