Network Working Group L. Yong Internet-Draft Huawei USA Intended status: Standard Track T. Herbert Google Expires: April 2015 October 27, 2014 Generic UDP Encapsulation (GUE) for Secure Transport draft-hy-gue-4-secure-transport-00 Abstract This document specifies use of generic UDP encapsulation (GUE) [GUE] to provide secure transport over IP networks and Internet, including use of IPSEC with GUE and methods to provide integrity and authentication of the GUE header. 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 April 27, 2015. Copyright Notice Copyright (c) 2014 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 October 2014 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. Generic UDP Encapsulation (GUE) for Secure Transport...........3 4. Encapsulation/Decapsualtion Operation..........................5 5. Security Considerations........................................6 5.1. GUE and IPsec.............................................6 5.2. GUE security field use....................................7 5.2.1. Cookies..............................................7 5.2.2. Secure hash..........................................7 6. IANA Considerations............................................7 7. References.....................................................7 7.1. Normative References......................................7 7.2. Informative References....................................8 8. Authors' Addresses.............................................8 Yong & Herbert [Page 2] Internet-Draft GUE for Secure Transport October 2014 1. Introduction This document specifies use of generic UDP encapsulation (GUE) [GUE] to provide secure transport over IP networks and Internet, including use of IPSEC with GUE and methods to provide integrity and authentication of the GUE header. Secure transport over IP networks is extremely important for many applications in IP networks. Tunnel mechanisms can be used to provide secure transport for some network protocols over IP networks. For example: IPsec [RFC4301], L2TP [RFC3931]. This draft specifies GUE security capability to tunnel a network protocol/application over IP networks. This security capability also offers option feature to GUE applications such as Network virtualization overlay [GUE4NVO] for secured transport. The draft allocates two flag bits from GUE undefined flag bits for Security purpose. Security field usage and key management, etc. is expected to be negotiated out of band between two tunnel end points. 2. Terminology The terms defined in [RFC768] 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. Generic UDP Encapsulation (GUE) for Secure Transport GUE [GUE] defines a generic GUE header that applies any UDP tunnel application. GUE header contains some key fields that a UDP tunnel application needs. These key fields are version, control message indication (c), Header Length (HLen), and Protocol Type (or ctype). It also contains some undefined flags for a UDP tunnel application to specify. Yong & Herbert [Page 3] Internet-Draft GUE for Secure Transport October 2014 This document proposes to allocate two flag bits from GUE undefined flags for GUE to provide secure transport to a tunneled protocol. This secure transport feature can apply to a GUE application when it is necessary. GUE format with Security Flag is shown in figure 1. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x0 |C| Hlen | Proto/Ctype |V|SEC| Undefined Flags |P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Virtual Network ID (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Security Field ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 GUE Format with Security Flag o 'V' Virtualization flag: This flag is designated for network virtualization overlay (NVO). When set, Security field appear after that; when clear, security field appear after GUE header. To tunnel a protocol for secure transport, this flag MUST be clear. NVO may utilize secure transport [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 communicating hosts. Potential uses of the security field are discussed in 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 Yong & Herbert [Page 4] Internet-Draft GUE for Secure Transport October 2014 The usage of the key fields in the GUE header [GUE] for secure transport is described as below: o Type: Set to 0x0 for secure transport. o Control flag: When it set, control message presents and control processing MUST occur after security validation. o Hlen: summary of optional fields (byte)/4 o Protocol: Contain the protocol of the encapsulated payload packet, i.e. next header. The next header begins at the offset provided by Hlen. o CType: N/A o 'P' Private flag. It is the last bit in the GUE header. For usage of private field see [GUE]. UDP header usage for secure transport: 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]. 4. Encapsulation/Decapsualtion Operation GUE secure transport 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). To tunnel a protocol for secure transport, tunnel ingress and egress MUST compliant GUE header process precedence specified in [GUE]. At tunnel egress, the payload processing MUST be done after security validation For a GUE application, secure transport is an option feature. When it is used, the flag MUST be set and the security field is placed in the optional fields. The GUE application MUST specify use of this option. See Section 5 for Security field encoding. Yong & Herbert [Page 5] Internet-Draft GUE for Secure Transport October 2014 5. Security Considerations Encapsulation of IP protocols within GUE should not increase security risk, nor provide additional security in itself. As suggested in section 3 the source port for of UDP packets in GUE should be randomly seeded to mitigate some possible denial service attacks. GUE is most useful when it is in the outermost header of a packet which allows for flow hash calculation as well as making GUE data (such as virtual network identifier) visible to switches and middleboxes. GUE must be amenable to encapsulating (and being encapsulated) within IPsec. Also, we allow provisions to secure the GUE header itself without external protocol. 5.1. GUE and IPsec GUE may be used to encapsulate IPsec packets. This allows the benefits of deriving a flow hash for the inner, potentially encrypted, packet. In this case the protocol stack may be: +-------------------------------+ | | | UDP/IP header | | | |-------------------------------| | | | GUE Header | | | |-------------------------------| | | | ESP/AH/private security | | | |-------------------------------| | | | Encapsulated packet | | | +-------------------------------+ Note that the security does not cover the GUE header (does not authenticate it for instance). The GUE security field may be used to provide authentication or integrity of the GUE header. Yong & Herbert [Page 6] Internet-Draft GUE for Secure Transport October 2014 5.2. GUE security field use 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. 5.2.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 might have different cookies. 5.2.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 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. 6. IANA Considerations The document does not require any IANA action. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC2119, March 1997. Yong & Herbert [Page 7] Internet-Draft GUE for Secure Transport October 2014 [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 [GUE] Herbert, T., and Yong, L., "Generic UNP Encapsulation", draft- herbert-gue-01, work in progress. 7.2. Informative References [GUE4NVO] Yong, L., and Herbert T., "Generic UNP Encapsulation for NVO", draft-hy-nov3-gue-4-nvo-00, work in progress. 8. Authors' Addresses Lucy Yong Huawei USA 5340 Legacy Dr. Plano, TX 75024 US Email: lucy.yong@huawei.com Tom Herbert Google 1600 Amphitheatre Parkway Mountain View, CA US Email: therbert@google.com Yong & Herbert [Page 8]