idnits 2.17.1 draft-hy-gue-4-secure-transport-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([GUE]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 27, 2014) is 3469 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC768' is mentioned on line 91, but not defined == Outdated reference: A later version (-03) exists of draft-herbert-gue-01 -- Possible downref: Normative reference to a draft: ref. 'GUE' -- No information found for draft-hy-nov3-gue-4-nvo - is the name correct? Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group L. Yong 2 Internet-Draft Huawei USA 3 Intended status: Standard Track T. Herbert 4 Google 6 Expires: April 2015 October 27, 2014 8 Generic UDP Encapsulation (GUE) for Secure Transport 9 draft-hy-gue-4-secure-transport-00 11 Abstract 13 This document specifies use of generic UDP encapsulation (GUE) [GUE] 14 to provide secure transport over IP networks and Internet, including 15 use of IPSEC with GUE and methods to provide integrity and 16 authentication of the GUE header. 18 Status of This Document 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other documents 30 at any time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 27, 2015. 35 Copyright Notice 37 Copyright (c) 2014 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with 45 respect to this document. Code Components extracted from this 46 document must include Simplified BSD License text as described in 47 Section 4.e of the Trust Legal Provisions and are provided without 48 warranty as described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction...................................................3 53 2. Terminology....................................................3 54 2.1. Requirements Language.....................................3 55 3. Generic UDP Encapsulation (GUE) for Secure Transport...........3 56 4. Encapsulation/Decapsualtion Operation..........................5 57 5. Security Considerations........................................6 58 5.1. GUE and IPsec.............................................6 59 5.2. GUE security field use....................................7 60 5.2.1. Cookies..............................................7 61 5.2.2. Secure hash..........................................7 62 6. IANA Considerations............................................7 63 7. References.....................................................7 64 7.1. Normative References......................................7 65 7.2. Informative References....................................8 66 8. Authors' Addresses.............................................8 68 1. Introduction 70 This document specifies use of generic UDP encapsulation (GUE) [GUE] 71 to provide secure transport over IP networks and Internet, including 72 use of IPSEC with GUE and methods to provide integrity and 73 authentication of the GUE header. 75 Secure transport over IP networks is extremely important for many 76 applications in IP networks. Tunnel mechanisms can be used to 77 provide secure transport for some network protocols over IP 78 networks. For example: IPsec [RFC4301], L2TP [RFC3931]. 80 This draft specifies GUE security capability to tunnel a network 81 protocol/application over IP networks. This security capability also 82 offers option feature to GUE applications such as Network 83 virtualization overlay [GUE4NVO] for secured transport. 85 The draft allocates two flag bits from GUE undefined flag bits for 86 Security purpose. Security field usage and key management, etc. is 87 expected to be negotiated out of band between two tunnel end points. 89 2. Terminology 91 The terms defined in [RFC768] are used in this document. 93 2.1. Requirements Language 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119]. 99 3. Generic UDP Encapsulation (GUE) for Secure Transport 101 GUE [GUE] defines a generic GUE header that applies any UDP tunnel 102 application. GUE header contains some key fields that a UDP tunnel 103 application needs. These key fields are version, control message 104 indication (c), Header Length (HLen), and Protocol Type (or ctype). 105 It also contains some undefined flags for a UDP tunnel application 106 to specify. 108 This document proposes to allocate two flag bits from GUE undefined 109 flags for GUE to provide secure transport to a tunneled protocol. 110 This secure transport feature can apply to a GUE application when it 111 is necessary. GUE format with Security Flag is shown in figure 1. 113 0 1 2 3 114 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 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | Source port | Destination port | 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | Length | Checksum | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | 0x0 |C| Hlen | Proto/Ctype |V|SEC| Undefined Flags |P| 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | Virtual Network ID (Optional) | 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | | 125 ~ Security Field ~ 126 | | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 Figure 1 GUE Format with Security Flag 131 o 'V' Virtualization flag: This flag is designated for network 132 virtualization overlay (NVO). When set, Security field appear 133 after that; when clear, security field appear after GUE header. 134 To tunnel a protocol for secure transport, this flag MUST be 135 clear. NVO may utilize secure transport [GUE4NVO]. 137 o 'SEC' Security flags: Indicates presence of security field. To 138 provide security capability, the flags MUST be set. Different 139 sizes are allowed to allow different methods and extensibility. 140 The use of the security field is expected to be negotiated out of 141 band between two communicating hosts. Potential uses of the 142 security field are discussed in Security Considerations. 144 o 00 - No security field 146 o 01 - 64 bit security field 148 o 10 - 128 bit security field 150 o 11 - 256 bit security field 152 The usage of the key fields in the GUE header [GUE] for secure 153 transport is described as below: 155 o Type: Set to 0x0 for secure transport. 157 o Control flag: When it set, control message presents and control 158 processing MUST occur after security validation. 160 o Hlen: summary of optional fields (byte)/4 162 o Protocol: Contain the protocol of the encapsulated payload packet, 163 i.e. next header. The next header begins at the offset provided 164 by Hlen. 166 o CType: N/A 168 o 'P' Private flag. It is the last bit in the GUE header. For usage 169 of private field see [GUE]. 171 UDP header usage for secure transport: UDP dst port SHOULD be filled 172 with GUE port [GUE]; UDP src port MAY be filled with entropy or a 173 random value. The checksum and length implementation MUST be 174 compliant with GUE implementation [GUE]. 176 4. Encapsulation/Decapsualtion Operation 178 GUE secure transport applies to both IPv4 and IPv6 underlay networks. 179 The outer IP address MUST be tunnel egress IP address (dst) and 180 tunnel ingress IP address (src). To tunnel a protocol for secure 181 transport, tunnel ingress and egress MUST compliant GUE header 182 process precedence specified in [GUE]. At tunnel egress, the payload 183 processing MUST be done after security validation 185 For a GUE application, secure transport is an option feature. When 186 it is used, the flag MUST be set and the security field is placed in 187 the optional fields. The GUE application MUST specify use of this 188 option. 190 See Section 5 for Security field encoding. 192 5. Security Considerations 194 Encapsulation of IP protocols within GUE should not increase 195 security risk, nor provide additional security in itself. As 196 suggested in section 3 the source port for of UDP packets in GUE 197 should be randomly seeded to mitigate some possible denial service 198 attacks. 200 GUE is most useful when it is in the outermost header of a packet 201 which allows for flow hash calculation as well as making GUE data 202 (such as virtual network identifier) visible to switches and 203 middleboxes. GUE must be amenable to encapsulating (and being 204 encapsulated) within IPsec. Also, we allow provisions to secure the 205 GUE header itself without external protocol. 207 5.1. GUE and IPsec 209 GUE may be used to encapsulate IPsec packets. This allows the 210 benefits of deriving a flow hash for the inner, potentially 211 encrypted, packet. In this case the protocol stack may be: 213 +-------------------------------+ 214 | | 215 | UDP/IP header | 216 | | 217 |-------------------------------| 218 | | 219 | GUE Header | 220 | | 221 |-------------------------------| 222 | | 223 | ESP/AH/private security | 224 | | 225 |-------------------------------| 226 | | 227 | Encapsulated packet | 228 | | 229 +-------------------------------+ 231 Note that the security does not cover the GUE header (does not 232 authenticate it for instance). The GUE security field may be used to 233 provide authentication or integrity of the GUE header. 235 5.2. GUE security field use 237 The GUE security field should be used to provide integrity and 238 authentication of the GUE header. Security negotiation 239 (interpretation of security field, key management, etc.) is expected 240 to be negotiated out of band between two communicating hosts. Two 241 possible uses for this field are outlined below, a more precise 242 specification is deferred to other documents. 244 5.2.1. Cookies 246 The security field may be used as a cookie. This would be similar to 247 cookie mechanism described in L2TP [RFC3931], and the general 248 properties should be the same. The cookie may be used to validate 249 the encapsulation. The cookie is a shared value between an 250 encapsulator and decapsulator which should be chosen randomly and 251 may be changed periodically. Different cookies may used for logical 252 flows between the encapsulator and decapsulator, for instance 253 packets sent with different VNIs in network virtualization might 254 have different cookies. 256 5.2.2. Secure hash 258 Strong authentication of the GUE header can be provided using a 259 secure hash. This may follow the model of the TCP authentication 260 option [RFC5925]. In this case the security field holds a message 261 digest for the GUE header (e.g. 16 bytes from MD5). The digest might 262 be done over static fields in IP and UDP headers per negotiation 263 (addresses, ports, and protocols). In order to provide enough 264 entropy, a random salt value in each packet might be added, for 265 instance the security field could be a 256 bit value which contains 266 128 bits of salt value, and a 128 bit digest value. The use of 267 secure hashes requires shared keys which are presumably negotiated 268 and rotated as needed out of band. 270 6. IANA Considerations 272 The document does not require any IANA action. 274 7. References 276 7.1. Normative References 278 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 279 Requirement Levels", BCP 14, RFC2119, March 1997. 281 [RFC3931] Lau, J., Townsley, W., et al, "Layer Tow Tunneling 282 Protocol - Version 3 (L2TPv3)", RFC3931, 1999 284 [RFC4301] Kent, S., Seo, K., "Security Architecture for the Internet 285 Protocol", RFC4301, December 2005 287 [RFC5925] Touch, J., et al, " The TCP Authentication Option", 288 RFC5925, June 2010 290 [GUE] Herbert, T., and Yong, L., "Generic UNP Encapsulation", draft- 291 herbert-gue-01, work in progress. 293 7.2. Informative References 295 [GUE4NVO] Yong, L., and Herbert T., "Generic UNP Encapsulation for 296 NVO", draft-hy-nov3-gue-4-nvo-00, work in progress. 298 8. Authors' Addresses 300 Lucy Yong 301 Huawei USA 302 5340 Legacy Dr. 303 Plano, TX 75024 304 US 306 Email: lucy.yong@huawei.com 308 Tom Herbert 309 Google 310 1600 Amphitheatre Parkway 311 Mountain View, CA 312 US 314 Email: therbert@google.com