idnits 2.17.1 draft-ietf-hip-rfc5202-bis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 == Line 1697 has weird spacing: '...ivision of Ve...' == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 23, 2010) is 4957 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) == Missing Reference: 'RFC2451' is mentioned on line 706, but not defined == Missing Reference: 'RFC2410' is mentioned on line 711, but not defined == Missing Reference: 'RFC4868' is mentioned on line 713, but not defined == Missing Reference: 'RFC4309' is mentioned on line 715, but not defined == Missing Reference: 'RFC4106' is mentioned on line 717, but not defined == Unused Reference: 'RFC0791' is defined on line 1338, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 5206 (Obsoleted by RFC 8046) Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 4 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 Intended status: Standards Track R. Moskowitz 5 Expires: March 27, 2011 ICSA labs 6 P. Nikander 7 J. Melen 8 Ericsson Research NomadicLab 9 September 23, 2010 11 Using the Encapsulating Security Payload (ESP) Transport Format with the 12 Host Identity Protocol (HIP) 13 draft-ietf-hip-rfc5202-bis-00 15 Abstract 17 This memo specifies an Encapsulated Security Payload (ESP) based 18 mechanism for transmission of user data packets, to be used with the 19 Host Identity Protocol (HIP). 21 IESG Note 23 The following issues describe IESG concerns about this document. The 24 IESG expects that these issues will be addressed when future versions 25 of HIP are designed. 27 In case of complex Security Policy Databases (SPDs) and the co- 28 existence of HIP and security-related protocols such as IKE, 29 implementors may encounter conditions that are unspecified in these 30 documents. For example, when the SPD defines an IP address subnet to 31 be protected and a HIP host is residing in that IP address area, 32 there is a possibility that the communication is encrypted multiple 33 times. Readers are advised to pay special attention when running HIP 34 with complex SPD settings. Future specifications should clearly 35 define when multiple encryption is intended, and when it should be 36 avoided. 38 Status of This Memo 40 This Internet-Draft is submitted to IETF in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF), its areas, and its working groups. Note that 45 other groups may also distribute working documents as Internet- 46 Drafts. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 The list of current Internet-Drafts can be accessed at 54 http://www.ietf.org/ietf/1id-abstracts.txt. 56 The list of Internet-Draft Shadow Directories can be accessed at 57 http://www.ietf.org/shadow.html. 59 This Internet-Draft will expire on March 27, 2011. 61 Copyright Notice 63 Copyright (c) 2010 IETF Trust and the persons identified as the 64 document authors. All rights reserved. 66 This document is subject to BCP 78 and the IETF Trust's Legal 67 Provisions Relating to IETF Documents 68 (http://trustee.ietf.org/license-info) in effect on the date of 69 publication of this document. Please review these documents 70 carefully, as they describe your rights and restrictions with respect 71 to this document. Code Components extracted from this document must 72 include Simplified BSD License text as described in Section 4.e of 73 the Trust Legal Provisions and are provided without warranty as 74 described in the BSD License. 76 This document may contain material from IETF Documents or IETF 77 Contributions published or made publicly available before November 78 10, 2008. The person(s) controlling the copyright in some of this 79 material may not have granted the IETF Trust the right to allow 80 modifications of such material outside the IETF Standards Process. 81 Without obtaining an adequate license from the person(s) controlling 82 the copyright in such materials, this document may not be modified 83 outside the IETF Standards Process, and derivative works of it may 84 not be created outside the IETF Standards Process, except to format 85 it for publication as an RFC or to translate it into languages other 86 than English. 88 Table of Contents 90 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 91 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 92 3. Using ESP with HIP . . . . . . . . . . . . . . . . . . . . . . 4 93 3.1. ESP Packet Format . . . . . . . . . . . . . . . . . . . . 5 94 3.2. Conceptual ESP Packet Processing . . . . . . . . . . . . . 5 95 3.2.1. Semantics of the Security Parameter Index (SPI) . . . 6 96 3.3. Security Association Establishment and Maintenance . . . . 6 97 3.3.1. ESP Security Associations . . . . . . . . . . . . . . 6 98 3.3.2. Rekeying . . . . . . . . . . . . . . . . . . . . . . . 7 99 3.3.3. Security Association Management . . . . . . . . . . . 8 100 3.3.4. Security Parameter Index (SPI) . . . . . . . . . . . . 8 101 3.3.5. Supported Transforms . . . . . . . . . . . . . . . . . 8 102 3.3.6. Sequence Number . . . . . . . . . . . . . . . . . . . 9 103 3.3.7. Lifetimes and Timers . . . . . . . . . . . . . . . . . 9 104 3.4. IPsec and HIP ESP Implementation Considerations . . . . . 9 105 3.4.1. Data Packet Processing Considerations . . . . . . . . 10 106 3.4.2. HIP Signaling Packet Considerations . . . . . . . . . 10 107 4. The Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 11 108 4.1. ESP in HIP . . . . . . . . . . . . . . . . . . . . . . . . 11 109 4.1.1. Setting Up an ESP Security Association . . . . . . . . 11 110 4.1.2. Updating an Existing ESP SA . . . . . . . . . . . . . 12 111 5. Parameter and Packet Formats . . . . . . . . . . . . . . . . . 12 112 5.1. New Parameters . . . . . . . . . . . . . . . . . . . . . . 12 113 5.1.1. ESP_INFO . . . . . . . . . . . . . . . . . . . . . . . 13 114 5.1.2. ESP_TRANSFORM . . . . . . . . . . . . . . . . . . . . 15 115 5.1.3. NOTIFY Parameter . . . . . . . . . . . . . . . . . . . 16 116 5.2. HIP ESP Security Association Setup . . . . . . . . . . . . 16 117 5.2.1. Setup During Base Exchange . . . . . . . . . . . . . . 16 118 5.3. HIP ESP Rekeying . . . . . . . . . . . . . . . . . . . . . 18 119 5.3.1. Initializing Rekeying . . . . . . . . . . . . . . . . 18 120 5.3.2. Responding to the Rekeying Initialization . . . . . . 19 121 5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 19 122 5.4.1. Unknown SPI . . . . . . . . . . . . . . . . . . . . . 19 123 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 19 124 6.1. Processing Outgoing Application Data . . . . . . . . . . . 20 125 6.2. Processing Incoming Application Data . . . . . . . . . . . 20 126 6.3. HMAC and SIGNATURE Calculation and Verification . . . . . 21 127 6.4. Processing Incoming ESP SA Initialization (R1) . . . . . . 21 128 6.5. Processing Incoming Initialization Reply (I2) . . . . . . 21 129 6.6. Processing Incoming ESP SA Setup Finalization (R2) . . . . 22 130 6.7. Dropping HIP Associations . . . . . . . . . . . . . . . . 22 131 6.8. Initiating ESP SA Rekeying . . . . . . . . . . . . . . . . 22 132 6.9. Processing Incoming UPDATE Packets . . . . . . . . . . . . 24 133 6.9.1. Processing UPDATE Packet: No Outstanding Rekeying 134 Request . . . . . . . . . . . . . . . . . . . . . . . 24 135 6.10. Finalizing Rekeying . . . . . . . . . . . . . . . . . . . 25 136 6.11. Processing NOTIFY Packets . . . . . . . . . . . . . . . . 26 137 7. Keying Material . . . . . . . . . . . . . . . . . . . . . . . 26 138 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 139 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 140 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 141 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 142 11.1. Normative references . . . . . . . . . . . . . . . . . . . 28 143 11.2. Informative references . . . . . . . . . . . . . . . . . . 28 144 Appendix A. A Note on Implementation Options . . . . . . . . . . 29 145 Appendix B. Bound End-to-End Tunnel mode for ESP . . . . . . . . 29 146 B.1. Protocol definition . . . . . . . . . . . . . . . . . . . 30 147 B.1.1. Changes to Security Association data structures . . . 30 148 B.1.2. Packet format . . . . . . . . . . . . . . . . . . . . 31 149 B.1.3. Cryptographic processing . . . . . . . . . . . . . . . 32 150 B.1.4. IP header processing . . . . . . . . . . . . . . . . . 33 151 B.1.5. Handling of outgoing packets . . . . . . . . . . . . . 33 152 B.1.6. Handling of incoming packets . . . . . . . . . . . . . 34 153 B.1.7. IPv4 options handling . . . . . . . . . . . . . . . . 35 155 1. Introduction 157 In the Host Identity Protocol Architecture 158 [I-D.moskowitz-hip-rfc4423-bis], hosts are identified with public 159 keys. The Host Identity Protocol [I-D.moskowitz-hip-rfc5201-bis] 160 base exchange allows any two HIP-supporting hosts to authenticate 161 each other and to create a HIP association between themselves. 162 During the base exchange, the hosts generate a piece of shared keying 163 material using an authenticated Diffie-Hellman exchange. 165 The HIP base exchange specification [I-D.moskowitz-hip-rfc5201-bis] 166 does not describe any transport formats or methods for user data to 167 be used during the actual communication; it only defines that it is 168 mandatory to implement the Encapsulated Security Payload (ESP) 169 [RFC4303] based transport format and method. This document specifies 170 how ESP is used with HIP to carry actual user data. 172 To be more specific, this document specifies a set of HIP protocol 173 extensions and their handling. Using these extensions, a pair of ESP 174 Security Associations (SAs) is created between the hosts during the 175 base exchange. The resulting ESP Security Associations use keys 176 drawn from the keying material (KEYMAT) generated during the base 177 exchange. After the HIP association and required ESP SAs have been 178 established between the hosts, the user data communication is 179 protected using ESP. In addition, this document specifies methods to 180 update an existing ESP Security Association. 182 It should be noted that representations of Host Identity are not 183 carried explicitly in the headers of user data packets. Instead, the 184 ESP Security Parameter Index (SPI) is used to indicate the right host 185 context. The SPIs are selected during the HIP ESP setup exchange. 186 For user data packets, ESP SPIs (in possible combination with IP 187 addresses) are used indirectly to identify the host context, thereby 188 avoiding any additional explicit protocol headers. 190 2. Conventions Used in This Document 192 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 193 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 194 document are to be interpreted as described in RFC 2119 [RFC2119]. 196 3. Using ESP with HIP 198 The HIP base exchange is used to set up a HIP association between two 199 hosts. The base exchange provides two-way host authentication and 200 key material generation, but it does not provide any means for 201 protecting data communication between the hosts. In this document, 202 we specify the use of ESP for protecting user data traffic after the 203 HIP base exchange. Note that this use of ESP is intended only for 204 host-to-host traffic; security gateways are not supported. 206 To support ESP use, the HIP base exchange messages require some minor 207 additions to the parameters transported. In the R1 packet, the 208 Responder adds the possible ESP transforms in a new ESP_TRANSFORM 209 parameter before sending it to the Initiator. The Initiator gets the 210 proposed transforms, selects one of those proposed transforms, and 211 adds it to the I2 packet in an ESP_TRANSFORM parameter. In this I2 212 packet, the Initiator also sends the SPI value that it wants to be 213 used for ESP traffic flowing from the Responder to the Initiator. 214 This information is carried using the new ESP_INFO parameter. When 215 finalizing the ESP SA setup, the Responder sends its SPI value to the 216 Initiator in the R2 packet, again using ESP_INFO. 218 3.1. ESP Packet Format 220 The ESP specification [RFC4303] defines the ESP packet format for 221 IPsec. The HIP ESP packet looks exactly the same as the IPsec ESP 222 transport format packet. The semantics, however, are a bit different 223 and are described in more detail in the next subsection. 225 3.2. Conceptual ESP Packet Processing 227 ESP packet processing can be implemented in different ways in HIP. 228 It is possible to implement it in a way that a standards compliant, 229 unmodified IPsec implementation [RFC4303] can be used. 231 When a standards compliant IPsec implementation that uses IP 232 addresses in the SPD and Security Association Database (SAD) is used, 233 the packet processing may take the following steps. For outgoing 234 packets, assuming that the upper-layer pseudoheader has been built 235 using IP addresses, the implementation recalculates upper-layer 236 checksums using Host Identity Tags (HITs) and, after that, changes 237 the packet source and destination addresses back to corresponding IP 238 addresses. The packet is sent to the IPsec ESP for transport mode 239 handling and from there the encrypted packet is sent to the network. 240 When an ESP packet is received, the packet is first put to the IPsec 241 ESP transport mode handling, and after decryption, the source and 242 destination IP addresses are replaced with HITs and finally, upper- 243 layer checksums are verified before passing the packet to the upper 244 layer. 246 An alternative way to implement packet processing is the BEET (Bound 247 End-to-End Tunnel) mode (see Appendix B). In BEET mode, the ESP 248 packet is formatted as a transport mode packet, but the semantics of 249 the connection are the same as for tunnel mode. The "outer" 250 addresses of the packet are the IP addresses and the "inner" 251 addresses are the HITs. For outgoing traffic, after the packet has 252 been encrypted, the packet's IP header is changed to a new one that 253 contains IP addresses instead of HITs, and the packet is sent to the 254 network. When the ESP packet is received, the SPI value, together 255 with the integrity protection, allow the packet to be securely 256 associated with the right HIT pair. The packet header is replaced 257 with a new header containing HITs, and the packet is decrypted. BEET 258 mode is completely internal for host and doesn't require that the 259 corresponding host implements it, instead the corresponding host can 260 have ESP transport mode and do HIT IP conversions outside ESP. 262 3.2.1. Semantics of the Security Parameter Index (SPI) 264 SPIs are used in ESP to find the right Security Association for 265 received packets. The ESP SPIs have added significance when used 266 with HIP; they are a compressed representation of a pair of HITs. 267 Thus, SPIs MAY be used by intermediary systems in providing services 268 like address mapping. Note that since the SPI has significance at 269 the receiver, only the < DST, SPI >, where DST is a destination IP 270 address, uniquely identifies the receiver HIT at any given point of 271 time. The same SPI value may be used by several hosts. A single < 272 DST, SPI > value may denote different hosts and contexts at different 273 points of time, depending on the host that is currently reachable at 274 the DST. 276 Each host selects for itself the SPI it wants to see in packets 277 received from its peer. This allows it to select different SPIs for 278 different peers. The SPI selection SHOULD be random; the rules of 279 Section 2.1 of the ESP specification [RFC4303] must be followed. A 280 different SPI SHOULD be used for each HIP exchange with a particular 281 host; this is to avoid a replay attack. Additionally, when a host 282 rekeys, the SPI MUST be changed. Furthermore, if a host changes over 283 to use a different IP address, it MAY change the SPI. 285 One method for SPI creation that meets the above criteria would be to 286 concatenate the HIT with a 32-bit random or sequential number, hash 287 this (using SHA1), and then use the high-order 32 bits as the SPI. 289 The selected SPI is communicated to the peer in the third (I2) and 290 fourth (R2) packets of the base HIP exchange. Changes in SPI are 291 signaled with ESP_INFO parameters. 293 3.3. Security Association Establishment and Maintenance 295 3.3.1. ESP Security Associations 297 In HIP, ESP Security Associations are setup between the HIP nodes 298 during the base exchange [I-D.moskowitz-hip-rfc5201-bis]. Existing 299 ESP SAs can be updated later using UPDATE messages. The reason for 300 updating the ESP SA later can be, for example, a need for rekeying 301 the SA because of sequence number rollover. 303 Upon setting up a HIP association, each association is linked to two 304 ESP SAs, one for incoming packets and one for outgoing packets. The 305 Initiator's incoming SA corresponds with the Responder's outgoing 306 one, and vice versa. The Initiator defines the SPI for its incoming 307 association, as defined in Section 3.2.1. This SA is herein called 308 SA-RI, and the corresponding SPI is called SPI-RI. Respectively, the 309 Responder's incoming SA corresponds with the Initiator's outgoing SA 310 and is called SA-IR, with the SPI being called SPI-IR. 312 The Initiator creates SA-RI as a part of R1 processing, before 313 sending out the I2, as explained in Section 6.4. The keys are 314 derived from KEYMAT, as defined in Section 7. The Responder creates 315 SA-RI as a part of I2 processing; see Section 6.5. 317 The Responder creates SA-IR as a part of I2 processing, before 318 sending out R2; see Section 6.5. The Initiator creates SA-IR when 319 processing R2; see Section 6.6. 321 The initial session keys are drawn from the generated keying 322 material, KEYMAT, after the HIP keys have been drawn as specified in 323 [I-D.moskowitz-hip-rfc5201-bis]. 325 When the HIP association is removed, the related ESP SAs MUST also be 326 removed. 328 3.3.2. Rekeying 330 After the initial HIP base exchange and SA establishment, both hosts 331 are in the ESTABLISHED state. There are no longer Initiator and 332 Responder roles and the association is symmetric. In this 333 subsection, the party that initiates the rekey procedure is denoted 334 with I' and the peer with R'. 336 An existing HIP-created ESP SA may need updating during the lifetime 337 of the HIP association. This document specifies the rekeying of an 338 existing HIP-created ESP SA, using the UPDATE message. The ESP_INFO 339 parameter introduced above is used for this purpose. 341 I' initiates the ESP SA updating process when needed (see 342 Section 6.8). It creates an UPDATE packet with required information 343 and sends it to the peer node. The old SAs are still in use, local 344 policy permitting. 346 R', after receiving and processing the UPDATE (see Section 6.9), 347 generates new SAs: SA-I'R' and SA-R'I'. It does not take the new 348 outgoing SA into use, but still uses the old one, so there 349 temporarily exists two SA pairs towards the same peer host. The SPI 350 for the new outgoing SA, SPI-R'I', is specified in the received 351 ESP_INFO parameter in the UPDATE packet. For the new incoming SA, R' 352 generates the new SPI value, SPI-I'R', and includes it in the 353 response UPDATE packet. 355 When I' receives a response UPDATE from R', it generates new SAs, as 356 described in Section 6.9: SA-I'R' and SA-R'I'. It starts using the 357 new outgoing SA immediately. 359 R' starts using the new outgoing SA when it receives traffic on the 360 new incoming SA or when it receives the UPDATE ACK confirming 361 completion of rekeying. After this, R' can remove the old SAs. 362 Similarly, when the I' receives traffic from the new incoming SA, it 363 can safely remove the old SAs. 365 3.3.3. Security Association Management 367 An SA pair is indexed by the 2 SPIs and 2 HITs (both local and remote 368 HITs since a system can have more than one HIT). An inactivity timer 369 is RECOMMENDED for all SAs. If the state dictates the deletion of an 370 SA, a timer is set to allow for any late arriving packets. 372 3.3.4. Security Parameter Index (SPI) 374 The SPIs in ESP provide a simple compression of the HIP data from all 375 packets after the HIP exchange. This does require a per HIT-pair 376 Security Association (and SPI), and a decrease of policy granularity 377 over other Key Management Protocols like IKE. 379 When a host updates the ESP SA, it provides a new inbound SPI to and 380 gets a new outbound SPI from its partner. 382 3.3.5. Supported Transforms 384 All HIP implementations MUST support AES-128-CBC [RFC3602] and HMAC- 385 SHA1 [RFC2404]. If the Initiator does not support any of the 386 transforms offered by the Responder, it should abandon the 387 negotiation and inform the peer with a NOTIFY message about a non- 388 supported transform. 390 In addition to AES-128-CBC, all implementations MUST implement the 391 ESP NULL encryption algorithm. When the ESP NULL encryption is used, 392 it MUST be used together with SHA1 authentication as specified in 393 Section 5.1.2 395 3.3.6. Sequence Number 397 The Sequence Number field is MANDATORY when ESP is used with HIP. 398 Anti-replay protection MUST be used in an ESP SA established with 399 HIP. When ESP is used with HIP, a 64-bit sequence number MUST be 400 used. This means that each host MUST rekey before its sequence 401 number reaches 2^64. 403 When using a 64-bit sequence number, the higher 32 bits are NOT 404 included in the ESP header, but are simply kept local to both peers. 405 See [RFC4301]. 407 3.3.7. Lifetimes and Timers 409 HIP does not negotiate any lifetimes. All ESP lifetimes are local 410 policy. The only lifetimes a HIP implementation MUST support are 411 sequence number rollover (for replay protection), and SHOULD support 412 timing out inactive ESP SAs. An SA times out if no packets are 413 received using that SA. The default timeout value is 15 minutes. 414 Implementations MAY support lifetimes for the various ESP transforms. 415 Each implementation SHOULD implement per-HIT configuration of the 416 inactivity timeout, allowing statically configured HIP associations 417 to stay alive for days, even when inactive. 419 3.4. IPsec and HIP ESP Implementation Considerations 421 When HIP is run on a node where a standards compliant IPsec is used, 422 some issues have to be considered. 424 The HIP implementation must be able to co-exist with other IPsec 425 keying protocols. When the HIP implementation selects the SPI value, 426 it may lead to a collision if not implemented properly. To avoid the 427 possibility for a collision, the HIP implementation MUST ensure that 428 the SPI values used for HIP SAs are not used for IPsec or other SAs, 429 and vice versa. 431 In the sending host, the HIP SA processing takes place always before 432 the IPsec processing. Vice versa, at the receiving host, the IPsec 433 processing is done first for incoming packets and the decrypted 434 packet is further given to the HIP processing. 436 Incoming packets using an SA that is not negotiated by HIP MUST NOT 437 be processed as described in Section 3.2, paragraph 2. The SPI will 438 identify the correct SA for packet decryption and MUST be used to 439 identify that the packet has an upper-layer checksum that is 440 calculated as specified in [I-D.moskowitz-hip-rfc5201-bis]. 442 3.4.1. Data Packet Processing Considerations 444 For outbound traffic, the SPD or (coordinated) SPDs if there are two 445 (one for HIP and one for IPsec) MUST ensure that packets intended for 446 HIP processing are given a HIP-enabled SA and that packets intended 447 for IPsec processing are given an IPsec-enabled SA. The SP then MUST 448 be bound to the matching SA and non-HIP packets will not be processed 449 by this SA. Data originating from a socket that is not using HIP 450 MUST NOT have checksum recalculated (as described in Section 3.2, 451 paragraph 2) and data MUST NOT be passed to the SP or SA created by 452 the HIP. 454 It is possible that in case of overlapping policies, the outgoing 455 packet would be handled both by the IPsec and HIP. In this case, it 456 is possible that the HIP association is end-to-end, while the IPsec 457 SA is for encryption between the HIP host and a Security Gateway. In 458 case of a Security Gateway ESP association, the ESP uses always 459 tunnel mode. 461 In case of IPsec tunnel mode, it is hard to see during the HIP SA 462 processing if the IPsec ESP SA has the same final destination. Thus, 463 traffic MUST be encrypted both with the HIP ESP SA and with the IPsec 464 SA when the IPsec ESP SA is used in tunnel mode. 466 In case of IPsec transport mode, the connection end-points are the 467 same. However, for HIP data packets it is not possible to avoid HIP 468 SA processing, while mapping the HIP data packet's IP addresses to 469 the corresponding HITs requires SPI values from the ESP header. In 470 case of transport mode IPsec SA, the IPsec encryption MAY be skipped 471 to avoid double encryption, if the local policy allows. 473 3.4.2. HIP Signaling Packet Considerations 475 In general, HIP signaling packets should follow the same processing 476 as HIP data packets. 478 In case of IPsec tunnel mode, the HIP signaling packets are always 479 encrypted using IPsec ESP SA. Note, that this hides the HIP 480 signaling packets from the eventual HIP middle boxes on the path 481 between the originating host and the Security Gateway. 483 In case of IPsec transport mode, the HIP signaling packets MAY skip 484 the IPsec ESP SA encryption if the local policy allows. This allows 485 the eventual HIP middle boxes to handle the passing HIP signaling 486 packets. 488 4. The Protocol 490 In this section, the protocol for setting up an ESP association to be 491 used with HIP association is described. 493 4.1. ESP in HIP 495 4.1.1. Setting Up an ESP Security Association 497 Setting up an ESP Security Association between hosts using HIP 498 consists of three messages passed between the hosts. The parameters 499 are included in R1, I2, and R2 messages during base exchange. 501 Initiator Responder 503 I1 504 ----------------------------------> 506 R1: ESP_TRANSFORM 507 <---------------------------------- 509 I2: ESP_TRANSFORM, ESP_INFO 510 ----------------------------------> 512 R2: ESP_INFO 513 <---------------------------------- 515 Setting up an ESP Security Association between HIP hosts requires 516 three messages to exchange the information that is required during an 517 ESP communication. 519 The R1 message contains the ESP_TRANSFORM parameter, in which the 520 sending host defines the possible ESP transforms it is willing to use 521 for the ESP SA. 523 The I2 message contains the response to an ESP_TRANSFORM received in 524 the R1 message. The sender must select one of the proposed ESP 525 transforms from the ESP_TRANSFORM parameter in the R1 message and 526 include the selected one in the ESP_TRANSFORM parameter in the I2 527 packet. In addition to the transform, the host includes the ESP_INFO 528 parameter containing the SPI value to be used by the peer host. 530 In the R2 message, the ESP SA setup is finalized. The packet 531 contains the SPI information required by the Initiator for the ESP 532 SA. 534 4.1.2. Updating an Existing ESP SA 536 The update process is accomplished using two messages. The HIP 537 UPDATE message is used to update the parameters of an existing ESP 538 SA. The UPDATE mechanism and message is defined in 539 [I-D.moskowitz-hip-rfc5201-bis], and the additional parameters for 540 updating an existing ESP SA are described here. 542 The following picture shows a typical exchange when an existing ESP 543 SA is updated. Messages include SEQ and ACK parameters required by 544 the UPDATE mechanism. 546 H1 H2 547 UPDATE: SEQ, ESP_INFO [, DIFFIE_HELLMAN] 548 -----------------------------------------------------> 550 UPDATE: SEQ, ACK, ESP_INFO [, DIFFIE_HELLMAN] 551 <----------------------------------------------------- 553 UPDATE: ACK 554 -----------------------------------------------------> 556 The host willing to update the ESP SA creates and sends an UPDATE 557 message. The message contains the ESP_INFO parameter containing the 558 old SPI value that was used, the new SPI value to be used, and the 559 index value for the keying material, giving the point from where the 560 next keys will be drawn. If new keying material must be generated, 561 the UPDATE message will also contain the DIFFIE_HELLMAN parameter 562 defined in [I-D.moskowitz-hip-rfc5201-bis]. 564 The host receiving the UPDATE message requesting update of an 565 existing ESP SA MUST reply with an UPDATE message. In the reply 566 message, the host sends the ESP_INFO parameter containing the 567 corresponding values: old SPI, new SPI, and the keying material 568 index. If the incoming UPDATE contained a DIFFIE_HELLMAN parameter, 569 the reply packet MUST also contain a DIFFIE_HELLMAN parameter. 571 5. Parameter and Packet Formats 573 In this section, new and modified HIP parameters are presented, as 574 well as modified HIP packets. 576 5.1. New Parameters 578 Two new HIP parameters are defined for setting up ESP transport 579 format associations in HIP communication and for rekeying existing 580 ones. Also, the NOTIFY parameter, described in 582 [I-D.moskowitz-hip-rfc5201-bis], has two new error parameters. 584 Parameter Type Length Data 586 ESP_INFO 65 12 Remote's old SPI, 587 new SPI, and other info 588 ESP_TRANSFORM 4095 variable ESP Encryption and 589 Authentication Transform(s) 591 5.1.1. ESP_INFO 593 During the establishment and update of an ESP SA, the SPI value of 594 both hosts must be transmitted between the hosts. During the 595 establishment and update of an ESP SA, the SPI value of both hosts 596 must be transmitted between the hosts. In addition, hosts need the 597 index value to the KEYMAT when they are drawing keys from the 598 generated keying material. The ESP_INFO parameter is used to 599 transmit the SPI values and the KEYMAT index information between the 600 hosts. 602 During the initial ESP SA setup, the hosts send the SPI value that 603 they want the peer to use when sending ESP data to them. The value 604 is set in the NEW SPI field of the ESP_INFO parameter. In the 605 initial setup, an old value for the SPI does not exist, thus the OLD 606 SPI value field is set to zero. The OLD SPI field value may also be 607 zero when additional SAs are set up between HIP hosts, e.g., in case 608 of multihomed HIP hosts [RFC5206]. However, such use is beyond the 609 scope of this specification. 611 RFC 4301 [RFC4301] describes how to establish multiple SAs to 612 properly support QoS. If different classes of traffic (distinguished 613 by Differentiated Services Code Point (DSCP) bits [RFC3474], 614 [RFC3260]) are sent on the same SA, and if the receiver is employing 615 the optional anti-replay feature available in ESP, this could result 616 in inappropriate discarding of lower priority packets due to the 617 windowing mechanism used by this feature. Therefore, a sender SHOULD 618 put traffic of different classes but with the same selector values on 619 different SAs to support Quality of Service (QoS) appropriately. To 620 permit this, the implementation MUST permit establishment and 621 maintenance of multiple SAs between a given sender and receiver with 622 the same selectors. Distribution of traffic among these parallel SAs 623 to support QoS is locally determined by the sender and is not 624 negotiated by HIP. The receiver MUST process the packets from the 625 different SAs without prejudice. It is possible that the DSCP value 626 changes en route, but this should not cause problems with respect to 627 IPsec processing since the value is not employed for SA selection and 628 MUST NOT be checked as part of SA/packet validation. 630 The KEYMAT index value points to the place in the KEYMAT from where 631 the keying material for the ESP SAs is drawn. The KEYMAT index value 632 is zero only when the ESP_INFO is sent during a rekeying process and 633 new keying material is generated. 635 During the life of an SA established by HIP, one of the hosts may 636 need to reset the Sequence Number to one and rekey. The reason for 637 rekeying might be an approaching sequence number wrap in ESP, or a 638 local policy on use of a key. Rekeying ends the current SAs and 639 starts new ones on both peers. 641 During the rekeying process, the ESP_INFO parameter is used to 642 transmit the changed SPI values and the keying material index. 644 0 1 2 3 645 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 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | Type | Length | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | Reserved | KEYMAT Index | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | OLD SPI | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | NEW SPI | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 Type 65 657 Length 12 658 KEYMAT Index Index, in bytes, where to continue to draw ESP keys 659 from KEYMAT. If the packet includes a new 660 Diffie-Hellman key and the ESP_INFO is sent in an 661 UPDATE packet, the field MUST be zero. If the 662 ESP_INFO is included in base exchange messages, the 663 KEYMAT Index must have the index value of the point 664 from where the ESP SA keys are drawn. Note that 665 the length of this field limits the amount of 666 keying material that can be drawn from KEYMAT. If 667 that amount is exceeded, the packet MUST contain 668 a new Diffie-Hellman key. 669 OLD SPI old SPI for data sent to address(es) associated 670 with this SA. If this is an initial SA setup, the 671 OLD SPI value is zero. 672 NEW SPI new SPI for data sent to address(es) associated 673 with this SA. 675 5.1.2. ESP_TRANSFORM 677 The ESP_TRANSFORM parameter is used during ESP SA establishment. The 678 first party sends a selection of transform families in the 679 ESP_TRANSFORM parameter, and the peer must select one of the proposed 680 values and include it in the response ESP_TRANSFORM parameter. 682 0 1 2 3 683 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 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | Type | Length | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | Reserved | Suite ID #1 | 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | Suite ID #2 | Suite ID #3 | 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 | Suite ID #n | Padding | 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 Type 4095 695 Length length in octets, excluding Type, Length, and 696 padding 697 Reserved zero when sent, ignored when received 698 Suite ID defines the ESP Suite to be used 700 The following Suite IDs can be used: 702 Suite ID Value 704 RESERVED 0 705 AES-128-CBC with HMAC-SHA1 1 [RFC3602], [RFC2404] 706 3DES-CBC with HMAC-SHA1 2 [RFC2451], [RFC2404] 707 DEPRECATED 3 708 DEPRECATED 4 709 NULL-ENCRYPT with HMAC-SHA1 5 [RFC2410], [RFC2404] 710 DEPRECATED 6 711 NULL-ENCRYPT with HMAC-SHA2 7 [RFC2410], [RFC4868] 712 AES-128-CBC with HMAC-SHA2 8 [RFC3602], [RFC4868] 713 AES-256-CBC with HMAC-SHA2 9 [RFC3602], [RFC4868] 714 AES-CCM-8 10 [RFC4309] 715 AES-CCM-16 11 [RFC4309] 716 AES-GCM with a 8 octet ICV 12 [RFC4106] 717 AES-GCM with a 16 octet ICV 13 [RFC4106] 719 The sender of an ESP transform parameter MUST make sure that there 720 are no more than six (6) Suite IDs in one ESP transform parameter. 721 Conversely, a recipient MUST be prepared to handle received transport 722 parameters that contain more than six Suite IDs. The limited number 723 of Suite IDs sets the maximum size of the ESP_TRANSFORM parameter. 724 As the default configuration, the ESP_TRANSFORM parameter MUST 725 contain at least one of the mandatory Suite IDs. There MAY be a 726 configuration option that allows the administrator to override this 727 default. 729 Mandatory implementations: AES-CBC with HMAC-SHA1 and NULL with HMAC- 730 SHA1. 732 Under some conditions, it is possible to use Traffic Flow 733 Confidentiality (TFC) [RFC4303] with ESP in BEET mode. However, the 734 definition of such operation is future work and must be done in a 735 separate specification. 737 5.1.3. NOTIFY Parameter 739 The HIP base specification defines a set of NOTIFY error types. The 740 following error types are required for describing errors in ESP 741 Transform crypto suites during negotiation. 743 NOTIFY PARAMETER - ERROR TYPES Value 744 ------------------------------ ----- 746 NO_ESP_PROPOSAL_CHOSEN 18 748 None of the proposed ESP Transform crypto suites was 749 acceptable. 751 INVALID_ESP_TRANSFORM_CHOSEN 19 753 The ESP Transform crypto suite does not correspond to 754 one offered by the Responder. 756 5.2. HIP ESP Security Association Setup 758 The ESP Security Association is set up during the base exchange. The 759 following subsections define the ESP SA setup procedure using both 760 base exchange messages (R1, I2, R2) and UPDATE messages. 762 5.2.1. Setup During Base Exchange 764 5.2.1.1. Modifications in R1 766 The ESP_TRANSFORM contains the ESP modes supported by the sender, in 767 the order of preference. All implementations MUST support AES-CBC 768 [RFC3602] with HMAC-SHA1 [RFC2404]. 770 The following figure shows the resulting R1 packet layout. 772 The HIP parameters for the R1 packet: 774 IP ( HIP ( [ R1_COUNTER, ] 775 PUZZLE, 776 DIFFIE_HELLMAN, 777 HIP_TRANSFORM, 778 ESP_TRANSFORM, 779 HOST_ID, 780 [ ECHO_REQUEST, ] 781 HIP_SIGNATURE_2 ) 782 [, ECHO_REQUEST ]) 784 5.2.1.2. Modifications in I2 786 The ESP_INFO contains the sender's SPI for this association as well 787 as the KEYMAT index from where the ESP SA keys will be drawn. The 788 old SPI value is set to zero. 790 The ESP_TRANSFORM contains the ESP mode selected by the sender of R1. 791 All implementations MUST support AES-CBC [RFC3602] with HMAC-SHA1 792 [RFC2404]. 794 The following figure shows the resulting I2 packet layout. 796 The HIP parameters for the I2 packet: 798 IP ( HIP ( ESP_INFO, 799 [R1_COUNTER,] 800 SOLUTION, 801 DIFFIE_HELLMAN, 802 HIP_TRANSFORM, 803 ESP_TRANSFORM, 804 ENCRYPTED { HOST_ID }, 805 [ ECHO_RESPONSE ,] 806 HMAC, 807 HIP_SIGNATURE 808 [, ECHO_RESPONSE] ) ) 810 5.2.1.3. Modifications in R2 812 The R2 contains an ESP_INFO parameter, which has the SPI value of the 813 sender of the R2 for this association. The ESP_INFO also has the 814 KEYMAT index value specifying where the ESP SA keys are drawn. 816 The following figure shows the resulting R2 packet layout. 818 The HIP parameters for the R2 packet: 820 IP ( HIP ( ESP_INFO, HMAC_2, HIP_SIGNATURE ) ) 822 5.3. HIP ESP Rekeying 824 In this section, the procedure for rekeying an existing ESP SA is 825 presented. 827 Conceptually, the process can be represented by the following message 828 sequence using the host names I' and R' defined in Section 3.3.2. 829 For simplicity, HMAC and HIP_SIGNATURE are not depicted, and 830 DIFFIE_HELLMAN keys are optional. The UPDATE with ACK_I need not be 831 piggybacked with the UPDATE with SEQ_R; it may be ACKed separately 832 (in which case the sequence would include four packets). 834 I' R' 836 UPDATE(ESP_INFO, SEQ_I, [DIFFIE_HELLMAN]) 837 -----------------------------------> 838 UPDATE(ESP_INFO, SEQ_R, ACK_I, [DIFFIE_HELLMAN]) 839 <----------------------------------- 840 UPDATE(ACK_R) 841 -----------------------------------> 843 Below, the first two packets in this figure are explained. 845 5.3.1. Initializing Rekeying 847 When HIP is used with ESP, the UPDATE packet is used to initiate 848 rekeying. The UPDATE packet MUST carry an ESP_INFO and MAY carry a 849 DIFFIE_HELLMAN parameter. 851 Intermediate systems that use the SPI will have to inspect HIP 852 packets for those that carry rekeying information. The packet is 853 signed for the benefit of the intermediate systems. Since 854 intermediate systems may need the new SPI values, the contents cannot 855 be encrypted. 857 The following figure shows the contents of a rekeying initialization 858 UPDATE packet. 860 The HIP parameters for the UPDATE packet initiating rekeying: 862 IP ( HIP ( ESP_INFO, 863 SEQ, 864 [DIFFIE_HELLMAN, ] 865 HMAC, 866 HIP_SIGNATURE ) ) 868 5.3.2. Responding to the Rekeying Initialization 870 The UPDATE ACK is used to acknowledge the received UPDATE rekeying 871 initialization. The acknowledgment UPDATE packet MUST carry an 872 ESP_INFO and MAY carry a DIFFIE_HELLMAN parameter. 874 Intermediate systems that use the SPI will have to inspect HIP 875 packets for packets carrying rekeying information. The packet is 876 signed for the benefit of the intermediate systems. Since 877 intermediate systems may need the new SPI values, the contents cannot 878 be encrypted. 880 The following figure shows the contents of a rekeying acknowledgment 881 UPDATE packet. 883 The HIP parameters for the UPDATE packet: 885 IP ( HIP ( ESP_INFO, 886 SEQ, 887 ACK, 888 [ DIFFIE_HELLMAN, ] 889 HMAC, 890 HIP_SIGNATURE ) ) 892 5.4. ICMP Messages 894 ICMP message handling is mainly described in the HIP base 895 specification [I-D.moskowitz-hip-rfc5201-bis]. In this section, we 896 describe the actions related to ESP security associations. 898 5.4.1. Unknown SPI 900 If a HIP implementation receives an ESP packet that has an 901 unrecognized SPI number, it MAY respond (subject to rate limiting the 902 responses) with an ICMP packet with type "Parameter Problem", with 903 the pointer pointing to the beginning of SPI field in the ESP header. 905 6. Packet Processing 907 Packet processing is mainly defined in the HIP base specification 908 [I-D.moskowitz-hip-rfc5201-bis]. This section describes the changes 909 and new requirements for packet handling when the ESP transport 910 format is used. Note that all HIP packets (currently protocol 253) 911 MUST bypass ESP processing. 913 6.1. Processing Outgoing Application Data 915 Outgoing application data handling is specified in the HIP base 916 specification [I-D.moskowitz-hip-rfc5201-bis]. When the ESP 917 transport format is used, and there is an active HIP session for the 918 given < source, destination > HIT pair, the outgoing datagram is 919 protected using the ESP security association. The following 920 additional steps define the conceptual processing rules for outgoing 921 ESP protected datagrams. 923 1. Detect the proper ESP SA using the HITs in the packet header or 924 other information associated with the packet 926 2. Process the packet normally, as if the SA was a transport mode 927 SA. 929 3. Ensure that the outgoing ESP protected packet has proper IP 930 header format depending on the used IP address family, and proper 931 IP addresses in its IP header, e.g., by replacing HITs left by 932 the ESP processing. Note that this placement of proper IP 933 addresses MAY also be performed at some other point in the stack, 934 e.g., before ESP processing. 936 6.2. Processing Incoming Application Data 938 Incoming HIP user data packets arrive as ESP protected packets. In 939 the usual case, the receiving host has a corresponding ESP security 940 association, identified by the SPI and destination IP address in the 941 packet. However, if the host has crashed or otherwise lost its HIP 942 state, it may not have such an SA. 944 The basic incoming data handling is specified in the HIP base 945 specification. Additional steps are required when ESP is used for 946 protecting the data traffic. The following steps define the 947 conceptual processing rules for incoming ESP protected datagrams 948 targeted to an ESP security association created with HIP. 950 1. Detect the proper ESP SA using the SPI. If the resulting SA is a 951 non-HIP ESP SA, process the packet according to standard IPsec 952 rules. If there are no SAs identified with the SPI, the host MAY 953 send an ICMP packet as defined in Section 5.4. How to handle 954 lost state is an implementation issue. 956 2. If the SPI matches with an active HIP-based ESP SA, the IP 957 addresses in the datagram are replaced with the HITs associated 958 with the SPI. Note that this IP-address-to-HIT conversion step 959 MAY also be performed at some other point in the stack, e.g., 960 after ESP processing. Note also that if the incoming packet has 961 IPv4 addresses, the packet must be converted to IPv6 format 962 before replacing the addresses with HITs (such that the transport 963 checksum will pass if there are no errors). 965 3. The transformed packet is next processed normally by ESP, as if 966 the packet were a transport mode packet. The packet may be 967 dropped by ESP, as usual. In a typical implementation, the 968 result of successful ESP decryption and verification is a 969 datagram with the associated HITs as source and destination. 971 4. The datagram is delivered to the upper layer. Demultiplexing the 972 datagram to the right upper layer socket is performed as usual, 973 except that the HITs are used in place of IP addresses during the 974 demultiplexing. 976 6.3. HMAC and SIGNATURE Calculation and Verification 978 The new HIP parameters described in this document, ESP_INFO and 979 ESP_TRANSFORM, must be protected using HMAC and signature 980 calculations. In a typical implementation, they are included in R1, 981 I2, R2, and UPDATE packet HMAC and SIGNATURE calculations as 982 described in [I-D.moskowitz-hip-rfc5201-bis]. 984 6.4. Processing Incoming ESP SA Initialization (R1) 986 The ESP SA setup is initialized in the R1 message. The receiving 987 host (Initiator) selects one of the ESP transforms from the presented 988 values. If no suitable value is found, the negotiation is 989 terminated. The selected values are subsequently used when 990 generating and using encryption keys, and when sending the reply 991 packet. If the proposed alternatives are not acceptable to the 992 system, it may abandon the ESP SA establishment negotiation, or it 993 may resend the I1 message within the retry bounds. 995 After selecting the ESP transform and performing other R1 processing, 996 the system prepares and creates an incoming ESP security association. 997 It may also prepare a security association for outgoing traffic, but 998 since it does not have the correct SPI value yet, it cannot activate 999 it. 1001 6.5. Processing Incoming Initialization Reply (I2) 1003 The following steps are required to process the incoming ESP SA 1004 initialization replies in I2. The steps below assume that the I2 has 1005 been accepted for processing (e.g., has not been dropped due to HIT 1006 comparisons as described in [I-D.moskowitz-hip-rfc5201-bis]). 1008 o The ESP_TRANSFORM parameter is verified and it MUST contain a 1009 single value in the parameter, and it MUST match one of the values 1010 offered in the initialization packet. 1012 o The ESP_INFO NEW SPI field is parsed to obtain the SPI that will 1013 be used for the Security Association outbound from the Responder 1014 and inbound to the Initiator. For this initial ESP SA 1015 establishment, the old SPI value MUST be zero. The KEYMAT Index 1016 field MUST contain the index value to the KEYMAT from where the 1017 ESP SA keys are drawn. 1019 o The system prepares and creates both incoming and outgoing ESP 1020 security associations. 1022 o Upon successful processing of the initialization reply message, 1023 the possible old Security Associations (as left over from an 1024 earlier incarnation of the HIP association) are dropped and the 1025 new ones are installed, and a finalizing packet, R2, is sent. 1026 Possible ongoing rekeying attempts are dropped. 1028 6.6. Processing Incoming ESP SA Setup Finalization (R2) 1030 Before the ESP SA can be finalized, the ESP_INFO NEW SPI field is 1031 parsed to obtain the SPI that will be used for the ESP Security 1032 Association inbound to the sender of the finalization message R2. 1033 The system uses this SPI to create or activate the outgoing ESP 1034 security association used for sending packets to the peer. 1036 6.7. Dropping HIP Associations 1038 When the system drops a HIP association, as described in the HIP base 1039 specification, the associated ESP SAs MUST also be dropped. 1041 6.8. Initiating ESP SA Rekeying 1043 During ESP SA rekeying, the hosts draw new keys from the existing 1044 keying material, or new keying material is generated from where the 1045 new keys are drawn. 1047 A system may initiate the SA rekeying procedure at any time. It MUST 1048 initiate a rekey if its incoming ESP sequence counter is about to 1049 overflow. The system MUST NOT replace its keying material until the 1050 rekeying packet exchange successfully completes. 1052 Optionally, a system may include a new Diffie-Hellman key for use in 1053 new KEYMAT generation. New KEYMAT generation occurs prior to drawing 1054 the new keys. 1056 The rekeying procedure uses the UPDATE mechanism defined in 1057 [I-D.moskowitz-hip-rfc5201-bis]. Because each peer must update its 1058 half of the security association pair (including new SPI creation), 1059 the rekeying process requires that each side both send and receive an 1060 UPDATE. A system will then rekey the ESP SA when it has sent 1061 parameters to the peer and has received both an ACK of the relevant 1062 UPDATE message and corresponding peer's parameters. It may be that 1063 the ACK and the required HIP parameters arrive in different UPDATE 1064 messages. This is always true if a system does not initiate ESP SA 1065 update but responds to an update request from the peer, and may also 1066 occur if two systems initiate update nearly simultaneously. In such 1067 a case, if the system has an outstanding update request, it saves the 1068 one parameter and waits for the other before completing rekeying. 1070 The following steps define the processing rules for initiating an ESP 1071 SA update: 1073 1. The system decides whether to continue to use the existing KEYMAT 1074 or to generate a new KEYMAT. In the latter case, the system MUST 1075 generate a new Diffie-Hellman public key. 1077 2. The system creates an UPDATE packet, which contains the ESP_INFO 1078 parameter. In addition, the host may include the optional 1079 DIFFIE_HELLMAN parameter. If the UPDATE contains the 1080 DIFFIE_HELLMAN parameter, the KEYMAT Index in the ESP_INFO 1081 parameter MUST be zero, and the Diffie-Hellman group ID must be 1082 unchanged from that used in the initial handshake. If the UPDATE 1083 does not contain DIFFIE_HELLMAN, the ESP_INFO KEYMAT Index MUST 1084 be greater than or equal to the index of the next byte to be 1085 drawn from the current KEYMAT. 1087 3. The system sends the UPDATE packet. For reliability, the 1088 underlying UPDATE retransmission mechanism MUST be used. 1090 4. The system MUST NOT delete its existing SAs, but continue using 1091 them if its policy still allows. The rekeying procedure SHOULD 1092 be initiated early enough to make sure that the SA replay 1093 counters do not overflow. 1095 5. In case a protocol error occurs and the peer system acknowledges 1096 the UPDATE but does not itself send an ESP_INFO, the system may 1097 not finalize the outstanding ESP SA update request. To guard 1098 against this, a system MAY re-initiate the ESP SA update 1099 procedure after some time waiting for the peer to respond, or it 1100 MAY decide to abort the ESP SA after waiting for an 1101 implementation-dependent time. The system MUST NOT keep an 1102 outstanding ESP SA update request for an indefinite time. 1104 To simplify the state machine, a host MUST NOT generate new UPDATEs 1105 while it has an outstanding ESP SA update request, unless it is 1106 restarting the update process. 1108 6.9. Processing Incoming UPDATE Packets 1110 When a system receives an UPDATE packet, it must be processed if the 1111 following conditions hold (in addition to the generic conditions 1112 specified for UPDATE processing in Section 6.12 of 1113 [I-D.moskowitz-hip-rfc5201-bis]): 1115 1. A corresponding HIP association must exist. This is usually 1116 ensured by the underlying UPDATE mechanism. 1118 2. The state of the HIP association is ESTABLISHED or R2-SENT. 1120 If the above conditions hold, the following steps define the 1121 conceptual processing rules for handling the received UPDATE packet: 1123 1. If the received UPDATE contains a DIFFIE_HELLMAN parameter, the 1124 received KEYMAT Index MUST be zero and the Group ID must match 1125 the Group ID in use on the association. If this test fails, the 1126 packet SHOULD be dropped and the system SHOULD log an error 1127 message. 1129 2. If there is no outstanding rekeying request, the packet 1130 processing continues as specified in Section 6.9.1. 1132 3. If there is an outstanding rekeying request, the UPDATE MUST be 1133 acknowledged, the received ESP_INFO (and possibly DIFFIE_HELLMAN) 1134 parameters must be saved, and the packet processing continues as 1135 specified in Section 6.10. 1137 6.9.1. Processing UPDATE Packet: No Outstanding Rekeying Request 1139 The following steps define the conceptual processing rules for 1140 handling a received UPDATE packet with the ESP_INFO parameter: 1142 1. The system consults its policy to see if it needs to generate a 1143 new Diffie-Hellman key, and generates a new key (with same Group 1144 ID) if needed. The system records any newly generated or 1145 received Diffie-Hellman keys for use in KEYMAT generation upon 1146 finalizing the ESP SA update. 1148 2. If the system generated a new Diffie-Hellman key in the previous 1149 step, or if it received a DIFFIE_HELLMAN parameter, it sets the 1150 ESP_INFO KEYMAT Index to zero. Otherwise, the ESP_INFO KEYMAT 1151 Index MUST be greater than or equal to the index of the next byte 1152 to be drawn from the current KEYMAT. In this case, it is 1153 RECOMMENDED that the host use the KEYMAT Index requested by the 1154 peer in the received ESP_INFO. 1156 3. The system creates an UPDATE packet, which contains an ESP_INFO 1157 parameter and the optional DIFFIE_HELLMAN parameter. This UPDATE 1158 would also typically acknowledge the peer's UPDATE with an ACK 1159 parameter, although a separate UPDATE ACK may be sent. 1161 4. The system sends the UPDATE packet and stores any received 1162 ESP_INFO and DIFFIE_HELLMAN parameters. At this point, it only 1163 needs to receive an acknowledgment for the newly sent UPDATE to 1164 finish ESP SA update. In the usual case, the acknowledgment is 1165 handled by the underlying UPDATE mechanism. 1167 6.10. Finalizing Rekeying 1169 A system finalizes rekeying when it has both received the 1170 corresponding UPDATE acknowledgment packet from the peer and it has 1171 successfully received the peer's UPDATE. The following steps are 1172 taken: 1174 1. If the received UPDATE messages contain a new Diffie-Hellman key, 1175 the system has a new Diffie-Hellman key due to initiating ESP SA 1176 update, or both, the system generates a new KEYMAT. If there is 1177 only one new Diffie-Hellman key, the old existing key is used as 1178 the other key. 1180 2. If the system generated a new KEYMAT in the previous step, it 1181 sets the KEYMAT Index to zero, independent of whether the 1182 received UPDATE included a Diffie-Hellman key or not. If the 1183 system did not generate a new KEYMAT, it uses the greater KEYMAT 1184 Index of the two (sent and received) ESP_INFO parameters. 1186 3. The system draws keys for new incoming and outgoing ESP SAs, 1187 starting from the KEYMAT Index, and prepares new incoming and 1188 outgoing ESP SAs. The SPI for the outgoing SA is the new SPI 1189 value received in an ESP_INFO parameter. The SPI for the 1190 incoming SA was generated when the ESP_INFO was sent to the peer. 1191 The order of the keys retrieved from the KEYMAT during the 1192 rekeying process is similar to that described in Section 7. 1193 Note, that only IPsec ESP keys are retrieved during the rekeying 1194 process, not the HIP keys. 1196 4. The system starts to send to the new outgoing SA and prepares to 1197 start receiving data on the new incoming SA. Once the system 1198 receives data on the new incoming SA, it may safely delete the 1199 old SAs. 1201 6.11. Processing NOTIFY Packets 1203 The processing of NOTIFY packets is described in the HIP base 1204 specification. 1206 7. Keying Material 1208 The keying material is generated as described in the HIP base 1209 specification. During the base exchange, the initial keys are drawn 1210 from the generated material. After the HIP association keys have 1211 been drawn, the ESP keys are drawn in the following order: 1213 SA-gl ESP encryption key for HOST_g's outgoing traffic 1215 SA-gl ESP authentication key for HOST_g's outgoing traffic 1217 SA-lg ESP encryption key for HOST_l's outgoing traffic 1219 SA-lg ESP authentication key for HOST_l's outgoing traffic 1221 HOST_g denotes the host with the greater HIT value, and HOST_l 1222 denotes the host with the lower HIT value. When HIT values are 1223 compared, they are interpreted as positive (unsigned) 128-bit 1224 integers in network byte order. 1226 The four HIP keys are only drawn from KEYMAT during a HIP I1->R2 1227 exchange. Subsequent rekeys using UPDATE will only draw the four ESP 1228 keys from KEYMAT. Section 6.9 describes the rules for reusing or 1229 regenerating KEYMAT based on the rekeying. 1231 The number of bits drawn for a given algorithm is the "natural" size 1232 of the keys. For the mandatory algorithms, the following sizes 1233 apply: 1235 AES 128 bits 1237 SHA-1 160 bits 1239 NULL 0 bits 1241 8. Security Considerations 1243 In this document, the usage of ESP [RFC4303] between HIP hosts to 1244 protect data traffic is introduced. The Security Considerations for 1245 ESP are discussed in the ESP specification. 1247 There are different ways to establish an ESP Security Association 1248 between two nodes. This can be done, e.g., using IKE [RFC4306]. 1250 This document specifies how the Host Identity Protocol is used to 1251 establish ESP Security Associations. 1253 The following issues are new or have changed from the standard ESP 1254 usage: 1256 o Initial keying material generation 1258 o Updating the keying material 1260 The initial keying material is generated using the Host Identity 1261 Protocol [I-D.moskowitz-hip-rfc5201-bis] using the Diffie-Hellman 1262 procedure. This document extends the usage of the UPDATE packet, 1263 defined in the base specification, to modify existing ESP SAs. The 1264 hosts may rekey, i.e., force the generation of new keying material 1265 using the Diffie-Hellman procedure. The initial setup of ESP SA 1266 between the hosts is done during the base exchange, and the message 1267 exchange is protected using methods provided by base exchange. 1268 Changes in connection parameters means basically that the old ESP SA 1269 is removed and a new one is generated once the UPDATE message 1270 exchange has been completed. The message exchange is protected using 1271 the HIP association keys. Both HMAC and signing of packets is used. 1273 9. IANA Considerations 1275 This document defines additional parameters and NOTIFY error types 1276 for the Host Identity Protocol [I-D.moskowitz-hip-rfc5201-bis]. 1278 The new parameters and their type numbers are defined in 1279 Section 5.1.1 and Section 5.1.2, and they have been added to the 1280 Parameter Type namespace specified in 1281 [I-D.moskowitz-hip-rfc5201-bis]. 1283 The new NOTIFY error types and their values are defined in 1284 Section 5.1.3, and they have been added to the Notify Message Type 1285 namespace specified in [I-D.moskowitz-hip-rfc5201-bis]. 1287 10. Acknowledgments 1289 This document was separated from the base "Host Identity Protocol" 1290 specification in the beginning of 2005. Since then, a number of 1291 people have contributed to the text by providing comments and 1292 modification proposals. The list of people include Tom Henderson, 1293 Jeff Ahrenholz, Jukka Ylitalo, and Miika Komu. The authors also want 1294 to thank Charlie Kaufman for reviewing the document with his eye on 1295 the usage of crypto algorithms. 1297 Due to the history of this document, most of the ideas are inherited 1298 from the base "Host Identity Protocol" specification. Thus, the list 1299 of people in the Acknowledgments section of that specification is 1300 also valid for this document. Many people have given valuable 1301 feedback, and our apologies to anyone whose name is missing. 1303 11. References 1305 11.1. Normative references 1307 [RFC2119] Bradner, S., "Key words for use in 1308 RFCs to Indicate Requirement 1309 Levels", BCP 14, RFC 2119, 1310 March 1997. 1312 [RFC2404] Madson, C. and R. Glenn, "The Use of 1313 HMAC-SHA-1-96 within ESP and AH", 1314 RFC 2404, November 1998. 1316 [RFC3602] Frankel, S., Glenn, R., and S. 1317 Kelly, "The AES-CBC Cipher Algorithm 1318 and Its Use with IPsec", RFC 3602, 1319 September 2003. 1321 [RFC4303] Kent, S., "IP Encapsulating Security 1322 Payload (ESP)", RFC 4303, 1323 December 2005. 1325 11.2. Informative references 1327 [I-D.moskowitz-hip-rfc4423-bis] Moskowitz, R., "Host Identity 1328 Protocol Architecture", 1329 draft-moskowitz-hip-rfc4423-bis-02 1330 (work in progress), June 2010. 1332 [I-D.moskowitz-hip-rfc5201-bis] Moskowitz, R., Jokela, P., 1333 Henderson, T., and T. Heer, "Host 1334 Identity Protocol", 1335 draft-moskowitz-hip-rfc5201-bis-02 1336 (work in progress), July 2010. 1338 [RFC0791] Postel, J., "Internet Protocol", 1339 STD 5, RFC 791, September 1981. 1341 [RFC2401] Kent, S. and R. Atkinson, "Security 1342 Architecture for the Internet 1343 Protocol", RFC 2401, November 1998. 1345 [RFC3260] Grossman, D., "New Terminology and 1346 Clarifications for Diffserv", 1347 RFC 3260, April 2002. 1349 [RFC3474] Lin, Z. and D. Pendarakis, 1350 "Documentation of IANA assignments 1351 for Generalized MultiProtocol Label 1352 Switching (GMPLS) Resource 1353 Reservation Protocol - Traffic 1354 Engineering (RSVP-TE) Usage and 1355 Extensions for Automatically 1356 Switched Optical Network (ASON)", 1357 RFC 3474, March 2003. 1359 [RFC4301] Kent, S. and K. Seo, "Security 1360 Architecture for the Internet 1361 Protocol", RFC 4301, December 2005. 1363 [RFC4306] Kaufman, C., "Internet Key Exchange 1364 (IKEv2) Protocol", RFC 4306, 1365 December 2005. 1367 [RFC5206] Henderson, T., Ed., "End-Host 1368 Mobility and Multihoming with the 1369 Host Identity Protocol", RFC 5206, 1370 April 2008. 1372 Appendix A. A Note on Implementation Options 1374 It is possible to implement this specification in multiple different 1375 ways. As noted above, one possible way of implementing this is to 1376 rewrite IP headers below IPsec. In such an implementation, IPsec is 1377 used as if it was processing IPv6 transport mode packets, with the 1378 IPv6 header containing HITs instead of IP addresses in the source and 1379 destination address fields. In outgoing packets, after IPsec 1380 processing, the HITs are replaced with actual IP addresses, based on 1381 the HITs and the SPI. In incoming packets, before IPsec processing, 1382 the IP addresses are replaced with HITs, based on the SPI in the 1383 incoming packet. In such an implementation, all IPsec policies are 1384 based on HITs and the upper layers only see packets with HITs in the 1385 place of IP addresses. Consequently, support of HIP does not 1386 conflict with other uses of IPsec as long as the SPI spaces are kept 1387 separate. Appendix B describes another way to implement this 1388 specification. 1390 Appendix B. Bound End-to-End Tunnel mode for ESP 1392 This section introduces an alternative way of implementing the 1393 necessary functions for HIP ESP transport. Compared to the option of 1394 implementing the required address rewrites outside of IPsec, BEET has 1395 one implementation level benefit. In BEET-way of implementing, the 1396 address rewriting information is kept in one place, at the SAD. On 1397 the other hand, when address rewriting is implemented separately, the 1398 implementation MUST make sure that the information in the SAD and the 1399 separate address rewriting DB are kept in synchrony. As a result, 1400 the BEET-mode-based way of implementing this specification is 1401 RECOMMENDED over the separate implementation as it keeps the binds 1402 the identities, encryption and locators tightly together. It should 1403 be noted that implementing BEET mode doesn't require that 1404 corresponding hosts implement it as the behavior is only visible 1405 internally in a host. 1407 The BEET mode is a combination of IPsec tunnel and transport modes 1408 and provides some of the features from both. The HIP uses HITs as 1409 the "inner" addresses and IP addresses as "outer" addresses, like IP 1410 addresses are used in the tunnel mode. Instead of tunneling packets 1411 between hosts, a conversion between inner and outer addresses is made 1412 at end-hosts and the inner address is never sent on the wire after 1413 the initial HIP negotiation. BEET provides IPsec transport mode 1414 syntax (no inner headers) with limited tunnel mode semantics (fixed 1415 logical inner addresses - the HITs - and changeable outer IP 1416 addresses). 1418 B.1. Protocol definition 1420 In this section we define the exact protocol formats and operations. 1422 B.1.1. Changes to Security Association data structures 1424 A BEET mode Security Association contains the same data as a regular 1425 tunnel mode Security Association, with the exception that the inner 1426 selectors must be single addresses and cannot be subnets. The data 1427 includes the following: 1429 A pair of inner IP addresses. 1431 A pair of outer IP addresses. 1433 Cryptographic keys and other data as defined in RFC2401 [RFC2401] 1434 Section 4.4.3. 1436 A conforming implementation MAY store the data in a way similar to a 1437 regular tunnel mode Security Association. 1439 Note that in a conforming implementation the inner and outer 1440 addresses MAY belong to different address families. All 1441 implementations that support both IPv4 and IPv6 SHOULD support both 1442 IPv4-over-IPv6 and IPv6-over-IPv4 tunneling. 1444 B.1.2. Packet format 1446 The wire packet format is identical to the ESP transport mode wire 1447 format as defined in [RFC4303] Section 3.1.1. However, the resulting 1448 packet contains outer IP addresses instead of the inner IP addresses 1449 received from the upper layer. The construction of the outer headers 1450 is defined in RFC2401 [RFC2401] Section 5.1.2. The following diagram 1451 illustrates ESP BEET mode positioning for typical IPv4 and IPv6 1452 packets. 1454 IPv4 INNER ADDRESSES 1455 -------------------- 1457 BEFORE APPLYING ESP 1458 ------------------------------ 1459 | inner IP hdr | | | 1460 | | TCP | Data | 1461 ------------------------------ 1463 AFTER APPLYING ESP, OUTER v4 ADDRESSES 1464 ---------------------------------------------------- 1465 | outer IP hdr | | | | ESP | ESP | 1466 | (any options) | ESP | TCP | Data | Trailer | ICV | 1467 ---------------------------------------------------- 1468 |<---- encryption ---->| 1469 |<-------- integrity ------->| 1471 AFTER APPLYING ESP, OUTER v6 ADDRESSES 1472 ------------------------------------------------------ 1473 | outer | new ext | | | | ESP | ESP | 1474 | IP hdr | hdrs. | ESP | TCP | Data | Trailer| ICV | 1475 ------------------------------------------------------ 1476 |<--- encryption ---->| 1477 |<------- integrity ------->| 1479 IPv4 INNER ADDRESSES with options 1480 --------------------------------- 1482 BEFORE APPLYING ESP 1483 ------------------------------ 1484 | inner IP hdr | | | 1485 | + options | TCP | Data | 1486 ------------------------------ 1488 AFTER APPLYING ESP, OUTER v4 ADDRESSES 1490 ---------------------------------------------------------- 1491 | outer IP hdr | | | | | ESP | ESP | 1492 | (any options) | ESP | PH | TCP | Data | Trailer | ICV | 1493 ---------------------------------------------------------- 1494 |<------- encryption ------->| 1495 |<----------- integrity ---------->| 1497 AFTER APPLYING ESP, OUTER v6 ADDRESSES 1498 ------------------------------------------------------------ 1499 | outer | new ext | | | | | ESP | ESP | 1500 | IP hdr | hdrs. | ESP | PH | TCP | Data | Trailer| ICV | 1501 ------------------------------------------------------------ 1502 |<------ encryption ------->| 1503 |<---------- integrity ---------->| 1505 PH Pseudo Header for IPv4 options 1507 IPv6 INNER ADDRESSES 1508 -------------------- 1510 BEFORE APPLYING ESP 1511 ------------------------------------------ 1512 | | ext hdrs | | | 1513 | inner IP hdr | if present | TCP | Data | 1514 ------------------------------------------ 1516 AFTER APPLYING ESP, OUTER v6 ADDRESSES 1517 -------------------------------------------------------------- 1518 | outer | new ext | | dest | | | ESP | ESP | 1519 | IP hdr | hdrs. | ESP | opts.| TCP | Data | Trailer | ICV | 1520 -------------------------------------------------------------- 1521 |<---- encryption ---->| 1522 |<------- integrity ------>| 1524 AFTER APPLYING ESP, OUTER v4 ADDRESSES 1525 ---------------------------------------------------- 1526 | outer | | dest | | | ESP | ESP | 1527 | IP hdr | ESP | opts.| TCP | Data | Trailer | ICV | 1528 ---------------------------------------------------- 1529 |<------- encryption -------->| 1530 |<----------- integrity ----------->| 1532 B.1.3. Cryptographic processing 1534 The outgoing packets MUST be protected exactly as in ESP transport 1535 mode [RFC4303]. That is, the upper layer protocol packet is wrapped 1536 into an ESP header, encrypted, and authenticated exactly as if 1537 regular transport mode was used. The resulting ESP packet is subject 1538 to IP header processing as defined in Appendix B.1.4 and 1539 Appendix B.1.5. The incoming ESP protected messages are verified and 1540 decrypted exactly as if regular transport mode was used. The 1541 resulting clear text packet is subject to IP header processing as 1542 defined in Appendix B.1.4 and Appendix B.1.6. 1544 B.1.4. IP header processing 1546 The biggest difference between the BEET mode and the other two modes 1547 is in IP header processing. In the regular transport mode the IP 1548 header is kept intact. In the regular tunnel mode an outer IP header 1549 is created on output and discarded on input. In the BEET mode the IP 1550 header is replaced with another one on both input and output. 1552 On the BEET mode output side, the IP header processing MUST first 1553 ensure that the IP addresses in the original IP header contain the 1554 inner addresses as specified in the SA. This MAY be ensured by 1555 proper policy processing, and it is possible that no checks are 1556 needed at the SA processing time. Once the IP header has been 1557 verified to contain the right IP inner addresses, it is discarded. A 1558 new IP header is created, using the discarded inner header as a hint 1559 for other fields but the IP addresses. The IP addresses in the new 1560 header MUST be the outer tunnel addresses. 1562 On input side, the received IP header is simply discarded. Since the 1563 packet has been decrypted and verified, no further checks are 1564 necessary. A new IP header, corresponding to a tunnel mode inner 1565 header, is created, using the discarded outer header as a hint for 1566 other fields but the IP addresses. The IP addresses in the new 1567 header MUST be the inner addresses. 1569 As the outer header fields are used as hint for creating inner 1570 header, it must be noted that inner header differs as compared to 1571 tunnel-mode inner header. In BEET mode the inner header will have 1572 the TTL, DF-bit and other option values from the outer header. The 1573 TTL, DF-bit and other option values of the inner header MUST be 1574 processed by the stack. 1576 B.1.5. Handling of outgoing packets 1578 The outgoing BEET mode packets are processed as follows: 1580 1. The system MUST verify that the IP header contains the inner 1581 source and destination addresses, exactly as defined in the SA. 1582 This verification MAY be explicit, or it MAY be implicit, for 1583 example, as a result of prior policy processing. Note that in 1584 some implementations there may be no real IP header at this time 1585 but the source and destination addresses may be carried out-of- 1586 band. In case the source address is still unassigned, it SHOULD 1587 be ensured that the designated inner source address would be 1588 selected at a later stage. 1590 2. The IP payload (the contents of the packet beyond the IP header) 1591 is wrapped into an ESP header as defined in [RFC4303] Section 1592 3.3. 1594 3. A new IP header is constructed, replacing the original one. The 1595 new IP header MUST contain the outer source and destination 1596 addresses, as defined in the SA. Note that in some 1597 implementations there may be no real IP header at this time but 1598 the source and destination addresses may be carried out-of-band. 1599 In the case where the source address must be left unassigned, it 1600 SHOULD be made sure that the right source address is selected at 1601 a later stage. Other than the addresses, it is RECOMMENDED that 1602 the new IP header copies the fields from the original IP header. 1604 4. If there are any IPv4 options in the original packet, it is 1605 RECOMMENDED that they are discarded. If the inner header 1606 contains one or more options that need to be transported between 1607 the tunnel end-points, sender MUST encapsulate the options as 1608 defined in Appendix B.1.7 1610 Instead of literally discarding the IP header and constructing a new 1611 one, a conforming implementation MAY simply replace the addresses in 1612 an existing header. However, if the RECOMMENDED feature of allowing 1613 the inner and outer addresses from different address families is 1614 used, this simple strategy does not work. 1616 B.1.6. Handling of incoming packets 1618 The incoming BEET mode packets are processed as follows: 1620 1. The system MUST verify and decrypt the incoming packet 1621 successfully, as defined in [RFC4303] section 3.4. If the 1622 verification or decryption fails, the packet MUST be discarded. 1624 2. The original IP header is simply discarded, without any checks. 1625 Since the ESP verification succeeded, the packet can be safely 1626 assumed to have arrived from the right sender. 1628 3. A new IP header is constructed, replacing the original one. The 1629 new IP header MUST contain the inner source and destination 1630 addresses, as defined in the SA. If the sender has set the ESP 1631 next protocol field to 94 and included the pseudo header as 1632 described in Appendix B.1.7, the receiver MUST include the 1633 options after the constructed IP header. Note, that in some 1634 implementations the real IP header may have already been 1635 discarded and the source and destination addresses are carried 1636 out-of-band. In such case the out-of-band addresses MUST be the 1637 inner addresses. Other than the addresses, it is RECOMMENDED 1638 that the new IP header copies the fields from the original IP 1639 header. 1641 Instead of literally discarding the IP header and constructing a new 1642 one a conforming implementation MAY simply replace the addresses in 1643 an existing header. However, if the RECOMMENDED feature of allowing 1644 the inner and outer addresses from different address families is 1645 used, this simple strategy does not work. 1647 B.1.7. IPv4 options handling 1649 In BEET mode, if IPv4 options are transported inside the tunnel, the 1650 sender MUST include a pseudo-header after ESP header. The pseudo- 1651 header identifies that IPv4 options from the original packet are to 1652 be applied on the packet on input side. 1654 The sender MUST set the next protocol field on the ESP header as 94. 1655 The resulting pseudo header including the IPv4 options MUST be padded 1656 to 8 octet boundary. The padding length is expressed in octets, 1657 valid padding lengths are 0 or 4 octets as the original IPv4 options 1658 are already padded to 4 octet boundary. The padding MUST be filled 1659 with NOP options as defined in [RFC0791]Internet Protocol section 3.1 1660 Internet header format. The padding is added in front of the 1661 original options to ensure that the receiver is able to reconstruct 1662 the original IPv4 datagram. The Header Length field contains the 1663 length of the IPv4 options, and padding in 8 octets units. 1665 0 1 2 3 1666 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 1667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1668 | Next Header | Header Len | Pad Len | Reserved | 1669 +---------------+---------------+-------------------------------+ 1670 | Padding (if needed) | 1671 +---------------------------------------------------------------+ 1672 | IPv4 options ... | 1673 | | 1674 +---------------------------------------------------------------+ 1676 Next Header Identifies the data following this header 1677 Length in octets 8-bit unsigned integer. Length of the 1678 pseudo header in 8-octet units, not 1679 including the first 8 octets. 1681 The receiver MUST remove this pseudo-header and padding as a part of 1682 BEET processing, in order reconstruct the original IPv4 datagram. 1683 The IPv4 options included into the pseudo-header MUST be added after 1684 the reconstructed IPv4 (inner) header on the receiving side. 1686 Authors' Addresses 1688 Petri Jokela 1689 Ericsson Research NomadicLab 1690 JORVAS FIN-02420 1691 FINLAND 1693 Phone: +358 9 299 1 1694 EMail: petri.jokela@nomadiclab.com 1696 Robert Moskowitz 1697 ICSA labs, An Independent Division of Verizon Business 1698 1000 Bent Creek Blvd, Suite 200 1699 Mechanicsburg, PA 1700 USA 1702 EMail: rgm@icsalabs.com 1704 Pekka Nikander 1705 Ericsson Research NomadicLab 1706 JORVAS FIN-02420 1707 FINLAND 1709 Phone: +358 9 299 1 1710 EMail: pekka.nikander@nomadiclab.com 1712 Jan Melen 1713 Ericsson Research NomadicLab 1714 JORVAS FIN-02420 1715 FINLAND 1717 Phone: +358 9 299 1 1718 EMail: jan.melen@nomadiclab.com