Network Working Group L. Yong Internet-Draft Huawei USA Intended status: Standard Track T. Herbert Facebook Expires: September 2016 March 14, 2016 Generic UDP Encapsulation (GUE) for Secure Transport draft-hy-gue-4-secure-transport-03 Abstract This document specifies the ability of Generic UDP Encapsulation (GUE) to provide secure transport over IP networks and the Internet, including GUE header integrity protection and origin authentication and GUE payload encryption. These are optional features of GUE. Status of This Document 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). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months 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." This Internet-Draft will expire on September 14, 2016. Copyright Notice Copyright (c) 2016 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Yong & Herbert [Page 1]
Internet-Draft GUE for Secure Transport March 2016 Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction...................................................3 2. Terminology....................................................3 2.1. Requirements Language.....................................3 3. GUE Security...................................................3 4. GUE Payload Encryption.........................................5 5. Encapsulation/Decapsulation Operations.........................7 6. Considerations of Using Other Security Tunnel Mechanisms.......8 7. Security Considerations........................................9 7.1. GUE Security Field Usage..................................9 7.1.1. Cookies..............................................9 7.1.2. Secure hash..........................................9 8. IANA Considerations...........................................10 9. References....................................................10 9.1. Normative References.....................................10 9.2. Informative References...................................11 10. Authors' Addresses...........................................11 Yong & Herbert [Page 2]
Internet-Draft GUE for Secure Transport March 2016 1. Introduction Generic UDP Encapsulation [GUE] is the protocol that specifies tunneling a network protocol over an IP network or Internet and a UDP tunnel. The tunneled network protocol is encapsulated in GUE header [GUE] at a tunnel encapsulator, transported as a regular IP packet, and decapsulated at the tunnel decapsulator. This draft specifies the security capabilities for GUE. One security capability is to provide origin authentication and integrity protection of the GUE header at tunnel end points to guarantee isolation between tunnels and mitigate Denial of Service attacks. Another capability is payload encryption that prevents the payload from eavesdropping, tampering, or message forgery. These security capabilities are specified as optional features of GUE. In theory, uses of GUE could leverage other existing tunnel mechanisms that provides secure transport over Internet such as DTLS [RFC6347] and IPsec[RFC4301]. Section 6 discusses the weakness to rely on another tunnel mechanism for GUE secure transport. 2. Terminology The terms defined in GUE [GUE] are used in this document. 2.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. GUE Security This document proposes to allocate two flag bits from GUE optional flag field as the Security flag for GUE integrity protection and authentication validation. GUE header format with Security Flag is shown in Figure 1. The second and third bits in GUE optional flag field are allocated for Security mechanism. Yong & Herbert [Page 3]
Internet-Draft GUE for Secure Transport March 2016 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ver|C| Hlen | Proto/Ctype |V|SEC| Undefined Flags |E| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Virtual Network ID (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Security Field ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 GUE Header Format with Security Flag o 'V' Virtualization flag: This flag is designated for network virtualization overlay (NVO)[GUE4NVO]. o 'SEC' Security flags: Indicates presence of security field. To provide security capability, the flags MUST be set. Different sizes are allowed to allow different methods and extensibility. The use of the security field is expected to be negotiated out of band between two tunnel end points. Potential uses of the security field are discussed in Section of Security Considerations. o 00 - No security field o 01 - 64 bit security field o 10 - 128 bit security field o 11 - 256 bit security field The usage of the key fields in the GUE header [GUE] for the security mechanism is described as below: o Ver: Set to 0x0. Security option is designed for GUE version 0. o 'C' Control flag: When it set, control message presents and control processing MUST occur after security validation. o Hlen: length of optional fields (byte)/4. Note that Payload Transform function does not require a private field. Yong & Herbert [Page 4]
Internet-Draft GUE for Secure Transport March 2016 o Proto/ctype: Contain the protocol of the encapsulated payload packet, i.e. next header when the C bit is not set. Contains a control message type when the C bit is set. The next header begins at the offset provided by Hlen. 'E' Extension flag. It is the last bit in the GUE header. For usage of Extension field see [GUE]. The security transport does not require use of any extension field. UDP header field must be set per [GUE]. The checksum and length implementation MUST be compliant with GUE implementation [GUE]. 4. GUE Payload Encryption The payload of a GUE packet can be secured using Datagram Transport Layer Security [RFC6347]. An encapsulator would apply DTLS to the GUE payload so that the payload packets are encrypted and the GUE header remains in plaintext. To differ encrypted payload from plaintext payload, the document proposes allocating one flag from GUE optional flag field for payload transformation indication and adding a 32 bit field when Payload Transform flag is set. Following format shows GUE header with Payload Transform flag, i.e. 'T' is set. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ver|C| Hlen | Proto/Ctype |V|SEC|K|F|S|T| Flags |E| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | VNID, security, GUE checksum, fragmentation, ~ ~ Session (optional) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Transform Field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 GUE Header with Payload Transform Flag A 32 bits field in GUE header is for the payload transform function and MUST be presented when Payload Transform flag T is set and MUST Yong & Herbert [Page 5]
Internet-Draft GUE for Secure Transport March 2016 NOT be presented when clear. The format of Payload Transform Field is in Figure 3. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Payload Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 Payload Transform Field Format Type: Payload Transform Type or Code point. Each payload transform mechanism must have one code point registered in IANA. This document specifies: 0x01: for DTLS [RFC6347] 0x80~0xFF: for private payload transform types A private payload transform type can be used for experimental purpose or vendor proprietary mechanism. Payload Type: used to indicate the encrypted payload type. When encryption flag is set, next protocol in the base header should set to 59 ("No next header") for a data message and zero for a control message. The payload type (IP protocol or control message type) of the unencrypted paytload must be encoded in this field. The benefit of this rule is to prevent a middle box from inspecting the encrypted payload according to GUE next protocol. Assumption here is that a middle box may understand GUE base header but does not understand GUE option flag definitions. Reserved field for DTLS type MUST set to Zero. For other transformation type, the reserved field may be specified for a purpose. The usage of the key fields in the GUE header [GUE] for the payload encryption mechanism is described as below: o Ver: Set to 0x0. Payload transform option applies to version 0x0. o Control flag: When it set, control message presents SHOULD be encrypted except GUE base header. o Hlen: length of optional fields (byte)/4 o Proto/CType: Set to 59. The payload type is encoded in the payload encryption option field. Yong & Herbert [Page 6]
Internet-Draft GUE for Secure Transport March 2016 o 'E' Extension flag. It is the last bit in the GUE header. For usage of Extension field see [GUE]. The payload encryption does not require use of any extension field. UDP header usage for payload encryption mechanism: UDP dst port SHOULD be filled with GUE port [GUE]; UDP src port MAY be filled with entropy or a random value. The checksum and length implementation MUST be compliant with GUE implementation [GUE]. 5. Encapsulation/Decapsulation Operations GUE secure transport mechanism applies to both IPv4 and IPv6 underlay networks. The outer IP address MUST be tunnel egress IP address (dst) and tunnel ingress IP address (src). GUE security option provides origin authentication and integrity to GUE based tunnel; GUE payload encryption provides payload privacy over an IP delivery network or Internet. Two functions are processed separately at tunnel end points. A GUE tunnel can use both functions or use one of them. When both encryption and security are required, an encapsulator must perform payload encryption first and then encapsulate the encrypted packet with security flag and encryption flag set in GUE header; the security field must be filled according Section 3 above; the encryption field must be filled according to Section 4 above; the decapsulator must decapsulate the packet first, then perform the authentication validation; if the validation is successful, it performs the payload decryption according the encryption information in the payload encryption field in the header; if the validation fails, the decapsulator must discard the packet and may generate an alert to the management system. These processing rules also apply when only one function, either encryption or security, is enabled, except another function is not performed as stated above. If GUE fragmentation is used in concert with the GUE security option and/or payload transform option, the security and playload transformation are performed after fragmentation at the encapsulator and before reassembly at the decapsulator. In order to get flow entropy from the payload, the encapsulator needs to get the flow entropy first before performing the payload encryption; then the flow entropy is inserted into UDP src port in the GUE header. DTLS [RFC6347] provides packet fragmentation capability. To avoid packet fragmentation performed multiple times at GUE encapsulator, GUE encapsulator SHOULD only perform the packet fragmentation at Yong & Herbert [Page 7]
Internet-Draft GUE for Secure Transport March 2016 packet encapsulation process, i.e., not in payload encryption process. The encryption process should apply to GUE control packets. DTLS usage [RFC6347] is limited to a single DTLS session for any specific tunnel encapsulator/decapsulator pair (identified by source and destination IP addresses). Both IP addresses MUST be unicast addresses - multicast traffic is not supported when DTLS is used. A GUE tunnel decapsulator implementation that supports DTLS can establish DTLS session(s) with one or multiple tunnel encapsulators, and likewise a GUE tunnel encapsulator implementation can establish DTLS session(s) with one or multiple decapsulators. 6. Considerations of Using Other Security Tunnel Mechanisms GUE may rely on other secure tunnel mechanisms such as DTLS [RFC6347] for securing the whole GUE packet or IPsec [RFC4301] to achieve the secure transport over an IP network or Internet. IPsec [RFC4301] was designed as a network security mechanism, and therefore it resides at the network layer. As such, if the tunnel is secured with IPsec, the UDP header would not be visible to intermediate routers anymore in either IPsec tunnel or transport mode. The big drawback here prohibits intermediate routers to perform load balance based on the flow entropy in UDP header. In addition, this method prohibits any middle box function on the path. By comparison, DTLS [RFC6347] was designed with application security and can better preserve network and transport layer protocol information than IPsec [RFC4301]. Using DTLS to secure the GUE tunnel, both GUE header and payload will be encrypted. In order to differentiate plaintext GUE header from encrypted GUE header, the destination port of the UDP header between two must be different, which essentially requires another standard UDP port for GUE with DTLS. The drawback on this method is to prevent a middle box operation to GUE tunnel on the path. Use of two independent tunnel mechanisms such as GUE and DTLS to carry a network protocol over an IP network adds some overlap and process complex. For example, fragmentation will be done twice. As the result, a GUE tunnel SHOULD use the security mechanisms specified in this document to provide secure transport over an IP network or Internet when it is needed. GUE tunnel can be used as secure transport mechanism over an IP network and Internet. Yong & Herbert [Page 8]
Internet-Draft GUE for Secure Transport March 2016 7. Security Considerations Encapsulation of network protocol in GUE should not increase security risk, nor provide additional security in itself. GUE requires that the source port for UDP packets should be randomly seeded to mitigate some possible denial service attacks. If the integrity and privacy of data packets being transported through GUE is a concern, GUE security and payload encryption SHOULD be used to remove the concern. If the integrity is the only concern, the tunnel may consider use of GUE security only for optimization. Likewise, if the privacy is the only concern, the tunnel may use GUE encryption function only. If GUE payload already provides secure mechanism, e.g., the payload is IPsec packets, it is still valuable to consider use of GUE secure mechanisms for the payload header privacy and the tunnel integrity. 7.1. GUE Security Field Usage The GUE security field should be used to provide integrity and authentication of the GUE header. Security negotiation (interpretation of security field, key management, etc.) is expected to be negotiated out of band between two communicating hosts. Two possible uses for this field are outlined below, a more precise specification is deferred to other documents. 7.1.1. Cookies The security field may be used as a cookie. This would be similar to cookie mechanism described in L2TP [RFC3931], and the general properties should be the same. The cookie may be used to validate the encapsulation. The cookie is a shared value between an encapsulator and decapsulator which should be chosen randomly and may be changed periodically. Different cookies may used for logical flows between the encapsulator and decapsulator, for instance packets sent with different VNIs in network virtualization [GUE4NVO] might have different cookies. 7.1.2. Secure hash Strong authentication of the GUE header can be provided using a secure hash. This may follow the model of the TCP authentication option [RFC5925]. In this case the security field holds a message digest for the GUE header (e.g. 16 bytes from MD5). The digest might be done over static fields in IP and UDP headers per negotiation (addresses, ports, and protocols). In order to provide enough Yong & Herbert [Page 9]
Internet-Draft GUE for Secure Transport March 2016 entropy, a random salt value in each packet might be added, for instance the security field could be a 256 bit value which contains 128 bits of salt value, and a 128 bit digest value. The use of secure hashes requires shared keys which are presumably negotiated and rotated as needed out of band. 8. IANA Considerations This document requires IANA to allocate: Two bits in GUE option flag field for GUE Security. One bit in GUE option flag field for GUE Payload Transform. This document requires IANA to have a new registry for Encryption Type and require two code points for: 0x01: for DTLS [RFC6347] 0x80~0xFF: for private payload transform 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC2119, March 1997. [RFC3931] Lau, J., Townsley, W., et al, "Layer Tow Tunneling Protocol - Version 3 (L2TPv3)", RFC3931, 1999 [RFC4301] Kent, S., Seo, K., "Security Architecture for the Internet Protocol", RFC4301, December 2005 [RFC5925] Touch, J., et al, "The TCP Authentication Option", RFC5925, June 2010 [RFC6347] Rescoria, E., Modadugu, N., "Datagram Transport Layer Security Version 1.2", RFC6347, 2012. [GUE] Herbert, T., Yong, L., et al "Generic UNP Encapsulation", draft-ietf-nvo3-gue-00, work in progress. Yong & Herbert [Page 10]
Internet-Draft GUE for Secure Transport March 2016 9.2. Informative References [GUE4NVO] Yong, L., and Herbert T., "Generic UNP Encapsulation for NVO", draft-hy-nvo3-gue-4-nvo-01, work in progress. 10. Authors' Addresses Lucy Yong Huawei USA Email: lucy.yong@huawei.com Tom Herbert Facebook 1 Hacker Way Menlo Park, CA 94052 US Email: tom@herbertland.com Yong & Herbert [Page 11]