idnits 2.17.1 draft-mglt-lwig-minimal-esp-05.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 (May 15, 2017) is 2535 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3602' is defined on line 446, but no explicit reference was found in the text == Unused Reference: 'RFC3686' is defined on line 451, but no explicit reference was found in the text == Unused Reference: 'RFC4106' is defined on line 456, but no explicit reference was found in the text == Unused Reference: 'RFC4309' is defined on line 469, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-ipsecme-rfc7321bis-05 == Outdated reference: A later version (-04) exists of draft-mglt-ipsecme-implicit-iv-02 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Light-Weight Implementation Guidance (lwig) D. Migault 3 Internet-Draft Ericsson 4 Intended status: Informational T. Guggemos 5 Expires: November 16, 2017 LMU Munich 6 May 15, 2017 8 Minimal ESP 9 draft-mglt-lwig-minimal-esp-05 11 Abstract 13 This document describes a minimal implementation of the IP 14 Encapsulation Security Payload (ESP) described in RFC 4303. Its 15 purpose is to enable implementation of ESP with a minimal set of 16 options that makes the minimal implementation compatible with ESP as 17 described in RFC 4303. A minimal version of ESP is not intended to 18 become a replacement of the RFC 4303 ESP, but instead to enable a 19 limited implementation to interoperate with implementations of RFC 20 4303 ESP. 22 This document describes what is required from RFC 4303 ESP as well as 23 various ways to optimize compliance with RFC 4303 ESP. 25 This document does not update or modify RFC 4303, but provides a 26 compact description of how to implement the minimal version of the 27 protocol. If this document and RFC 4303 conflicts then RFC 4303 is 28 the authoritative description. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on November 16, 2017. 47 Copyright Notice 49 Copyright (c) 2017 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 1. Requirements notation 64 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 65 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 66 document are to be interpreted as described in [RFC2119]. 68 2. Introduction 70 ESP [RFC4303] is part of the IPsec suite protocol [RFC4301] . It is 71 used to provide confidentiality, data origin authentication, 72 connectionless integrity, an anti-replay service (a form of partial 73 sequence integrity) and limited traffic flow confidentiality. 75 Figure 1 describes an ESP Packet. Currently ESP is implemented in 76 the kernel of major multi purpose Operating Systems (OS). The ESP 77 and IPsec stack implemented is usually complete to fit multiple 78 purpose usage of these OS. Completeness of the IPsec stack as well 79 as multi purpose of these OS is often performed at the expense of 80 resources, or a lack of performance, and so devices especially 81 constraint devices like sensors have developed their own specific and 82 task specific OS. This document provides a minimal ESP 83 implementation guideline so these devices can implement ESP and 84 benefit from IPsec. 86 For each field of the ESP packet represented in Figure 1 this 87 document provides recommendations and guidance for minimal 88 implementations. The primary purpose of Minimal ESP is to remain 89 interoperable with other nodes implementing RFC 4303 ESP, while 90 limiting the standard complexity of the implementation. 92 0 1 2 3 93 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 94 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---- 95 | Security Parameters Index (SPI) | ^Int. 96 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- 97 | Sequence Number | |ered 98 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ---- 99 | Payload Data* (variable) | | ^ 100 ~ ~ | | 101 | | |Conf. 102 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- 103 | | Padding (0-255 bytes) | |ered* 104 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 105 | | Pad Length | Next Header | v v 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ 107 | Integrity Check Value-ICV (variable) | 108 ~ ~ 109 | | 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 Figure 1: ESP Packet Description 114 3. Security Parameter Index (SPI) (32 bit) 116 According to the [RFC4303], the SPI is a mandatory 32 bits field and 117 is not allowed to be removed. 119 The SPI has a local significance to index the Security Association 120 (SA). From [RFC4301] section 4.1, nodes supporting only unicast 121 communications can index their SA only using the SPI. On the other 122 hand, nodes supporting multicast communications must also use the IP 123 addresses and thus SA lookup needs to be performed using the longest 124 match. 126 For nodes supporting only unicast communications, it is RECOMMENDED 127 to index SA with the SPI only. Some other local constraints on the 128 node may require a combination of the SPI as well as other parameters 129 to index the SA. 131 It is RECOMMENDED to randomly generate the SPI indexing each inbound 132 session. A random generation provides a stateless way to generate 133 the SPIs, while keeping the probability of collision between SPIs 134 relatively low. In case of collision, the SPI is simply re- 135 generated. 137 However, for some constraint nodes, generating a random SPI may 138 consume to much resource, in which case SPI can be generated using 139 predictable functions or even a fix value. In fact, the SPI does not 140 need to the SPI does not need to be random. 142 When a constraint node uses fix value for SPIs, it imposes some 143 limitations on the number of inbound SA. This limitation can be 144 alleviate by how the SA look up is performed. When fix SPI are used, 145 it is RECOMMENDED the constraint node has as many SPI values as ESP 146 session per host IP address, and that lookup includes the IP 147 addresses. 149 Note that SPI value is used only for inbound traffic, as such the SPI 150 negotiated with IKEv2 [RFC7296] or [RFC7815] by a peer, is the value 151 used by the remote peer when its sends traffic. 153 The use of fix SPI should not be considered as a way to avoid strong 154 random generators. Such generator will be required in order to 155 provide strong cryptographic protection. Instead, the use of a fix 156 SPI should only considered as a way to overcome the resource 157 limitations of the node, when this is feasible. 159 The use of a limited number of fix SPI also come with security or 160 privacy drawbacks. Typically, a passive attacker may derive 161 information such as the number of constraint devices connecting the 162 remote peer, and in conjunction with data rate, the attacker may 163 eventually determine the application the constraint device is 164 associated to. In addition, if the fix value SPI is fixed by a 165 manufacturer or by some software application, the SPI may leak in an 166 obvious way the type of sensor, the application involved or the model 167 of the constraint device. As a result, the use of a unpredictable 168 SPI is preferred to provide better privacy. 170 As far as security is concerned, revealing the type of application or 171 model of the constraint device could be used to identify the 172 vulnerabilities the constraint device is subject to. This is 173 especially sensitive for constraint device where patches or software 174 updates will be challenging to operate. As a result, these devices 175 may remain vulnerable for relatively long period. In addition, 176 predictable SPI enable an attacker to forge packets with a valid SPI. 177 Such packet will not be rejected due to an SPI mismatch, but instead 178 after the signature check which requires more resource and thus make 179 DoS more efficient, especially for devices powered by batteries. 181 Values 0-255 SHOULD NOT be used. Values 1-255 are reserved and 0 is 182 only allowed to be used internal and it MUST NOT be send on the wire. 184 [RFC4303] mentions : 186 :: "The SPI is an arbitrary 32-bit value that is used by a 187 receiver to identify the SA to which an incoming packet is bound. 188 The SPI field is mandatory. [...]" 190 :: "For a unicast SA, the SPI can be used by itself to specify an 191 SA, or it may be used in conjunction with the IPsec protocol type 192 (in this case ESP). Because the SPI value is generated by the 193 receiver for a unicast SA, whether the value is sufficient to 194 identify an SA by itself or whether it must be used in conjunction 195 with the IPsec protocol value is a local matter. This mechanism 196 for mapping inbound traffic to unicast SAs MUST be supported by 197 all ESP implementations." 199 4. Sequence Number(SN) (32 bit) 201 According to [RFC4303], the sequence number is a mandatory 32 bits 202 field in the packet. 204 The SN is set by the sender so the receiver can implement anti-replay 205 protection. The SN is derived from any strictly increasing function 206 that guarantees: if packet B is sent after packet A, then SN of 207 packet B is strictly greater then the SN of packet A. 209 In IoT, constraint devices are expected to establish communication 210 with specific devices, like a specific gateway, or nodes similar to 211 them. As a result, the sender may know whereas the receiver 212 implements anti-replay protection or not. Even though the sender may 213 know the receiver does not implement anti replay protection, the 214 sender MUST implement a always increasing function to generate the 215 SN. 217 Usually, SN is generated by incrementing a counter for each packet 218 sent. A constraint device may avoid maintaining this context. If 219 the device has a clock, it may use the time indicated by the clock 220 has a SN. This guarantees a strictly increasing function, and avoid 221 storing any additional values or context related to the SN. When the 222 use of a clock is considered, one should take care that packets 223 associated to a given SA are not sent with the same time value. 225 [RFC4303] mentions : 227 :: "This unsigned 32-bit field contains a counter value that 228 increases by one for each packet sent, i.e., a per-SA packet 229 sequence number. For a unicast SA or a single-sender multicast 230 SA, the sender MUST increment this field for every transmitted 231 packet. Sharing an SA among multiple senders is permitted, though 232 generally not recommended. [...] The field is mandatory and MUST 233 always be present even if the receiver does not elect to enable 234 the anti-replay service for a specific SA." 236 5. Padding 238 The purpose of padding is to respect the 32 bit alignment of ESP. 239 ESP MUST have at least one padding byte Pad Length that indicates the 240 padding length. ESP padding bytes are generated by a succession of 241 unsigned bytes starting with 1, 2, 3 with the last byte set to Pad 242 Length, where Pad Length designates the length of the padding bytes. 244 Checking the padding structure is not mandatory, so the constraint 245 device may not proceed to such checks, however, in order to 246 interoperate with existing ESP implementations, it MUST build the 247 padding bytes as recommended by ESP. 249 In some situation the padding bytes may take a fix value. This would 250 typically be the case when the Data Payload is of fix size. 252 [RFC4303] mentions : 254 :: "If Padding bytes are needed but the encryption algorithm does 255 not specify the padding contents, then the following default 256 processing MUST be used. The Padding bytes are initialized with a 257 series of (unsigned, 1-byte) integer values. The first padding 258 byte appended to the plaintext is numbered 1, with subsequent 259 padding bytes making up a monotonically increasing sequence: 1, 2, 260 3, .... When this padding scheme is employed, the receiver SHOULD 261 inspect the Padding field. (This scheme was selected because of 262 its relative simplicity, ease of implementation in hardware, and 263 because it offers limited protection against certain forms of "cut 264 and paste" attacks in the absence of other integrity measures, if 265 the receiver checks the padding values upon decryption.)" 267 ESP [RFC4303] also provides Traffic Flow Confidentiality (TFC) as a 268 way to perform padding to hide traffic characteristics, which differs 269 from respecting a 32 bit alignment. TFC is not mandatory and MUST be 270 negotiated with the SA management protocol. As a result, TFC is not 271 expected to be supported by a minimal ESP implementation. On the 272 other hand, disabling TFC should be carefully measured and understood 273 as it exposes the node to traffic shaping. This could expose the 274 application as well as the devices used to a passive monitoring 275 attacker. Such information could be used by the attacker in case a 276 vulnerability is disclosed on the specific device. In addition, some 277 application use - such as health applications - may also reveal 278 important privacy oriented informations. 280 Some constraint nodes that have limited battery life time may also 281 prefer avoiding sending extra padding bytes. However the same nodes 282 may also be very specific to an application and device. As a result, 283 they are also likely to be the main target for traffic shaping. In 284 most cases, the payload carried by these nodes is quite small, and 285 the standard padding mechanism may also be used as an alternative to 286 TFC, with a sufficient trade off between the require energy to send 287 additional payload and the exposure to traffic shaping attacks. 289 6. Next Header (8 bit) 291 According to [RFC4303], the Next Header is a mandatory 8 bits field 292 in the packet. Next header is intended to specify the data contained 293 in the payload as well as dummy packet. In addition, the Next Header 294 may also carry an indication on how to process the packet 295 [I-D.nikander-esp-beet-mode]. 297 The ability to generate and receive dummy packet is required by 298 [RFC4303]. For interoperability, it is RECOMMENDED a minimal ESP 299 implementation discards dummy packets. Note that such recommendation 300 only applies for nodes receiving packets, and that nodes designed to 301 only send data may not implement this capability. 303 As the generation of dummy packets is subject to local management and 304 based on a per-SA basis, a minimal ESP implementation may not 305 generate such dummy packet. More especially, in constraint 306 environment sending dummy packets may have too much impact on the 307 device life time, and so may be avoided. On the other hand, 308 constraint nodes may be dedicated to specific applications, in which 309 case, traffic pattern may expose the application or the type of node. 310 For these nodes, not sending dummy packet may have some privacy 311 implication that needs to be measured. 313 In some cases, devices are dedicated to a single application or a 314 single transport protocol, in which case, the Next Header has a fix 315 value. 317 Specific processing indications have not been standardized yet 318 [I-D.nikander-esp-beet-mode] and is expected to result from an 319 agreement between the peers. As a result, it is not expected to be 320 part of a minimal implementation of ESP. 322 [RFC4303] mentions : 324 :: "The Next Header is a mandatory, 8-bit field that identifies 325 the type of data contained in the Payload Data field, e.g., an 326 IPv4 or IPv6 packet, or a next layer header and data. [...] the 327 protocol value 59 (which means "no next header") MUST be used to 328 designate a "dummy" packet. A transmitter MUST be capable of 329 generating dummy packets marked with this value in the next 330 protocol field, and a receiver MUST be prepared to discard such 331 packets, without indicating an error." 333 7. ICV 335 The ICV depends on the crypto-suite used. Currently recommended 336 [I-D.ietf-ipsecme-rfc7321bis] only recommend crypto-suites with an 337 ICV which makes the ICV a mandatory field. 339 As detailed in Section 8 we recommend to use authentication, the ICV 340 field is expected to be present that is to say with a size different 341 from zero. This makes it a mandatory field which size is defined by 342 the security recommendations only. 344 [RFC4303] mentions : 346 :: "The Integrity Check Value is a variable-length field computed 347 over the ESP header, Payload, and ESP trailer fields. Implicit 348 ESP trailer fields (integrity padding and high-order ESN bits, if 349 applicable) are included in the ICV computation. The ICV field is 350 optional. It is present only if the integrity service is selected 351 and is provided by either a separate integrity algorithm or a 352 combined mode algorithm that uses an ICV. The length of the field 353 is specified by the integrity algorithm selected and associated 354 with the SA. The integrity algorithm specification MUST specify 355 the length of the ICV and the comparison rules and processing 356 steps for validation." 358 8. Cryptographic Suites 360 The cryptographic suites implemented are an important component of 361 ESP. The recommended suites to use are expect to evolve over time 362 and implementer SHOULD follow the recommendations provided by 363 [I-D.ietf-ipsecme-rfc7321bis] and updates. Recommendations are 364 provided for standard nodes as well as constraint nodes. 366 This section lists some of the criteria that may be considered. The 367 list is not expected to be exhaustive and may also evolve overtime. 368 As a result, the list is provided as indicative: 370 1. Security: Security is the criteria that should be considered 371 first when a selection of cipher suites is performed. The 372 security of cipher suites is expected to evolve over time, and it 373 is of primary importance to follow up-to-date security guidances 374 and recommendations. The chosen cipher suites MUST NOT be known 375 vulnerable or weak (see [I-D.ietf-ipsecme-rfc7321bis] for 376 outdated ciphers). ESP can be used to authenticate only or to 377 encrypt the communication. In the later case, authenticated 378 encryption must always be considered 379 [I-D.ietf-ipsecme-rfc7321bis]. 381 2. Interoperability: Interoperability considers the cipher suites 382 shared with the other nodes. Note that it is not because a 383 cipher suite is widely deployed that is secured. As a result, 384 security SHOULD NOT be weaken for interoperability. 385 [I-D.ietf-ipsecme-rfc7321bis] and successors consider the life 386 cycle of cipher suites sufficiently long to provide 387 interoperability. Constraint devices may have limited 388 interoperability requirements which makes possible to reduces the 389 number of cipher suites to implement. 391 3. Power Consumption and Cipher Suite Complexity: Complexity of the 392 cipher suite or the energy associated to it are especially 393 considered when devices have limited resources or are using some 394 batteries, in which case the battery determines the life of the 395 device. The choice of a cryptographic function may consider re- 396 using specific libraries or to take advantage of hardware 397 acceleration provided by the device. For example if the device 398 benefits from AES hardware modules and uses AES-CTR, it may 399 prefer AUTH_AES-XCBC for its authentication. In addition, some 400 devices may also embed radio modules with hardware acceleration 401 for AES-CCM, in which case, this mode may be preferred. 403 4. Power Consumption and Bandwidth Consumption: Similarly to the 404 cipher suite complexity, reducing the payload sent, may 405 significantly reduce the energy consumption of the device. As a 406 result, cipher suites with low overhead may be considered. To 407 reduce the overall payload size one may for example, one MAY 408 consider: 410 1. Use of counter-based ciphers without fixed block length (e.g. 411 AES-CTR, or ChaCha20-Poly1305). 413 2. Use of ciphers with capability of using implicit IVs 414 [I-D.mglt-ipsecme-implicit-iv]. 416 3. Use of ciphers recommended for IoT 417 [I-D.ietf-ipsecme-rfc7321bis]. 419 4. Avoid Padding by sending payload data which are aligned to 420 the cipher block length -2 for the ESP trailer. 422 9. IANA Considerations 424 There are no IANA consideration for this document. 426 10. Security Considerations 428 Security considerations are those of [RFC4303]. In addition, this 429 document provided security recommendations an guidances over the 430 implementation choices for each fields. 432 11. Acknowledgment 434 The authors would like to thank Scott Fluhrer, Tero Kivinen, Valery 435 Smyslov, Yoav Nir, Michael Richardson for their valuable comments. 437 12. References 439 12.1. Normative References 441 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 442 Requirement Levels", BCP 14, RFC 2119, 443 DOI 10.17487/RFC2119, March 1997, 444 . 446 [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher 447 Algorithm and Its Use with IPsec", RFC 3602, 448 DOI 10.17487/RFC3602, September 2003, 449 . 451 [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) 452 Counter Mode With IPsec Encapsulating Security Payload 453 (ESP)", RFC 3686, DOI 10.17487/RFC3686, January 2004, 454 . 456 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 457 (GCM) in IPsec Encapsulating Security Payload (ESP)", 458 RFC 4106, DOI 10.17487/RFC4106, June 2005, 459 . 461 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 462 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 463 December 2005, . 465 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 466 RFC 4303, DOI 10.17487/RFC4303, December 2005, 467 . 469 [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM 470 Mode with IPsec Encapsulating Security Payload (ESP)", 471 RFC 4309, DOI 10.17487/RFC4309, December 2005, 472 . 474 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 475 Kivinen, "Internet Key Exchange Protocol Version 2 476 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 477 2014, . 479 [RFC7815] Kivinen, T., "Minimal Internet Key Exchange Version 2 480 (IKEv2) Initiator Implementation", RFC 7815, 481 DOI 10.17487/RFC7815, March 2016, 482 . 484 12.2. Informative References 486 [I-D.ietf-ipsecme-rfc7321bis] 487 Migault, D., Mattsson, J., Wouters, P., Nir, Y., and T. 488 Kivinen, "Cryptographic Algorithm Implementation 489 Requirements and Usage Guidance for Encapsulating Security 490 Payload (ESP) and Authentication Header (AH)", draft-ietf- 491 ipsecme-rfc7321bis-05 (work in progress), February 2017. 493 [I-D.mglt-ipsecme-implicit-iv] 494 Migault, D., Guggemos, T., and Y. Nir, "Implicit IV for 495 Counter-based Ciphers in IPsec", draft-mglt-ipsecme- 496 implicit-iv-02 (work in progress), November 2016. 498 [I-D.nikander-esp-beet-mode] 499 NikanderMelen, PJ., "A Bound End-to-End Tunnel (BEET) mode 500 for ESP", draft-nikander-esp-beet-mode-09 (work in 501 progress), February 2017. 503 Appendix A. Document Change Log 505 [RFC Editor: This section is to be removed before publication] 507 -00: First version published. 509 -01: Clarified description 511 -02: Clarified description 513 Authors' Addresses 515 Daniel Migault 516 Ericsson 517 8400 boulevard Decarie 518 Montreal, QC H4P 2N2 519 Canada 521 Email: daniel.migault@ericsson.com 523 Tobias Guggemos 524 LMU Munich 525 MNM-Team 526 Oettingenstr. 67 527 80538 Munich, Bavaria 528 Germany 530 Email: guggemos@mnm-team.org