idnits 2.17.1 draft-ietf-hip-rfc5202-bis-07.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 (September 5, 2014) is 3513 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) == Unused Reference: 'RFC5226' is defined on line 1353, but no explicit reference was found in the text == Outdated reference: A later version (-20) exists of draft-ietf-hip-rfc5201-bis-14 ** Downref: Normative reference to an Informational RFC: RFC 4493 == Outdated reference: A later version (-20) exists of draft-ietf-hip-rfc4423-bis-08 -- Obsolete informational reference (is this intentional?): RFC 5202 (Obsoleted by RFC 7402) -- Obsolete informational reference (is this intentional?): RFC 5206 (Obsoleted by RFC 8046) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Jokela 3 Internet-Draft Ericsson Research NomadicLab 4 Obsoletes: 5202 (if approved) R. Moskowitz 5 Intended status: Standards Track Verizon 6 Expires: March 9, 2015 J. Melen 7 Ericsson Research NomadicLab 8 September 5, 2014 10 Using the Encapsulating Security Payload (ESP) Transport Format with the 11 Host Identity Protocol (HIP) 12 draft-ietf-hip-rfc5202-bis-07 14 Abstract 16 This memo specifies an Encapsulated Security Payload (ESP) based 17 mechanism for transmission of user data packets, to be used with the 18 Host Identity Protocol (HIP). This document obsoletes RFC 5202. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on March 9, 2015. 37 Copyright Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 56 3. Using ESP with HIP . . . . . . . . . . . . . . . . . . . . . 4 57 3.1. ESP Packet Format . . . . . . . . . . . . . . . . . . . . 5 58 3.2. Conceptual ESP Packet Processing . . . . . . . . . . . . 5 59 3.2.1. Semantics of the Security Parameter Index (SPI) . . . 6 60 3.3. Security Association Establishment and Maintenance . . . 6 61 3.3.1. ESP Security Associations . . . . . . . . . . . . . . 6 62 3.3.2. Rekeying . . . . . . . . . . . . . . . . . . . . . . 7 63 3.3.3. Security Association Management . . . . . . . . . . . 8 64 3.3.4. Security Parameter Index (SPI) . . . . . . . . . . . 8 65 3.3.5. Supported Ciphers . . . . . . . . . . . . . . . . . . 8 66 3.3.6. Sequence Number . . . . . . . . . . . . . . . . . . . 9 67 3.3.7. Lifetimes and Timers . . . . . . . . . . . . . . . . 9 68 3.4. IPsec and HIP ESP Implementation Considerations . . . . . 9 69 3.4.1. Data Packet Processing Considerations . . . . . . . . 9 70 3.4.2. HIP Signaling Packet Considerations . . . . . . . . . 10 71 4. The Protocol . . . . . . . . . . . . . . . . . . . . . . . . 10 72 4.1. ESP in HIP . . . . . . . . . . . . . . . . . . . . . . . 11 73 4.1.1. IPsec ESP Transport Format Type . . . . . . . . . . . 11 74 4.1.2. Setting Up an ESP Security Association . . . . . . . 11 75 4.1.3. Updating an Existing ESP SA . . . . . . . . . . . . . 12 76 5. Parameter and Packet Formats . . . . . . . . . . . . . . . . 13 77 5.1. New Parameters . . . . . . . . . . . . . . . . . . . . . 13 78 5.1.1. ESP_INFO . . . . . . . . . . . . . . . . . . . . . . 13 79 5.1.2. ESP_TRANSFORM . . . . . . . . . . . . . . . . . . . . 14 80 5.1.3. NOTIFICATION Parameter . . . . . . . . . . . . . . . 16 81 5.2. HIP ESP Security Association Setup . . . . . . . . . . . 16 82 5.2.1. Setup During Base Exchange . . . . . . . . . . . . . 16 83 5.3. HIP ESP Rekeying . . . . . . . . . . . . . . . . . . . . 18 84 5.3.1. Initializing Rekeying . . . . . . . . . . . . . . . . 18 85 5.3.2. Responding to the Rekeying Initialization . . . . . . 19 86 5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 19 87 5.4.1. Unknown SPI . . . . . . . . . . . . . . . . . . . . . 19 88 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 20 89 6.1. Processing Outgoing Application Data . . . . . . . . . . 20 90 6.2. Processing Incoming Application Data . . . . . . . . . . 20 91 6.3. HMAC and SIGNATURE Calculation and Verification . . . . . 21 92 6.4. Processing Incoming ESP SA Initialization (R1) . . . . . 21 93 6.5. Processing Incoming Initialization Reply (I2) . . . . . . 22 94 6.6. Processing Incoming ESP SA Setup Finalization (R2) . . . 22 95 6.7. Dropping HIP Associations . . . . . . . . . . . . . . . . 22 96 6.8. Initiating ESP SA Rekeying . . . . . . . . . . . . . . . 22 97 6.9. Processing Incoming UPDATE Packets . . . . . . . . . . . 24 98 6.9.1. Processing UPDATE Packet: No Outstanding 99 Rekeying Request . . . . . . . . . . . . . . . . . . 24 100 6.10. Finalizing Rekeying . . . . . . . . . . . . . . . . . . . 25 101 6.11. Processing NOTIFY Packets . . . . . . . . . . . . . . . . 26 102 7. Keying Material . . . . . . . . . . . . . . . . . . . . . . . 26 103 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 104 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 105 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 106 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 107 11.1. Normative references . . . . . . . . . . . . . . . . . . 28 108 11.2. Informative references . . . . . . . . . . . . . . . . . 29 109 Appendix A. A Note on Implementation Options . . . . . . . . . . 31 110 Appendix B. Bound End-to-End Tunnel mode for ESP . . . . . . . . 31 111 B.1. Protocol definition . . . . . . . . . . . . . . . . . . . 32 112 B.1.1. Changes to Security Association data structures . . . 32 113 B.1.2. Packet format . . . . . . . . . . . . . . . . . . . . 32 114 B.1.3. Cryptographic processing . . . . . . . . . . . . . . 34 115 B.1.4. IP header processing . . . . . . . . . . . 34 116 B.1.5. Handling of outgoing packets . . . . . . . . . . . . 35 117 B.1.6. Handling of incoming packets . . . . . . . . . . . . 36 118 B.1.7. IPv4 options handling . . . . . . . . . . . . . . . . 36 120 1. Introduction 122 In the Host Identity Protocol Architecture 123 [I-D.ietf-hip-rfc4423-bis], hosts are identified with public keys. 124 The Host Identity Protocol [I-D.ietf-hip-rfc5201-bis] base exchange 125 allows any two HIP-supporting hosts to authenticate each other and to 126 create a HIP association between themselves. During the base 127 exchange, the hosts generate a piece of shared keying material using 128 an authenticated Diffie-Hellman exchange. 130 The HIP base exchange specification [I-D.ietf-hip-rfc5201-bis] does 131 not describe any transport formats or methods for user data to be 132 used during the actual communication; it only defines that it is 133 mandatory to implement the Encapsulated Security Payload (ESP) 134 [RFC4303] based transport format and method. This document specifies 135 how ESP is used with HIP to carry actual user data. 137 To be more specific, this document specifies a set of HIP protocol 138 extensions and their handling. Using these extensions, a pair of ESP 139 Security Associations (SAs) is created between the hosts during the 140 base exchange. The resulting ESP Security Associations use keys 141 drawn from the keying material (KEYMAT) generated during the base 142 exchange. After the HIP association and required ESP SAs have been 143 established between the hosts, the user data communication is 144 protected using ESP. In addition, this document specifies methods to 145 update an existing ESP Security Association. 147 It should be noted that representations of Host Identity are not 148 carried explicitly in the headers of user data packets. Instead, the 149 ESP Security Parameter Index (SPI) is used to indicate the right host 150 context. The SPIs are selected during the HIP ESP setup exchange. 151 For user data packets, ESP SPIs (in possible combination with IP 152 addresses) are used indirectly to identify the host context, thereby 153 avoiding any additional explicit protocol headers. 155 HIP and ESP traffic have known issues with middlebox traversal RFC 156 5207 [RFC5207]. Other specifications exist for operating HIP and ESP 157 over UDP (RFC 5770 [RFC5770] is an experimental specification, and 158 others are being developed). Middlebox traversal is out of scope for 159 this document. 161 This document obsoletes RFC 5202. 163 2. Conventions Used in This Document 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 167 document are to be interpreted as described in RFC 2119 [RFC2119]. 169 3. Using ESP with HIP 171 The HIP base exchange is used to set up a HIP association between two 172 hosts. The base exchange provides two-way host authentication and 173 key material generation, but it does not provide any means for 174 protecting data communication between the hosts. In this document, 175 we specify the use of ESP for protecting user data traffic after the 176 HIP base exchange. Note that this use of ESP is intended only for 177 host-to-host traffic; security gateways are not supported. 179 To support ESP use, the HIP base exchange messages require some minor 180 additions to the parameters transported. In the R1 packet, the 181 Responder adds the possible ESP transforms in an ESP_TRANSFORM 182 parameter before sending it to the Initiator. The Initiator gets the 183 proposed transforms, selects one of those proposed transforms, and 184 adds it to the I2 packet in an ESP_TRANSFORM parameter. In this I2 185 packet, the Initiator also sends the SPI value that it wants to be 186 used for ESP traffic flowing from the Responder to the Initiator. 187 This information is carried using the ESP_INFO parameter. When 188 finalizing the ESP SA setup, the Responder sends its SPI value to the 189 Initiator in the R2 packet, again using ESP_INFO. 191 3.1. ESP Packet Format 193 The ESP specification [RFC4303] defines the ESP packet format for 194 IPsec. The HIP ESP packet looks exactly the same as the IPsec ESP 195 transport format packet. The semantics, however, are a bit different 196 and are described in more detail in the next subsection. 198 3.2. Conceptual ESP Packet Processing 200 ESP packet processing can be implemented in different ways in HIP. 201 It is possible to implement it in a way that a standards compliant, 202 unmodified IPsec implementation [RFC4303] can be used in conjunction 203 with some additional transport checksum processing above it, and if 204 IP addresses are used as indexes to the right host context. 206 When a standards compliant IPsec implementation that uses IP 207 addresses in the SPD and Security Association Database (SAD) is used, 208 the packet processing may take the following steps. For outgoing 209 packets, assuming that the upper-layer pseudoheader has been built 210 using IP addresses, the implementation recalculates upper-layer 211 checksums using Host Identity Tags (HITs) and, after that, changes 212 the packet source and destination addresses back to corresponding IP 213 addresses. The packet is sent to the IPsec ESP for transport mode 214 handling and from there the encrypted packet is sent to the network. 215 When an ESP packet is received, the packet is first put to the IPsec 216 ESP transport mode handling, and after decryption, the source and 217 destination IP addresses are replaced with HITs and finally, upper- 218 layer checksums are verified before passing the packet to the upper 219 layer. 221 An alternative way to implement packet processing is the BEET (Bound 222 End-to-End Tunnel) mode (see Appendix B). In BEET mode, the ESP 223 packet is formatted as a transport mode packet, but the semantics of 224 the connection are the same as for tunnel mode. The "outer" 225 addresses of the packet are the IP addresses and the "inner" 226 addresses are the HITs. For outgoing traffic, after the packet has 227 been encrypted, the packet's IP header is changed to a new one that 228 contains IP addresses instead of HITs, and the packet is sent to the 229 network. When the ESP packet is received, the SPI value, together 230 with the integrity protection, allow the packet to be securely 231 associated with the right HIT pair. The packet header is replaced 232 with a new header containing HITs, and the packet is decrypted. BEET 233 mode is completely internal for host and doesn't require that the 234 corresponding host implements it, instead the corresponding host can 235 have ESP transport mode and do HIT IP conversions outside ESP. 237 3.2.1. Semantics of the Security Parameter Index (SPI) 239 SPIs are used in ESP to find the right Security Association for 240 received packets. The ESP SPIs have added significance when used 241 with HIP; they are a compressed representation of a pair of HITs. 242 Thus, SPIs MAY be used by intermediary systems in providing services 243 like address mapping. Note that since the SPI has significance at 244 the receiver, only the ?< DST, SPI >?, where DST is a destination IP 245 address, uniquely identifies the receiver HIT at any given point of 246 time. The same SPI value may be used by several hosts. A single ?< 247 DST, SPI >? value may denote different hosts and contexts at 248 different points of time, depending on the host that is currently 249 reachable at the DST. 251 Each host selects for itself the SPI it wants to see in packets 252 received from its peer. This allows it to select different SPIs for 253 different peers. The SPI selection SHOULD be random; the rules of 254 Section 2.1 of the ESP specification [RFC4303] must be followed. A 255 different SPI SHOULD be used for each HIP exchange with a particular 256 host; this is to avoid a replay attack. Additionally, when a host 257 rekeys, the SPI MUST be changed. Furthermore, if a host changes over 258 to use a different IP address, it MAY change the SPI. 260 One method for SPI creation that meets the above criteria would be to 261 concatenate the HIT with a 32-bit random or sequential number, hash 262 this (using SHA1), and then use the high-order 32 bits as the SPI. 264 The selected SPI is communicated to the peer in the third (I2) and 265 fourth (R2) packets of the base HIP exchange. Changes in SPI are 266 signaled with ESP_INFO parameters. 268 3.3. Security Association Establishment and Maintenance 270 3.3.1. ESP Security Associations 272 In HIP, ESP Security Associations are setup between the HIP nodes 273 during the base exchange [I-D.ietf-hip-rfc5201-bis]. Existing ESP 274 SAs can be updated later using UPDATE messages. The reason for 275 updating the ESP SA later can be, for example, a need for rekeying 276 the SA because of sequence number rollover. 278 Upon setting up a HIP association, each association is linked to two 279 ESP SAs, one for incoming packets and one for outgoing packets. The 280 Initiator's incoming SA corresponds with the Responder's outgoing 281 one, and vice versa. The Initiator defines the SPI for its incoming 282 association, as defined in Section 3.2.1. This SA is herein called 283 SA-RI, and the corresponding SPI is called SPI-RI. Respectively, the 284 Responder's incoming SA corresponds with the Initiator's outgoing SA 285 and is called SA-IR, with the SPI being called SPI-IR. 287 The Initiator creates SA-RI as a part of R1 processing, before 288 sending out the I2, as explained in Section 6.4. The keys are 289 derived from KEYMAT, as defined in Section 7. The Responder creates 290 SA-RI as a part of I2 processing; see Section 6.5. 292 The Responder creates SA-IR as a part of I2 processing, before 293 sending out R2; see Section 6.5. The Initiator creates SA-IR when 294 processing R2; see Section 6.6. 296 The initial session keys are drawn from the generated keying 297 material, KEYMAT, after the HIP keys have been drawn as specified in 298 [I-D.ietf-hip-rfc5201-bis]. 300 When the HIP association is removed, the related ESP SAs MUST also be 301 removed. 303 3.3.2. Rekeying 305 After the initial HIP base exchange and SA establishment, both hosts 306 are in the ESTABLISHED state. There are no longer Initiator and 307 Responder roles and the association is symmetric. In this 308 subsection, the party that initiates the rekey procedure is denoted 309 with I' and the peer with R'. 311 An existing HIP-created ESP SA may need updating during the lifetime 312 of the HIP association. This document specifies the rekeying of an 313 existing HIP-created ESP SA, using the UPDATE message. The ESP_INFO 314 parameter introduced above is used for this purpose. 316 I' initiates the ESP SA updating process when needed (see 317 Section 6.8). It creates an UPDATE packet with required information 318 and sends it to the peer node. The old SAs are still in use, local 319 policy permitting. 321 R', after receiving and processing the UPDATE (see Section 6.9), 322 generates new SAs: SA-I'R' and SA-R'I'. It does not take the new 323 outgoing SA into use, but still uses the old one, so there 324 temporarily exists two SA pairs towards the same peer host. The SPI 325 for the new outgoing SA, SPI-R'I', is specified in the received 326 ESP_INFO parameter in the UPDATE packet. For the new incoming SA, R' 327 generates the new SPI value, SPI-I'R', and includes it in the 328 response UPDATE packet. 330 When I' receives a response UPDATE from R', it generates new SAs, as 331 described in Section 6.9: SA-I'R' and SA-R'I'. It starts using the 332 new outgoing SA immediately. 334 R' starts using the new outgoing SA when it receives traffic on the 335 new incoming SA or when it receives the UPDATE ACK confirming 336 completion of rekeying. After this, R' can remove the old SAs. 337 Similarly, when the I' receives traffic from the new incoming SA, it 338 can safely remove the old SAs. 340 3.3.3. Security Association Management 342 An SA pair is indexed by the 2 SPIs and 2 HITs (both local and remote 343 HITs since a system can have more than one HIT). An inactivity timer 344 is RECOMMENDED for all SAs. If the state dictates the deletion of an 345 SA, a timer is set to allow for any late arriving packets. 347 3.3.4. Security Parameter Index (SPI) 349 The SPIs in ESP provide a simple compression of the HIP data from all 350 packets after the HIP exchange. This does require a per HIT-pair 351 Security Association (and SPI), and a decrease of policy granularity 352 over other Key Management Protocols like Internet Key Exchange (IKE) 353 [RFC5996]. 355 When a host updates the ESP SA, it provides a new inbound SPI to and 356 gets a new outbound SPI from its peer. 358 3.3.5. Supported Ciphers 360 All HIP implementations MUST support AES-128-CBC and AES-256-CBC 361 [RFC3602]. If the Initiator does not support any of the transforms 362 offered by the Responder, it should abandon the negotiation and 363 inform the peer with a NOTIFY message about a non-supported 364 transform. 366 In addition to AES-128-CBC, all implementations SHOULD implement the 367 ESP NULL encryption algorithm. When the ESP NULL encryption is used, 368 it MUST be used together with SHA-256 authentication as specified in 369 Section 5.1.2 371 When an authentication-only suite is used (NULL, AES-CMAC-96, and 372 AES-GMAC are examples), the suite MUST NOT be accepted if offered by 373 the peer unless the local policy configuration regarding the peer 374 host is explicitly set to allow an authentication-only mode. This is 375 to prevent sessions from being downgraded to an authentication-only 376 mode when one side's policy requests privacy for the session. 378 3.3.6. Sequence Number 380 The Sequence Number field is MANDATORY when ESP is used with HIP. 381 Anti-replay protection MUST be used in an ESP SA established with 382 HIP. When ESP is used with HIP, a 64-bit sequence number MUST be 383 used. This means that each host MUST rekey before its sequence 384 number reaches 2^64. 386 When using a 64-bit sequence number, the higher 32 bits are NOT 387 included in the ESP header, but are simply kept local to both peers. 388 See [RFC4301]. 390 3.3.7. Lifetimes and Timers 392 HIP does not negotiate any lifetimes. All ESP lifetimes are local 393 policy. The only lifetimes a HIP implementation MUST support are 394 sequence number rollover (for replay protection), and SHOULD support 395 timing out inactive ESP SAs. An SA times out if no packets are 396 received using that SA. Implementations SHOULD support a 397 configurable SA timeout value. Implementations MAY support lifetimes 398 for the various ESP transforms. Each implementation SHOULD implement 399 per-HIT configuration of the inactivity timeout, allowing statically 400 configured HIP associations to stay alive for days, even when 401 inactive. 403 3.4. IPsec and HIP ESP Implementation Considerations 405 When HIP is run on a node where a standards compliant IPsec is used, 406 some issues have to be considered. 408 The HIP implementation must be able to co-exist with other IPsec 409 keying protocols. When the HIP implementation selects the SPI value, 410 it may lead to a collision if not implemented properly. To avoid the 411 possibility for a collision, the HIP implementation MUST ensure that 412 the SPI values used for HIP SAs are not used for IPsec or other SAs, 413 and vice versa. 415 Incoming packets using an SA that is not negotiated by HIP MUST NOT 416 be processed as described in Section 3.2, paragraph 2. The SPI will 417 identify the correct SA for packet decryption and MUST be used to 418 identify that the packet has an upper-layer checksum that is 419 calculated as specified in [I-D.ietf-hip-rfc5201-bis]. 421 3.4.1. Data Packet Processing Considerations 423 For outbound traffic, the SPD or (coordinated) SPDs if there are two 424 (one for HIP and one for IPsec) MUST ensure that packets intended for 425 HIP processing are given a HIP-enabled SA and that packets intended 426 for IPsec processing are given an IPsec-enabled SA. The SP then MUST 427 be bound to the matching SA and non-HIP packets will not be processed 428 by this SA. Data originating from a socket that is not using HIP 429 MUST NOT have checksum recalculated (as described in Section 3.2, 430 paragraph 2) and data MUST NOT be passed to the SP or SA created by 431 the HIP. 433 It is possible that in case of overlapping policies, the outgoing 434 packet would be handled both by the IPsec and HIP. In this case, it 435 is possible that the HIP association is end-to-end, while the IPsec 436 SA is for encryption between the HIP host and a Security Gateway. In 437 case of a Security Gateway ESP association, the ESP uses always 438 tunnel mode. 440 In case of IPsec tunnel mode, it is hard to see during the HIP SA 441 processing if the IPsec ESP SA has the same final destination. Thus, 442 traffic MUST be encrypted both with the HIP ESP SA and with the IPsec 443 SA when the IPsec ESP SA is used in tunnel mode. 445 In case of IPsec transport mode, the connection end-points are the 446 same. However, for HIP data packets it is not possible to avoid HIP 447 SA processing, while mapping the HIP data packet's IP addresses to 448 the corresponding HITs requires SPI values from the ESP header. In 449 case of transport mode IPsec SA, the IPsec encryption MAY be skipped 450 to avoid double encryption, if the local policy allows. 452 3.4.2. HIP Signaling Packet Considerations 454 In general, HIP signaling packets should follow the same processing 455 as HIP data packets. 457 In case of IPsec tunnel mode, the HIP signaling packets are always 458 encrypted using IPsec ESP SA. Note, that this hides the HIP 459 signaling packets from the eventual HIP middle boxes on the path 460 between the originating host and the Security Gateway. 462 In case of IPsec transport mode, the HIP signaling packets MAY skip 463 the IPsec ESP SA encryption if the local policy allows. This allows 464 the eventual HIP middle boxes to handle the passing HIP signaling 465 packets. 467 4. The Protocol 469 In this section, the protocol for setting up an ESP association to be 470 used with HIP association is described. 472 4.1. ESP in HIP 474 4.1.1. IPsec ESP Transport Format Type 476 The HIP handshake signals the TRANSPORT_FORMAT_LIST parameter in the 477 R1 and I2 messages. This parameter contains a list of the supported 478 HIP transport formats of the sending host in the order of preference. 479 The transport format type for IPsec ESP is the type number of the 480 ESP_TRANSFORM parameter, i.e., 4095. 482 4.1.2. Setting Up an ESP Security Association 484 Setting up an ESP Security Association between hosts using HIP 485 consists of three messages passed between the hosts. The parameters 486 are included in R1, I2, and R2 messages during base exchange. 488 Initiator Responder 490 I1 491 ----------------------------------> 493 R1: ESP_TRANSFORM 494 <---------------------------------- 496 I2: ESP_TRANSFORM, ESP_INFO 497 ----------------------------------> 499 R2: ESP_INFO 500 <---------------------------------- 502 Setting up an ESP Security Association between HIP hosts requires 503 three messages to exchange the information that is required during an 504 ESP communication. 506 The R1 message contains the ESP_TRANSFORM parameter, in which the 507 sending host defines the possible ESP transforms it is willing to use 508 for the ESP SA. 510 Including the ESP_TRANSFORM parameter in the R1 message adds clarity 511 to the TRANSPORT_FORMAT_LIST, but may initiate negotiations for 512 possibly unselected transforms. However, resource-constrained 513 devices will most likely restrict support to a single transform for 514 the sake of minimizing ROM overhead and the additional parameter adds 515 negligible overhead with unconstrained devices. 517 The I2 message contains the response to an ESP_TRANSFORM received in 518 the R1 message. The sender must select one of the proposed ESP 519 transforms from the ESP_TRANSFORM parameter in the R1 message and 520 include the selected one in the ESP_TRANSFORM parameter in the I2 521 packet. In addition to the transform, the host includes the ESP_INFO 522 parameter containing the SPI value to be used by the peer host. 524 In the R2 message, the ESP SA setup is finalized. The packet 525 contains the SPI information required by the Initiator for the ESP 526 SA. 528 4.1.3. Updating an Existing ESP SA 530 The update process is accomplished using two messages. The HIP 531 UPDATE message is used to update the parameters of an existing ESP 532 SA. The UPDATE mechanism and message is defined in 533 [I-D.ietf-hip-rfc5201-bis], and the additional parameters for 534 updating an existing ESP SA are described here. 536 The following picture shows a typical exchange when an existing ESP 537 SA is updated. Messages include SEQ and ACK parameters required by 538 the UPDATE mechanism. 540 H1 H2 541 UPDATE: SEQ, ESP_INFO [, DIFFIE_HELLMAN] 542 -----------------------------------------------------> 544 UPDATE: SEQ, ACK, ESP_INFO [, DIFFIE_HELLMAN] 545 <----------------------------------------------------- 547 UPDATE: ACK 548 -----------------------------------------------------> 550 The host willing to update the ESP SA creates and sends an UPDATE 551 message. The message contains the ESP_INFO parameter containing the 552 old SPI value that was used, the new SPI value to be used, and the 553 index value for the keying material, giving the point from where the 554 next keys will be drawn. If new keying material must be generated, 555 the UPDATE message will also contain the DIFFIE_HELLMAN parameter 556 defined in [I-D.ietf-hip-rfc5201-bis]. 558 The host receiving the UPDATE message requesting update of an 559 existing ESP SA MUST reply with an UPDATE message. In the reply 560 message, the host sends the ESP_INFO parameter containing the 561 corresponding values: old SPI, new SPI, and the keying material 562 index. If the incoming UPDATE contained a DIFFIE_HELLMAN parameter, 563 the reply packet MUST also contain a DIFFIE_HELLMAN parameter. 565 5. Parameter and Packet Formats 567 In this section, new and modified HIP parameters are presented, as 568 well as modified HIP packets. 570 5.1. New Parameters 572 Two new HIP parameters are defined for setting up ESP transport 573 format associations in HIP communication and for rekeying existing 574 ones. Also, the NOTIFICATION parameter, described in 575 [I-D.ietf-hip-rfc5201-bis], has two new error parameters. 577 Parameter Type Length Data 579 ESP_INFO 65 12 Remote's old SPI, 580 new SPI, and other info 581 ESP_TRANSFORM 4095 variable ESP Encryption and 582 Authentication Transform(s) 584 5.1.1. ESP_INFO 586 During the establishment and update of an ESP SA, the SPI value of 587 both hosts must be transmitted between the hosts. In addition, hosts 588 need the index value to the KEYMAT when they are drawing keys from 589 the generated keying material. The ESP_INFO parameter is used to 590 transmit the SPI values and the KEYMAT index information between the 591 hosts. 593 During the initial ESP SA setup, the hosts send the SPI value that 594 they want the peer to use when sending ESP data to them. The value 595 is set in the NEW SPI field of the ESP_INFO parameter. In the 596 initial setup, an old value for the SPI does not exist, thus the OLD 597 SPI value field is set to zero. The OLD SPI field value may also be 598 zero when additional SAs are set up between HIP hosts, e.g., in case 599 of multihomed HIP hosts [RFC5206]. However, such use is beyond the 600 scope of this specification. 602 The KEYMAT index value points to the place in the KEYMAT from where 603 the keying material for the ESP SAs is drawn. The KEYMAT index value 604 is zero only when the ESP_INFO is sent during a rekeying process and 605 new keying material is generated. 607 During the life of an SA established by HIP, one of the hosts may 608 need to reset the Sequence Number to one and rekey. The reason for 609 rekeying might be an approaching sequence number wrap in ESP, or a 610 local policy on use of a key. Rekeying ends the current SAs and 611 starts new ones on both peers. 613 During the rekeying process, the ESP_INFO parameter is used to 614 transmit the changed SPI values and the keying material index. 616 0 1 2 3 617 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 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | Type | Length | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | Reserved | KEYMAT Index | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | OLD SPI | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | NEW SPI | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 Type 65 629 Length 12 630 KEYMAT Index Index, in bytes, where to continue to draw ESP keys 631 from KEYMAT. If the packet includes a new 632 Diffie-Hellman key and the ESP_INFO is sent in an 633 UPDATE packet, the field MUST be zero. If the 634 ESP_INFO is included in base exchange messages, the 635 KEYMAT Index must have the index value of the point 636 from where the ESP SA keys are drawn. Note that 637 the length of this field limits the amount of 638 keying material that can be drawn from KEYMAT. If 639 that amount is exceeded, the packet MUST contain 640 a new Diffie-Hellman key. 641 OLD SPI old SPI for data sent to address(es) associated 642 with this SA. If this is an initial SA setup, the 643 OLD SPI value is zero. 644 NEW SPI new SPI for data sent to address(es) associated 645 with this SA. 647 5.1.2. ESP_TRANSFORM 649 The ESP_TRANSFORM parameter is used during ESP SA establishment. The 650 first party sends a selection of transform families in the 651 ESP_TRANSFORM parameter, and the peer must select one of the proposed 652 values and include it in the response ESP_TRANSFORM parameter. 654 0 1 2 3 655 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 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | Type | Length | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | Reserved | Suite ID #1 | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | Suite ID #2 | Suite ID #3 | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | Suite ID #n | Padding | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 Type 4095 667 Length length in octets, excluding Type, Length, and 668 padding 669 Reserved zero when sent, ignored when received 670 Suite ID defines the ESP Suite to be used 672 The following Suite IDs can be used: 674 Suite ID Value 676 RESERVED 0 677 AES-128-CBC with HMAC-SHA1 1 [RFC3602], [RFC2404] 678 DEPRECATED 2 679 DEPRECATED 3 680 DEPRECATED 4 681 DEPRECATED 5 682 DEPRECATED 6 683 NULL with HMAC-SHA-256 7 [RFC2410], [RFC4868] 684 AES-128-CBC with HMAC-SHA-256 8 [RFC3602], [RFC4868] 685 AES-256-CBC with HMAC-SHA-256 9 [RFC3602], [RFC4868] 686 AES-CCM-8 10 [RFC4309] 687 AES-CCM-16 11 [RFC4309] 688 AES-GCM with a 8 octet ICV 12 [RFC4106] 689 AES-GCM with a 16 octet ICV 13 [RFC4106] 690 AES-CMAC-96 14 [RFC4493], [RFC4494] 691 AES-GMAC 15 [RFC4543] 693 The sender of an ESP transform parameter MUST make sure that there 694 are no more than six (6) Suite IDs in one ESP transform parameter. 695 Conversely, a recipient MUST be prepared to handle received transform 696 parameters that contain more than six Suite IDs. The limited number 697 of Suite IDs sets the maximum size of the ESP_TRANSFORM parameter. 698 As the default configuration, the ESP_TRANSFORM parameter MUST 699 contain at least one of the mandatory Suite IDs. There MAY be a 700 configuration option that allows the administrator to override this 701 default. 703 Mandatory implementations: AES-128-CBC with HMAC-SHA-256. NULL with 704 HMAC-SHA-256 SHOULD also be supported (see also Section 3.3.5). 706 Under some conditions, it is possible to use Traffic Flow 707 Confidentiality (TFC) [RFC4303] with ESP in BEET mode. However, the 708 definition of such operation is future work and must be done in a 709 separate specification. 711 5.1.3. NOTIFICATION Parameter 713 The HIP base specification defines a set of NOTIFICATION error types. 714 The following error types are required for describing errors in ESP 715 Transform crypto suites during negotiation. 717 NOTIFICATION PARAMETER - ERROR TYPES Value 718 ------------------------------------ ----- 720 NO_ESP_PROPOSAL_CHOSEN 18 722 None of the proposed ESP Transform crypto suites was 723 acceptable. 725 INVALID_ESP_TRANSFORM_CHOSEN 19 727 The ESP Transform crypto suite does not correspond to 728 one offered by the Responder. 730 5.2. HIP ESP Security Association Setup 732 The ESP Security Association is set up during the base exchange. The 733 following subsections define the ESP SA setup procedure using both 734 base exchange messages (R1, I2, R2) and UPDATE messages. 736 5.2.1. Setup During Base Exchange 738 5.2.1.1. Modifications in R1 740 The ESP_TRANSFORM contains the ESP modes supported by the sender, in 741 the order of preference. All implementations MUST support AES- 742 128-CBC [RFC3602] with HMAC-SHA-256 [RFC4868]. 744 The following figure shows the resulting R1 packet layout. 746 The HIP parameters for the R1 packet: 748 IP ( HIP ( [ R1_COUNTER, ] 749 PUZZLE, 750 DIFFIE_HELLMAN, 751 HIP_CIPHER, 752 ESP_TRANSFORM, 753 HOST_ID, 754 [ ECHO_REQUEST, ] 755 HIP_SIGNATURE_2 ) 756 [, ECHO_REQUEST ]) 758 5.2.1.2. Modifications in I2 760 The ESP_INFO contains the sender's SPI for this association as well 761 as the KEYMAT index from where the ESP SA keys will be drawn. The 762 old SPI value is set to zero. 764 The ESP_TRANSFORM contains the ESP mode selected by the sender of R1. 765 All implementations MUST support AES-128-CBC [RFC3602] with HMAC- 766 SHA-256 [RFC4868]. 768 The following figure shows the resulting I2 packet layout. 770 The HIP parameters for the I2 packet: 772 IP ( HIP ( ESP_INFO, 773 [R1_COUNTER,] 774 SOLUTION, 775 DIFFIE_HELLMAN, 776 HIP_CIPHER, 777 ESP_TRANSFORM, 778 ENCRYPTED { HOST_ID }, 779 [ ECHO_RESPONSE ,] 780 HMAC, 781 HIP_SIGNATURE 782 [, ECHO_RESPONSE] ) ) 784 5.2.1.3. Modifications in R2 786 The R2 contains an ESP_INFO parameter, which has the SPI value of the 787 sender of the R2 for this association. The ESP_INFO also has the 788 KEYMAT index value specifying where the ESP SA keys are drawn. 790 The following figure shows the resulting R2 packet layout. 792 The HIP parameters for the R2 packet: 794 IP ( HIP ( ESP_INFO, HMAC_2, HIP_SIGNATURE ) ) 796 5.3. HIP ESP Rekeying 798 In this section, the procedure for rekeying an existing ESP SA is 799 presented. 801 Conceptually, the process can be represented by the following message 802 sequence using the host names I' and R' defined in Section 3.3.2. 803 For simplicity, HMAC and HIP_SIGNATURE are not depicted, and 804 DIFFIE_HELLMAN keys are optional. The UPDATE with ACK_I need not be 805 piggybacked with the UPDATE with SEQ_R; it may be ACKed separately 806 (in which case the sequence would include four packets). 808 I' R' 810 UPDATE(ESP_INFO, SEQ_I, [DIFFIE_HELLMAN]) 811 -----------------------------------> 812 UPDATE(ESP_INFO, SEQ_R, ACK_I, [DIFFIE_HELLMAN]) 813 <----------------------------------- 814 UPDATE(ACK_R) 815 -----------------------------------> 817 Below, the first two packets in this figure are explained. 819 5.3.1. Initializing Rekeying 821 When HIP is used with ESP, the UPDATE packet is used to initiate 822 rekeying. The UPDATE packet MUST carry an ESP_INFO and MAY carry a 823 DIFFIE_HELLMAN parameter. 825 Intermediate systems that use the SPI will have to inspect HIP 826 packets for those that carry rekeying information. The packet is 827 signed for the benefit of the intermediate systems. Since 828 intermediate systems may need the new SPI values, the contents cannot 829 be encrypted. 831 The following figure shows the contents of a rekeying initialization 832 UPDATE packet. 834 The HIP parameters for the UPDATE packet initiating rekeying: 836 IP ( HIP ( ESP_INFO, 837 SEQ, 838 [DIFFIE_HELLMAN, ] 839 HMAC, 840 HIP_SIGNATURE ) ) 842 5.3.2. Responding to the Rekeying Initialization 844 The UPDATE ACK is used to acknowledge the received UPDATE rekeying 845 initialization. The acknowledgment UPDATE packet MUST carry an 846 ESP_INFO and MAY carry a DIFFIE_HELLMAN parameter. 848 Intermediate systems that use the SPI will have to inspect HIP 849 packets for packets carrying rekeying information. The packet is 850 signed for the benefit of the intermediate systems. Since 851 intermediate systems may need the new SPI values, the contents cannot 852 be encrypted. 854 The following figure shows the contents of a rekeying acknowledgment 855 UPDATE packet. 857 The HIP parameters for the UPDATE packet: 859 IP ( HIP ( ESP_INFO, 860 SEQ, 861 ACK, 862 [ DIFFIE_HELLMAN, ] 863 HMAC, 864 HIP_SIGNATURE ) ) 866 5.4. ICMP Messages 868 ICMP message handling is mainly described in the HIP base 869 specification [I-D.ietf-hip-rfc5201-bis]. In this section, we 870 describe the actions related to ESP security associations. 872 5.4.1. Unknown SPI 874 If a HIP implementation receives an ESP packet that has an 875 unrecognized SPI number, it MAY respond (subject to rate limiting the 876 responses) with an ICMP packet with type "Parameter Problem", with 877 the pointer pointing to the beginning of SPI field in the ESP header. 879 6. Packet Processing 881 Packet processing is mainly defined in the HIP base specification 882 [I-D.ietf-hip-rfc5201-bis]. This section describes the changes and 883 new requirements for packet handling when the ESP transport format is 884 used. Note that all HIP packets (currently protocol 139) MUST bypass 885 ESP processing. 887 6.1. Processing Outgoing Application Data 889 Outgoing application data handling is specified in the HIP base 890 specification [I-D.ietf-hip-rfc5201-bis]. When the ESP transport 891 format is used, and there is an active HIP session for the given < 892 source, destination > HIT pair, the outgoing datagram is protected 893 using the ESP security association. The following additional steps 894 define the conceptual processing rules for outgoing ESP protected 895 datagrams. 897 1. Detect the proper ESP SA using the HITs in the packet header or 898 other information associated with the packet 900 2. Process the packet normally, as if the SA was a transport mode 901 SA. 903 3. Ensure that the outgoing ESP protected packet has proper IP 904 header format depending on the used IP address family, and proper 905 IP addresses in its IP header, e.g., by replacing HITs left by 906 the ESP processing. Note that this placement of proper IP 907 addresses MAY also be performed at some other point in the stack, 908 e.g., before ESP processing. 910 6.2. Processing Incoming Application Data 912 Incoming HIP user data packets arrive as ESP protected packets. In 913 the usual case, the receiving host has a corresponding ESP security 914 association, identified by the SPI and destination IP address in the 915 packet. However, if the host has crashed or otherwise lost its HIP 916 state, it may not have such an SA. 918 The basic incoming data handling is specified in the HIP base 919 specification. Additional steps are required when ESP is used for 920 protecting the data traffic. The following steps define the 921 conceptual processing rules for incoming ESP protected datagrams 922 targeted to an ESP security association created with HIP. 924 1. Detect the proper ESP SA using the SPI. If the resulting SA is a 925 non-HIP ESP SA, process the packet according to standard IPsec 926 rules. If there are no SAs identified with the SPI, the host MAY 927 send an ICMP packet as defined in Section 5.4. How to handle 928 lost state is an implementation issue. 930 2. If the SPI matches with an active HIP-based ESP SA, the IP 931 addresses in the datagram are replaced with the HITs associated 932 with the SPI. Note that this IP-address-to-HIT conversion step 933 MAY also be performed at some other point in the stack, e.g., 934 after ESP processing. Note also that if the incoming packet has 935 IPv4 addresses, the packet must be converted to IPv6 format 936 before replacing the addresses with HITs (such that the transport 937 checksum will pass if there are no errors). 939 3. The transformed packet is next processed normally by ESP, as if 940 the packet were a transport mode packet. The packet may be 941 dropped by ESP, as usual. In a typical implementation, the 942 result of successful ESP decryption and verification is a 943 datagram with the associated HITs as source and destination. 945 4. The datagram is delivered to the upper layer. Demultiplexing the 946 datagram to the right upper layer socket is performed as usual, 947 except that the HITs are used in place of IP addresses during the 948 demultiplexing. 950 6.3. HMAC and SIGNATURE Calculation and Verification 952 The new HIP parameters described in this document, ESP_INFO and 953 ESP_TRANSFORM, must be protected using HMAC and signature 954 calculations. In a typical implementation, they are included in R1, 955 I2, R2, and UPDATE packet HMAC and SIGNATURE calculations as 956 described in [I-D.ietf-hip-rfc5201-bis]. 958 6.4. Processing Incoming ESP SA Initialization (R1) 960 The ESP SA setup is initialized in the R1 message. The receiving 961 host (Initiator) selects one of the ESP transforms from the presented 962 values. If no suitable value is found, the negotiation is 963 terminated. The selected values are subsequently used when 964 generating and using encryption keys, and when sending the reply 965 packet. If the proposed alternatives are not acceptable to the 966 system, it may abandon the ESP SA establishment negotiation, or it 967 may resend the I1 message within the retry bounds. 969 After selecting the ESP transform and performing other R1 processing, 970 the system prepares and creates an incoming ESP security association. 971 It may also prepare a security association for outgoing traffic, but 972 since it does not have the correct SPI value yet, it cannot activate 973 it. 975 6.5. Processing Incoming Initialization Reply (I2) 977 The following steps are required to process the incoming ESP SA 978 initialization replies in I2. The steps below assume that the I2 has 979 been accepted for processing (e.g., has not been dropped due to HIT 980 comparisons as described in [I-D.ietf-hip-rfc5201-bis]). 982 o The ESP_TRANSFORM parameter is verified and it MUST contain a 983 single value in the parameter, and it MUST match one of the values 984 offered in the initialization packet. 986 o The ESP_INFO NEW SPI field is parsed to obtain the SPI that will 987 be used for the Security Association outbound from the Responder 988 and inbound to the Initiator. For this initial ESP SA 989 establishment, the old SPI value MUST be zero. The KEYMAT Index 990 field MUST contain the index value to the KEYMAT from where the 991 ESP SA keys are drawn. 993 o The system prepares and creates both incoming and outgoing ESP 994 security associations. 996 o Upon successful processing of the initialization reply message, 997 the possible old Security Associations (as left over from an 998 earlier incarnation of the HIP association) are dropped and the 999 new ones are installed, and a finalizing packet, R2, is sent. 1000 Possible ongoing rekeying attempts are dropped. 1002 6.6. Processing Incoming ESP SA Setup Finalization (R2) 1004 Before the ESP SA can be finalized, the ESP_INFO NEW SPI field is 1005 parsed to obtain the SPI that will be used for the ESP Security 1006 Association inbound to the sender of the finalization message R2. 1007 The system uses this SPI to create or activate the outgoing ESP 1008 security association used for sending packets to the peer. 1010 6.7. Dropping HIP Associations 1012 When the system drops a HIP association, as described in the HIP base 1013 specification, the associated ESP SAs MUST also be dropped. 1015 6.8. Initiating ESP SA Rekeying 1017 During ESP SA rekeying, the hosts draw new keys from the existing 1018 keying material, or new keying material is generated from where the 1019 new keys are drawn. 1021 A system may initiate the SA rekeying procedure at any time. It MUST 1022 initiate a rekey if its incoming ESP sequence counter is about to 1023 overflow. The system MUST NOT replace its keying material until the 1024 rekeying packet exchange successfully completes. 1026 Optionally, a system may include a new Diffie-Hellman key for use in 1027 new KEYMAT generation. New KEYMAT generation occurs prior to drawing 1028 the new keys. 1030 The rekeying procedure uses the UPDATE mechanism defined in 1031 [I-D.ietf-hip-rfc5201-bis]. Because each peer must update its half 1032 of the security association pair (including new SPI creation), the 1033 rekeying process requires that each side both send and receive an 1034 UPDATE. A system will then rekey the ESP SA when it has sent 1035 parameters to the peer and has received both an ACK of the relevant 1036 UPDATE message and corresponding peer's parameters. It may be that 1037 the ACK and the required HIP parameters arrive in different UPDATE 1038 messages. This is always true if a system does not initiate ESP SA 1039 update but responds to an update request from the peer, and may also 1040 occur if two systems initiate update nearly simultaneously. In such 1041 a case, if the system has an outstanding update request, it saves the 1042 one parameter and waits for the other before completing rekeying. 1044 The following steps define the processing rules for initiating an ESP 1045 SA update: 1047 1. The system decides whether to continue to use the existing KEYMAT 1048 or to generate a new KEYMAT. In the latter case, the system MUST 1049 generate a new Diffie-Hellman public key. 1051 2. The system creates an UPDATE packet, which contains the ESP_INFO 1052 parameter. In addition, the host may include the optional 1053 DIFFIE_HELLMAN parameter. If the UPDATE contains the 1054 DIFFIE_HELLMAN parameter, the KEYMAT Index in the ESP_INFO 1055 parameter MUST be zero, and the Diffie-Hellman group ID must be 1056 unchanged from that used in the initial handshake. If the UPDATE 1057 does not contain DIFFIE_HELLMAN, the ESP_INFO KEYMAT Index MUST 1058 be greater than or equal to the index of the next byte to be 1059 drawn from the current KEYMAT. 1061 3. The system sends the UPDATE packet. For reliability, the 1062 underlying UPDATE retransmission mechanism MUST be used. 1064 4. The system MUST NOT delete its existing SAs, but continue using 1065 them if its policy still allows. The rekeying procedure SHOULD 1066 be initiated early enough to make sure that the SA replay 1067 counters do not overflow. 1069 5. In case a protocol error occurs and the peer system acknowledges 1070 the UPDATE but does not itself send an ESP_INFO, the system may 1071 not finalize the outstanding ESP SA update request. To guard 1072 against this, a system MAY re-initiate the ESP SA update 1073 procedure after some time waiting for the peer to respond, or it 1074 MAY decide to abort the ESP SA after waiting for an 1075 implementation-dependent time. The system MUST NOT keep an 1076 outstanding ESP SA update request for an indefinite time. 1078 To simplify the state machine, a host MUST NOT generate new UPDATEs 1079 while it has an outstanding ESP SA update request, unless it is 1080 restarting the update process. 1082 6.9. Processing Incoming UPDATE Packets 1084 When a system receives an UPDATE packet, it must be processed if the 1085 following conditions hold (in addition to the generic conditions 1086 specified for UPDATE processing in Section 6.12 of 1087 [I-D.ietf-hip-rfc5201-bis]): 1089 1. A corresponding HIP association must exist. This is usually 1090 ensured by the underlying UPDATE mechanism. 1092 2. The state of the HIP association is ESTABLISHED or R2-SENT. 1094 If the above conditions hold, the following steps define the 1095 conceptual processing rules for handling the received UPDATE packet: 1097 1. If the received UPDATE contains a DIFFIE_HELLMAN parameter, the 1098 received KEYMAT Index MUST be zero and the Group ID must match 1099 the Group ID in use on the association. If this test fails, the 1100 packet SHOULD be dropped and the system SHOULD log an error 1101 message. 1103 2. If there is no outstanding rekeying request, the packet 1104 processing continues as specified in Section 6.9.1. 1106 3. If there is an outstanding rekeying request, the UPDATE MUST be 1107 acknowledged, the received ESP_INFO (and possibly DIFFIE_HELLMAN) 1108 parameters must be saved, and the packet processing continues as 1109 specified in Section 6.10. 1111 6.9.1. Processing UPDATE Packet: No Outstanding Rekeying Request 1113 The following steps define the conceptual processing rules for 1114 handling a received UPDATE packet with the ESP_INFO parameter: 1116 1. The system consults its policy to see if it needs to generate a 1117 new Diffie-Hellman key, and generates a new key (with same Group 1118 ID) if needed. The system records any newly generated or 1119 received Diffie-Hellman keys for use in KEYMAT generation upon 1120 finalizing the ESP SA update. 1122 2. If the system generated a new Diffie-Hellman key in the previous 1123 step, or if it received a DIFFIE_HELLMAN parameter, it sets the 1124 ESP_INFO KEYMAT Index to zero. Otherwise, the ESP_INFO KEYMAT 1125 Index MUST be greater than or equal to the index of the next byte 1126 to be drawn from the current KEYMAT. In this case, it is 1127 RECOMMENDED that the host use the KEYMAT Index requested by the 1128 peer in the received ESP_INFO. 1130 3. The system creates an UPDATE packet, which contains an ESP_INFO 1131 parameter and the optional DIFFIE_HELLMAN parameter. This UPDATE 1132 would also typically acknowledge the peer's UPDATE with an ACK 1133 parameter, although a separate UPDATE ACK may be sent. 1135 4. The system sends the UPDATE packet and stores any received 1136 ESP_INFO and DIFFIE_HELLMAN parameters. At this point, it only 1137 needs to receive an acknowledgment for the newly sent UPDATE to 1138 finish ESP SA update. In the usual case, the acknowledgment is 1139 handled by the underlying UPDATE mechanism. 1141 6.10. Finalizing Rekeying 1143 A system finalizes rekeying when it has both received the 1144 corresponding UPDATE acknowledgment packet from the peer and it has 1145 successfully received the peer's UPDATE. The following steps are 1146 taken: 1148 1. If the received UPDATE messages contain a new Diffie-Hellman key, 1149 the system has a new Diffie-Hellman key due to initiating ESP SA 1150 update, or both, the system generates a new KEYMAT. If there is 1151 only one new Diffie-Hellman key, the old existing key is used as 1152 the other key. 1154 2. If the system generated a new KEYMAT in the previous step, it 1155 sets the KEYMAT Index to zero, independent of whether the 1156 received UPDATE included a Diffie-Hellman key or not. If the 1157 system did not generate a new KEYMAT, it uses the greater KEYMAT 1158 Index of the two (sent and received) ESP_INFO parameters. 1160 3. The system draws keys for new incoming and outgoing ESP SAs, 1161 starting from the KEYMAT Index, and prepares new incoming and 1162 outgoing ESP SAs. The SPI for the outgoing SA is the new SPI 1163 value received in an ESP_INFO parameter. The SPI for the 1164 incoming SA was generated when the ESP_INFO was sent to the peer. 1165 The order of the keys retrieved from the KEYMAT during the 1166 rekeying process is similar to that described in Section 7. 1168 Note, that only IPsec ESP keys are retrieved during the rekeying 1169 process, not the HIP keys. 1171 4. The system starts to send to the new outgoing SA and prepares to 1172 start receiving data on the new incoming SA. Once the system 1173 receives data on the new incoming SA, it may safely delete the 1174 old SAs. 1176 6.11. Processing NOTIFY Packets 1178 The processing of NOTIFY packets is described in the HIP base 1179 specification. 1181 7. Keying Material 1183 The keying material is generated as described in the HIP base 1184 specification. During the base exchange, the initial keys are drawn 1185 from the generated material. After the HIP association keys have 1186 been drawn, the ESP keys are drawn in the following order: 1188 SA-gl ESP encryption key for HOST_g's outgoing traffic 1190 SA-gl ESP authentication key for HOST_g's outgoing traffic 1192 SA-lg ESP encryption key for HOST_l's outgoing traffic 1194 SA-lg ESP authentication key for HOST_l's outgoing traffic 1196 HOST_g denotes the host with the greater HIT value, and HOST_l 1197 denotes the host with the lower HIT value. When HIT values are 1198 compared, they are interpreted as positive (unsigned) 128-bit 1199 integers in network byte order. 1201 The four HIP keys are only drawn from KEYMAT during a HIP I1->R2 1202 exchange. Subsequent rekeys using UPDATE will only draw the four ESP 1203 keys from KEYMAT. Section 6.9 describes the rules for reusing or 1204 regenerating KEYMAT based on the rekeying. 1206 The number of bits drawn for a given algorithm is the "natural" size 1207 of the keys, as specified in Section 6.5 of 1208 [I-D.ietf-hip-rfc5201-bis]. 1210 8. Security Considerations 1212 In this document, the usage of ESP [RFC4303] between HIP hosts to 1213 protect data traffic is introduced. The Security Considerations for 1214 ESP are discussed in the ESP specification. 1216 There are different ways to establish an ESP Security Association 1217 between two nodes. This can be done, e.g., using IKE [RFC5996]. 1218 This document specifies how the Host Identity Protocol is used to 1219 establish ESP Security Associations. 1221 The following issues are new or have changed from the standard ESP 1222 usage: 1224 o Initial keying material generation 1226 o Updating the keying material 1228 The initial keying material is generated using the Host Identity 1229 Protocol [I-D.ietf-hip-rfc5201-bis] using the Diffie-Hellman 1230 procedure. This document extends the usage of the UPDATE packet, 1231 defined in the base specification, to modify existing ESP SAs. The 1232 hosts may rekey, i.e., force the generation of new keying material 1233 using the Diffie-Hellman procedure. The initial setup of ESP SA 1234 between the hosts is done during the base exchange, and the message 1235 exchange is protected using methods provided by base exchange. 1236 Changes in connection parameters means basically that the old ESP SA 1237 is removed and a new one is generated once the UPDATE message 1238 exchange has been completed. The message exchange is protected using 1239 the HIP association keys. Both HMAC and signing of packets is used. 1241 9. IANA Considerations 1243 The following changes to the "Host Identity Protocol (HIP) 1244 Parameters" registries are requested. In all cases, the changes 1245 required are to update the reference from [RFC5202] to this 1246 specification. 1248 This document defines two Parameter Types and two NOTIFY Message 1249 Types for the Host Identity Protocol [I-D.ietf-hip-rfc5201-bis]. 1251 The parameters and their type numbers are defined in Section 5.1.1 1252 and Section 5.1.2, and they have been added to the Parameter Type 1253 namespace created by [I-D.ietf-hip-rfc5201-bis]. No new action 1254 regarding these values are required by this specification, other than 1255 updating the reference from [RFC5202] to this specification. 1257 The new NOTIFY error types and their values are defined in 1258 Section 5.1.3, and they have been added to the Notify Message Type 1259 namespace created by [I-D.ietf-hip-rfc5201-bis]. No new action 1260 regarding these values are required by this specification, other than 1261 updating the reference from [RFC5202] to this specification. 1263 10. Acknowledgments 1265 This document was separated from the base "Host Identity Protocol" 1266 specification in the beginning of 2005. Since then, a number of 1267 people have contributed to the text by providing comments and 1268 modification proposals. The list of people include Tom Henderson, 1269 Jeff Ahrenholz, Jan Melen, Jukka Ylitalo, and Miika Komu. 1270 Especially, the authors want to thank Pekka Nikander for his 1271 invaluable contributions to the document since the first draft 1272 version. The authors want to thank also Charlie Kaufman for 1273 reviewing the document with his eye on the usage of crypto 1274 algorithms. 1276 Due to the history of this document, most of the ideas are inherited 1277 from the base "Host Identity Protocol" specification. Thus, the list 1278 of people in the Acknowledgments section of that specification is 1279 also valid for this document. Many people have given valuable 1280 feedback, and our apologies to anyone whose name is missing. 1282 11. References 1284 11.1. Normative references 1286 [I-D.ietf-hip-rfc5201-bis] 1287 Moskowitz, R., Heer, T., Jokela, P., and T. Henderson, 1288 "Host Identity Protocol Version 2 (HIPv2)", draft-ietf- 1289 hip-rfc5201-bis-14 (work in progress), October 2013. 1291 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1292 Requirement Levels", BCP 14, RFC 2119, March 1997. 1294 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within 1295 ESP and AH", RFC 2404, November 1998. 1297 [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and 1298 Its Use With IPsec", RFC 2410, November 1998. 1300 [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher 1301 Algorithm and Its Use with IPsec", RFC 3602, September 1302 2003. 1304 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 1305 (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 1306 4106, June 2005. 1308 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 1309 4303, December 2005. 1311 [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM 1312 Mode with IPsec Encapsulating Security Payload (ESP)", RFC 1313 4309, December 2005. 1315 [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The 1316 AES-CMAC Algorithm", RFC 4493, June 2006. 1318 [RFC4494] Song, JH., Poovendran, R., and J. Lee, "The AES-CMAC-96 1319 Algorithm and Its Use with IPsec", RFC 4494, June 2006. 1321 [RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message 1322 Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, 1323 May 2006. 1325 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 1326 384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007. 1328 11.2. Informative references 1330 [I-D.ietf-hip-rfc4423-bis] 1331 Moskowitz, R. and M. Komu, "Host Identity Protocol 1332 Architecture", draft-ietf-hip-rfc4423-bis-08 (work in 1333 progress), April 2014. 1335 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1336 1981. 1338 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1339 Internet Protocol", RFC 4301, December 2005. 1341 [RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the 1342 Encapsulating Security Payload (ESP) Transport Format with 1343 the Host Identity Protocol (HIP)", RFC 5202, April 2008. 1345 [RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End- 1346 Host Mobility and Multihoming with the Host Identity 1347 Protocol", RFC 5206, April 2008. 1349 [RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and 1350 Firewall Traversal Issues of Host Identity Protocol (HIP) 1351 Communication", RFC 5207, April 2008. 1353 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1354 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1355 May 2008. 1357 [RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. 1358 Keranen, "Basic Host Identity Protocol (HIP) Extensions 1359 for Traversal of Network Address Translators", RFC 5770, 1360 April 2010. 1362 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 1363 "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 1364 5996, September 2010. 1366 Appendix A. A Note on Implementation Options 1368 It is possible to implement this specification in multiple different 1369 ways. As noted above, one possible way of implementing this is to 1370 rewrite IP headers below IPsec. In such an implementation, IPsec is 1371 used as if it was processing IPv6 transport mode packets, with the 1372 IPv6 header containing HITs instead of IP addresses in the source and 1373 destination address fields. In outgoing packets, after IPsec 1374 processing, the HITs are replaced with actual IP addresses, based on 1375 the HITs and the SPI. In incoming packets, before IPsec processing, 1376 the IP addresses are replaced with HITs, based on the SPI in the 1377 incoming packet. In such an implementation, all IPsec policies are 1378 based on HITs and the upper layers only see packets with HITs in the 1379 place of IP addresses. Consequently, support of HIP does not 1380 conflict with other uses of IPsec as long as the SPI spaces are kept 1381 separate. Appendix B describes another way to implement this 1382 specification. 1384 Appendix B. Bound End-to-End Tunnel mode for ESP 1386 This section introduces an alternative way of implementing the 1387 necessary functions for HIP ESP transport. Compared to the option of 1388 implementing the required address rewrites outside of IPsec, BEET has 1389 one implementation level benefit. In BEET-way of implementing, the 1390 address rewriting information is kept in one place, at the SAD. On 1391 the other hand, when address rewriting is implemented separately, the 1392 implementation MUST make sure that the information in the SAD and the 1393 separate address rewriting DB are kept in synchrony. As a result, 1394 the BEET-mode-based way of implementing this specification is 1395 RECOMMENDED over the separate implementation as it keeps the binds 1396 the identities, encryption and locators tightly together. It should 1397 be noted that implementing BEET mode doesn't require that 1398 corresponding hosts implement it as the behavior is only visible 1399 internally in a host. 1401 The BEET mode is a combination of IPsec tunnel and transport modes 1402 and provides some of the features from both. The HIP uses HITs as 1403 the "inner" addresses and IP addresses as "outer" addresses, like IP 1404 addresses are used in the tunnel mode. Instead of tunneling packets 1405 between hosts, a conversion between inner and outer addresses is made 1406 at end-hosts and the inner address is never sent on the wire after 1407 the initial HIP negotiation. BEET provides IPsec transport mode 1408 syntax (no inner headers) with limited tunnel mode semantics (fixed 1409 logical inner addresses - the HITs - and changeable outer IP 1410 addresses). 1412 B.1. Protocol definition 1414 In this section we define the exact protocol formats and operations. 1416 B.1.1. Changes to Security Association data structures 1418 A BEET mode Security Association contains the same data as a regular 1419 tunnel mode Security Association, with the exception that the inner 1420 selectors must be single addresses and cannot be subnets. The data 1421 includes the following: 1423 A pair of inner IP addresses. 1425 A pair of outer IP addresses. 1427 Cryptographic keys and other data as defined in RFC4301 [RFC4301] 1428 Section 4.4.2. 1430 A conforming implementation MAY store the data in a way similar to a 1431 regular tunnel mode Security Association. 1433 Note that in a conforming implementation the inner and outer 1434 addresses MAY belong to different address families. All 1435 implementations that support both IPv4 and IPv6 SHOULD support both 1436 IPv4-over-IPv6 and IPv6-over-IPv4 tunneling. 1438 B.1.2. Packet format 1440 The wire packet format is identical to the ESP transport mode wire 1441 format as defined in [RFC4303] Section 3.1.1. However, the resulting 1442 packet contains outer IP addresses instead of the inner IP addresses 1443 received from the upper layer. The construction of the outer headers 1444 is defined in RFC4301 [RFC4301] Section 5.1.2. The following diagram 1445 illustrates ESP BEET mode positioning for typical IPv4 and IPv6 1446 packets. 1448 IPv4 INNER ADDRESSES 1449 -------------------- 1451 BEFORE APPLYING ESP 1452 ------------------------------ 1453 | inner IP hdr | | | 1454 | | TCP | Data | 1455 ------------------------------ 1457 AFTER APPLYING ESP, OUTER v4 ADDRESSES 1458 ---------------------------------------------------- 1459 | outer IP hdr | | | | ESP | ESP | 1460 | (any options) | ESP | TCP | Data | Trailer | ICV | 1461 ---------------------------------------------------- 1462 |<---- encryption ---->| 1463 |<-------- integrity ------->| 1465 AFTER APPLYING ESP, OUTER v6 ADDRESSES 1466 ------------------------------------------------------ 1467 | outer | new ext | | | | ESP | ESP | 1468 | IP hdr | hdrs. | ESP | TCP | Data | Trailer| ICV | 1469 ------------------------------------------------------ 1470 |<--- encryption ---->| 1471 |<------- integrity ------->| 1473 IPv4 INNER ADDRESSES with options 1474 --------------------------------- 1476 BEFORE APPLYING ESP 1477 ------------------------------ 1478 | inner IP hdr | | | 1479 | + options | TCP | Data | 1480 ------------------------------ 1482 AFTER APPLYING ESP, OUTER v4 ADDRESSES 1483 ---------------------------------------------------------- 1484 | outer IP hdr | | | | | ESP | ESP | 1485 | (any options) | ESP | PH | TCP | Data | Trailer | ICV | 1486 ---------------------------------------------------------- 1487 |<------- encryption ------->| 1488 |<----------- integrity ---------->| 1490 AFTER APPLYING ESP, OUTER v6 ADDRESSES 1491 ------------------------------------------------------------ 1492 | outer | new ext | | | | | ESP | ESP | 1493 | IP hdr | hdrs. | ESP | PH | TCP | Data | Trailer| ICV | 1494 ------------------------------------------------------------ 1495 |<------ encryption ------->| 1496 |<---------- integrity ---------->| 1498 PH Pseudo Header for IPv4 options 1500 IPv6 INNER ADDRESSES 1501 -------------------- 1503 BEFORE APPLYING ESP 1504 ------------------------------------------ 1505 | | ext hdrs | | | 1506 | inner IP hdr | if present | TCP | Data | 1507 ------------------------------------------ 1509 AFTER APPLYING ESP, OUTER v6 ADDRESSES 1510 -------------------------------------------------------------- 1511 | outer | new ext | | dest | | | ESP | ESP | 1512 | IP hdr | hdrs. | ESP | opts.| TCP | Data | Trailer | ICV | 1513 -------------------------------------------------------------- 1514 |<---- encryption ---->| 1515 |<------- integrity ------>| 1517 AFTER APPLYING ESP, OUTER v4 ADDRESSES 1518 ---------------------------------------------------- 1519 | outer | | dest | | | ESP | ESP | 1520 | IP hdr | ESP | opts.| TCP | Data | Trailer | ICV | 1521 ---------------------------------------------------- 1522 |<------- encryption -------->| 1523 |<----------- integrity ----------->| 1525 B.1.3. Cryptographic processing 1527 The outgoing packets MUST be protected exactly as in ESP transport 1528 mode [RFC4303]. That is, the upper layer protocol packet is wrapped 1529 into an ESP header, encrypted, and authenticated exactly as if 1530 regular transport mode was used. The resulting ESP packet is subject 1531 to IP header processing as defined in Appendix B.1.4 and 1532 Appendix B.1.5. The incoming ESP protected messages are verified and 1533 decrypted exactly as if regular transport mode was used. The 1534 resulting clear text packet is subject to IP header processing as 1535 defined in Appendix B.1.4 and Appendix B.1.6. 1537 B.1.4. IP header processing 1539 The biggest difference between the BEET mode and the other two modes 1540 is in IP header processing. In the regular transport mode the IP 1541 header is kept intact. In the regular tunnel mode an outer IP header 1542 is created on output and discarded on input. In the BEET mode the IP 1543 header is replaced with another one on both input and output. 1545 On the BEET mode output side, the IP header processing MUST first 1546 ensure that the IP addresses in the original IP header contain the 1547 inner addresses as specified in the SA. This MAY be ensured by 1548 proper policy processing, and it is possible that no checks are 1549 needed at the SA processing time. Once the IP header has been 1550 verified to contain the right IP inner addresses, it is discarded. A 1551 new IP header is created, using the discarded inner header as a hint 1552 for other fields but the IP addresses. The IP addresses in the new 1553 header MUST be the outer tunnel addresses. 1555 On input side, the received IP header is simply discarded. Since the 1556 packet has been decrypted and verified, no further checks are 1557 necessary. A new IP header, corresponding to a tunnel mode inner 1558 header, is created, using the discarded outer header as a hint for 1559 other fields but the IP addresses. The IP addresses in the new 1560 header MUST be the inner addresses. 1562 As the outer header fields are used as hint for creating inner 1563 header, it must be noted that inner header differs as compared to 1564 tunnel-mode inner header. In BEET mode the inner header will have 1565 the TTL, DF-bit and other option values from the outer header. The 1566 TTL, DF-bit and other option values of the inner header MUST be 1567 processed by the stack. 1569 B.1.5. Handling of outgoing packets 1571 The outgoing BEET mode packets are processed as follows: 1573 1. The system MUST verify that the IP header contains the inner 1574 source and destination addresses, exactly as defined in the SA. 1575 This verification MAY be explicit, or it MAY be implicit, for 1576 example, as a result of prior policy processing. Note that in 1577 some implementations there may be no real IP header at this time 1578 but the source and destination addresses may be carried out-of- 1579 band. In case the source address is still unassigned, it SHOULD 1580 be ensured that the designated inner source address would be 1581 selected at a later stage. 1583 2. The IP payload (the contents of the packet beyond the IP header) 1584 is wrapped into an ESP header as defined in [RFC4303] 1585 Section 3.3. 1587 3. A new IP header is constructed, replacing the original one. The 1588 new IP header MUST contain the outer source and destination 1589 addresses, as defined in the SA. Note that in some 1590 implementations there may be no real IP header at this time but 1591 the source and destination addresses may be carried out-of-band. 1592 In the case where the source address must be left unassigned, it 1593 SHOULD be made sure that the right source address is selected at 1594 a later stage. Other than the addresses, it is RECOMMENDED that 1595 the new IP header copies the fields from the original IP header. 1597 4. If there are any IPv4 options in the original packet, it is 1598 RECOMMENDED that they are discarded. If the inner header 1599 contains one or more options that need to be transported between 1600 the tunnel end-points, sender MUST encapsulate the options as 1601 defined in Appendix B.1.7 1603 Instead of literally discarding the IP header and constructing a new 1604 one, a conforming implementation MAY simply replace the addresses in 1605 an existing header. However, if the RECOMMENDED feature of allowing 1606 the inner and outer addresses from different address families is 1607 used, this simple strategy does not work. 1609 B.1.6. Handling of incoming packets 1611 The incoming BEET mode packets are processed as follows: 1613 1. The system MUST verify and decrypt the incoming packet 1614 successfully, as defined in [RFC4303] section 3.4. If the 1615 verification or decryption fails, the packet MUST be discarded. 1617 2. The original IP header is simply discarded, without any checks. 1618 Since the ESP verification succeeded, the packet can be safely 1619 assumed to have arrived from the right sender. 1621 3. A new IP header is constructed, replacing the original one. The 1622 new IP header MUST contain the inner source and destination 1623 addresses, as defined in the SA. If the sender has set the ESP 1624 next protocol field to 94 and included the pseudo header as 1625 described in Appendix B.1.7, the receiver MUST include the 1626 options after the constructed IP header. Note, that in some 1627 implementations the real IP header may have already been 1628 discarded and the source and destination addresses are carried 1629 out-of-band. In such case the out-of-band addresses MUST be the 1630 inner addresses. Other than the addresses, it is RECOMMENDED 1631 that the new IP header copies the fields from the original IP 1632 header. 1634 Instead of literally discarding the IP header and constructing a new 1635 one a conforming implementation MAY simply replace the addresses in 1636 an existing header. However, if the RECOMMENDED feature of allowing 1637 the inner and outer addresses from different address families is 1638 used, this simple strategy does not work. 1640 B.1.7. IPv4 options handling 1642 In BEET mode, if IPv4 options are transported inside the tunnel, the 1643 sender MUST include a pseudo-header after ESP header. The pseudo- 1644 header identifies that IPv4 options from the original packet are to 1645 be applied on the packet on input side. 1647 The sender MUST set the next protocol field on the ESP header as 94. 1648 The resulting pseudo header including the IPv4 options MUST be padded 1649 to 8 octet boundary. The padding length is expressed in octets, 1650 valid padding lengths are 0 or 4 octets as the original IPv4 options 1651 are already padded to 4 octet boundary. The padding MUST be filled 1652 with NOP options as defined in Internet Protocol [RFC0791] section 1653 3.1 Internet header format. The padding is added in front of the 1654 original options to ensure that the receiver is able to reconstruct 1655 the original IPv4 datagram. The Header Length field contains the 1656 length of the IPv4 options, and padding in 8 octets units. 1658 0 1 2 3 1659 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 1660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1661 | Next Header | Header Len | Pad Len | Reserved | 1662 +---------------+---------------+-------------------------------+ 1663 | Padding (if needed) | 1664 +---------------------------------------------------------------+ 1665 | IPv4 options ... | 1666 | | 1667 +---------------------------------------------------------------+ 1669 Next Header Identifies the data following this header 1670 Length in octets 8-bit unsigned integer. Length of the 1671 pseudo header in 8-octet units, not 1672 including the first 8 octets. 1674 The receiver MUST remove this pseudo-header and padding as a part of 1675 BEET processing, in order reconstruct the original IPv4 datagram. 1676 The IPv4 options included into the pseudo-header MUST be added after 1677 the reconstructed IPv4 (inner) header on the receiving side. 1679 Authors' Addresses 1681 Petri Jokela 1682 Ericsson Research NomadicLab 1683 JORVAS FIN-02420 1684 FINLAND 1686 Phone: +358 9 299 1 1687 EMail: petri.jokela@nomadiclab.com 1689 Robert Moskowitz 1690 Verizon Telcom and Business 1691 1000 Bent Creek Blvd, Suite 200 1692 Mechanicsburg, PA 1693 USA 1695 EMail: rgm@icsalabs.com 1696 Jan Melen 1697 Ericsson Research NomadicLab 1698 JORVAS FIN-02420 1699 FINLAND 1701 Phone: +358 9 299 1 1702 EMail: jan.melen@nomadiclab.com