--- 1/draft-ietf-intarea-gue-02.txt 2017-05-10 13:13:10.344607280 -0700 +++ 2/draft-ietf-intarea-gue-03.txt 2017-05-10 13:13:10.424609197 -0700 @@ -1,21 +1,21 @@ Internet Area WG T. Herbert Internet-Draft Quantonium Intended status: Standard track L. Yong -Expires October 28, 2017 Huawei USA +Expires November 11, 2017 Huawei USA O. Zia Microsoft - April 26, 2017 + May 10, 2017 Generic UDP Encapsulation - draft-ietf-intarea-gue-02 + draft-ietf-intarea-gue-03 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 October 28, 2017. + This Internet-Draft will expire on November 11, 2017. 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 @@ -110,21 +110,21 @@ 5.9. Congestion control . . . . . . . . . . . . . . . . . . . . 21 5.10. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 22 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 Consideration . . . . . . . . . . . . . . . . . . . . . . 27 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 27 8.1. UDP source port . . . . . . . . . . . . . . . . . . . . . . 27 8.2. GUE version number . . . . . . . . . . . . . . . . . . . . 28 8.3. Control types . . . . . . . . . . . . . . . . . . . . . . . 28 8.4. Flag-fields . . . . . . . . . . . . . . . . . . . . . . . . 28 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 10.1. Normative References . . . . . . . . . . . . . . . . . . . 29 10.2. Informative References . . . . . . . . . . . . . . . . . . 30 Appendix A: NIC processing for GUE . . . . . . . . . . . . . . . . 33 A.1. Receive multi-queue . . . . . . . . . . . . . . . . . . . . 33 @@ -154,22 +154,21 @@ 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 and [GUE4NVO3] defines - an extension for using GUE with network virtualization. + [GUEEXTENS] 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 @@ -313,25 +312,25 @@ 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. o Proto/ctype: When the C-bit is set, this field contains a - control message type for the payload (section 3.2.2). When 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. + 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 flag bits MUST be set to zero on transmission. o Extension Fields: Optional fields whose presence is indicated by corresponding flags. o Private data: Optional private data block (see section 3.4). If the private block is present, it immediately follows that last @@ -400,21 +399,21 @@ 3.3. Flags and extension fields Flags and associated extension fields are the primary mechanism of extensibility in GUE. As mentioned in section 3.1, GUE header flags indicate the presence of optional extension fields in the GUE header. [GUEXTENS] defines a basic set of GUE extensions. 3.3.1. Requirements - There are sixteen flag bits in the GUE header. Some flags indicate + There are sixteen flag bits in the GUE header. Flags may indicate presence of an extension fields. The size of an extension field indicated by a flag MUST be fixed. Flags can be paired together to allow different lengths for an extension field. For example, if two flag bits are paired, a field can possibly be three different lengths-- that is bit value of 00 indicates no field present; 01, 10, and 11 indicate three possible lengths for the field. Regardless of how flag bits are paired, the lengths and offsets of optional fields corresponding to a set of flags MUST be well defined. @@ -436,39 +435,39 @@ 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 of flags. 3.3.2. Example GUE header with extension fields An example GUE header for a data message encapsulating an IPv4 packet - and containing the VNID and Security extension fields (both defined - in [GUEXTENS]) is shown below: + and containing the Group Identifier and Security extension fields + (both defined in [GUEXTENS]) is shown 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 |0| 3 | 94 |1|0 0 1| 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | VNID | + | Group Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Security + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In the above example, the first flag bit is set which indicates that - the VNID extension is present which is a 32 bit field. The second - through fourth bits of the flags are paired flags that indicate the - presence of a security field with seven possible sizes. In this - example 001 indicates a sixty-four bit security field. + the Group Identifier extension is present which is a 32 bit field. + The second through fourth bits of the flags are paired flags that + indicate the presence of a Security field with seven possible sizes. + In this example 001 indicates a sixty-four bit security field. 3.4. Private data An implementation MAY use private data for its own use. The private data immediately follows the last field in the GUE header and is not a fixed length. This data is considered part of the GUE header and MUST be accounted for in header length (Hlen). The length of the private data MUST be a multiple of four and is determined by subtracting the offset of private data in the GUE header from the header length. Specifically: @@ -668,21 +667,21 @@ packets. In this case the encapsulator and decapsulator nodes are the tunnel endpoints. These could be routers that provide network tunnels on behalf of communicating hosts. 5.2. Transport layer encapsulation When encapsulating layer 4 packets, the encapsulator and decapsulator should be co-resident with the hosts. In this case, the encapsulation headers are inserted between the IP header and the transport packet. The addresses in the IP header refer to both the endpoints of the - encapsulation and the endpoints for terminating the the transport + encapsulation and the endpoints for terminating the transport protocol. Note that the transport layer ports in the encapsulated packet are independent of the UDP ports in the outer packet. Details about performing transport layer encapsulation are discussed in [TOU]. 5.3. Encapsulator operation Encapsulators create GUE data messages, set the fields of the UDP header, set flags and optional extension fields in the GUE header, @@ -714,26 +713,26 @@ 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. 5.4.1. Processing a received data message - If a valid data message is received, the UDP headers are removed from - the packet. The outer IP header remains intact and the next protocol - in the IP header is set to the protocol from the proto field in the - GUE header. The resulting packet is then resubmitted into the - protocol stack to process that packet as though it was received with - the protocol in the GUE header. + If a valid data message is received, the UDP header and GUE header + are removed from the packet. The outer IP header remains intact and + the next protocol in the IP header is set to the protocol from the + proto field in the GUE header. The resulting packet is then + resubmitted into the protocol stack to process that packet as though + it was received with the protocol in the GUE header. As an example, consider that a data message is received where GUE encapsulates an IP packet. In this case proto field in the GUE header is set 94 for IPIP: +-------------------------------------+ | IP header (next proto = 17,UDP) | |-------------------------------------| | UDP | |-------------------------------------| @@ -862,22 +861,22 @@ described in [GUEEXTENS] 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 sending over paths subject to packet corruption. If verification - of a non-zero checksum fails, a decapsulator lacks the capability to + be traversing paths subject to packet corruption. If verification of + a non-zero checksum fails, a decapsulator lacks the capability to verify a non-zero checksum, or a packet with a zero-checksum was 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 @@ -1105,23 +1104,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 [7510], 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], 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. @@ -1146,21 +1146,21 @@ 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. - For comparison, the number of TCAM entries needed to parse a set + 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 @@ -1171,21 +1171,21 @@ 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. -8. IANA Consideration +8. IANA Considerations 8.1. UDP source port A user UDP port number assignment for GUE has been assigned: Service Name: gue Transport Protocol(s): UDP Assignee: Tom Herbert Contact: Tom Herbert Description: Generic UDP Encapsulation @@ -1234,21 +1234,22 @@ 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]. +-------------+--------------+-------------+--------------------+ | Flags bits | Field size | Description | Reference | +-------------+--------------+-------------+--------------------+ - | Bit 0 | 4 bytes | VNID | [GUE4NVO3] | + | Bit 0 | 4 bytes | Group | [GUEEXTENS] | + | | | identifier | | | | | | | | Bit 1..3 | 001->8 bytes | Security | [GUEEXTENS] | | | 010->16 bytes| | | | | 011->32 bytes| | | | | | | | | Bit 4 | 8 bytes | Fragmen- | [GUEEXTENS] | | | | tation | | | | | | | | Bit 5 | 4 bytes | Payload | [GUEEXTENS] | | | | transform | |