idnits 2.17.1 draft-hy-gue-4-secure-transport-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 14, 2016) is 2965 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 == Outdated reference: A later version (-04) exists of draft-hy-nvo3-gue-4-nvo-01 Summary: 1 error (**), 0 flaws (~~), 3 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: September 2016 March 14, 2016 8 Generic UDP Encapsulation (GUE) for Secure Transport 9 draft-hy-gue-4-secure-transport-03 11 Abstract 13 This document specifies the ability of Generic UDP Encapsulation 14 (GUE) to provide secure transport over IP networks and the Internet, 15 including GUE header integrity protection and origin authentication 16 and GUE payload encryption. These are optional features of GUE. 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 September 14, 2016. 35 Copyright Notice 37 Copyright (c) 2016 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. GUE Security...................................................3 56 4. GUE Payload Encryption.........................................5 57 5. Encapsulation/Decapsulation Operations.........................7 58 6. Considerations of Using Other Security Tunnel Mechanisms.......8 59 7. Security Considerations........................................9 60 7.1. GUE Security Field Usage..................................9 61 7.1.1. Cookies..............................................9 62 7.1.2. Secure hash..........................................9 63 8. IANA Considerations...........................................10 64 9. References....................................................10 65 9.1. Normative References.....................................10 66 9.2. Informative References...................................11 67 10. Authors' Addresses...........................................11 69 1. Introduction 71 Generic UDP Encapsulation [GUE] is the protocol that specifies 72 tunneling a network protocol over an IP network or Internet and a 73 UDP tunnel. The tunneled network protocol is encapsulated in GUE 74 header [GUE] at a tunnel encapsulator, transported as a regular IP 75 packet, and decapsulated at the tunnel decapsulator. 77 This draft specifies the security capabilities for GUE. One security 78 capability is to provide origin authentication and integrity 79 protection of the GUE header at tunnel end points to guarantee 80 isolation between tunnels and mitigate Denial of Service attacks. 81 Another capability is payload encryption that prevents the payload 82 from eavesdropping, tampering, or message forgery. These security 83 capabilities are specified as optional features of GUE. 85 In theory, uses of GUE could leverage other existing tunnel 86 mechanisms that provides secure transport over Internet such as DTLS 87 [RFC6347] and IPsec[RFC4301]. Section 6 discusses the weakness to 88 rely on another tunnel mechanism for GUE secure transport. 90 2. Terminology 92 The terms defined in GUE [GUE] are used in this document. 94 2.1. Requirements Language 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in [RFC2119]. 100 3. GUE Security 102 This document proposes to allocate two flag bits from GUE optional 103 flag field as the Security flag for GUE integrity protection and 104 authentication validation. GUE header format with Security Flag is 105 shown in Figure 1. The second and third bits in GUE optional flag 106 field are allocated for Security mechanism. 108 0 1 2 3 109 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 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | Source port | Destination port | 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 | Length | Checksum | 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 |Ver|C| Hlen | Proto/Ctype |V|SEC| Undefined Flags |E| 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 | Virtual Network ID (Optional) | 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 | | 120 ~ Security Field ~ 121 | | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 Figure 1 GUE Header Format with Security Flag 126 o 'V' Virtualization flag: This flag is designated for network 127 virtualization overlay (NVO)[GUE4NVO]. 129 o 'SEC' Security flags: Indicates presence of security field. To 130 provide security capability, the flags MUST be set. Different 131 sizes are allowed to allow different methods and extensibility. 132 The use of the security field is expected to be negotiated out of 133 band between two tunnel end points. Potential uses of the 134 security field are discussed in Section of Security 135 Considerations. 137 o 00 - No security field 139 o 01 - 64 bit security field 141 o 10 - 128 bit security field 143 o 11 - 256 bit security field 145 The usage of the key fields in the GUE header [GUE] for the security 146 mechanism is described as below: 148 o Ver: Set to 0x0. Security option is designed for GUE version 0. 150 o 'C' Control flag: When it set, control message presents and 151 control processing MUST occur after security validation. 153 o Hlen: length of optional fields (byte)/4. Note that Payload 154 Transform function does not require a private field. 156 o Proto/ctype: Contain the protocol of the encapsulated payload 157 packet, i.e. next header when the C bit is not set. Contains a 158 control message type when the C bit is set. The next header 159 begins at the offset provided by Hlen. 161 'E' Extension flag. It is the last bit in the GUE header. For usage 162 of Extension field see [GUE]. The security transport does not 163 require use of any extension field. 165 UDP header field must be set per [GUE]. The checksum and length 166 implementation MUST be compliant with GUE implementation [GUE]. 168 4. GUE Payload Encryption 170 The payload of a GUE packet can be secured using Datagram Transport 171 Layer Security [RFC6347]. An encapsulator would apply DTLS to the 172 GUE payload so that the payload packets are encrypted and the GUE 173 header remains in plaintext. 175 To differ encrypted payload from plaintext payload, the document 176 proposes allocating one flag from GUE optional flag field for 177 payload transformation indication and adding a 32 bit field when 178 Payload Transform flag is set. Following format shows GUE header 179 with Payload Transform flag, i.e. 'T' is set. 181 0 1 2 3 182 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 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Source port | Destination port | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Length | Checksum | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 |Ver|C| Hlen | Proto/Ctype |V|SEC|K|F|S|T| Flags |E| 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | | 191 | VNID, security, GUE checksum, fragmentation, ~ 192 ~ Session (optional) | 193 | | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Payload Transform Field | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 Figure 2 GUE Header with Payload Transform Flag 199 A 32 bits field in GUE header is for the payload transform function 200 and MUST be presented when Payload Transform flag T is set and MUST 201 NOT be presented when clear. The format of Payload Transform Field 202 is in Figure 3. 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Type | Payload Type | Reserved | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 Figure 3 Payload Transform Field Format 209 Type: Payload Transform Type or Code point. Each payload transform 210 mechanism must have one code point registered in IANA. This 211 document specifies: 213 0x01: for DTLS [RFC6347] 215 0x80~0xFF: for private payload transform types 217 A private payload transform type can be used for experimental 218 purpose or vendor proprietary mechanism. 220 Payload Type: used to indicate the encrypted payload type. When 221 encryption flag is set, next protocol in the base header should set 222 to 59 ("No next header") for a data message and zero for a control 223 message. The payload type (IP protocol or control message type) of 224 the unencrypted paytload must be encoded in this field. 226 The benefit of this rule is to prevent a middle box from inspecting 227 the encrypted payload according to GUE next protocol. Assumption 228 here is that a middle box may understand GUE base header but does 229 not understand GUE option flag definitions. 231 Reserved field for DTLS type MUST set to Zero. For other 232 transformation type, the reserved field may be specified for a 233 purpose. 235 The usage of the key fields in the GUE header [GUE] for the payload 236 encryption mechanism is described as below: 238 o Ver: Set to 0x0. Payload transform option applies to version 0x0. 240 o Control flag: When it set, control message presents SHOULD be 241 encrypted except GUE base header. 243 o Hlen: length of optional fields (byte)/4 245 o Proto/CType: Set to 59. The payload type is encoded in the 246 payload encryption option field. 248 o 'E' Extension flag. It is the last bit in the GUE header. For 249 usage of Extension field see [GUE]. The payload encryption does 250 not require use of any extension field. 252 UDP header usage for payload encryption mechanism: UDP dst port 253 SHOULD be filled with GUE port [GUE]; UDP src port MAY be filled 254 with entropy or a random value. The checksum and length 255 implementation MUST be compliant with GUE implementation [GUE]. 257 5. Encapsulation/Decapsulation Operations 259 GUE secure transport mechanism applies to both IPv4 and IPv6 260 underlay networks. The outer IP address MUST be tunnel egress IP 261 address (dst) and tunnel ingress IP address (src). GUE security 262 option provides origin authentication and integrity to GUE based 263 tunnel; GUE payload encryption provides payload privacy over an IP 264 delivery network or Internet. Two functions are processed separately 265 at tunnel end points. A GUE tunnel can use both functions or use one 266 of them. 268 When both encryption and security are required, an encapsulator must 269 perform payload encryption first and then encapsulate the encrypted 270 packet with security flag and encryption flag set in GUE header; the 271 security field must be filled according Section 3 above; the 272 encryption field must be filled according to Section 4 above; the 273 decapsulator must decapsulate the packet first, then perform the 274 authentication validation; if the validation is successful, it 275 performs the payload decryption according the encryption information 276 in the payload encryption field in the header; if the validation 277 fails, the decapsulator must discard the packet and may generate an 278 alert to the management system. These processing rules also apply 279 when only one function, either encryption or security, is enabled, 280 except another function is not performed as stated above. 282 If GUE fragmentation is used in concert with the GUE security option 283 and/or payload transform option, the security and playload 284 transformation are performed after fragmentation at the encapsulator 285 and before reassembly at the decapsulator. 287 In order to get flow entropy from the payload, the encapsulator 288 needs to get the flow entropy first before performing the payload 289 encryption; then the flow entropy is inserted into UDP src port in 290 the GUE header. 292 DTLS [RFC6347] provides packet fragmentation capability. To avoid 293 packet fragmentation performed multiple times at GUE encapsulator, 294 GUE encapsulator SHOULD only perform the packet fragmentation at 295 packet encapsulation process, i.e., not in payload encryption 296 process. The encryption process should apply to GUE control packets. 298 DTLS usage [RFC6347] is limited to a single DTLS session for any 299 specific tunnel encapsulator/decapsulator pair (identified by source 300 and destination IP addresses). Both IP addresses MUST be unicast 301 addresses - multicast traffic is not supported when DTLS is used. A 302 GUE tunnel decapsulator implementation that supports DTLS can 303 establish DTLS session(s) with one or multiple tunnel encapsulators, 304 and likewise a GUE tunnel encapsulator implementation can establish 305 DTLS session(s) with one or multiple decapsulators. 307 6. Considerations of Using Other Security Tunnel Mechanisms 309 GUE may rely on other secure tunnel mechanisms such as DTLS [RFC6347] 310 for securing the whole GUE packet or IPsec [RFC4301] to achieve the 311 secure transport over an IP network or Internet. 313 IPsec [RFC4301] was designed as a network security mechanism, and 314 therefore it resides at the network layer. As such, if the tunnel 315 is secured with IPsec, the UDP header would not be visible to 316 intermediate routers anymore in either IPsec tunnel or transport 317 mode. The big drawback here prohibits intermediate routers to 318 perform load balance based on the flow entropy in UDP header. In 319 addition, this method prohibits any middle box function on the path. 321 By comparison, DTLS [RFC6347] was designed with application security 322 and can better preserve network and transport layer protocol 323 information than IPsec [RFC4301]. Using DTLS to secure the GUE 324 tunnel, both GUE header and payload will be encrypted. In order to 325 differentiate plaintext GUE header from encrypted GUE header, the 326 destination port of the UDP header between two must be different, 327 which essentially requires another standard UDP port for GUE with 328 DTLS. The drawback on this method is to prevent a middle box 329 operation to GUE tunnel on the path. 331 Use of two independent tunnel mechanisms such as GUE and DTLS to 332 carry a network protocol over an IP network adds some overlap and 333 process complex. For example, fragmentation will be done twice. 335 As the result, a GUE tunnel SHOULD use the security mechanisms 336 specified in this document to provide secure transport over an IP 337 network or Internet when it is needed. GUE tunnel can be used as 338 secure transport mechanism over an IP network and Internet. 340 7. Security Considerations 342 Encapsulation of network protocol in GUE should not increase 343 security risk, nor provide additional security in itself. GUE 344 requires that the source port for UDP packets should be randomly 345 seeded to mitigate some possible denial service attacks. 347 If the integrity and privacy of data packets being transported 348 through GUE is a concern, GUE security and payload encryption SHOULD 349 be used to remove the concern. If the integrity is the only concern, 350 the tunnel may consider use of GUE security only for optimization. 351 Likewise, if the privacy is the only concern, the tunnel may use GUE 352 encryption function only. 354 If GUE payload already provides secure mechanism, e.g., the payload 355 is IPsec packets, it is still valuable to consider use of GUE secure 356 mechanisms for the payload header privacy and the tunnel integrity. 358 7.1. GUE Security Field Usage 360 The GUE security field should be used to provide integrity and 361 authentication of the GUE header. Security negotiation 362 (interpretation of security field, key management, etc.) is expected 363 to be negotiated out of band between two communicating hosts. Two 364 possible uses for this field are outlined below, a more precise 365 specification is deferred to other documents. 367 7.1.1. Cookies 369 The security field may be used as a cookie. This would be similar to 370 cookie mechanism described in L2TP [RFC3931], and the general 371 properties should be the same. The cookie may be used to validate 372 the encapsulation. The cookie is a shared value between an 373 encapsulator and decapsulator which should be chosen randomly and 374 may be changed periodically. Different cookies may used for logical 375 flows between the encapsulator and decapsulator, for instance 376 packets sent with different VNIs in network virtualization [GUE4NVO] 377 might have different cookies. 379 7.1.2. Secure hash 381 Strong authentication of the GUE header can be provided using a 382 secure hash. This may follow the model of the TCP authentication 383 option [RFC5925]. In this case the security field holds a message 384 digest for the GUE header (e.g. 16 bytes from MD5). The digest might 385 be done over static fields in IP and UDP headers per negotiation 386 (addresses, ports, and protocols). In order to provide enough 387 entropy, a random salt value in each packet might be added, for 388 instance the security field could be a 256 bit value which contains 389 128 bits of salt value, and a 128 bit digest value. The use of 390 secure hashes requires shared keys which are presumably negotiated 391 and rotated as needed out of band. 393 8. IANA Considerations 395 This document requires IANA to allocate: 397 Two bits in GUE option flag field for GUE Security. 398 One bit in GUE option flag field for GUE Payload Transform. 400 This document requires IANA to have a new registry for Encryption 401 Type and require two code points for: 403 0x01: for DTLS [RFC6347] 405 0x80~0xFF: for private payload transform 407 9. References 409 9.1. Normative References 411 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 412 Requirement Levels", BCP 14, RFC2119, March 1997. 414 [RFC3931] Lau, J., Townsley, W., et al, "Layer Tow Tunneling 415 Protocol - Version 3 (L2TPv3)", RFC3931, 1999 417 [RFC4301] Kent, S., Seo, K., "Security Architecture for the Internet 418 Protocol", RFC4301, December 2005 420 [RFC5925] Touch, J., et al, "The TCP Authentication Option", RFC5925, 421 June 2010 423 [RFC6347] Rescoria, E., Modadugu, N., "Datagram Transport Layer 424 Security Version 1.2", RFC6347, 2012. 426 [GUE] Herbert, T., Yong, L., et al "Generic UNP Encapsulation", 427 draft-ietf-nvo3-gue-00, work in progress. 429 9.2. Informative References 431 [GUE4NVO] Yong, L., and Herbert T., "Generic UNP Encapsulation for 432 NVO", draft-hy-nvo3-gue-4-nvo-01, work in progress. 434 10. Authors' Addresses 436 Lucy Yong 437 Huawei USA 439 Email: lucy.yong@huawei.com 441 Tom Herbert 442 Facebook 443 1 Hacker Way 444 Menlo Park, CA 94052 445 US 447 Email: tom@herbertland.com