idnits 2.17.1 draft-hy-gue-4-secure-transport-02.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 (May 20, 2015) is 3254 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) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-05) exists of draft-ietf-nvo3-gue-00 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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 Facebook 6 Expires: November 2015 May 20, 2015 8 Generic UDP Encapsulation (GUE) for Secure Transport 9 draft-hy-gue-4-secure-transport-02 11 Abstract 13 This document specifies the ability of Generic UDP Encapsulation 14 (GUE) [GUE] to provide secure transport over IP networks and the 15 Internet, including GUE header integrity protection and origin 16 authentication and GUE payload encryption. These are optional 17 features of GUE. 19 Status of This Document 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other documents 31 at any time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on November 20, 2015. 36 Copyright Notice 38 Copyright (c) 2015 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with 46 respect to this document. Code Components extracted from this 47 document must include Simplified BSD License text as described in 48 Section 4.e of the Trust Legal Provisions and are provided without 49 warranty as described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction...................................................3 54 2. Terminology....................................................3 55 2.1. Requirements Language.....................................3 56 3. GUE Security...................................................3 57 4. GUE Payload Encryption.........................................5 58 5. Encapsulation/Decapsulation Operations.........................7 59 6. Considerations of Using Other Security Tunnel Mechanisms.......8 60 7. Security Considerations........................................9 61 7.1. GUE Security Field Usage..................................9 62 7.1.1. Cookies..............................................9 63 7.1.2. Secure hash..........................................9 64 8. IANA Considerations...........................................10 65 9. References....................................................10 66 9.1. Normative References.....................................10 67 9.2. Informative References...................................11 68 10. Authors' Addresses...........................................11 70 1. Introduction 72 Generic UDP Encapsulation [GUE] is the protocol that specifies 73 tunneling a network protocol over an IP network or Internet and a 74 UDP tunnel. The tunneled network protocol is encapsulated in GUE 75 header [GUE] at a tunnel encapsulator, transported as a regular IP 76 packet, and decapsulated at the tunnel decapsulator. 78 This draft specifies the security capabilities for GUE. One security 79 capability is to provide origin authentication and integrity 80 protection of the GUE header at tunnel end points to guarantee 81 isolation between tunnels and mitigate Denial of Service attacks. 82 Another capability is payload encryption that prevents the payload 83 from eavesdropping, tampering, or message forgery. These security 84 capabilities are specified as optional features of GUE. 86 In theory, uses of GUE could leverage other existing tunnel 87 mechanisms that provides secure transport over Internet such as DTLS 88 [RFC6347] and IPsec[RFC4301]. Section 6 discusses the weakness to 89 rely on another tunnel mechanism for GUE secure transport. 91 2. Terminology 93 The terms defined in GUE [GUE] are used in this document. 95 2.1. Requirements Language 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [RFC2119]. 101 3. GUE Security 103 This document proposes to allocate two flag bits from GUE optional 104 flag field as the Security flag for GUE integrity protection and 105 authentication validation. GUE header format with Security Flag is 106 shown in Figure 1. The second and third bits in GUE optional flag 107 field are allocated for Security mechanism. 109 0 1 2 3 110 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 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | Source port | Destination port | 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 | Length | Checksum | 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 |Ver|C| Hlen | Proto/Ctype |V|SEC| Undefined Flags |E| 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | Virtual Network ID (Optional) | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | | 121 ~ Security Field ~ 122 | | 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 Figure 1 GUE Header Format with Security Flag 127 o 'V' Virtualization flag: This flag is designated for network 128 virtualization overlay (NVO)[GUE4NVO]. 130 o 'SEC' Security flags: Indicates presence of security field. To 131 provide security capability, the flags MUST be set. Different 132 sizes are allowed to allow different methods and extensibility. 133 The use of the security field is expected to be negotiated out of 134 band between two tunnel end points. Potential uses of the 135 security field are discussed in Section of Security 136 Considerations. 138 o 00 - No security field 140 o 01 - 64 bit security field 142 o 10 - 128 bit security field 144 o 11 - 256 bit security field 146 The usage of the key fields in the GUE header [GUE] for the security 147 mechanism is described as below: 149 o Ver: Set to 0x0. Security option is designed for GUE version 0. 151 o 'C' Control flag: When it set, control message presents and 152 control processing MUST occur after security validation. 154 o Hlen: length of optional fields (byte)/4. Note that Payload 155 Transform function does not require a private field. 157 o Proto/ctype: Contain the protocol of the encapsulated payload 158 packet, i.e. next header when the C bit is not set. Contains a 159 control message type when the C bit is set. The next header 160 begins at the offset provided by Hlen. 162 'E' Extension flag. It is the last bit in the GUE header. For usage 163 of Extension field see [GUE]. The security transport does not 164 require use of any extension field. 166 UDP header field must be set per [GUE]. The checksum and length 167 implementation MUST be compliant with GUE implementation [GUE]. 169 4. GUE Payload Encryption 171 The payload of a GUE packet can be secured using Datagram Transport 172 Layer Security [RFC6347]. An encapsulator would apply DTLS to the 173 GUE payload so that the payload packets are encrypted and the GUE 174 header remains in plaintext. 176 To differ encrypted payload from plaintext payload, the document 177 proposes allocating one flag from GUE optional flag field for 178 payload transformation indication and adding a 32 bit field when 179 Payload Transform flag is set. Following format shows GUE header 180 with Payload Transform flag, i.e. 'T' is set. 182 0 1 2 3 183 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 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Source port | Destination port | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Length | Checksum | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 |Ver|C| Hlen | Proto/Ctype |V|SEC|K|F|S|T| Flags |E| 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | | 192 | VNID, security, GUE checksum, fragmentation, ~ 193 ~ Session (optional) | 194 | | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | Payload Transform Field | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 Figure 2 GUE Header with Payload Transform Flag 200 A 32 bits field in GUE header is for the payload transform function 201 and MUST be presented when Payload Transform flag T is set and MUST 202 NOT be presented when clear. The format of Payload Transform Field 203 is in Figure 3. 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Type | Payload Type | Reserved | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 Figure 3 Payload Encryption Field Format 210 Type: Payload Transform Type or Code point. Each payload transform 211 mechanism must have one code point registered in IANA. This 212 document specifies: 214 0x01: for DTLS [RFC6347] 216 0x80~0xFF: for private payload transform types 218 A private payload transform type can be used for experimental 219 purpose or vendor proprietary mechanism. 221 Payload Type: used to indicate the encrypted payload type. When 222 encryption flag is set, next protocol in the base header should set 223 to 59 ("No next header") for a data message and zero for a control 224 message. The payload type (IP protocol or control message type) of 225 the unencrypted paytload must be encoded in this field. 227 The benefit of this rule is to prevent a middle box from inspecting 228 the encrypted payload according to GUE next protocol. Assumption 229 here is that a middle box may understand GUE base header but does 230 not understand GUE option flag definitions. 232 Reserved field for DTLS type MUST set to Zero. For other 233 transformation type, the reserved field may be specified for a 234 purpose. 236 The usage of the key fields in the GUE header [GUE] for the payload 237 encryption mechanism is described as below: 239 o Ver: Set to 0x0. Payload transform option applies to version 0x0. 241 o Control flag: When it set, control message presents SHOULD be 242 encrypted except GUE base header. 244 o Hlen: length of optional fields (byte)/4 246 o Proto/CType: Set to 59. The payload type is encoded in the 247 payload encryption option field. 249 o 'E' Extension flag. It is the last bit in the GUE header. For 250 usage of Extension field see [GUE]. The payload encryption does 251 not require use of any extension field. 253 UDP header usage for payload encryption mechanism: UDP dst port 254 SHOULD be filled with GUE port [GUE]; UDP src port MAY be filled 255 with entropy or a random value. The checksum and length 256 implementation MUST be compliant with GUE implementation [GUE]. 258 5. Encapsulation/Decapsulation Operations 260 GUE secure transport mechanism applies to both IPv4 and IPv6 261 underlay networks. The outer IP address MUST be tunnel egress IP 262 address (dst) and tunnel ingress IP address (src). GUE security 263 option provides origin authentication and integrity to GUE based 264 tunnel; GUE payload encryption provides payload privacy over an IP 265 delivery network or Internet. Two functions are processed separately 266 at tunnel end points. A GUE tunnel can use both functions or use one 267 of them. 269 When both encryption and security are required, an encapsulator must 270 perform payload encryption first and then encapsulate the encrypted 271 packet with security flag and encryption flag set in GUE header; the 272 security field must be filled according Section 3 above; the 273 encryption field must be filled according to Section 4 above; the 274 decapsulator must decapsulate the packet first, then perform the 275 authentication validation; if the validation is successful, it 276 performs the payload decryption according the encryption information 277 in the payload encryption field in the header; if the validation 278 fails, the decapsulator must discard the packet and may generate an 279 alert to the management system. These processing rules also apply 280 when only one function, either encryption or security, is enabled, 281 except another function is not performed as stated above. 283 If GUE fragmentation is used in concert with the GUE security option 284 and/or payload transform option, the security and playload 285 transformation are performed after fragmentation at the encapsulator 286 and before reassembly at the decapsulator. 288 In order to get flow entropy from the payload, the encapsulator 289 needs to get the flow entropy first before performing the payload 290 encryption; then the flow entropy is inserted into UDP src port in 291 the GUE header. 293 DTLS [RFC6347] provides packet fragmentation capability. To avoid 294 packet fragmentation performed multiple times at GUE encapsulator, 295 GUE encapsulator SHOULD only perform the packet fragmentation at 296 packet encapsulation process, i.e., not in payload encryption 297 process. The encryption process should apply to GUE control packets. 299 DTLS usage [RFC6347] is limited to a single DTLS session for any 300 specific tunnel encapsulator/decapsulator pair (identified by source 301 and destination IP addresses). Both IP addresses MUST be unicast 302 addresses - multicast traffic is not supported when DTLS is used. A 303 GUE tunnel decapsulator implementation that supports DTLS can 304 establish DTLS session(s) with one or multiple tunnel encapsulators, 305 and likewise a GUE tunnel encapsulator implementation can establish 306 DTLS session(s) with one or multiple decapsulators. 308 6. Considerations of Using Other Security Tunnel Mechanisms 310 GUE may rely on other secure tunnel mechanisms such as DTLS [RFC6347] 311 for securing the whole GUE packet or IPsec [RFC4301] to achieve the 312 secure transport over an IP network or Internet. 314 IPsec [RFC4301] was designed as a network security mechanism, and 315 therefore it resides at the network layer. As such, if the tunnel 316 is secured with IPsec, the UDP header would not be visible to 317 intermediate routers anymore in either IPsec tunnel or transport 318 mode. The big drawback here prohibits intermediate routers to 319 perform load balance based on the flow entropy in UDP header. In 320 addition, this method prohibits any middle box function on the path. 322 By comparison, DTLS [RFC6347] was designed with application security 323 and can better preserve network and transport layer protocol 324 information than IPsec [RFC4301]. Using DTLS to secure the GUE 325 tunnel, both GUE header and payload will be encrypted. In order to 326 differentiate plaintext GUE header from encrypted GUE header, the 327 destination port of the UDP header between two must be different, 328 which essentially requires another standard UDP port for GUE with 329 DTLS. The drawback on this method is to prevent a middle box 330 operation to GUE tunnel on the path. 332 Use of two independent tunnel mechanisms such as GUE and DTLS to 333 carry a network protocol over an IP network adds some overlap and 334 process complex. For example, fragmentation will be done twice. 336 As the result, a GUE tunnel SHOULD use the security mechanisms 337 specified in this document to provide secure transport over an IP 338 network or Internet when it is needed. GUE tunnel can be used as 339 secure transport mechanism over an IP network and Internet. 341 7. Security Considerations 343 Encapsulation of network protocol in GUE should not increase 344 security risk, nor provide additional security in itself. GUE 345 requires that the source port for UDP packets should be randomly 346 seeded to mitigate some possible denial service attacks. 348 If the integrity and privacy of data packets being transported 349 through GUE is a concern, GUE security and payload encryption SHOULD 350 be used to remove the concern. If the integrity is the only concern, 351 the tunnel may consider use of GUE security only for optimization. 352 Likewise, if the privacy is the only concern, the tunnel may use GUE 353 encryption function only. 355 If GUE payload already provides secure mechanism, e.g., the payload 356 is IPsec packets, it is still valuable to consider use of GUE secure 357 mechanisms for the payload header privacy and the tunnel integrity. 359 7.1. GUE Security Field Usage 361 The GUE security field should be used to provide integrity and 362 authentication of the GUE header. Security negotiation 363 (interpretation of security field, key management, etc.) is expected 364 to be negotiated out of band between two communicating hosts. Two 365 possible uses for this field are outlined below, a more precise 366 specification is deferred to other documents. 368 7.1.1. Cookies 370 The security field may be used as a cookie. This would be similar to 371 cookie mechanism described in L2TP [RFC3931], and the general 372 properties should be the same. The cookie may be used to validate 373 the encapsulation. The cookie is a shared value between an 374 encapsulator and decapsulator which should be chosen randomly and 375 may be changed periodically. Different cookies may used for logical 376 flows between the encapsulator and decapsulator, for instance 377 packets sent with different VNIs in network virtualization [GUE4NVO] 378 might have different cookies. 380 7.1.2. Secure hash 382 Strong authentication of the GUE header can be provided using a 383 secure hash. This may follow the model of the TCP authentication 384 option [RFC5925]. In this case the security field holds a message 385 digest for the GUE header (e.g. 16 bytes from MD5). The digest might 386 be done over static fields in IP and UDP headers per negotiation 387 (addresses, ports, and protocols). In order to provide enough 388 entropy, a random salt value in each packet might be added, for 389 instance the security field could be a 256 bit value which contains 390 128 bits of salt value, and a 128 bit digest value. The use of 391 secure hashes requires shared keys which are presumably negotiated 392 and rotated as needed out of band. 394 8. IANA Considerations 396 This document requires IANA to allocate: 398 Two bits in GUE option flag field for GUE Security. 399 One bit in GUE option flag field for GUE Payload Transform. 401 This document requires IANA to have a new registry for Encryption 402 Type and require two code points for: 404 0x01: for DTLS [RFC6347] 406 0x80~0xFF: for private payload transform 408 9. References 410 9.1. Normative References 412 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 413 Requirement Levels", BCP 14, RFC2119, March 1997. 415 [RFC3931] Lau, J., Townsley, W., et al, "Layer Tow Tunneling 416 Protocol - Version 3 (L2TPv3)", RFC3931, 1999 418 [RFC4301] Kent, S., Seo, K., "Security Architecture for the Internet 419 Protocol", RFC4301, December 2005 421 [RFC5925] Touch, J., et al, "The TCP Authentication Option", RFC5925, 422 June 2010 424 [RFC6347] Rescoria, E., Modadugu, N., "Datagram Transport Layer 425 Security Version 1.2", RFC6347, 2012. 427 [GUE] Herbert, T., Yong, L., et al "Generic UNP Encapsulation", 428 draft-ietf-nvo3-gue-00, work in progress. 430 9.2. Informative References 432 [GUE4NVO] Yong, L., and Herbert T., "Generic UNP Encapsulation for 433 NVO", draft-hy-nvo3-gue-4-nvo, work in progress. 435 10. Authors' Addresses 437 Lucy Yong 438 Huawei USA 440 Email: lucy.yong@huawei.com 442 Tom Herbert 443 Facebook 444 1 Hacker Way 445 Menlo Park, CA 94052 446 US 448 Email: tom@herbertland.com