idnits 2.17.1 draft-mglt-dice-ipsec-for-application-payload-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 : ---------------------------------------------------------------------------- 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 (July 23, 2014) is 3564 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) == Outdated reference: A later version (-12) exists of draft-mglt-ipsecme-diet-esp-01 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DICE D. Migault (Ed) 3 Internet-Draft Orange 4 Intended status: Standards Track C. Bormann 5 Expires: January 24, 2015 Universitaet Bremen TZI 6 July 23, 2014 8 IPsec/ESP for Application Payload 9 draft-mglt-dice-ipsec-for-application-payload-00.txt 11 Abstract 13 This document is a strawman specification describing how IPsec/ESP 14 could be used to secure application payloads, in particular to enable 15 multicast applications where DTLS would be used for unicast. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 24, 2015. 34 Copyright Notice 36 Copyright (c) 2014 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 53 2. State of the Art . . . . . . . . . . . . . . . . . . . . . . 3 54 3. UDP-Encapsulation Header . . . . . . . . . . . . . . . . . . 5 55 4. Removing Transport Header . . . . . . . . . . . . . . . . . . 6 56 5. Additional Compression . . . . . . . . . . . . . . . . . . . 6 57 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 58 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 59 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 61 8.2. Informational References . . . . . . . . . . . . . . . . 8 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 64 1. Introduction 66 [I-D.keoh-dice-multicast-security] defines a way to protect multicast 67 traffic against group outsiders using a modified DTLS record 68 protocol. Reservations have been voiced about modifying DTLS this 69 way without strengthening security by adding data origin 70 authentication. 72 However, many applications do not require this additional security. 73 One protocol that already supports group-level security for multicast 74 is IPsec. 76 This document discusses how IPsec can be used to secure data at the 77 application layer. The resulting packet structure is expected to 78 resemble a DTLS flavor as represented in Figure 1. 80 +--------+-------------------------------------------------+ 81 | | +--------+------------------------------------+ | 82 | | | | +-------------+------------------+ | | 83 | | | | | | +--------------+ | | | 84 | IP | | UDP | | Security | | Application | | | | 85 | header | | header | | Header | | Data | | | | 86 | | | | | | +--------------+ | | | 87 | | | | +-------------+------------------+ | | 88 | | +--------+------------------------------------+ | 89 +--------+-------------------------------------------------+ 91 Figure 1: Securing Application Data 93 1.1. Requirements notation 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 2. State of the Art 101 IPsec/ESP [RFC4303] has been designed to secure IP payload according 102 to two different modes: the transport mode and the tunnel mode. 103 Figure 2 represents an non protected UDP packet that is protected 104 with IPsec/ESP. UDP is chosen as an example and could be any other 105 transport mode like TCP or SCTP, or ANY for unknown transport. 106 Figure 3 illustrates how IPsec/ESP secures the non protected packet 107 using the transport mode and Figure 4 illustrates how IPsec/ESP 108 secures the packet with the tunnel mode. 110 +--------------------------+ 111 | IP Header | 112 +--------------------------+ 113 | UDP Header | 114 +--------------------------+ 115 | Application | 116 | Data | 117 +--------------------------+ 119 Figure 2: Example: non protected IP Packet 121 +--------------------------+ 122 | IP Header | 123 +--------------------------+--- 124 | ESP Header | ^ 125 ---+--------------------------+ | 126 ^ | IV | | 127 | +--------------------------+ | 128 | | UDP Header | | Integrity 129 | +--------------------------+ | Protection 130 Encryption | | Application | | 131 | | Data | | 132 | +--------------------------+ | 133 v | ESP Trailer | v 134 --- +--------------------------+--- 135 | ICV | 136 +--------------------------+ 138 Figure 3: Example: IPsec/ESP with transport mode 139 +--------------------------+ 140 | Tunnel IP Header | 141 +--------------------------+--- 142 | ESP Header | ^ 143 ---+--------------------------+ | 144 ^ | IV | | 145 | +--------------------------+ | 146 | | IP Header | | Integrity 147 Encryption | +--------------------------+ | Protection 148 | | UDP Header | | 149 | +--------------------------+ | 150 | | Encrypted Application | | 151 | | Data | | 152 | +--------------------------+ | 153 v | ESP Trailer | v 154 ---+--------------------------+--- 155 | ICV | 156 +--------------------------+ 158 Figure 4: Ex: IPsec/ESP with tunnel mode 160 This document does not consider the tunnel mode and only the 161 transport mode. DTLS is usually used to secure application data. 162 Among other differences, IPsec/ESP with transport mode differs from 163 DTLS on the following aspects: 1) The Security Header is placed 164 before the transport header, as a result 2) the transport header is 165 encrypted. Then 3) IPsec/ESP is an extension of IP which makes the 166 whole packet described in Figure 3 and Figure 4 an IP packet with an 167 empty IP payload. One consequence is that the packet has to respect 168 the bit alignment required for IP headers, that is 32 bit alignment 169 for IPv4 and 64 bit alignment for IPv6. This is why the ESP Trailer 170 presents some Padding. 172 Figure 3 and Figure 4 mentions the IV which is necessary for 173 encryption and decryption. The IV is usually not part of the IPsec/ 174 ESP protocol, but is defined by the encryption protocol used by 175 IPsec/ESP. Each encryption protocol defines the size of its IV. It 176 is mentioned in the figures in order to clarify the way we compute 177 the overhead. 179 For NAT traversal, IPsec has defined a UDP encapsulation in 180 [RFC3948]. UDP encapsulation of the IPsec/ESP packet with transport 181 mode is illustrated in Figure 5. 183 +--------------------------+ 184 | IP Header | 185 +--------------------------+ 186 | UDP-Encapsulation | 187 +--------------------------+--- 188 | ESP Header | ^ 189 ---+--------------------------+ | 190 ^ | IV | | 191 | +--------------------------+ | 192 | | UDP Header | | Integrity 193 | +--------------------------+ | Protection 194 Encryption | | Application | | 195 | | Data | | 196 | +--------------------------+ | 197 v | ESP Trailer | v 198 --- +--------------------------+--- 199 | ICV | 200 +--------------------------+ 202 Figure 5: Ex: UDP Encapsulation of IPsec/ESP Transport mode 204 As illustrated in Figure 5, using IPsec/ESP with UDP encapsulation 205 achieves our goal: A UDP packet carries a encrypted payload. In 206 Figure 5, the encrypted payload is the concatenation of the IV, the 207 UDP header, the application data and the ESP Trailer. 209 The overhead of such a packet is the ESP Header (8 bytes), the IV (8 210 bytes for AES-CCM mode [RFC4309]), an extra UDP header (8 bytes), the 211 ESP Trailer (2 bytes and padding bytes. Padding bytes are between 0 212 and 8 for 64 bit alignment in IPv6 and between 0 and 4 bytes for 213 IPv4. As a result, the average is 6 bytes for IPv6 and 4 bytes for 214 IPv4). This leads to a 30 bytes overhead for IPv6 and 28 byte 215 overhead for IPv4. 217 If this approach is to be pursued, it is probably worthwhile to 218 reduce this overhead 220 The remaining sections describe ways to do that. 222 3. UDP-Encapsulation Header 224 [RFC3948] specifies that ports of the UDP-Encapsulation Header MUST 225 be the one used during the IKEv2 negotiation. In addition IKEv2 is 226 listening for UDP encapsulation on port 4500. As a result, the port 227 of the responder is always set to 4500 for any ESP packet. 229 The use of a fix port in 4500 for IKEv2 is a standard port that 230 specifies, IKEv2 packets are expected to be UDP encapsulated. The 231 reason to keep these ports in the ESP UDP encapsulated communication, 232 is that 1) IKEv2 has set a channel between the peers through a NAT -- 233 note that each peer may have a different set of (port source, port 234 destination). 2) IKEv2 is used to set up the IPsec/ESP communication 235 on each peer by setting the various IPsec database. Since IKEv2 is 236 aware of a through-NAT-reachable channel, IKEv2 can proceed to UDP 237 encapsulation setting on each hosts. 239 Port fixing is not required in applications other than the UDP 240 encapsulation or if IKEv2 is not used to setup the IPsec/ESP 241 communication. 243 4. Removing Transport Header 245 The Transport Header is used to identify the application with ports, 246 once IPsec has decrypted an incoming packet. For sending packets, 247 the ports in the transport header can be used as Traffic Selectors to 248 identify the right Securicy Policy. 250 Removing the Transport Header implies that none of the ports or 251 transport protocol can be used as selectors. IPsec [RFC4301] does 252 not prevent that, and only the IP addresses will be considered, and 253 thus all applications that do not use ports as selectors between the 254 two peers will be protected with the same SA. Note that IPsec SPD is 255 an ordered database. This means that if an application between the 256 two peers with ports specified as Traffic Selectors needs a specific 257 Security Association, this is still possible. The policy has simply 258 to be placed before the policy using only IP addresses. 260 5. Additional Compression 262 With the current standard [RFC3948], [RFC4301], no additional 263 compression can be completed, which leaves an overhead of 22 bytes 264 for IPv4 and 20 bytes for IPv4. 266 Protocols like 6LowPAN [I-D.raza-6lowpan-ipsec], ROHC [RFC3095], 267 [RFC5225] can compress the ESP Header up to zero bytes. The ESP 268 Header contains a Security Policy Index (SPI) of 4 bytes and a 269 Sequence Number (SN) of 4 bytes. The SPI may be completely 270 compressed if the UDP decapsulation decompressor is able to derive 271 the SPI from UDP ports. Both SPI and SN are necessary to perform 272 authentication and integrity check. 274 Compression of the ESP Trailer cannot be currently performed. 275 However, ongoing work [I-D.mglt-ipsecme-diet-esp] makes possible the 276 compression of all fields of the ESP Trailer. 278 Compression of IV is not currently permitted with IPsec, and this 279 field MUST be included in each IP packet. However, some ongoing work 280 [I-D.mglt-ipsecme-diet-esp-iv-generation]. 282 Finally, compression of the transport header may also be performed 283 using [I-D.mglt-ipsecme-diet-esp-payload-compression]. The advanatge 284 of compressing it over removing it is that compression enables the 285 use of ports as Traffic Selectors without carrying the transport 286 header. Note that this is done under conditions. 288 6. IANA Considerations 290 There are no IANA consideration for this document. 292 7. Security Considerations 294 The security considerations of IPsec and Diet-ESP (if used) apply. 296 8. References 298 8.1. Normative References 300 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 301 Requirement Levels", BCP 14, RFC 2119, March 1997. 303 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 304 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 305 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 306 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 307 Compression (ROHC): Framework and four profiles: RTP, UDP, 308 ESP, and uncompressed", RFC 3095, July 2001. 310 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 311 Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 312 3948, January 2005. 314 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 315 Internet Protocol", RFC 4301, December 2005. 317 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 318 4303, December 2005. 320 [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM 321 Mode with IPsec Encapsulating Security Payload (ESP)", RFC 322 4309, December 2005. 324 [RFC5225] Pelletier, G. and K. Sandlund, "RObust Header Compression 325 Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and 326 UDP-Lite", RFC 5225, April 2008. 328 8.2. Informational References 330 [I-D.keoh-dice-multicast-security] 331 Keoh, S., Kumar, S., Garcia-Morchon, O., Dijk, E., and A. 332 Rahman, "DTLS-based Multicast Security in Constrained 333 Environments", draft-keoh-dice-multicast-security-08 (work 334 in progress), July 2014. 336 [I-D.mglt-ipsecme-diet-esp] 337 Migault, D. and T. Guggemos, "Diet-ESP: a flexible and 338 compressed format for IPsec/ESP", draft-mglt-ipsecme-diet- 339 esp-01 (work in progress), July 2014. 341 [I-D.mglt-ipsecme-diet-esp-iv-generation] 342 Migault, D. and T. Guggemos, "Diet-ESP: Generating 343 compressed IV and SN", draft-mglt-ipsecme-diet-esp-iv- 344 generation-00 (work in progress), July 2014. 346 [I-D.mglt-ipsecme-diet-esp-payload-compression] 347 Migault, D. and T. Guggemos, "Diet-IPsec: ESP Payload 348 Compression of IPv6 / UDP / TCP / UDP-Lite", draft-mglt- 349 ipsecme-diet-esp-payload-compression-00 (work in 350 progress), July 2014. 352 [I-D.raza-6lowpan-ipsec] 353 Raza, S., Duquennoy, S., and G. Selander, "Compression of 354 IPsec AH and ESP Headers for Constrained Environments", 355 draft-raza-6lowpan-ipsec-01 (work in progress), September 356 2013. 358 Authors' Addresses 360 Daniel Migault 361 Orange 362 38 rue du General Leclerc 363 92794 Issy-les-Moulineaux Cedex 9 364 France 366 Phone: +33 1 45 29 60 52 367 Email: daniel.migault@orange.com 368 Carsten Bormann 369 Universitaet Bremen TZI 370 Postfach 330440 371 D-28359 Bremen 372 Germany 374 Phone: +49-421-218-63921 375 Email: cabo@tzi.org