idnits 2.17.1 draft-moskowitz-hip-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 20 instances of too long lines in the document, the longest one being 5 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1063 has weird spacing: '...ariable publ...' == Line 1262 has weird spacing: '...c Value the ...' == Line 1361 has weird spacing: '...dentity actua...' == Line 1391 has weird spacing: '... length len...' == Line 1392 has weird spacing: '...dentity actua...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: All compliant implementations MUST produce R1 packets. An R1 packet MAY be precomputed. An R1 packet MAY be reused for time Delta T, which is implementation dependent. R1 information MUST not be discarded until Delta S after T. Time S is the delay needed for the last I2 to arrive back to the responder. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 23, 2003) is 7490 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) -- Looks like a reference, but probably isn't: 'RFC2536' on line 1369 -- Looks like a reference, but probably isn't: 'RFC3110' on line 1370 == Missing Reference: '0' is mentioned on line 3277, but not defined == Unused Reference: '5' is defined on line 2969, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 2995, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2408 (ref. '5') (Obsoleted by RFC 4306) ** Downref: Normative reference to an Informational RFC: RFC 2412 (ref. '6') ** Obsolete normative reference: RFC 2460 (ref. '8') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2535 (ref. '9') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 3280 (ref. '11') (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 3484 (ref. '12') (Obsoleted by RFC 6724) ** Obsolete normative reference: RFC 3513 (ref. '13') (Obsoleted by RFC 4291) == Outdated reference: A later version (-10) exists of draft-ietf-ipsec-esp-v3-06 == Outdated reference: A later version (-17) exists of draft-ietf-ipsec-ikev2-10 == Outdated reference: A later version (-06) exists of draft-moskowitz-hip-arch-03 -- Possible downref: Normative reference to a draft: ref. '17' -- Possible downref: Non-RFC (?) normative reference: ref. '18' -- No information found for draft-nikander-hip-nat - is the name correct? Summary: 9 errors (**), 0 flaws (~~), 15 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Moskowitz 3 Internet-Draft ICSAlabs, a Division of TruSecure 4 Expires: April 22, 2004 Corporation 5 P. Nikander (editor) 6 P. Jokela 7 Ericsson Research Nomadiclab 8 T. Henderson 9 The Boeing Company 10 October 23, 2003 12 Host Identity Protocol 13 draft-moskowitz-hip-08 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that other 22 groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at http:// 30 www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 22, 2004. 37 Copyright Notice 39 Copyright (C) The Internet Society (2003). All Rights Reserved. 41 Abstract 43 This memo specifies the details of the Host Identity Protocol (HIP). 44 The overall description of protocol and the underlying architectural 45 thinking is available in the separate HIP architecture specification. 46 The Host Identity Protocol is used to establish a rapid 47 authentication between two hosts and to provide continuity of 48 communications between those hosts independent of the networking 49 layer. 51 The various forms of the Host Identity, Host Identity Tag (HIT) and 52 Local Scope Identifier (LSI), are covered in detail. It is described 53 how they are used to support authentication and the establishment of 54 keying material, which is then used by IPsec Encapsulated Security 55 payload (ESP) to establish a two-way secured communication channel 56 between the hosts. The basic state machine for HIP provides a HIP 57 compliant host with the resiliency to avoid many denial-of-service 58 (DoS) attacks. The basic HIP exchange for two public hosts shows the 59 actual packet flow. Other HIP exchanges, including those that work 60 across NATs are covered elsewhere. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5 65 1.1 A new name space and identifiers . . . . . . . . . . . . . 5 66 1.2 The HIP protocol . . . . . . . . . . . . . . . . . . . . . 5 67 2. Conventions used in this document . . . . . . . . . . . . 7 68 3. Host Identifier (HI) and its representations . . . . . . . 8 69 3.1 Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 8 70 3.1.1 Generating a HIT from a HI . . . . . . . . . . . . . . . . 8 71 3.2 Local Scope Identifier (LSI) . . . . . . . . . . . . . . . 9 72 3.3 Security Parameter Index (SPI) . . . . . . . . . . . . . . 10 73 3.4 Difference between an LSI and the SPI . . . . . . . . . . 11 74 3.5 TCP and UDP pseudo-header computation . . . . . . . . . . 11 75 4. Host Identity Protocol . . . . . . . . . . . . . . . . . . 12 76 4.1 HIP base exchange . . . . . . . . . . . . . . . . . . . . 12 77 4.1.1 HIP Cookie Mechanism . . . . . . . . . . . . . . . . . . . 13 78 4.1.2 Authenticated Diffie-Hellman protocol . . . . . . . . . . 15 79 4.1.3 HIP Birthday . . . . . . . . . . . . . . . . . . . . . . . 16 80 4.2 Sending data on HIP packets . . . . . . . . . . . . . . . 16 81 4.3 Rekey . . . . . . . . . . . . . . . . . . . . . . . . . . 16 82 4.4 Bootstrap support . . . . . . . . . . . . . . . . . . . . 16 83 4.5 Certificate distribution . . . . . . . . . . . . . . . . . 17 84 5. HIP packet flow and state machine . . . . . . . . . . . . 18 85 5.1 HIP Scenarios . . . . . . . . . . . . . . . . . . . . . . 18 86 5.2 Refusing a HIP exchange . . . . . . . . . . . . . . . . . 19 87 5.3 Reboot and SA timeout restart of HIP . . . . . . . . . . . 19 88 5.4 HIP State Machine . . . . . . . . . . . . . . . . . . . . 20 89 5.4.1 HIP States . . . . . . . . . . . . . . . . . . . . . . . . 20 90 5.4.2 HIP State Processes . . . . . . . . . . . . . . . . . . . 20 91 5.4.3 Simplified HIP State Diagram . . . . . . . . . . . . . . . 22 92 6. Packet formats . . . . . . . . . . . . . . . . . . . . . . 24 93 6.1 Payload format . . . . . . . . . . . . . . . . . . . . . . 24 94 6.1.1 HIP Controls . . . . . . . . . . . . . . . . . . . . . . . 25 95 6.1.2 Checksum . . . . . . . . . . . . . . . . . . . . . . . . . 25 96 6.2 HIP parameters . . . . . . . . . . . . . . . . . . . . . . 26 97 6.2.1 TLV format . . . . . . . . . . . . . . . . . . . . . . . . 27 98 6.2.2 Defining new parameters . . . . . . . . . . . . . . . . . 28 99 6.2.3 SPI_LSI . . . . . . . . . . . . . . . . . . . . . . . . . 29 100 6.2.4 BIRTHDAY_COOKIE . . . . . . . . . . . . . . . . . . . . . 29 101 6.2.5 DIFFIE_HELLMAN . . . . . . . . . . . . . . . . . . . . . . 30 102 6.2.6 HIP_TRANSFORM . . . . . . . . . . . . . . . . . . . . . . 31 103 6.2.7 ESP_TRANSFORM . . . . . . . . . . . . . . . . . . . . . . 31 104 6.2.8 HOST_ID . . . . . . . . . . . . . . . . . . . . . . . . . 32 105 6.2.9 HOST_ID_FQDN . . . . . . . . . . . . . . . . . . . . . . . 33 106 6.2.10 CERT . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 107 6.2.11 HMAC . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 108 6.2.12 HIP_SIGNATURE . . . . . . . . . . . . . . . . . . . . . . 35 109 6.2.13 HIP_SIGNATURE_2 . . . . . . . . . . . . . . . . . . . . . 36 110 6.2.14 NES_INFO . . . . . . . . . . . . . . . . . . . . . . . . . 37 111 6.2.15 ENCRYPTED . . . . . . . . . . . . . . . . . . . . . . . . 38 112 7. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 40 113 7.1 I1 - the HIP initiator packet . . . . . . . . . . . . . . 40 114 7.2 R1 - the HIP responder packet . . . . . . . . . . . . . . 41 115 7.3 I2 - the second HIP initiator packet . . . . . . . . . . . 42 116 7.4 R2 - the second HIP responder packet . . . . . . . . . . . 43 117 7.5 NES - the HIP New SPI Packet . . . . . . . . . . . . . . . 43 118 7.6 BOS - the HIP Bootstrap Packet . . . . . . . . . . . . . . 44 119 7.7 CER - the HIP Certificate Packet . . . . . . . . . . . . . 45 120 7.8 PAYLOAD - the HIP Payload Packet . . . . . . . . . . . . . 45 121 8. Packet processing . . . . . . . . . . . . . . . . . . . . 47 122 8.1 Processing outgoing application data . . . . . . . . . . . 47 123 8.2 Processing incoming application data . . . . . . . . . . . 48 124 8.3 Initiation of a HIP exchange . . . . . . . . . . . . . . . 49 125 8.3.1 Sending multiple I1s in parallel . . . . . . . . . . . . . 50 126 8.3.2 Processing incoming ICMP Protocol Unreachable messages . . 50 127 8.4 Processing incoming I1 packets . . . . . . . . . . . . . . 50 128 8.4.1 R1 Management . . . . . . . . . . . . . . . . . . . . . . 51 129 8.5 Processing incoming R1 packets . . . . . . . . . . . . . . 51 130 8.6 Processing incoming I2 packets . . . . . . . . . . . . . . 54 131 8.7 Processing incoming R2 packets . . . . . . . . . . . . . . 56 132 8.8 Initiating rekeying . . . . . . . . . . . . . . . . . . . 57 133 8.9 Processing NES packets . . . . . . . . . . . . . . . . . . 58 134 8.9.1 Processing an initial NES packet . . . . . . . . . . . . . 59 135 8.9.2 Processing a reply NES packet . . . . . . . . . . . . . . 60 136 8.10 Processing BOS packets . . . . . . . . . . . . . . . . . . 60 137 8.11 Processing CER packets . . . . . . . . . . . . . . . . . . 60 138 8.12 Processing PAYLOAD packets . . . . . . . . . . . . . . . . 61 139 9. HIP KEYMAT . . . . . . . . . . . . . . . . . . . . . . . . 62 140 10. HIP Fragmentation Support . . . . . . . . . . . . . . . . 64 141 11. ESP with HIP . . . . . . . . . . . . . . . . . . . . . . . 65 142 11.1 Security Association Management . . . . . . . . . . . . . 65 143 11.2 Security Parameter Index (SPI) . . . . . . . . . . . . . . 65 144 11.3 Supported Transforms . . . . . . . . . . . . . . . . . . . 65 145 11.4 Sequence Number . . . . . . . . . . . . . . . . . . . . . 65 146 12. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . 67 147 13. Security Considerations . . . . . . . . . . . . . . . . . 68 148 14. IANA Considerations . . . . . . . . . . . . . . . . . . . 70 149 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 71 150 Normative references . . . . . . . . . . . . . . . . . . . 72 151 Informative references . . . . . . . . . . . . . . . . . . 74 152 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 74 153 A. Backwards compatibility API issues . . . . . . . . . . . . 76 154 B. Probabilities of HIT collisions . . . . . . . . . . . . . 79 155 C. Probabilities in the cookie calculation . . . . . . . . . 80 156 D. Using responder cookies . . . . . . . . . . . . . . . . . 81 157 E. Running HIP over IPv4 UDP . . . . . . . . . . . . . . . . 84 158 Intellectual Property and Copyright Statements . . . . . . 85 160 1. Introduction 162 The Host Identity Protocol (HIP) provides a rapid exchange of Host 163 Identities between two hosts. The exchange also establishes a pair 164 IPsec Security Associations (SA), to be used with IPsec Encapsulated 165 Security Payload (ESP) [15]. The HIP protocol is designed to be 166 resistant to Denial-of-Service (DoS) and Man-in-the-middle (MitM) 167 attacks, and when used to enable ESP, provides DoS and MitM 168 protection for upper layer protocols, such as TCP and UDP. 170 1.1 A new name space and identifiers 172 The Host Identity Protocol introduces a new namespace, the Host 173 Identity. The effects of this change are explained in the companion 174 document, the HIP architecture [17] specification. 176 There are three representations of the Host Identity, the full Host 177 Identifier (HI), the Host Identity Tag (HIT), and the Local Scope 178 Identifier (LSI). Three representations are used, as each meets a 179 different design goal of HIP, and none of them can be removed and 180 meet these goals. The HI represents directly the Identity. It is a 181 public key. Since there are different public key algorithms that can 182 be used with different key lengths, the HI is not good for using as a 183 packet identifier, or as a index into the various operational tables 184 needed to support HIP. 186 A hash of the HI, the Host Identity Tag (HIT), thus becomes the 187 operational representation. It is 128 bits long. It is used in the 188 HIP payloads, and it is intended be used to index the corresponding 189 state in the end hosts. 191 In many environments, 128 bits is still considered large. For 192 example, currently used IPv4 based applications are constrained with 193 32 bit API fields. Thus, the third representation, the 32 bit LSI, 194 is needed. The LSI provides a compression of the HIT with only a 195 local scope so that it can be carried efficiently in any application 196 level packet and used in API calls. 198 1.2 The HIP protocol 200 The base HIP exchange consists of four packets. The four-packet 201 design helps to make HIP DoS resilient. The protocol exchanges 202 Diffie-Hellman keys in the 2nd and 3rd packets, and authenticates the 203 parties in the 3rd and 4th packets. Additionally, it starts the 204 cookie exchange in the 2nd packet, completing it in the 3rd packet. 206 The exchange uses the Diffie-Hellman exchange to hide the Host 207 Identity of the Initiator in packet 3. The Responder's Host Identity 208 is not protected. It should be noted, however, that both the 209 Initiator's and the Responder's HITs are transported as such (in 210 cleartext) in the packets, allowing an eavesdropper with a priori 211 knowledge about the parties to verify their identies. 213 Data packets start after the 4th packet. The 3rd and 4th HIP packets 214 may carry a data payload in the future. However, the details of this 215 are to be defined later as more implementation experience is gained. 217 Finally, HIP is designed as an end-to-end authentication and key 218 establishment protocol. It lacks much of the fine-grain policy 219 control found in IKE that allows IKE to support complex gateway 220 policies. Thus, HIP is not a complete replacement for IKE. 222 2. Conventions used in this document 224 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 225 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 226 document are to be interpreted as described in RFC2119 [3]. 228 3. Host Identifier (HI) and its representations 230 The structure of the Host Identifier (HI) is the public key of an 231 asymmetric key pair. Correspondingly, the host itself is entity that 232 holds the private key from the key pair. See the HIP architecture 233 specification [17] for more details about the difference between an 234 identity and the corresponding identifier. 236 DSA is the MUST implement public key algorithm for all HIP 237 implementations, other algorithms MAY be supported. DSA was chosen 238 as the default algorithm due to its small signature size. 240 A Host Identity Tag (HIT) is used in protocols to represent the Host 241 Identity. Another representation of the Host Identity, the Local 242 Scope Identifier (LSI), can also be used in protocols and APIs. 243 LSI's advantage over HIT is its size; its disadvantage is its local 244 scope. 246 3.1 Host Identity Tag (HIT) 248 The Host Identity Tag is a 128 bit value -- a hash of the Host 249 Identifier. There are two advantages of using a hash over the actual 250 Identity in protocols. Firstly, its fixed length makes for easier 251 protocol coding and also better manages the packet size cost of this 252 technology. Secondly, it presents a consistent format to the 253 protocol whatever underlying identity technology is used. 255 There are two types of HITs. HITs of the first type, called *type 1 256 HIT*, consist of an initial 2 bit prefix of 01, followed by 126 bits 257 of the SHA-1 hash of the public key. HITs of the second type consist 258 of an initial 2 bit prefix of 10, a Host Assigning Authority (HAA) 259 field, and only the last 64 bits come from a SHA-1 hash of the Host 260 Identity. This latter format for HIT is recommended for 'well known' 261 systems. It is possible to support a resolution mechanism for these 262 names in hierarchical directories, like the DNS. Another use of HAA 263 is in policy controls, see Section 12. 265 This document fully specifies only type 1 HITs. HITs that consists 266 of the HAA field and the hash are specified in [20]. 268 Any conforming implementation MUST be able to deal with both types of 269 HITs. When handling other than type 1 HITs, the implementation is 270 RECOMMENDED to explicitly learn and record the binding between the 271 Host Identifier and the HIT, as it may not be able generate such HITs 272 from Host Identifiers. 274 3.1.1 Generating a HIT from a HI 275 The 126 or 64 hash bits in a HIT MUST be generated by taking the 276 least significant 126 or 64 bits of the SHA-1 [18] hash of the Host 277 Identifier as it is represented in the Host Identity field in a HIP 278 payload packet. 280 For Identities that are DSA public keys, the HIT is formed as 281 follows: 283 1. The DSA public key is encoded as defined in RFC2536 [10] Section 284 2, taking the fields T, Q, P, G, and Y, concatenated. Thus, the 285 data to be hashed is 1 + 20 + 3 * 64 + 3 * 8 * T octets long, 286 where T is the size parameter as defined in RFC2536 [10]. The 287 size parameter T, affecting the field lengths, MUST be selected 288 as the minimum value that is long enough to accomodate P, G, and 289 Y. The fields MUST be encoded in network byte order, as defined 290 in RFC2536 [10]. 292 2. A SHA-1 hash [18] is calculated over the encoded key. 294 3. The least significant 126 or 64 bits of the hash result are used 295 to create the HIT, as defined above. 297 The following pseudo-code illustrates the process. The symbol := 298 denotes assignment; the symbol += denotes appending. The 299 pseudo-function encode_in_network_byte_order takes two parameters, an 300 integer (bignum) and a length in bytes, and returns the integer 301 encoded into a byte string of the given length. 303 buffer := encode_in_network_byte_order ( DSA.T , 1 ) 304 buffer += encode_in_network_byte_order ( DSA.Q , 20 ) 305 buffer += encode_in_network_byte_order ( DSA.P , 64 + 8 * T ) 306 buffer += encode_in_network_byte_order ( DSA.G , 64 + 8 * T ) 307 buffer += encode_in_network_byte_order ( DSA.Y , 64 + 8 * T ) 309 digest := SHA-1 ( buffer ) 311 hit_126 := concatenate ( 01 , low_order_bits ( digest, 126 ) ) 312 hit_haa := concatenate ( 10 , HAA, low_order_bits ( digest, 64 ) ) 314 3.2 Local Scope Identifier (LSI) 316 LSIs are 32-bit localized representations of a Host Identity. The 317 purpose of an LSI is to facilitate using Host Identities in existing 318 IPv4 based protocols and APIs. The owner of the Host Identity does 319 not set the LSI that other hosts use for it; each host selects the 320 LSIs that it uses for representing its partners. 322 A *local LSI* is an LSI that a remote host has assigned to a host. 323 In some implementations, local LSIs may be assigned to some interface 324 as an IP address. A *remote LSI* is an LSI that the host has 325 assigned to represent a remote host (and that the remote host has 326 accepted). 328 The LSIs MUST be allocated from the 1.0.0.0/8 subnet. That makes it 329 easier to differentiate between LSIs and IPv4 addresses at the API 330 level. By default, the low order 24 bits of an LSI SHOULD be equal 331 with the low order 24 bits of the corresponding HIT. That allows 332 easier mapping between LSIs and HITs, and makes the LSI assigned to a 333 host to be a fixed one. 335 If a host is forming a remote LSI for a HIT whose low order 24 bits 336 are equal with another already existing remote LSI, the host MAY 337 select another LSI to represent that host. If the low order 24 bits 338 of a remote HIT are equal to the low order 24 bits of a local LSI, 339 the host MAY select a different LSI to represent the remote host. In 340 either case, the host SHOULD assign the low order 24 bits of the LSI 341 randomly. All hosts SHOULD be prepared to handle local LSIs whose 342 low order 24 bits do not match with any of their own HITs. Note that 343 any such mechanisms may be subject to implementation complications, 344 see Appendix A. 346 If the LSI assigned by a peer to represent a host is unacceptable, 347 the host MAY terminate the HIP four-way handshake and start anew. 349 It is possible that the HITs of two remote hosts have equal low order 350 24 bits. Since HITs are basically random, if a host is communicating 351 with 1000 other hosts, the risk of such collision is roughly 0.006%, 352 and for a host communicating with 10000 other hosts, the risk is 353 about 0.06%. However, given a population of 100000 hosts, each 354 communicating with 1000 other hosts, the probability that there were 355 no collisions at all is only about 2%. In other words, even though 356 collisions are fairly rare events for any given host, they will 357 happen, and there must be a way to handle them. However, this 358 specification does not currently specify any such way. A future 359 version of this specification is expected to include a definition; 360 see also the discussion in Appendix A. 362 3.3 Security Parameter Index (SPI) 364 SPIs are used in ESP to find the right security association for 365 received packets. The ESP SPIs have added significance when used 366 with HIP; they are a compressed representation of the HITs in every 367 packet. Thus, SPIs MAY be used by intermediary systems in providing 368 services like address mapping. Note that since the SPI has 369 significance at the receiver, only the < DST, SPI >, where DST is a 370 destination IP address, uniquely identifies the receiver HIT at every 371 given point of time. The same SPI value may be used by several 372 hosts. A single < DST, SPI > value may denote different hosts at 373 different points of time, depending on which host is currently 374 reachable at the DST. 376 Each host selects for itself the SPI it wants to see in packets 377 received from its peer. This allows it to select different SPIs for 378 different peers. The SPI selection SHOULD be random; the rules of 379 Section 2.1 of the ESP specification [15] must be followed. A 380 different SPI SHOULD be used for each HIP exchange with a particular 381 host; this is to avoid a replay attack. Additionally, when a host 382 rekeys, the SPI MUST be changed. Furthermore, if a host changes over 383 to use a different IP address, it MAY change the SPI. 385 One method for SPI creation that meets these criteria would be to 386 concatenate the HIT with a 32 bit random or sequential number, hash 387 this (using SHA1), and then use the high order 32 bits as the SPI. 389 The selected SPI is communicated to the peer in the third (I2) and 390 fourth (R2) packets of the base HIP exchange. Changes in SPI are 391 signalled with NES packets. 393 3.4 Difference between an LSI and the SPI 395 There is a subtle difference between an LSI and a SPI. 397 The LSI is designed to be relatively long-lived. A system selects 398 the LSI it locally uses to represent its peer, and it SHOULD reuse a 399 previous LSI for a HIT during a subsequent HIP exchange. This could 400 be important in a timeout recovery situation. The LSI only appears 401 in the 3rd and 4th HIP packets. The LSI is used anywhere in system 402 processes where IP addresses have traditionally have been used, like 403 in TCBs, IPv4 API calls, and FTP PORT commands. 405 The SPI is short-lived. It changes with each HIP exchange and with a 406 HIP rekey. A system notifies its peer of the SPI to use in ESP 407 packets sent to it. Since the SPI is in all but the first two HIP 408 packets, it can be used in intermediary systems to assist in address 409 remapping. 411 3.5 TCP and UDP pseudo-header computation 413 When computing TCP and UDP checksums on sockets bound to HITs or 414 LSIs, the IPv6 pseudo-header format [8] is used. Additionally, the 415 HITs MUST be used in the place of the IPv6 addresses in the IPv6 416 pseudo-header. Note that the pseudo-header for actual HIP payloads 417 is computed differently; see Section 6.1.2. 419 4. Host Identity Protocol 421 The Host Identity Protocol is IP protocol TBD. The HIP payload could 422 be carried in every datagram. However, since HIP datagrams are 423 relatively large (at least 40 bytes), and ESP already has all of the 424 functionality to maintain and protect state, the HIP payload is 425 'compressed' into an ESP payload after the HIP exchange. Thus in 426 practice, HIP packets only occur in datagrams to establish or change 427 HIP state. 429 For testing purposes, the protocol number 99 is currently used. 431 4.1 HIP base exchange 433 The base HIP exchange serves to manage the establishment of state 434 between an Initiator and a Responder. The Initiator first sends a 435 trigger packet, I1, to the Responder. The second packet, R1, starts 436 the actual exchange. It contains a puzzle, that is, a cryptographic 437 challenge that the Initiator must solve before continuing the 438 exchange. In its reply, I2, the Initiator must display the solution. 439 Without a solution the I2 message is simply discarded. 441 The last three packets of the exchange, R1, I2, and R2, constitute a 442 standard authenticated Diffie-Hellman key exchange. The base 443 exchange is illustrated below. 445 Initiator Responder 447 I1: trigger exchange 448 --------------------------> 449 select pre-computed R1 450 R1: puzzle, D-H, key, sig 451 <------------------------- 452 check sig remain stateless 453 solve puzzle 454 I2: solution, D-H, {key}, sig 455 --------------------------> 456 compute D-H check cookie 457 check puzzle 458 check sig 459 R2: sig 460 <-------------------------- 461 check sig compute D-H 463 In this section we cover the overall design of the base exchange. 464 The details are the subject of the rest of this memo. 466 4.1.1 HIP Cookie Mechanism 468 The purpose of the HIP cookie mechanism is to protect the Responder 469 from a number of denial-of-service threats. It allows the Responder 470 to delay state creation until receiving I2. Furthermore, the puzzle 471 included in the cookie allows the Responder to use a fairly cheap 472 calculation to check that the Initiator is "sincere" in the sense 473 that it has churned CPU cycles in solving the puzzle. 475 The Cookie mechanism has been explicitly designed to give space for 476 various implementation options. It allows a responder implementation 477 to completely delay session specific state creation until a valid I2 478 is received. In such a case a validly formatted I2 can be rejected 479 earliest only once the Responder has checked its validity by 480 computing one hash function. On the other hand, the design also 481 allows a responder implementation to keep state about received I1s, 482 and match the received I2s against the state, thereby allowing the 483 implementation to avoid the computational cost of the hash function. 484 The drawback of this latter approach is the requirement of creating 485 state. Finally, it also allows an implementation to use any 486 combination of the space-saving and computation-saving mechanisms. 488 One possible way for a Responder to remain stateless but drop most 489 spoofed I2s is to base the selection of the cookie on some function 490 over the Initiator's Host Identity. The idea is that the Responder 491 has a (perhaps varying) number of pre-calculated R1 packets, and it 492 selects one of these based on the information carried in I1. When 493 the Responder then later receives I2, it checks that the cookie in 494 the I2 matches with the cookie sent in the R1, thereby making it 495 impractical for the attacker to first exchange one I1/R1, and then 496 generate a large number of spoofed I2s that seemingly come from 497 different IP addresses or use different HITs. The method does not 498 protect from an attacker that uses fixed IP addresses and HITs, 499 though. Against such an attacker it is probably best to create a 500 piece of local state, and remember that the puzzle check has 501 previously failed. See Appendix D for one possible implementation. 502 Note, however, that the implementations MUST NOT use the exact 503 implementation given in the appendix, and SHOULD include sufficient 504 randomness to the algorithm so that algorithm complexity attacks 505 become impossible [22]. 507 The Responder can set the difficulty for Initiator, based on its 508 concern of trust of the Initiator. The Responder SHOULD use 509 heuristics to determine when it is under a denial-of-service attack, 510 and set the difficulty value K appropriately. 512 The Responder starts the cookie exchange when it receives an I1. The 513 Responder supplies a random number I, and requires the Initiator to 514 find a number J. To select a proper J, the Initiator must create the 515 concatenation of I, the HITs of the parties, and J, and take a SHA-1 516 hash over this concatenation. The lowest order K bits of the result 517 MUST be zeros. 519 To generate a proper number J, the Initiator will have to generate a 520 number of Js until one produces the hash target of zero. The 521 Initiator SHOULD give up after trying 2^(K+2) times, and start over 522 the exchange. (See Appendix C.) The Responder needs to re-create 523 the concatenation of I, the HITs, and the provided J, and compute the 524 hash once to prove that the Initiator did its assigned task. 526 To prevent pre-computation attacks, the Responder MUST select the 527 number I in such a way that the Initiator cannot guess it. 528 Furthermore, the construction MUST allow the Responder to verify that 529 the value was indeed selected by it and not by the Initiator. See 530 Appendix D for an example on how to implement this. 532 It is RECOMMENDED that the Responder generates a new cookie and a new 533 R1 once every few minutes. Furthermore, it is RECOMMENDED that the 534 Responder remembers an old cookie at least 60 seconds after it has 535 been deprecated. These time values allow a slower Initiator to solve 536 the cookie puzzle while limiting the usability that an old, solved 537 cookie has to an attacker. 539 NOTE: The protocol developers explicitly considered whether R1 should 540 include a timestamp in order to protect the Initiator from replay 541 attacks. The decision was NOT to include a timestamp. 543 In R1, the values I and K are sent in network byte order. Similarily, 544 in I2 the values I and J are sent in network byte order. The SHA-1 545 hash is created by concatenating, in network byte order, the 546 following data, in the following order: 548 64-bit random value I, in network byte order, as appearing in R1 549 and I2. 551 128-bit initiator HIT, in network byte order, as appearing in the 552 HIP Payload in R1 and I2. 554 128-bit responder HIT, in network byte order, as appearing in the 555 HIP Payload in R1 and I2. 557 64-bit random value J, in network byte order, as appearing in I2. 559 In order to be a valid response cookie, the K low-order bits of the 560 resulting SHA-1 digest must be zero. 562 Notes: 564 The length of the data to be hashed is 48 bytes. 566 All the data in the hash input MUST be in network byte order. 568 The order of the initiator and responder HITs are different in the 569 R1 and I2 packets, see Section 6.1. Care must be taken to copy 570 the values in right order to the hash input. 572 Precomputation by the Responder Sets up the challenge difficulty K. 574 Generates a random number I. 575 Creates a signed R1 and caches it. 577 Responder Selects a suitable cached R1. 579 Sends I and K in a HIP Cookie in the R1. 580 Saves I and K for a Delta time. 582 Initiator Generates repeated attempts to solve the challenge until a 583 matching J is found: 585 Ltrunc( SHA-1( I | HIT-I | HIT-R | J ), K ) == 0 586 Sends I and J in HIP Cookie in a I2. 588 Responder Verifies that the received I is a saved one. 590 Finds the right K based on I. 591 Computes V := Ltrunc( SHA-1( I | HIT-I | HIT-R | J ), K ) 592 Rejects if V != 0 593 Accept if V == 0 595 4.1.2 Authenticated Diffie-Hellman protocol 597 The packets R1, I2, and R2 implement a standard authenticated 598 Diffie-Hellman exchange. The Responder sents its public 599 Diffie-Hellman key and its public authentication key, i.e., its host 600 identity, in R1. The signature in R1 allows the Initiator to verify 601 that the R1 has been once generated by the Responder. However, since 602 it is precomputed and therefore does not cover all of the packet, it 603 does not protect from replay attacks. 605 When the Initiator receives an R1, it computes the Diffie-Hellman 606 session key. It creates a HIP security association using keying 607 material from the session key (see Section 9), and uses the security 608 association to encrypt its public authentication key, i.e., host 609 identity. The resulting I2 contains the Initiator's Diffie-Hellman 610 key and its the encrypted public authentication key. The signature 611 in I2 covers all of the packet. 613 The Responder extracts the Initiator Diffie-Hellman public key from 614 the I2, computes the Diffie-Hellman session key, creates a 615 corresponding HIP security association, and decrypts the Initiator's 616 public authentication key. It can then verify the signature using 617 the authentication key. 619 The final message, R2, is needed to protect the Initiator from replay 620 attacks. 622 4.1.3 HIP Birthday 624 The HIP Birthday is a reboot count used to manage state 625 re-establishment when one peer rebooted or timed out its SA. The 626 Birthday is increased every time the system boots. The Birthday also 627 has to be increased in accordance with the system's SA timeout 628 parameter. If the system has open SAs, it MUST increase its 629 Birthday. This impacts a system's approach to precomputing R1 630 packets. 632 Birthday SHOULD be a counter. It MUST NOT be reset by the user and a 633 system is unlikely to need a birthday larger than 2^64. Date-time in 634 GMT MAY be used if a cross-boot counter is not possible, but it has a 635 potential problem if the system time is set back by the user. 637 4.2 Sending data on HIP packets 639 A future version of this document may define how to include ESP 640 protected data on various HIP packets. However, currently the HIP 641 header is a terminal header, and not followed by any other headers. 643 The OPTIONAL PAYLOAD packet (see Section 7.8) MAY be used to transfer 644 data. 646 4.3 Rekey 648 HIP includes a simple rekey mechanism, allowing the hosts to 649 introduce new keying material at any time by introducing a new 650 Diffie-Hellman public key; see Section 7.5. All conforming HIP 651 implementations MUST support rekeying. 653 4.4 Bootstrap support 655 This memo defines an OPTIONAL HIP based bootstrap mechanism, intended 656 for ad hoc like environments; see Section 7.6. There is little 657 operational experience of the usability of this mechanism, and it may 658 be dropped or completely revised in some future protocol version. 660 4.5 Certificate distribution 662 HIP does not define how to use certificates. However, it does define 663 a simple certificate transport mechanisms that MAY be used to 664 implement certificate based security policies. The certificate 665 payload is defined in Section 6.2.10, and the certificate packet in 666 Section 7.7. 668 5. HIP packet flow and state machine 670 A typical HIP packet flow is shown below. 672 I --> Directory: lookup of R 673 I <-- Directory: return R's addresses, and HI and/or HIT 674 I1 I --> R (Hi. Here is my I1, let's talk HIP) 675 R1 I <-- R (OK. Here is my R1, handle this HIP cookie) 676 I2 I --> R (Compute, compute, here is my counter I2) 677 R2 I <-- R (OK. Let's finish HIP with my R2) 678 I --> R (ESP protected data) 679 I <-- R (ESP protected data) 681 5.1 HIP Scenarios 683 The HIP protocol and state machine is designed to recover from one of 684 the parties crashing and losing its state. The following scenarios 685 describe the main use cases covered by the design. 687 No prior state between the two systems. 689 The system with data to send is the Initiator. The process 690 follows standard 4 packet base exchange, establishing the SAs. 692 The system with data to send has no state with the receiver, but 693 the receiver has a residual SA. 695 Initiator acts as in no prior state, sending I1 and getting R1. 696 When the Receiver gets an I2, the old SAs are 'discovered' and 697 deleted; the new SAs are established. 699 The system with data to send has an SA, but the receiver does not. 701 The receiver 'detects' the situation when it receives an ESP 702 packet that contains an unknown SPI. The receiver sends an R1 703 with a NULL initiator HIT. The sender gets the R1 with a later 704 birthdate, discards old SA, and continues the base exchange to 705 establish new SAs for sending data. 707 A peer determines that it needs to reset Sequence number or rekey. 709 It sends NES. Receiver sends NES response, establishes new SAs 710 for peers. 712 5.2 Refusing a HIP exchange 714 A HIP aware host may choose not to accept a HIP exchange. If the 715 host's policy is to only be an initiator, it should begin its own HIP 716 exchange. A host MAY choose to have such a policy since only the 717 initiator HI is protected in the exchange. There is a risk of a race 718 condition if each host's policy is to only be an Initiator, at which 719 point the HIP exchange will fail. 721 If the host's policy does not permit it to enter into a HIP exchange 722 with the Initiator, it should send an ICMP 'Destination Unreachable, 723 Administratively Prohibited' message. A more complex HIP packet is 724 not used here as it actually opens up more potential DoS attacks than 725 a simple ICMP message. 727 5.3 Reboot and SA timeout restart of HIP 729 Simulating a loss of state is a potential DoS attack. The following 730 process has been crafted to manage state recovery without presenting 731 a DoS opportunity. 733 If a host reboots or times out, it has lost its HIP state. If the 734 system that lost state has a datagram to deliver to its peer, it 735 simply restarts the HIP exchange. The peer sends an R1 HIP packet, 736 but does not reset its state until it receives the I2 HIP packet. 737 The I2 packet MUST have a Birthday greater than the current SA's 738 Birthday. This is to handle DoS attacks that simulate a reboot of a 739 peer. Note that either the original Initiator or the Responder could 740 end up restarting the exchange, becoming the new Initiator. 742 If a system receives an ESP packet for an unknown SPI, the assumption 743 is that it has lost the state and its peer did not. In this case, the 744 system treats the ESP packet like an I1 packet and sends an R1 745 packet. The initiator HIT is typically NULL in the R1, since the 746 system usually does not know the peer's HIT any more. 748 The system receiving the R1 packet first checks to see if it has an 749 established and recently used SA with the party sending the R1. If 750 such an SA exists, the system checks the Birthday, and if the 751 Birthday is greater than the current SA's Birthday, it processes the 752 R1 packet, optionally queuing the payload packet(s) to be resent 753 later. The peer system processes the I2 in the normal manner, and 754 replies with an R2. This will re-establish state between the two 755 peers. Note that the process will result in new ESP SAs being used, 756 and therefore simply resending ESP packets is not sufficient. 758 Note that there is a potential DoS attack. If an attacker can 759 simulate a situation where a large number of peers apparently loose 760 their state at the same time, and all send R1 packet at once to a 761 server, the server will choke on trying to solve all the puzzles at 762 the same time. However, such an attack would require that the 763 attacker has specific knowledge about the SAs being used, and an 764 ability to trigger R1s as the SAs are used. 766 5.4 HIP State Machine 768 The HIP protocol itself has very little state. In the HIP base 769 exchange, there is an Initiator and a Responder. Once the SAs are 770 established, this distinction is lost. If the HIP state needs to be 771 re-established, the controlling parameters are which peer still has 772 state and which has a datagram to send to its peer. The following 773 state machine attempts to capture these processes. 775 The state machine is presented in a single system view, representing 776 either an Initiator or a Responder. There is not a complete overlap 777 of processing logic here and in the packet definitions. Both are 778 needed to completely implement HIP. 780 Implementors must understand that the state machine, as described 781 here, is informational. Specific implementations are free to 782 implement the actual functions differently. 784 5.4.1 HIP States 786 E0 State machine start 788 E1 Initiating HIP 790 E2 Waiting to finish HIP 792 E3 HIP SA established 794 E4 HIP SA established, rekeying 796 E-FAILED HIP SA establishment failed 798 5.4.2 HIP State Processes 800 +---------+ 801 | E0 | Start state 802 +---------+ 804 Datagram to send, send I1 and go to E1 805 Receive I1, send R1 and stay at E0 806 Receive I2, process 807 if successful, send R2 and go to E3 808 if fail, stay at E0 809 Receive ESP for unknown SA, send R1 and stay at E0 810 Receive ANYOTHER, drop and stay at E0 812 +---------+ 813 | E1 | Initiating HIP 814 +---------+ 816 Receive I1, send R1 and stay at E1 817 Receive I2, process 818 if successful, send R2 and go to E3 819 if fail, stay at E1 820 Receive R1, process 821 if successful, send I2 and go to E2 822 if fail, go to E-FAILED 823 Receive ANYOTHER, drop and stay at E1 824 Timeout, increment timeout counter 825 If counter is less than I1_RETRIES_MAX, send I1 and stay at E1 826 If counter is greater than I1_RETRIES_MAX, go to E-FAILED 828 +---------+ 829 | E2 | Waiting to finish HIP 830 +---------+ 832 Receive I1, send R1 and stay at E2 833 Receive I2, process 834 if successful, send R2 and go to E3 835 if fail, stay at E2 836 Receive R2, process 837 if successful, go to E3 838 if fail, go to E-FAILED 839 Receive ANYOTHER, drop and stay at E2 840 Timeout, increment timeout counter 841 If counter is less than I2_RETRIES_MAX, send I2 and stay at E2 842 If counter is greater than I2_RETRIES_MAX, go to E-FAILED 844 +---------+ 845 | E3 | HIP SA established 846 +---------+ 848 Receive I1, send R1 and stay at E3 849 Receive I2, process with Birthday check 850 if successful, send R2, drop old SA and cycle at E3 851 if fail, stay at E3 852 Receive R1, process with SA and Birthday check 853 if successful, send I2, prepare to drop old SA and cycle at E3 854 if fail, stay at E3 856 Receive R2, drop and stay at E3 858 Receive ESP for SA, process and stay at E3 859 Receive NES, process 860 if successful, send NES and stay at E3 861 if failed, stay at E3 862 Need rekey, 863 send NES and go to E4 865 +---------+ 866 | E4 | HIP SA established, rekey pending 867 +---------+ 869 Receive I1, send R1 and stay at E4 870 Receive I2, process with Birthday check 871 if successful, send R2, drop old SA and go to E3 872 if fail, stay at E4 873 Receive R1, process with SA and Birthday check 874 if successful, send I2, prepare to drop old SA and go to E3 875 if fail, stay at E4 876 Receive R2, drop and stay at E4 878 Receive ESP for SA, process and stay at E4 879 Receive NES, process 880 if successful, replace SAs and go to E3 881 if failed, stay at E4 882 Timeout, increment timeout counter 883 If counter is less than NES_RETRIES_MAX, send NES and stay at E4 884 If counter is greater than NES_RETRIES_MAX, go to E-FAILED 886 5.4.3 Simplified HIP State Diagram 888 Receive packets cause a move to a new state. 890 +---------+ 891 | E0 |>---+ 892 +---------+ | 893 | ^ | | 894 | | | Dgm to | 895 +-+ | send | 896 I1 | | (note: ESP- means ESP with unknown SPI) 897 ESP- | | 898 v | 899 +---------+ | 900 | E1 |>---|----------+ 901 +---------+ | | 902 | | | 903 | R1 | | 904 | |I2 |I2 905 v | | 906 +---------+ | | 907 | E2 |>---|----------|-----+ 908 | | | | | 909 +---------+ | | | 910 | | | | 911 | R2 | | |I2 912 | | | | 913 v | | | 914 +---------+<---+ | | 915 | | | | 916 | E3 |<--------------+ | 917 | |<--------------------+ 918 | |<-------+ 919 | |----+ | 920 +---------+ | | 921 | ^ ^ | | 922 | | | | | 923 +--+ | | | 924 ESP, | rekey| |R1,I2 925 NES, | | | 926 I1, |NES | | 927 I2, | | | 928 R1 | | | 929 | | | 930 +---------+ | | 931 | |<---+ | 932 | E4 |>-------+ 933 +---------+ 934 | ^ 935 | | 936 +--+ 937 ESP, 938 I1, 940 6. Packet formats 942 6.1 Payload format 944 All HIP packets start with a fixed header. 946 0 1 2 3 947 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 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 | Next Header | Payload Len | Type | VER. | RES. | 950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 951 | Controls | Checksum | 952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 | Sender's Host Identity Tag (HIT) | 954 | | 955 | | 956 | | 957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 958 | Receiver's Host Identity Tag (HIT) | 959 | | 960 | | 961 | | 962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 963 | | 964 / HIP Parameters / 965 / / 966 | | 967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 The HIP header is logically an IPv6 extension header. However, this 970 document does not describe processing for Next Header values other 971 than decimal 59, IPPROTO_NONE, the IPV6 no next header value. Future 972 documents MAY do so. However, implementations MUST ignore trailing 973 data if a Next Header value is received that is not implemented. 975 The Header Length field contains the length of the HIP Header and the 976 length of HIP parameters in 8 bytes units, excluding the first 8 977 bytes. Since all HIP headers MUST contain the sender's and 978 receiver's HIT fields, the minimum value for this field is 4, and 979 conversely, the maximum length of the HIP Parameters field is 980 (255*8)-32 = 2008 bytes. 982 The Packet Type indicates the HIP packet type. The individual packet 983 types are defined in the relevant sections. If a HIP host receives a 984 HIP packet that contains an unknown packet type, it MUST drop the 985 packet. 987 The HIP Version is four bits. The current version is 1. The version 988 number is expected to be incremented only if there are incompatible 989 changes to the protocol. Most extensions can be handled by defining 990 new packet types, new parameter types, or new controls. 992 The following four bits are reserved for future use. They MUST be 993 zero when sent, and they SHOULD be ignored when handling a received 994 packet. 996 The HIT fields are always 128 bits (16 bytes) long. 998 6.1.1 HIP Controls 1000 The HIP control section transfers information about the structure of 1001 the packet and capabilities of the host. 1003 The following fields have been defined: 1005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1006 | | | | | | | | | | | | | |C|E|A| 1007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1009 C - Certificate One or more certificate packets (CER) follows this 1010 HIP packet (see Section 7.7). 1012 E - ESP sequence numbers The ESP transform requires 64-bit sequence 1013 numbers. See Section 11.4 for processing this control. 1015 A - Anonymous If this is set, the sender's HI in this packet is 1016 anonymous, i.e., one not listed in a directory. Anonymous HIs 1017 SHOULD NOT be stored. This control is set in packets R1 and/or 1018 I2. The peer receiving an anonymous HI may choose to refuse it by 1019 silently dropping the exchange. 1021 The rest of the fields are reserved for future use and MUST be set to 1022 zero on sent packets and ignored on received packets. 1024 6.1.2 Checksum 1026 The checksum field is located at the same location within the header 1027 as the checksum field in UDP packets, enabling hardware assisted 1028 checksum generation and verification. Note that since the checksum 1029 covers the source and destination addresses in the IP header, it must 1030 be recomputed on HIP based NAT boxes. 1032 If IPv6 is used to carry the HIP packet, the pseudo-header [8] 1033 contains the source and destination IPv6 addresses, HIP packet length 1034 in the pseudo-header length field, a zero field, and the HIP protocol 1035 number (TBD) in the Next Header field. The length field is in bytes 1036 and can be calculated from the HIP header length field: (HIP Header 1037 Length + 1) * 8. 1039 In case of using IPv4, the IPv4 UDP pseudo header format [1] is used. 1040 In the pseudo header, the source and destination addresses are those 1041 used in the IP header, the zero field is obviously zero, the protocol 1042 is the HIP protocol number (TBD), and the length is calculated as in 1043 the IPv6 case. 1045 6.2 HIP parameters 1047 The HIP Parameters are used to carry the public key associated with 1048 the sender's HIT, together with other related security information. 1049 The HIP Parameters consists of ordered parameters, encoded in TLV 1050 format. 1052 The following parameter types are currently defined. 1054 TLV Type Length Data 1056 SPI_LSI 0 16 Remote's SPI, Remote's LSI. 1058 BIRTHDAY_COOKIE 2/4 32 System Boot Counter plus 1059 two 64-bit fields: 1060 - Random #I 1061 - K or random #J 1063 DIFFIE_HELLMAN 6 variable public key 1065 NES_INFO 10 Old SPI, New SPI and other 1066 info needed for NES 1068 HIP_TRANSFORM 16 variable HIP Encryption and Integrity 1069 Transform 1071 ESP_TRANSFORM 18 variable ESP Encryption and 1072 Authentication Transform 1074 ENCRYPTED 20 variable Encrypted part of I2 or CER 1075 packets 1076 HOST_ID 32 variable Host Identity 1078 HOST_ID_FQDN 34 variable Host Identity with Fully 1079 Qualified Domain Name 1081 CERT 64 variable HI certificate 1082 HMAC 65500 24 HMAC based message 1083 authentication code, with 1084 key material from HIP_TRANSFORM 1086 HIP_SIGNATURE2 65532 variable Signature of the R1 packet 1088 HIP_SIGNATURE 65534 variable Signature of the packet 1090 6.2.1 TLV format 1092 The TLV encoded parameters are described in the following 1093 subsections. The type-field value also describes the order of these 1094 fields in the packet. The parameters MUST be included into the 1095 packet so that the types form an increasing order. If the order does 1096 not follow this rule, the packet is considered to be malformed and it 1097 MUST be discarded. 1099 All the TLV parameters have a length which is a multiple of 8 bytes. 1100 When needed, padding MUST be added to the end of the parameter so 1101 that the total length becomes a multiple of 8 bytes. This rule 1102 ensures proper alignment of data. If padding is added, the Length 1103 field MUST NOT include the padding. Any added padding bytes MUST be 1104 set zero by the sender, but their content SHOULD NOT be checked on 1105 the receiving end. 1107 Consequently, the Length field indicates the length of the Contents 1108 field (in bytes). The total length of the TLV parameter (including 1109 Type, Length, Contents, and Padding) is related to the Length field 1110 according to the following formula: 1112 Total Length = 11 + Length - (Length + 3) % 8; 1114 0 1 2 3 1115 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 1116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1117 | Type |C| Length | 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 | | 1120 / Contents / 1121 / +-+-+-+-+-+-+-+-+ 1122 | | Padding | 1123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1125 Type Type code for the parameter 1126 C Critical. Zero if this parameter is critical, and 1127 MUST be recognized by the recipient, one otherwise. 1129 The C bit is considered to be a part of the Type field. 1130 Consequently, critical parameters are always even 1131 and non-critical ones have an odd value. 1132 Length Length of the parameter, in bytes. 1133 Contents Parameter specific, defined by Type 1134 Padding Padding, 0-7 bytes, added if needed 1136 Critical parameters MUST be recognized by the recipient. If a 1137 recipient encounters a critical parameter that it does not recognize, 1138 it MUST NOT process the packet any further. 1140 Non-critical parameters MAY be safely ignored. If a recipient 1141 encounters a non-critical parameter that it does not recognize, it 1142 SHOULD proceed as if the parameter was not present in the received 1143 packet. 1145 6.2.2 Defining new parameters 1147 Future specifications may define new parameters as needed. When 1148 defining new parameters, care must be taken to ensure that the 1149 parameter type values are appropriate and leave suitable space for 1150 other future extensions. One must remember that the parameters MUST 1151 always be arranged in the increasing order by the type code, thereby 1152 limiting the order of parameters. 1154 The following rules must be followed when defining new parameters. 1156 1. The low order bit C of the Type code is used to distinguish 1157 between critical and non-critical parameters. 1159 2. A new parameter may be critical only if an old recipient ignoring 1160 it would cause security problems. In general, new parameters 1161 SHOULD be defined as non-critical, and expect a reply from the 1162 recipient. 1164 3. If a system implements a new critical parameter, it MUST provide 1165 the ability to configure the associated feature off, such that 1166 the critical parameter is not sent at all. The configuration 1167 option must be well documented. By default, sending of such a 1168 new critical parameter SHOULD be off. In other words, the 1169 management interface MUST allow vanilla standards only mode as a 1170 default configuration setting, and MAY allow new critical 1171 payloads to be configured on (and off). 1173 4. The following type codes are reserved for future base protocol 1174 extensions, and may be assigned only through an appropriate WG or 1175 RFC action. 1177 0 - 511 1179 65024 - 65535 1181 5. The following type codes are reserved for experimentation and 1182 private use. Types SHOULD be selected in a random fashion from 1183 this range, thereby reducing the probability of collisions. A 1184 method employing genuine randomness (such as flipping a coin) 1185 SHOULD be used. 1187 32768 - 49141 1189 6. All other parameter type codes MUST be registed by the IANA. See 1190 Section 14. 1192 6.2.3 SPI_LSI 1194 The SPI_LSI parameter contains the SPI that the receiving host must 1195 use when sending data to the sending host, and the LSI that the 1196 receiving host must to represent itself when talkin to the sending 1197 host. 1199 0 1 2 3 1200 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 1201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1202 | Type | Length | 1203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1204 | Reserved | 1205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1206 | SPI | 1207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1208 | LSI | 1209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1211 Type 0 1212 Length 12 1213 Reserved Zero when sent, ignored when received 1214 SPI Security Parameter Index 1215 LSI Local Scope Identifier 1217 6.2.4 BIRTHDAY_COOKIE 1219 0 1 2 3 1220 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 1221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1222 | Type | Length | 1223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1224 | Reserved | 1225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1226 | Birthday, 8 bytes | 1227 | | 1228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1229 | Random # I, 8 bytes | 1230 | | 1231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1232 | K or Random # J, 8 bytes | 1233 | | 1234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1236 Type 2 (in R1) or 4 (in I2) 1237 Length 28 1238 Reserved Zero when sent, ignored when received 1239 Birthday System boot counter 1240 Random # I random number 1241 K K is the number of verified bits (in R1 packet) 1242 Random # J random number (in I2 packet) 1244 Birthday, Random #I, K, and Random #J are represented as 64-bit 1245 integers, in network byte order. 1247 6.2.5 DIFFIE_HELLMAN 1249 0 1 2 3 1250 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 1251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1252 | Type | Length | 1253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1254 | Group ID | Public Value / 1255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1256 / | padding | 1257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1259 Type 6 1260 Length length in octets, excluding Type, Length, and padding 1261 Group ID defines values for p and g 1262 Public Value the sender's public Diffie-Hellman key 1264 The following Group IDs have been defined: 1266 Group Value 1267 Reserved 0 1268 OAKLEY well known group 1 1 1269 OAKLEY well known group 2 2 1270 1536-bit MODP group 3 1271 2048-bit MODP group 4 1272 3072-bit MODP group 5 1273 4096-bit MODP group 6 1274 6144-bit MODP group 7 1275 8192-bit MODP group 8 1277 The MODP Diffie-Hellman groups are defined in [14]. The OAKLEY 1278 groups are defined in [6]. The OAKLEY well known group 5 is the same 1279 as the 1536-bit MODP group. 1281 6.2.6 HIP_TRANSFORM 1283 0 1 2 3 1284 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 1285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1286 | Type | Length | 1287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1288 | Transform-ID #1 | Transform-ID #2 | 1289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1290 | Transform-ID #n | Padding | 1291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1293 Type 16 1294 Length length in octets, excluding Type, Length, and padding 1295 Transform-ID Defines the HIP Suite to be used 1297 The Suite-IDs are identical to those defined in Section 6.2.7. 1299 There MUST NOT be more than six (6) HIP Suite-IDs in one HIP 1300 transform TLV. The limited number of transforms sets the maximum size 1301 of HIP_TRANSFORM TLV. The HIP_TRANSFORM TLV MUST contain at least one 1302 of the mandatory Suide-IDs. 1304 Mandatory implementations: ENCR-3DES-CBC with HMAC-SHA1 and ENCR-NULL 1305 with HMAC-SHA1. 1307 6.2.7 ESP_TRANSFORM 1309 0 1 2 3 1310 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 1311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1312 | Type | Length | 1313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1314 | Suite-ID #1 | Suite-ID #2 | 1315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1316 | Suite-ID #n | Padding | 1317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1318 Type 18 1319 Length length in octets, excluding Type, Length, and padding 1320 Suite-ID Defines the ESP Suite to be used 1322 The following Suite-IDs are defined ([16],[19]): 1324 Suite-ID Value 1326 RESERVED 0 1327 ESP-AES-CBC with HMAC-SHA1 1 1328 ESP-3DES-CBC with HMAC-SHA1 2 1329 ESP-3DES-CBC with HMAC-MD5 3 1330 ESP-BLOWFISH-CBC with HMAC-SHA1 4 1331 ESP-NULL with HMAC-SHA1 5 1332 ESP-NULL with HMAC-MD5 6 1334 There MUST NOT be more than six (6) ESP Suite-IDs in one 1335 ESP_TRANSFORM TLV. The limited number of Suite-IDs sets the maximum 1336 size of ESP_TRANSFORM TLV. The ESP_TRANSFORM MUST contain at least 1337 one of the mandatory Suite-IDs. 1339 Mandatory implementations: ESP-3DES-CBC with HMAC-SHA1 and ESP-NULL 1340 with HMAC-SHA1. 1342 6.2.8 HOST_ID 1344 When the host sends a Host Identity to a peer, it MAY send the 1345 identity without any verification information or use certificates to 1346 proof the HI. If certificates are sent, they are sent in a separate 1347 HIP packet (CER). 1349 0 1 2 3 1350 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 1351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1352 | Type | Length | 1353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1354 | Host Identity / 1355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1356 / | padding | 1357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1359 Type 32 1360 Length length in octets, excluding Type, Length, and padding 1361 Host Identity actual host identity 1363 The Host Identity is represented in RFC2535 [9] format. The 1364 algorithms used in RDATA format are the following: 1366 Algorithms Values 1368 RESERVED 0 1369 DSA 3 [RFC2536] (REQUIRED) 1370 RSA 5 [RFC3110] (OPTIONAL) 1372 6.2.9 HOST_ID_FQDN 1374 0 1 2 3 1375 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 1376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1377 | Type | Length | 1378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1379 | HI Length | FQDN Length | 1380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1381 | Host Identity / 1382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1383 / | FDQN / 1384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1385 / | Padding | 1386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1388 Type 34 1389 Length length in octets, excluding Type, Length, and padding 1390 HI length length of the Host Identity 1391 FQDN length length of the FQDN 1392 Host Identity actual host identity 1393 FQDN Fully Qualified Domain Name, in the binary format. 1395 The Host Identity is represented in RFC2535 [9] format; see above. 1396 The format for the FQDN is defined in RFC1035 [2] Section 3.1. 1398 If there is no FQDN, the HOST_ID TLV is sent instead. 1400 6.2.10 CERT 1402 0 1 2 3 1403 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 1404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1405 | Type | Length | 1406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1407 | Cert count | Cert ID | Cert type | / 1408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1409 / Certificate / 1410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1411 / | Padding | 1412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1414 Type 64 1415 Length length in octets, excluding Type, Length, and padding 1416 Cert count total count of certificates that are sent, possibly 1417 in several consequtive CER packets 1418 Cert ID the order number for this certificate 1419 Cert Type describes the type of the certificate 1421 The receiver must know the total number (Cert count) of certificates 1422 that it will receive from the sender, related to the R1 or I2. The 1423 Cert ID identifies the particular certificate and its order in the 1424 certificate chain. The numbering in Cert ID MUST go from 1 to Cert 1425 count. 1427 The following certificate types are defined: 1429 Cert format Type number 1430 X.509 v3 1 1432 The encoding format for X.509v3 certificate is defined in [11]. 1434 6.2.11 HMAC 1436 0 1 2 3 1437 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 1438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1439 | Type | Length | 1440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1441 | | 1442 | HMAC | 1443 | | 1444 | | 1445 | | 1446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1448 Type 65500 1449 Length 20 1450 HMAC 1452 160 low order bits of the HMAC computed over the HIP 1453 packet, excluding the HMAC parameter and any 1454 following HIP_SIGNATURE or HIP_SIGNATURE2 1455 parameters. The checksum field MUST be set to zero 1456 and the HIP header length in the HIP common header 1457 MUST be calculated not to cover any excluded 1458 parameters when the HMAC is calculated. 1460 HMAC calculation and verification process: 1462 Packet sender: 1464 1. Create the HIP packet, without the HMAC and possibly following 1465 the HIP_SIGNATURE or HIP_SIGNATURE2 TLVs. 1467 2. Calculate the length field in the HIP header. 1469 3. Compute the HMAC. 1471 4. Add the HMAC TLV to the packet. 1473 5. Recalculate the length field in the HIP header. 1475 Packet receiver: 1477 1. Verify the HIP header length field. 1479 2. Remove the HIP TLV, and if the packet contains any HIP_SIGNATURE 1480 or HIP_SIGNATURE2 fields, remove them too, saving the contents if 1481 they will be needed later. 1483 3. Recalculate the HIP packet length in the HIP header and clear the 1484 checksum field (set it to all zeros). 1486 4. Compute the HMAC and verify it against the received HMAC. 1488 6.2.12 HIP_SIGNATURE 1490 0 1 2 3 1491 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 1492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1493 | Type | Length | 1494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1495 | SIG alg | Signature / 1496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1497 / | padding | 1498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1500 Type 65534 (2^16-2) 1501 Length length in octets, excluding Type, Length, and padding 1502 SIG alg Signature algorithm 1503 Signature the signature is calculated over the HIP packet, 1504 excluding the HIP_SIGNATURE TLV field, but including 1505 the HMAC field, if present. The checksum field MUST 1506 be set to zero and the HIP header length in the HIP 1507 common header MUST be calculated to the beginning of 1508 the HIP_SIGNATURE TLV when the signature is 1509 calculated. 1511 Signature calculation and verification process: 1513 Packet sender: 1515 1. Create the HIP packet without the HIP_SIGNATURE TLV. 1517 2. Calculate the length field in the HIP header. 1519 3. Compute the signature. 1521 4. Add the HIP_SIGNATURE TLV to the packet. 1523 5. Recalculate the length field in the HIP header. 1525 Packet receiver: 1527 1. Verify the HIP header length field. 1529 2. Save the contents of the HIP_SIGNATURE TLV and remove it from the 1530 packet. 1532 3. Recalculate the HIP packet length in the HIP header and clear the 1533 checksum field (set it to all zeros). 1535 4. Compute the signature and verify it against the received 1536 signature. 1538 The signature algorithms are defined in Section 6.2.8. The signature 1539 in the Signature field is encoded using the proper method depending 1540 on the signature algorithm (e.g. in case of DSA, according to [10]). 1542 The verification can use either the HI received from a HIP packet, 1543 the HI from a DNS query, if the FQDN has been received either in the 1544 HOST_ID_FQDN or in the CER packet, or one received by some other 1545 means. 1547 6.2.13 HIP_SIGNATURE_2 1549 The TLV structure is the same as in Section 6.2.12. The fields are: 1551 Type 65532 (2^16-4) 1552 Length length in octets, excluding Type, Length, and padding 1553 SIG alg Signature algorithm 1554 Signature the signature is calculated over the R1 packet, 1555 excluding the HIP_SIGNATURE_2 TLV field, but 1556 including the HMAC field, if present. Initiator's 1557 HIT and Checksum field MUST be set to zero and the 1558 HIP packet length in the HIP header MUST be 1559 calculated to the beginning of the HIP_SIGNATURE_2 1560 TLV when the signature is calculated. 1562 Zeroing the Initiator's HIT makes it possible to create R1 packets 1563 beforehand to minimize the effects of possible DoS attacks. 1565 Signature calculation and verification process follows the process in 1566 Section 6.2.12. The only difference is that instead of the the 1567 HIP_SIGNATURE TLV the HIP_SIGNATURE_2 TLV is used, and the 1568 Initiator's HIT is cleared (set to all zeros) before computing the 1569 signature. 1571 6.2.14 NES_INFO 1573 The NES payload is used to reset Security Associations. It introduces 1574 a new SPI to be used when sending data to the sender of the NES 1575 packet. The keys for the new Security Association will be drawn from 1576 KEYMAT. If the packet contains a Diffie-Hellman parameter, the 1577 KEYMAT is first recomputed before drawing the new keys. 1579 0 1 2 3 1580 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 1581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1582 | Type | Length | 1583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1584 |R| Keymat Index | NES ID | 1585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1586 | Old SPI | 1587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1588 | New SPI | 1589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1591 Type 10 1592 Length 12 1593 R One if the NES is a reply to another NES, 1594 otherwise zero. 1595 Keymat Index Index, in bytes, where to continue to draw ESP keys 1596 from KEYMAT. If the packet includes a new 1597 Diffie-Hellman key, the field MUST be zero. Note 1598 that the length of this field limits the amount of 1599 keying material that can be drawn from KEYMAT. If 1600 that amount is exceeded, the NES packet MUST contain 1601 a new Diffie-Hellman key. 1602 NES ID Packet identifier. Used to tie NES packets 1603 into pairs. Initialized to zero and incremented 1604 for each NES. 1605 Old SPI Old SPI for data sent to the source address of 1606 this packet 1607 New SPI New SPI for data sent to the source address of 1608 this packet 1610 Note that the NES_INFO used to include the SPI used in reverse 1611 direction, too. However, since NES packets are now always sent in 1612 pairs, that is not needed any more. Any middleboxes between the 1613 communicating hosts will learn the reverse mappings from the NES 1614 reply. 1616 6.2.15 ENCRYPTED 1618 0 1 2 3 1619 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 1620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1621 | Type | Length | 1622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1623 | Reserved | 1624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1625 | IV / 1626 / / 1627 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 1629 / Encrypted data / 1630 / / 1631 / +-------------------------------+ 1632 / | Padding | 1633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1635 Type 20 1636 Length length in octets, excluding Type, Length, and padding 1637 Reserved zero when sent, ignored when received 1638 IV Initialization vector, if needed, otherwise nonexisting. 1639 The length of the IV is inferred from the HIP transform. 1640 Encrypted The data is encrypted using an encryption algorithm as 1641 data defined in HIP transform. 1642 Padding Any Padding, if necessary, to make the TLV a multiple 1643 of 8 bytes. 1645 The encrypted data is in TLV format itself. Consequently, the first 1646 fields in the contents are Type and Length, allowing the contents to 1647 be easily parsed after decryption. 1649 If the encryption algorithm requires the length of the data to be 1650 encrypted to be a multiple of the cipher algorithm block size, 1651 thereby necessitating padding, and if the encryption algorithm does 1652 not specify the padding contents, then an implementation MUST append 1653 the TLV parameter that is to be encrypted with an additional padding, 1654 so that the length of the resulting cleartext is a multiple of the 1655 cipher block size length. Such a padding MUST be constructed as 1656 specified in [15] Section 2.4. On the other hand, if the data to be 1657 encrypted is already a multiple of the block size, or if the 1658 encryption algorithm does specify padding as per [15] Section 2.4, 1659 then such additional padding SHOULD NOT be added. 1661 The Length field in the inside, to be encrypted TLV does not include 1662 the padding. The Length field in the outside ENCRYPTED TLV is the 1663 length of the data after encryption (including the Reserved field, 1664 the IV field, and the output from the encryption process specified 1665 for that suite, but not any additional external padding). Note that 1666 the length of the cipher suite output may be smaller or larger than 1667 the length of the data to be encrypted, since the encryption process 1668 may compress the data or add additional padding to the data. 1670 The ENCRYPTED payload may contain additional external padding, if the 1671 result of encryption, the TLV header and the IV is not a multiple of 1672 8 bytes. The contents of this external padding MUST follow the rules 1673 given in Section Section 6.2.1. 1675 7. HIP Packets 1677 There are eight basic HIP packets. Four are for the base HIP 1678 exchange, one is for rekeying, one is a broadcast for use when there 1679 is no IP addressing (e.g., before DHCP exchange), one is used to send 1680 certificates, and one is for sending unencrypted data. 1682 Packets consist of the fixed header as described in Section 6.1, 1683 followed by the parameters. The parameter part, in turn, consists of 1684 zero or more TLV coded parameters. 1686 In addition to the base packets, other packets types will be defined 1687 later in separate specifications. For example, support for mobility 1688 and multi-homing is not included in this specification. 1690 Packet representation uses the following operations: 1692 () parameter 1693 x{y} operation x on content y 1694 i x exists i times 1695 [] optional parameter 1696 x | y x or y 1698 In the future, an OPTIONAL upper layer payload MAY follow the HIP 1699 header. The payload proto field in the header indicates if there is 1700 additional data following the HIP header. The HIP packet, however, 1701 MUST NOT be fragmented. This limits the size of the possible 1702 additional data in the packet. 1704 7.1 I1 - the HIP initiator packet 1706 The HIP header values for the I1 packet: 1708 Header: 1709 Packet Type = 1 1710 SRC HIT = Initiator's HIT 1711 DST HIT = Responder's HIT, or NULL 1713 IP(HIP()) 1715 The I1 packet contains only the fixed HIP header. 1717 Valid control bits: None 1719 The Initiator gets the Responder's HIT either from a DNS lookup of 1720 the Responder's FQDN, from some other repository, or from a local 1721 table. If the Initiator does not know the Responder's HIT, it may 1722 attempt opportunistic mode by using NULL (all zeros) as the 1723 Responder's HIT. 1725 Since this packet is so easy to spoof even if it were signed, no 1726 attempt is made to add to its generation or processing cost. 1728 Implementation MUST be able to handle a storm of received I1 packets, 1729 discarding those with common content that arrive within a small time 1730 delta. 1732 7.2 R1 - the HIP responder packet 1734 The HIP header values for the R1 packet: 1736 Header: 1737 Packet Type = 2 1738 SRC HIT = Responder's HIT 1739 DST HIT = Initiator's HIT 1741 IP ( HIP ( BIRTHDAY_COOKIE, 1742 DIFFIE_HELLMAN, 1743 HIP_TRANSFORM, 1744 ESP_TRANSFORM, 1745 ( HOST_ID | HOST_ID_FQDN ), 1746 HIP_SIGNATURE_2 ) ) 1748 Valid control bits: C, A 1750 The R1 packet may be followed by one or more CER packets. In this 1751 case, the C-bit in the control field MUST be set. 1753 If the responder HI is an anonymous one, the A control MUST be set. 1755 The initiator HIT MUST match the one received in I1. If the R1 is a 1756 response to an ESP packet with an unknown SPI, the Initiator HIT 1757 SHOULD be zero. If the Responder has multiple HIs, the responder HIT 1758 used MUST match Initiator's request. If the Initiator used 1759 opportunistic mode, the Responder may select freely among its HIs. 1761 The Birthday is a reboot count used to manage state re-establishment 1762 when one peer rebooted or timed out its SA. 1764 The Cookie contains a random # I and the difficulty K. The 1765 difficulty K is the number of bits that the Initiator must get zero 1766 in the puzzle. 1768 The Diffie-Hellman value is ephemeral, but can be reused over a 1769 number of connections. In fact, as a defense against I1 storms, an 1770 implementation MAY use the same Diffie-Hellman value for a period of 1771 time, for example, 15 minutes. By using a small number of different 1772 Cookies for a given Diffie-Hellman value, the R1 packets can be 1773 pre-computed and delivered as quickly as I1 packets arrive. A 1774 scavenger process should clean up unused DHs and Cookies. 1776 The HIP_TRANSFORM contains the encryption and integrity algorithms 1777 supported by the Responder to protect the HI exchange, in the order 1778 of preference. All implementations MUST support the 3DES [7] with 1779 HMAC-SHA-1-96 [4]. 1781 The ESP_TRANSFORM contains the ESP modes supported by the Responder, 1782 in the order of preference. All implementations MUST support 3DES 1783 [7] with HMAC-SHA-1-96 [4]. 1785 The signature is calculated over the whole HIP envelope, after 1786 setting the initiator HIT and header checksum temporarily to zero. 1787 This allows the Responder to use precomputed R1s. The Initiator 1788 SHOULD validate this signature. It SHOULD check that the responder 1789 HI received matches with the one expected, if any. 1791 7.3 I2 - the second HIP initiator packet 1793 The HIP header values for the I2 packet: 1795 Header: 1796 Type = 3 1797 SRC HIT = Initiator's HIT 1798 DST HIT = Responder's HIT 1800 IP ( HIP ( SPI_LSI, 1801 BIRTHDAY_COOKIE, 1802 DIFFIE_HELLMAN, 1803 HIP_TRANSFORM, 1804 ESP_TRANSFORM, 1805 ENCRYPTED { HOST_ID | HOST_ID_FQDN }, 1806 HIP_SIGNATURE ) ) 1808 Valid control bits: C, E, A 1810 The HITs used MUST match the ones used previously. 1812 If the initiator HI is an anonymous one, the A control MUST be set. 1814 The Birthday is a reboot count used to manage state re-establishment 1815 when one peer rebooted or timed out its SA. 1817 The Cookie contains the random # I from R1 and the computed # J. The 1818 low order K bits of the SHA-1(I | ... | J) MUST be zero. 1820 The Diffie-Hellman value is ephemeral. If precomputed, a scavenger 1821 process should clean up unused DHs. 1823 The HIP_TRANSFORM contains the encryption and integrity used to 1824 protect the HI exchange selected by the Initiator. All 1825 implementations MUST support the 3DES transform [7]. 1827 The Initiator's HI is encrypted using the HIP_TRANSFORM encryption 1828 algorithm. The keying material is derived from the Diffie-Hellman 1829 exchanged as defined in Section 9. 1831 The ESP_TRANSFORM contains the ESP mode selected by the Initiator. 1832 All implementations MUST support 3DES [7] with HMAC-SHA-1-96 [4]. 1834 The signature is calculated over whole HIP envelope. The Responder 1835 MUST validate this signature. It MAY use either the HI in the packet 1836 or the HI acquired by some other means. 1838 7.4 R2 - the second HIP responder packet 1840 The HIP header values for the R2 packet: 1842 Header: 1843 Packet Type = 4 1844 SRC HIT = Responder's HIT 1845 DST HIT = Initiator's HIT 1847 IP ( HIP ( SPI_LSI, HMAC, HIP_SIGNATURE ) ) 1849 Valid control bits: E 1851 The HMAC and signature are calculated over whole HIP envelope. The 1852 Initiator MUST validate both the HMAC and the signature. 1854 7.5 NES - the HIP New SPI Packet 1856 The NES packet is MANDATORY. 1858 The NES serves three functions. Firstly, it provides the peer system 1859 with a new SPI to use when sending packets. Secondly, it optionally 1860 provides a new Diffie-Hellman key to produce new keying material. 1861 Thirdly, it provides any intermediate system with the mapping of the 1862 old SPI to the new one. This is important to systems like NATs [21] 1863 that use SPIs to maintain address translation state. 1865 The NES packet is a HIP packet with NES_INFO and optional 1866 DIFFIE_HELLMAN and in the HIP payload. The NES_INFO parameter 1867 contains the old and new SPI values. It also contains a NES ID and 1868 HMAC to provide DoS and replay protection. Each system must have a 1869 NES ID counter, initialized to zero and incremented on each NES. 1871 The HIP header values for the NES packet: 1873 Header: 1874 Packet Type = 5 1875 SRC HIT = Sender's HIT 1876 DST HIT = Recipients's HIT 1878 IP ( HIP ( [ DIFFIE_HELLMAN, ] NES_INFO , HMAC, HIP_SIGNATURE ) ) 1880 Valid control bits: None 1882 During the life of an SA established by HIP, one of the hosts may 1883 need to reset the Sequence Number to one (to prevent wrapping) and 1884 rekey. The reason for rekeying might be an approaching sequence 1885 number wrap in ESP, or a local policy on use of a key. Rekeying ends 1886 the current SAs and starts new ones on both peers. 1888 NES packets are always used in pairs, one in both directions, with 1889 identical NES IDs. In the case both parties decide to rekey at the 1890 same time, the result is four NES packets, two in both directions. 1892 Intermediate systems that use the SPI will have to inspect HIP 1893 packets for a NES packet. The packet is signed for the benefit of 1894 the intermediate systems. Since intermediate systems may need the 1895 new SPI values, the contents of this packet cannot be encrypted. 1897 Processing NES signatures is a potential DoS attack against 1898 intermediate systems. 1900 7.6 BOS - the HIP Bootstrap Packet 1902 The BOS packet is OPTIONAL. 1904 In some situations, an Initiator may not be able to learn of a 1905 Responder's information from DNS or another repository. Some examples 1906 of this are DHCP and NetBios servers. Thus, a packet is needed to 1907 provide information that would otherwise be gleaned from a 1908 repository. This HIP packet is either self-signed in applications 1909 like SoHo, or from a trust anchor in large private or public 1910 deployments. This packet MAY be broadcasted in IPv4 or multicasted 1911 to the all hosts multicast group in IPv6. The packet MUST NOT be 1912 sent more often than once in every second. Implementations MAY 1913 ignore received BOS packets. 1915 The HIP header values for the BOS packet: 1917 Header: 1918 Packet Type = 7 1919 SRC HIT = Announcer's HIT 1920 DST HIT = NULL 1922 IP ( HIP ( ( HOST_ID | HOST_ID_FQDN ), HIP_SIGNATURE ) ) 1924 The BOS packet may be followed by a CER packet if the HI is signed. 1925 In this case, the C-bit in the control field MUST be set. If the BOS 1926 packet is broadcasted or multicasted, the following CER packet(s) 1927 MUST be broadcasted or multicasted to the same multicast group and 1928 scope, respectively. 1930 Valid control bits: C, A 1932 7.7 CER - the HIP Certificate Packet 1934 The CER packet is OPTIONAL. 1936 The Optional CER packets over the Announcer's HI by a higher level 1937 authority known to the Recipient is an alternative method for the 1938 Recipient to trust the Announcer's HI (over DNSSEC or PKI). 1940 The HIP header values for CER packet: 1942 Header: 1943 Packet Type = 8 1944 SRC HIT = Announcer's HIT 1945 DST HIT = Recipients's HIT 1947 IP ( HIP ( { i }, HIP_SIGNATURE ) ) or 1949 IP ( HIP ( ENCRYPTED { i }, HIP_SIGNATURE ) ) 1951 Valid control bits: None 1953 Certificates in the CER packet MAY be encrypted. The encryption 1954 algorithm is provided in the HIP transform of the previous (R1 or I2) 1955 packet. 1957 7.8 PAYLOAD - the HIP Payload Packet 1959 The PAYLOAD packet is OPTIONAL. 1961 The HIP header values for the PAYLOAD packet: 1963 Header: 1964 Packet Type = 64 1965 SRC HIT = Senders's HIT 1966 DST HIT = Recipients's HIT 1968 IP ( HIP ( ), payload ) 1970 Valid control bits: None 1972 Payload Proto field in the Header MUST be set to correspond the 1973 correct protocol number of the payload. 1975 The PAYLOAD packet is used to carry a non-ESP protected data. By 1976 using the HIP header we ensure interoperability with NAT and other 1977 middle boxes. 1979 Processing rules of the PAYLOAD packet are the following: 1981 Receiving: If there is an existing HIP security association with the 1982 given HITs, and the IP addresses match the IP addresses associated 1983 with the HITs, pass the packet to the upper layer, tagged with 1984 metadata indicating that the packet was NOT integrity or 1985 confidentiality protected. 1987 Sending: If the IPsec SPD defines BYPASS for a given destination 1988 HIT, send it with the PAYLOAD packet. Otherwise use ESP as 1989 specified in the SPD. 1991 8. Packet processing 1993 Each host is assumed to have a separate HIP protocol implementation 1994 that manages the host's HIP associations and handles requests for new 1995 ones. Each HIP association is governed by a state machine, with 1996 states defined above in Section 5.4. The HIP implementation can 1997 simultaneously maintain HIP associations with more than one host. 1998 Furthermore, the HIP implementation may have more than one active HIP 1999 association with another host; in this case, HIP associations are 2000 distinguished by their respective HITs and IPsec SPIs. It is not 2001 possible to have more than one HIP associations between any given 2002 pair of HITs. Consequently, the only way for two hosts to have more 2003 than one parallel associations is to use different HITs, at least in 2004 one end. 2006 The processing of packets depends on the state of the HIP 2007 association(s) with respect to the authenticated or apparent 2008 originator of the packet. A HIP implementation determines whether it 2009 has an active association with the originator of the packet based on 2010 the HITs or the SPI of the packet. 2012 8.1 Processing outgoing application data 2014 In a HIP host, an application can send application level data using 2015 HITs or LSIs as source and destination identifiers. The HITs and LSIs 2016 may be specified via a backwards compatible API (see Appendix A) or a 2017 completely new API. However, whenever there is such outgoing data, 2018 the stack has to protect the data with ESP, and send the resulting 2019 datagram using appropriate source and destination IP addresses. 2020 Here, we specify the processing rules only for the base case where 2021 both hosts have only single usable IP addresses; the multi-address 2022 multi-homing case will be specified separately. 2024 If the IPv4 backward compatible APIs and therefore LSIs are 2025 supported, it is assumed that the LSIs will be converted into proper 2026 HITs somewhere in the stack. The exact location of the conversion is 2027 an implementation specific issue and not discussed here. The 2028 following conceptual algorithm discusses only HITs, with the 2029 assumption that the LSI-to-HIT conversion takes place somewhere. 2031 The following steps define the conceptual processing rules for 2032 outgoing datagrams destinated to a HIT. 2034 1. If the datagram has a specified source address, it MUST be a HIT. 2035 If it is not, the implementation MAY replace the source address 2036 with a HIT. Otherwise it MUST drop the packet. 2038 2. If the datagram has an unspecified source address, the 2039 implementation must choose a suitable source HIT for the 2040 datagram. In selecting a proper local HIT, the implementation 2041 SHOULD consult the table of currently active HIP sessions, and 2042 preferably select a HIT that already has an active session with 2043 the target HIT. 2045 3. If there no active HIP session with the given < source, 2046 destination > HIT pair, one must be created by running the base 2047 exchange. The implementation SHOULD queue at least one packet 2048 per a HIP session to be formed, and it MAY queue more than one. 2050 4. Once there is an active HIP session for the given < source, 2051 destination > HIT pair, the outgoing datagram is protected using 2052 the associated ESP security association. In a typical 2053 implementation, this will result in an transport mode ESP 2054 datagram that still has HITs in the place of IP addresses. 2056 5. The HITs in the datagram are replaced with suitable IP addresses. 2057 For IPv6, the rules defined in [12] SHOULD be followed. Note 2058 that this HIT-to-IP-address conversion step MAY also be performed 2059 at some other point in the stack, e.g., before ESP processing. 2060 However, care must be taken to make sure that the right ESP SA is 2061 employed. 2063 8.2 Processing incoming application data 2065 Incoming HIP datagrams arrive as ESP protected packets. In the usual 2066 case the receiving host has a corresponding ESP security association, 2067 identified by the SPI and destination IP address in the packet. 2068 However, if the host has crashed or otherwise lost its HIP state, it 2069 may not have such an SA. 2071 The following steps define the conceptual processing rules for 2072 incoming ESP protected datagrams targeted to an ESP security 2073 association created with HIP. 2075 1. Detect the proper IPsec SA, using the destination IP address and 2076 the SPI. If the resulting SA is a non-HIP ESP SA, process the 2077 packet according to standard IPsec rules. If there are no SAs 2078 identified with the SPI, the host MAY send an R1 with a NULL 2079 Initiator SPI. Sending such R1s MUST be rate limited. 2081 2. If a proper HIP ESP SA is found, the packet is processed normally 2082 by ESP, as if the packet were a transport mode packet. The 2083 packet may be dropped by ESP, as usual. In a typical 2084 implementation, the result of succesful ESP decryption and 2085 verification is a datagram with the original IP addresses as 2086 source and destination. 2088 3. The IP addresses in the datagram are replaced with the HITs 2089 associated with the ESP SA. Note that this IP-address-to-HIT 2090 conversion step MAY also be performed at some other point in the 2091 stack, e.g., before ESP processing. 2093 4. The datagram is delivered to the upper layer. Demultiplexing the 2094 datagram the right upper layer socket is based on the HITs (or 2095 LSIs). 2097 8.3 Initiation of a HIP exchange 2099 An implementation may originate a HIP exchange to another host based 2100 on a local policy decision, usually triggered by an application 2101 datagram, in much the same way that an IPsec IKE key exchange can 2102 dynamically create a Security Association. Alternatively, a system 2103 may initiate a HIP exchange if it has rebooted or timed out, or 2104 otherwise lost its HIP state, as described in Section 5.3. 2106 The implementation prepares an I1 packet and sends it to the IP 2107 address that corresponds to the peer host. The IP address of the 2108 peer host may be obtained via conventional mechanisms, such as DNS 2109 lookup. The I1 contents are specified in Section 7.1. The selection 2110 of which host identity to use, if a host has more than one to choose 2111 from, is typically also be a policy decision. 2113 The following steps define the conceptual processing rules for 2114 initiating a HIP exchange: 2116 1. The Initiator gets the Responder's HIT and one or more addresses 2117 either from a DNS lookup of the responder's FQDN, from some other 2118 repository, or from a local table. If the initiator does not know 2119 the responder's HIT, it may attempt opportunistic mode by using 2120 NULL (all zeros) as the responder's HIT. 2122 2. The Initiator sends an I1 to one of the Responder's addresses. 2123 The selection of which address to use is a local policy decision. 2125 3. Upon sending an I1, the sender shall transition to state E1, 2126 start a timer whose timeout value should be larger than the 2127 worst-case anticipated RTT, and shall increment a timeout counter 2128 associated with the I1. 2130 4. Upon timeout, the sender SHOULD retransmit the I1 and restart the 2131 timer, up to a maximum of I1_RETRIES_MAX tries. 2133 8.3.1 Sending multiple I1s in parallel 2135 For the sake of minimizing the session establishment latency, an 2136 implementation MAY send the same I1 to more than one of the 2137 Responder's addresses. However, it MUST NOT send to more than three 2138 (3) addresses in parallel. Furthermore, upon timeout, the 2139 implementation MUST refrain from sending the same I1 packet to 2140 multiple addresses. These limitations are placed order to avoid 2141 congestion of the network, and potential DoS attacks that might 2142 happen, e.g., because someone claims to have hundreds or thousands of 2143 addresses. 2145 As the Responder is not guaranteed to distinguish the duplicate I1's 2146 it receives at several of its addresses (because it avoids to store 2147 states when it answers back an R1), the Initiator may receive several 2148 duplicate R1's. 2150 The Initiator SHOULD then select the destination address using the 2151 source address of the first received R1 as a source address for the 2152 next I2, and discards subsequent R1's. This strategy seems to be 2153 quite good in terms of RTT. 2155 8.3.2 Processing incoming ICMP Protocol Unreachable messages 2157 A host may receive an ICMP Destination Protocol Unreachable message 2158 as a response to sending an HIP I1 packet. Such a packet may be an 2159 indication that the peer does not support HIP, or it may be an 2160 attempt to launch an attack by making the Initiator to believe that 2161 the Responder does not support HIP. 2163 When a system receives an ICMP Destination Protocol Unreachable 2164 message while it is waiting for an R1, it MUST NOT terminate the 2165 wait. It MAY continue as if it had not received the ICMP message, 2166 and send a few more I1s. Alternatively, it MAY take the ICMP message 2167 as a hint that the peer most probably does not support HIP, and 2168 return to state E0 earlier than otherwise. However, at minimum, it 2169 MUST continue waiting for an R1 for a reasonable time before 2170 returning to E0. 2172 8.4 Processing incoming I1 packets 2174 An implementation SHOULD reply to an I1 with an R1 packet, unless the 2175 implementation is unable or unwilling to setup a HIP association. If 2176 the implementation is unable to setup a HIP association, the host 2177 SHOULD send an ICMP Destination Protocol Unreachable, 2178 Administratively Prohibited, message to the I1 source address. If 2179 the implementation is unwilling to setup a HIP association, the host 2180 MAY ignore the I1. This latter case may occur during a DoS attack 2181 such as an I1 flood. 2183 The implementation MUST be able to handle a storm of received I1 2184 packets, discarding those with common content that arrive within a 2185 small time delta. 2187 A spoofed I1 can result in an R1 attack on a system. An R1 sender 2188 MUST have a mechanism to rate limit R1s to an address. 2190 Under no circumstances does the HIP state machine transition upon 2191 sending an R1. 2193 The following steps define the conceptual processing rules for 2194 responding to an I1 packet: 2196 1. The responder MUST check that the responder HIT in the received 2197 I1 is either one of its own HITs, or NULL. 2199 2. If the implementation chooses to respond to the I1 with and R1 2200 packet, it creates a new R1 or selects a precomputed R1 according 2201 to the format described in Section 7.2. 2203 3. The R1 MUST contain the received responder HIT, unless the 2204 received HIT is NULL, in which case the Responder may freely 2205 select among its HITs. 2207 4. The HIP control bits MUST be ignored in the received I1. The 2208 received initiator HIT MUST be copied over to the Initiator HIT 2209 field in the R1. 2211 5. The responder sends the R1 to the source IP address of the I1 2212 packet. 2214 8.4.1 R1 Management 2216 All compliant implementations MUST produce R1 packets. An R1 packet 2217 MAY be precomputed. An R1 packet MAY be reused for time Delta T, 2218 which is implementation dependent. R1 information MUST not be 2219 discarded until Delta S after T. Time S is the delay needed for the 2220 last I2 to arrive back to the responder. 2222 An implementation MAY keep state about received I1s and match the 2223 received I2s against the state, as discussed in Section 4.1.1. 2225 8.5 Processing incoming R1 packets 2227 A system receiving an R1 MUST first check to see if it has sent an I1 2228 to the originator of the R1 (i.e., it is in state E1). If so, it 2229 SHOULD process the R1 as described below, send an I2, and go to state 2230 E2, setting a timer to protect the I2. If the system is in state E0 2231 or state E2 with respect to that host, it SHOULD silently drop the 2232 R1. 2234 If the system is in state E3/E4, it SHOULD process with a Security 2235 Association and Birthday check as described in Section 5.3, before 2236 further processing. In this last case, if the R1 is successfully 2237 processed, the system sends an I2, sets a retransmit timer to protect 2238 the I2, prepares to replace its old Security Associations with the 2239 newly generated ones upon receiving a matching R2, and goes to state 2240 E3. Note that if the system was in state E4, it stops the rekey 2241 attempt and goes to state E3. 2243 The following steps define the conceptual processing rules for 2244 responding to an R1 packet: 2246 1. A system receiving an R1 MUST first check to see if it has sent 2247 an I1 to the originator of the R1 (i.e., it has a HIP 2248 association that is in state E1 and that is associated with the 2249 HITs in the R1). If so, it should process the R1 as described 2250 below. 2252 2. If the received R1 has a NULL Initiator HIT, the system should 2253 look for a HIP association in state E3/E4 that is associated 2254 with the received Responder HIT. If it finds one, it MUST 2255 perform the Security Association and Birthday checks as 2256 described in Section 5.3. If the SA and Birthday checks 2257 succeed, it should process the R1 as described below. 2259 3. Otherwise, if the system is in state E0 or state E2 with respect 2260 to the HITs included in the R1, it SHOULD silently drop the R1 2261 and remain in E0 or E2. 2263 4. If the HIP association state is E1, the received Initiator's HIT 2264 MUST correspond to the HIT used in the original, I1 and the 2265 Responder's HIT MUST correspond to the one used, unless the I1 2266 contained a NULL HIT. If the HIP association state is E3/E4, 2267 the received Initiator's HIT MUST either be NULL or correspond 2268 to the one stored in the HIP association, and the Responder's 2269 HIT MUST correspond to the one stored in the association. 2271 5. The system SHOULD validate the R1 signature before applying 2272 further packet processing, according to Section 6.2.13. 2274 6. The R1 packet may have the C bit set -- in this case, the system 2275 should anticipate the receipt of HIP CER packets that contain 2276 the host identity corresponding to the responder's HIT. 2278 7. The R1 packet may have the A bit set -- in this case, the system 2279 MAY choose to refuse it by dropping the R1 and returning to 2280 state E0. The system SHOULD consider dropping the R1 only if it 2281 used a NULL HIT in I1. If the A bit is set, the Responder's HIT 2282 is anonymous and should not be stored. 2284 8. The system SHOULD attempt to validate the HIT against the 2285 received Host Identity. 2287 9. The system MUST store the received Birthday count for future 2288 reference. 2290 10. The attempts to solve the cookie puzzle in R1. The system MUST 2291 terminate the search after a number of tries, the minimum of the 2292 degree of difficulty specified by the K value or an 2293 implementation- or policy-defined maximum retry count. It is 2294 RECOMMENDED that the system does not try more than 2^(K+2) 2295 times. If the cookie puzzle is not successfully solved, the 2296 implementation may either resend I1 within the retry bounds or 2297 abandon the HIP exchange. 2299 11. The system computes standard Diffie-Hellman keying material 2300 according to the public value and Group ID provided in the 2301 DIFFIE_HELLMAN parameter. The Diffie-Hellman keying material 2302 Kij is used for key extraction as specified in Section 9. If 2303 the received Diffie-Hellman Group ID is not supported, the 2304 implementation may either resend I1 within the retry bounds or 2305 abandon the HIP exchange. 2307 12. The system selects the HIP transform and ESP transform from the 2308 choices presented in the R1 packet and uses the selected values 2309 subsequently when generating and using encryption keys, and when 2310 sending the I2. If the proposed alternatives are not acceptable 2311 to the system, it may either resend I1 within the retry bounds 2312 or abandon the HIP exchange. 2314 13. The system prepares and creates an incoming IPsec ESP security 2315 association. It may also prepare a security association for 2316 outgoing traffic, but since it does not have the correct SPI 2317 value yet, it cannot activate it. 2319 14. The system initialized the remaining variables in the associated 2320 state, including NES ID counters. 2322 15. The system prepares and sends an I2, as described in Section 2323 7.3. 2325 16. The system SHOULD start a timer whose timeout value should be 2326 larger than the worst-case anticipated RTT, and MUST increment a 2327 timeout counter associated with the I2. The sender SHOULD 2328 retransmit the I2 upon a timeout and restart the timer, up to a 2329 maximum of I2_RETRIES_MAX tries. 2331 17. If the system is in state E1, it shall transition to state E2. 2332 If the system is in state E3, it remains so. If the system is in 2333 state E4, it stops the rekey attempt and goes to E3. 2335 18. If the system is in state E3/E4, the system prepares to drop its 2336 old outgoing Security Association and replace the incoming 2337 Security Association with the newly generated ones upon 2338 receiving a matching R2. 2340 8.6 Processing incoming I2 packets 2342 Upon receipt of an I2, the system MAY perform initial checks to 2343 determine whether the I2 corresponds to a recent R1 that has been 2344 sent out, if the Responder keeps such state. For example, the sender 2345 could check whether the I2 is from an address or HIT that has 2346 recently received an R1 from it. If the I2 is considered to be 2347 suspect, it MAY be silently discarded by the system. 2349 Otherwise, the HIP implementation SHOULD process the I2. This 2350 includes validation of the cookie puzzle solution, generating the 2351 Diffie-Hellman key, decrypting the Initiator's Host Identity, 2352 verifying the signature, creating state, and finally sending an R2. 2354 The following steps define the conceptual processing rules for 2355 responding to an I2 packet: 2357 1. The system MAY perform checks to verify that the I2 corresponds 2358 to a recently sent R1. Such checks are implementation 2359 dependent. See Appendix D for a description of an example 2360 implementation. 2362 2. The system MUST check that the Responder's HIT corresponds to 2363 one of its own HITs. 2365 3. The system MUST validate the solution to the cookie puzzle by 2366 computing the SHA-1 hash described in Section 7.3. 2368 4. The I2 MUST have a single value in each of the HIP_TRANSFORM and 2369 ESP_TRANSFORM parameters, which MUST each match one of the 2370 values offered to the Initiator in the R1 packet. 2372 5. The system must derive Diffie-Hellman keying material Kij based 2373 on the public value and Group ID in the DIFFIE_HELLMAN 2374 parameter. This key is used to derive the HIP and ESP 2375 association keys, as described in Section 9. If the 2376 Diffie-Hellman Group ID is unsupported, the I2 packet is 2377 silently dropped. 2379 6. The encrypted HOST_ID or HOST_ID_FQDN is decrypted by the 2380 Initiator encryption key defined in Section 9. If the decrypted 2381 data is not an HOST_ID or HOST_ID_FQDN parameter, the I2 packet 2382 is silently dropped. 2384 7. The implementation SHOULD also verify that the Initiator's HIT 2385 in the I2 corresponds to the Host Identity sent in the I2. 2387 8. The system MUST verify the HIP_SIGNATURE according to Section 2388 6.2.12 and Section 7.3. 2390 9. If the system is in state E3 with respect to the HITs, the 2391 system MUST perform the birthday cookie check as defined in 2392 Section 5.3. 2394 10. If the checks above are valid, then the system proceeds with 2395 further I2 processing; otherwise, it discards the I2 and remains 2396 in the same state. 2398 11. The I2 packet may have the C bit set -- in this case, the system 2399 should anticipate the receipt of HIP CER packets that contain 2400 the host identity corresponding to the responder's HIT. 2402 12. The I2 packet may have the A bit set -- in this case, the system 2403 MAY choose to refuse it by dropping the I2 and returning to 2404 state E0. If the A bit is set, the Initiator's HIT is anonymous 2405 and should not be stored. 2407 13. The I2 packet may have the E bit set. If so, the HIP 2408 implementation MUST treat the ESP sequence numbers as 64 bit 2409 quantities as described in Section 11.4. 2411 14. The Birthday count is extracted from the BIRTHDAY_COOKIE 2412 parameter and stored for future use. 2414 15. The SPI_LSI field is parsed to obtain the SPI that will be used 2415 for the Security Association outbound from the Responder and 2416 inbound to the Initiator. 2418 16. If the system supports LSIs, it should check that the received 2419 LSI is an acceptable representation of its own identity, and 2420 create an appropriate state. If the LSI is not acceptable, the 2421 behaviour is currently undefined; see Appendix A. 2423 17. The system prepares and creates both incoming and outgoing ESP 2424 security associations. 2426 18. The system initialized the remaining variables in the associated 2427 state, including NES ID counters. 2429 19. Upon successful processing of an I2 in states E0, E1, and E2, an 2430 R2 is sent and the state machine transitions to state E3. 2432 20. Upon successful processing of an I2 in state E3/E4 (which 2433 includes a successful Birthday check), the old Security 2434 Association is dropped and a new one is installed, an R2 is 2435 sent, and the state machine transitions to E3, dropping any 2436 possibly ongoing rekeying attempt. 2438 8.7 Processing incoming R2 packets 2440 An R2 received in states E0, E1, E3 or E4 results in the R2 being 2441 dropped and the state machine staying in the same state. If an R2 is 2442 received in state E2, it SHOULD be processed. 2444 The following steps define the conceptual processing rules for 2445 responding to an I2 packet: 2447 1. The system MUST verify that the HITs in use correspond to the 2448 HITs that were received in R1. 2450 2. The system MUST verify the HMAC according to the procedures in 2451 Section 6.2.11. 2453 3. The system MUST verify the HIP signature according to the 2454 procedures in Section 6.2.12. 2456 4. If any of the checks above fail, there is a high probability of 2457 an ongoing man-in-the-middle or other security attack. The 2458 system SHOULD act accordingly, based on its local policy. 2460 5. The R2 packet may have the E bit set. If so, the HIP 2461 implementation MUST treat the ESP sequence numbers as 64 bit 2462 quantities as described in Section 11.4. 2464 6. If the system is already in state E3 or E4, it drops the old 2465 outbound ESP Security association. If the system is in state E4, 2466 it stops the rekey attempt. 2468 7. The SPI_LSI field is parsed to obtain the SPI that will be used 2469 for the ESP Security Association inbound to the Responder. The 2470 system uses this SPI to create or activate the outgoing ESP 2471 security association used to send packets to the peer. 2473 8. If the system supports LSIs, it should check that the received 2474 LSI is an acceptable representation of its own identity, and 2475 create an appropriate state. If the LSI is not acceptable, the 2476 behaviour is currently undefined; see Appendix A. 2478 9. Upon successful processing of the R2, the state machine moves to 2479 state E3. 2481 8.8 Initiating rekeying 2483 A system may initiate the rekey procedure at any time. It MUST 2484 initiate a rekey if its incoming ESP sequence counter is about to 2485 overflow. 2487 The following steps define the conceptual processing rules for 2488 initiating a rekey: 2490 1. The system SHOULD generate a new Diffie-Hellman public key. 2492 2. The system MUST increment its outgoing NES ID counter. 2494 3. The system creates a NES packet, which SHOULD contain a 2495 Diffie-Hellman parameter. If the NES packet contains the 2496 Diffie-Hellman parameter, the Keymat Index in the NES_INFO 2497 parameter MUST be zero. 2499 4. The system sends the NES packet and transitions to state E4. 2501 5. The system SHOULD start a timer whose timeout value should be 2502 larger than the worst-case anticipated RTT, and MUST increment a 2503 timeout counter associated with NES. The sender SHOULD retransmit 2504 the NES upon a timeout and restart the timer, up to a maximum of 2505 NES_RETRIES_MAX tries. 2507 6. The system MUST NOT delete its existing SAs, but continue using 2508 them if its policy still allows. The NES procedure SHOULD be 2509 initiated prior enough in order to make sure that the SA replay 2510 counters do not overflow. 2512 8.9 Processing NES packets 2514 When a system receives a NES packet, its processing depends on 2515 whether the packet is a reply to a previously sent NES packet or the 2516 NES is a new packet. 2518 The following steps define the conceptual processing rules responding 2519 handling a received NES packet: 2521 1. If the system is in state E3 and the NES has the R-bit set, the 2522 packet is silently dropped. 2524 2. If the NES ID in the received NES is smaller than the stored 2525 incoming NES ID, the packet MUST BE dropped. Note that if the 2526 NES ID is equal to the stored value, the packet can be expected 2527 to be a retransmission, and acted accordingly. However, the 2528 HMAC verification (next step) MUST NOT be skipped. (A 2529 byte-by-byte comparison of the received and a store packet would 2530 be OK, though.) 2532 3. The system MUST verify the HMAC in the NES packet. If the 2533 verification fails, the packet MUST be dropped. 2535 4. If the received NES contains a Diffie-Hellman parameter, the 2536 received Keymat Index MUST zero. If this test fails, the packet 2537 SHOULD be dropped and the system SHOULD log an error message. 2539 5. If the received NES does not contain a Diffie-Hellman parameter, 2540 the received Keymat Index MUST be larger or equal to the index 2541 of the next byte to be drawn from the current KEYMAT. If this 2542 test fails, the packet SHOULD be dropped and the system SHOULD 2543 log an error message. 2545 6. The system MAY verify the SIGNATURE in the NES packet. If the 2546 verification fails, the packet SHOULD be dropped and an error 2547 message logged. 2549 7. The system MUST record the NES ID in the received packet, for 2550 replay protection. 2552 8. If the system is in state E3, and the NES does not have the 2553 R-bit set, the packet is processed as specified in Section 2554 8.9.1. 2556 9. If the system is in state E4, and the NES has the R-bit set, the 2557 packet is processed as specified in Section 8.9.2. 2559 10. If the system is in state E4, and the NES doesn't have the R-bit 2560 set, there are apparently two NES packets crossing each other in 2561 the network. Consequently, the R-bit-less packet is handled as 2562 specified in Section 8.9.1. However, in order not to 2563 unnecessarily spend cycles in Diffie-Hellman computations, there 2564 are minor differences to the case of receiving such a packet in 2565 state E3. 2567 8.9.1 Processing an initial NES packet 2569 When a system receives an initial NES packet, i.e. one that does not 2570 have the R-bit set, it prepares new incoming and outgoing SAs, but 2571 does not change the outgoing SA yet. Once it has the new SAs in 2572 place, it sends a reply NES. The contents of the reply NES depend on 2573 whether the system was in state E3 or E4 upon receiving the initial 2574 NES packet. 2576 The following steps define the conceptual processing rules responding 2577 handling a received initial NES packet: 2579 1. If the system is in state E3, it consults its policy to see if it 2580 needs to generate a new Diffie-Hellman key, and generates a new 2581 key if needed. If the system is in state E4, it may already have 2582 generated a new Diffie-Hellman key, and SHOULD use it. 2584 2. If either the received NES contains a new Diffie-Hellman key, the 2585 system has a new Diffie-Hellman key from the previous step, or 2586 both, the system generates new KEYMAT. If there is only one new 2587 Diffie-Hellman key, the other old key is used. 2589 3. If the system generated new KEYMAT in the previous step, it sets 2590 Keymat Index to zero, independent on whether the received NES 2591 included a Diffie-Hellman key or not. 2593 4. The system draws keys for new incoming and outgoing ESP SAs, 2594 starting from the Keymat Index, and prepares new incoming and 2595 outgoing ESP SAs. The SPI for the outgoing SA is the new SPI 2596 value from the received NES. The SPI for the incoming SA is 2597 locally generated, and SHOULD be random. The system MUST NOT 2598 start using the new outgoing SA before it receives traffic on the 2599 new incoming SA. 2601 5. The system prepares a reply NES packet, with the R-bit one, 2602 Keymat Index being the one used above, NES ID being equal to the 2603 one in the received NES, old SPI being the current incoming SPI, 2604 and new SPI being the newly generated incoming SPI. If the 2605 system generated a new Diffie-Hellman key above, the new key is 2606 included in the packet in the Diffie-Hellman payload. Note that 2607 if the system is in state E4, the new Diffie-Hellman key was 2608 probably generated and sent already earlier, in which case it 2609 MUST NOT be included into the reply packet. 2611 8.9.2 Processing a reply NES packet 2613 When a system receives a reply NES packet, i.e. one that has the 2614 R-bit set, it starts to use the new outgoing SA. It must also 2615 complete its new incoming SA. 2617 The following steps define the conceptual processing rules responding 2618 handling a received reply NES packet: 2620 1. If either the received NES contains a new Diffie-Hellman key, the 2621 system has a new Diffie-Hellman key from initiating rekey, or 2622 both, the system generates new KEYMAT. If there is only one new 2623 Diffie-Hellman key, the old key is used as the other key. 2625 2. If the system generated new KEYMAT in the previous step, it sets 2626 Keymat Index to zero, independent on whether the received NES 2627 included a Diffie-Hellman key or not. 2629 3. The system draws keys for new incoming and outgoing ESP SAs, 2630 starting from the Keymat Index, and prepares new incoming and 2631 outgoing ESP SAs. The SPI for the outgoing SA is the new SPI 2632 value from the NES. The SPI for the incoming SA was generated 2633 when rekey was initiated. 2635 4. The system starts to send to the new outgoing SA. It should 2636 start receiving data on the new incoming SA as soon as the peer 2637 receives data on the new SA. 2639 5. If the system has no data to send for 500ms, it SHOULD send an 2640 ESP packet anyway. The purpose of this packet is to acknowledge 2641 the other party that the NES reply came through, and to allow the 2642 other party to switch over to the new outgoing SA. It is 2643 RECOMMENDED that the system sends an empty ESP packet, i.e., one 2644 where the Next Header field is IPPROTO_NONE (decimal 59). 2646 8.10 Processing BOS packets 2648 Processing BOS packets is OPTIONAL, and currently undefined. 2650 8.11 Processing CER packets 2652 Processing CER packets is OPTIONAL, and currently undefined. 2654 8.12 Processing PAYLOAD packets 2656 Processing PAYLOAD packets is OPTIONAL, and currently undefined. 2658 9. HIP KEYMAT 2660 HIP keying material is derived from the Diffie-Hellman Kij produced 2661 during the base HIP exchange. The Initiator has Kij during the 2662 creation of the I2 packet, and the Responder has Kij once it receives 2663 the I2 packet. This is why I2 can already contain encrypted 2664 information. 2666 The KEYMAT is derived by feeding Kij and the HITs into the following 2667 operation; the | operation denotes concatenation. 2669 KEYMAT = K1 | K2 | K3 | ... 2670 where 2672 K1 = SHA-1( Kij | sort(HIT-I | HIT-R) | 0x01 ) 2673 K2 = SHA-1( Kij | K1 | 0x02 ) 2674 K3 = SHA-1( Kij | K2 | 0x03 ) 2675 ... 2676 K255 = SHA-1( Kij | K254 | 0xff ) 2677 K256 = SHA-1( Kij | K255 | 0x00 ) 2678 etc. 2680 Sort(HIT-I | HIT-R) is defined as the numeric network byte order 2681 comparison of the HITs, with lower HIT preceding higher HIT, 2682 resulting in the concatenation of the HITs in the said order. The 2683 initial keys are drawn sequentially in the following order: 2685 Initiator HIP encryption key 2687 Initiator HIP integrity (HMAC) key 2689 Responder HIP encryption key (currently unused) 2691 Responder HIP integrity (HMAC) key 2693 Initiator ESP encryption key 2695 Initiator ESP authentication key 2697 Responder ESP encryption key 2699 Responder ESP authentication key 2701 The number of bits drawn for a given algorithm is the "natural" size 2702 of the keys. For the mandatory algorithms, the following sizes 2703 apply: 2705 3DES 192 bits 2707 SHA-1 160 bits 2709 NULL 0 bits 2711 Subsequent rekeys without Diffie-Hellman just require drawing out 2712 more sets of ESP keys. In the situation where Kij is the result of a 2713 HIP rekey exchange with Diffie-Hellman, there is only the need from 2714 one set of ESP keys, without the HIP keys. These are then the only 2715 keys taken from the KEYMAT. 2717 10. HIP Fragmentation Support 2719 A HIP implementation must support IP fragmentation / reassembly. 2720 Fragment reassembly MUST be implemented in both IPv4 and IPv6, but 2721 fragment generation MUST be implemented only in IPv4 (IPv4 stacks and 2722 networks will usually do this by default) and SHOULD be implemented 2723 in IPv6. In the IPv6 world, the minimum MTU is larger, 1280 bytes, 2724 than in the IPv4 world. The larger MTU size is usually sufficient for 2725 most HIP packets, and therefore fragment generation may not be 2726 needed. If a host expects to send HIP packets that are larger than 2727 the minimum IPv6 MTU, it MUST implement fragment generation even for 2728 IPv6. 2730 In the IPv4 world, HIP packets may encounter low MTUs along their 2731 routed path. Since HIP does not provide a mechanism to use multiple 2732 IP datagrams for a single HIP packet, support of path MTU discovery 2733 does not bring any value to HIP in the IPv4 world. HIP aware NAT 2734 systems MUST perform any IPv4 reassembly/fragmentation. 2736 All HIP implementations MUST employ a reassembly algorithm that is 2737 sufficiently resistant against DoS attacks. 2739 11. ESP with HIP 2741 XXX: Since HIP is designed for host usage, not for gateways, only ESP 2742 transport mode is supported with HIP. The SA is not bound to an IP 2743 address; all internal control of the SA is by the HIT and LSI. XXX 2744 BEET mode. 2746 Since HIP does not negotiate any lifetimes, all lifetimes are local 2747 policy. The only lifetimes a HIP implementation MUST support are 2748 sequence number rollover (for replay protection), and SA timeout. An 2749 SA times out if no packets are received using that SA. The default 2750 timeout value is 15 minutes. Implementations MAY support lifetimes 2751 for the various ESP transforms. 2753 11.1 Security Association Management 2755 An SA pair is indexed by the 2 SPIs and 2 HITs (both HITs since a 2756 system can have more than one HIT). An inactivity timer is 2757 recommended for all SAs. If the state dictates the deletion of an 2758 SA, a timer is set to allow for any late arriving packets. 2760 11.2 Security Parameter Index (SPI) 2762 The SPIs in ESP provide a simple compression of the HIP data from all 2763 packets after the HIP exchange. This does require a per HIT- pair 2764 Security Association (and SPI), and a decrease of policy granularity 2765 over other Key Management Protocols like IKE. 2767 When a host rekeys, it gets a new SPI from its partner. 2769 11.3 Supported Transforms 2771 All HIP implementations MUST support 3DES [7] and HMAC-SHA-1-96 [4]. 2772 If the Initiator does not support any of the transforms offered by 2773 the Responder in the R1 HIP packet, it MUST use 3DES and 2774 HMAC-SHA-1-96 and state so in the I2 HIP packet. 2776 In addition to 3DES, all implementations MUST implement the ESP NULL 2777 encryption and authentication algorithms. These algoritms are 2778 provided mainly for debugging purposes, and SHOULD NOT be used in 2779 production environments. The default configuration in 2780 implementations MUST be to reject NULL encryption or authentication. 2782 11.4 Sequence Number 2784 The Sequence Number field is MANDATORY in ESP. Anti-replay 2785 protection MUST be used in an ESP SA established with HIP. 2787 This means that each host MUST rekey before its sequence number 2788 reaches 2^32, or if extended sequence numbers are used, 2^64. Note 2789 that in HIP rekeying, unlike IKE rekeying, only one Diffie-Hellman 2790 key can be changed, that of the rekeying host. However, if one host 2791 rekeys, the other host SHOULD rekey as well. 2793 In some instances, a 32 bit sequence number is inadequate. In either 2794 the I2 or R2 packets, a peer MAY require that a 64 bit sequence 2795 number be used. In this case the higher 32 bits are NOT included in 2796 the ESP header, but are simply kept local to both peers. 64 bit 2797 sequence numbers must only be used for ciphers that will not be open 2798 to cryptoanalysis as a result. AES is one such cipher. 2800 12. HIP Policies 2802 There are a number of variables that will influence the HIP exchanges 2803 that each host must support. All HIP implementations MUST support 2804 more than one simultaneous HIs, at least one of which SHOULD be 2805 reserved for anonymous usage. Although anonymous HIs will be rarely 2806 used as responder HIs, they will be common for Initiators. Support 2807 for more than two HIs is RECOMMENDED. 2809 Many Initiators would want to use a different HI for different 2810 Responders. The implementations SHOULD provide for an ACL of 2811 initiator HIT to responder HIT. This ACL SHOULD also include 2812 preferred transform and local lifetimes. For HITs with HAAs, 2813 wildcarding SHOULD be supported. Thus if a Community of Interest, 2814 like Banking, gets an RAA, a single ACL could be used. A global 2815 wildcard would represent the general policy to be used. Policy 2816 selection would be from most specific to most general. 2818 The value of K used in the HIP R1 packet can also vary by policy. K 2819 should never be greater than 20, but for trusted partners it could be 2820 as low as 0. 2822 Responders would need a similar ACL, representing which hosts they 2823 accept HIP exchanges, and the preferred transform and local 2824 lifetimes. Wildcarding SHOULD be supported for this ACL also. 2826 13. Security Considerations 2828 HIP is designed to provide secure authentication of hosts and to 2829 provide a fast key exchange for IPsec ESP. HIP also attempts to 2830 limit the exposure of the host to various denial-of-service and man- 2831 in-the-middle attacks. In so doing, HIP itself is subject to its own 2832 DoS and MitM attacks that potentially could be more damaging to a 2833 host's ability to conduct business as usual. 2835 HIP enabled ESP is IP address independent. This might seem to make 2836 it easier for an attacker, but ESP with replay protection is already 2837 as well protected as possible, and the removal of the IP address as a 2838 check should not increase the exposure of ESP to DoS attacks. 2839 Furthermore, this is in line with the forthcoming revision of ESP. 2841 Denial-of-service attacks take advantage of the cost of start of 2842 state for a protocol on the Responder compared to the 'cheapness' on 2843 the Initiator. HIP makes no attempt to increase the cost of the 2844 start of state on the Initiator, but makes an effort to reduce the 2845 cost to the Responder. This is done by having the Responder start 2846 the 3-way cookie exchange instead of the Initiator, making the HIP 2847 protocol 4 packets long. In doing this, packet 2 becomes a 'stock' 2848 packet that the Responder MAY use many times. The duration of use is 2849 a paranoia versus throughput concern. Using the same Diffie- Hellman 2850 values and random puzzle I has some risk. This risk needs to be 2851 balanced against a potential storm of HIP I1 packets. 2853 This shifting of the start of state cost to the Initiator in creating 2854 the I2 HIP packet, presents another DoS attack. The attacker spoofs 2855 the I1 HIP packet and the Responder sends out the R1 HIP packet. 2856 This could conceivably tie up the 'initiator' with evaluating the R1 2857 HIP packet, and creating the I2 HIP packet. The defense against this 2858 attack is to simply ignore any R1 packet where a corresponding I1 or 2859 ESP data was not sent. 2861 A second form of DoS attack arrives in the I2 HIP packet. Once the 2862 attacking Initiator has solved the cookie challenge, it can send 2863 packets with spoofed IP source addresses with either invalid 2864 encrypted HIP payload component or a bad HIP signature. This would 2865 take resources in the Responder's part to reach the point to discover 2866 that the I2 packet cannot be completely processed. The defense 2867 against this attack is after N bad I2 packets, the Responder would 2868 discard any I2s that contain the given Initiator HIT. Thus will shut 2869 down the attack. The attacker would have to request another R1 and 2870 use that to launch a new attack. The Responder could up the value of 2871 K while under attack. On the downside, valid I2s might get dropped 2872 too. 2874 A third form of DoS attack is emulating the restart of state after a 2875 reboot of one of the partners. To protect from such an attack, a 2876 system Birthday is included in the R1 and I2 packets to prove loss of 2877 state to a peer. The inclusion of the Birthday creates a very 2878 deterministic process for state restart. Any other action is a DoS 2879 attack. 2881 A fourth form of DoS attack is emulating the end of state. HIP has 2882 no end of state packet. It relies on a local policy timer to end 2883 state. 2885 Man-in-the-middle attacks are difficult to defend against, without 2886 third-party authentication. A skillful MitM could easily handle all 2887 parts of HIP; but HIP indirectly provides the following protection 2888 from a MitM attack. If the Responder's HI is retrieved from a signed 2889 DNS zone, a certificate, or through some other secure means, the 2890 Initiator can use this to validate the R1 HIP packet. 2892 Likewise, if the Initiator's HI is in a secure DNS zone, a trusted 2893 certificate, or otherwise securely available, the Responder can 2894 retrieve it after it gets the I2 HIP packet and validate that. 2895 However, since an Initiator may choose to use an anonymous HI, it 2896 knowingly risks a MitM attack. The Responder may choose not to 2897 accept a HIP exchange with an anonymous Initiator. 2899 Since not all hosts will ever support HIP, ICMP 'Destination Protocol 2900 Unreachable' are to be expected and present a DoS attack. Against an 2901 Initiator, the attack would look like the Responder does not support 2902 HIP, but shortly after receiving the ICMP message, the Initiator 2903 would receive a valid R1 HIP packet. Thus to protect from this 2904 attack, an Initiator should not react to an ICMP message until a 2905 reasonable delta time to get the real Responder's R1 HIP packet. A 2906 similar attack against the Responder is more involved. First an ICMP 2907 message is expected if the I1 was a DoS attack and the real owner of 2908 the spoofed IP address does not support HIP. The Responder SHOULD 2909 NOT act on this ICMP message to remove the minimal state from the R1 2910 HIP packet (if it has one), but wait for either a valid I2 HIP packet 2911 or the natural timeout of the R1 HIP packet. This is to allow for a 2912 sophisticated attacker that is trying to break up the HIP exchange. 2913 Likewise, the Initiator should ignore any ICMP message while waiting 2914 for an R2 HIP packet, deleting state only after a natural timeout. 2916 14. IANA Considerations 2918 IANA has assigned IP Protocol number TBD to HIP. 2920 15. Acknowledgments 2922 The drive to create HIP came to being after attending the MALLOC 2923 meeting at IETF 43. Baiju Patel and Hilarie Orman really gave the 2924 original author, Bob Moskowitz, the assist to get HIP beyond 5 2925 paragraphs of ideas. It has matured considerably since the early 2926 drafts thanks to extensive input from IETFers. Most importantly, its 2927 design goals are articulated and are different from other efforts in 2928 this direction. Particular mention goes to the members of the 2929 NameSpace Research Group of the IRTF. Noel Chiappa provided the 2930 framework for LSIs and Keith Moore the impetus to provide 2931 resolvability. Steve Deering provided encouragement to keep working, 2932 as a solid proposal can act as a proof of ideas for a research group. 2934 Many others contributed; extensive security tips were provided by 2935 Steve Bellovin. Rob Austein kept the DNS parts on track. Paul 2936 Kocher taught Bob Moskowitz how to make the cookie exchange expensive 2937 for the Initiator to respond, but easy for the Responder to validate. 2938 Bill Sommerfeld supplied the Birthday concept to simplify reboot 2939 management. Rodney Thayer and Hugh Daniels provide extensive 2940 feedback. In the early times of this draft, John Gilmore kept Bob 2941 Moskowitz challenged to provide something of value. 2943 During the later stages of this document, when the editing baton was 2944 transfered to Pekka Nikander, the input from the early implementors 2945 were invaluable. Without having actual implementations, this 2946 document would not be on the level it is now. 2948 In the usual IETF fashion, a large number of people have contributed 2949 to the actual text or ideas. The list of these people include Jeff 2950 Ahrenholz, Francis Dupont, Derek Fawcus, George Gross, Andrew 2951 McGregor, Julien Laganier, Miika Komu, Mika Kousa, Jan Melen, Henrik 2952 Petander, Michael Richardson, Tim Shepard, and Jukka Ylitalo. Our 2953 apologies to anyone who's name is missing. 2955 Normative references 2957 [1] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 2958 1980. 2960 [2] Mockapetris, P., "Domain names - implementation and 2961 specification", STD 13, RFC 1035, November 1987. 2963 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2964 Levels", BCP 14, RFC 2119, March 1997. 2966 [4] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP 2967 and AH", RFC 2404, November 1998. 2969 [5] Maughan, D., Schneider, M. and M. Schertler, "Internet Security 2970 Association and Key Management Protocol (ISAKMP)", RFC 2408, 2971 November 1998. 2973 [6] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, 2974 November 1998. 2976 [7] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", 2977 RFC 2451, November 1998. 2979 [8] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 2980 Specification", RFC 2460, December 1998. 2982 [9] Eastlake, D., "Domain Name System Security Extensions", RFC 2983 2535, March 1999. 2985 [10] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System 2986 (DNS)", RFC 2536, March 1999. 2988 [11] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 2989 Public Key Infrastructure Certificate and Certificate 2990 Revocation List (CRL) Profile", RFC 3280, April 2002. 2992 [12] Draves, R., "Default Address Selection for Internet Protocol 2993 version 6 (IPv6)", RFC 3484, February 2003. 2995 [13] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 2996 Addressing Architecture", RFC 3513, April 2003. 2998 [14] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 2999 Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3000 3526, May 2003. 3002 [15] Kent, S., "IP Encapsulating Security Payload (ESP)", 3003 draft-ietf-ipsec-esp-v3-06 (work in progress), July 2003. 3005 [16] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 3006 draft-ietf-ipsec-ikev2-10 (work in progress), August 2003. 3008 [17] Moskowitz, R., "Host Identity Protocol Architecture", 3009 draft-moskowitz-hip-arch-03 (work in progress), May 2003. 3011 [18] NIST, "FIPS PUB 180-1: Secure Hash Standard", April 1995. 3013 Informative references 3015 [19] Bellovin, S. and W. Aiello, "Just Fast Keying (JFK)", 3016 draft-ietf-ipsec-jfk-04 (work in progress), July 2002. 3018 [20] Moskowitz, R. and P. Nikander, "Using Domain Name System (DNS) 3019 with Host Identity Protocol (HIP)", draft-nikander-hip-dns-00 3020 (to be issued) (work in progress), June 2003. 3022 [21] Nikander, P., "SPI assisted NAT traversal (SPINAT) with Host 3023 Identity Protocol (HIP)", draft-nikander-hip-nat-00 (to be 3024 issued) (work in progress), June 2003. 3026 [22] Crosby, SA. and DS. Wallach, "Denial of Service via Algorithmic 3027 Complexity Attacks", in Proceedings of Usenix Security 3028 Symposium 2003, Washington, DC., August 2003. 3030 Authors' Addresses 3032 Robert Moskowitz 3033 ICSAlabs, a Division of TruSecure Corporation 3034 1000 Bent Creek Blvd, Suite 200 3035 Mechanicsburg, PA 3036 USA 3038 EMail: rgm@icsalabs.com 3040 Pekka Nikander 3041 Ericsson Research Nomadiclab 3043 JORVAS FIN-02420 3044 FINLAND 3046 Phone: +358 9 299 1 3047 EMail: pekka.nikander@nomadiclab.com 3049 Petri Jokela 3050 Ericsson Research Nomadiclab 3052 JORVAS FIN-02420 3053 FINLAND 3055 Phone: +358 9 299 1 3056 EMail: petri.jokela@nomadiclab.com 3057 Thomas R. Henderson 3058 The Boeing Company 3059 P.O. Box 3707 3060 Seattle, WA 3061 USA 3063 EMail: thomas.r.henderson@boeing.com 3065 Appendix A. Backwards compatibility API issues 3067 Tom Henderson has several times expressed the thought that that the 3068 LSI could be completely local and does not need to be exchanged. 3069 Applications could continue to use IP addresses in socket calls, and 3070 kernel does whatever NATting (including application NATting) is 3071 required. It was pointed out that this approach was going to be 3072 prone to some kinds of data flows escaping the HIP protection, unless 3073 the local housekeeping in an implementation was especially good. 3074 Example: FTP opens control connection to IP address. One or both 3075 parties move. FTP later opens data connection to the old IP address. 3076 Kernel must identify that the application really means to connect to 3077 the host that was previously at that IP address -- but obviously if 3078 the old address is reused by another host, this becomes difficult. 3080 Related to this, the discussion also opened up the question of DNS 3081 resolution. Should the HIT/LSI be returned to applications as a 3082 (spoofed) address in the resolution process, allowing apps to use the 3083 socket API with HIT or LSI values instead of an IP address? While 3084 this seems to be the original intention of LSIs, there are a couple 3085 of difficulties especially in the IPv4 case: 3087 How does kernel know whether value being passed in a socket call 3088 is an IP address or an LSI? The fact that a name resolver library 3089 gave an application an LSI is no guarantee that the application 3090 will use that information in its socket call. It may also have 3091 cached some IP address from before or received an IP address as 3092 side information. This difficulty is now relieved as the LSIs are 3093 constrained to the well-known private subnet space. 3095 Handing an LSI may confuse legacy applications that assume that 3096 what is being passed to them is an IP address. Good examples of 3097 this are diagnostic tools such as dig and ping. The conclusion is 3098 that HIP should most not be used with diagnostic applications. 3100 What does kernel do with an LSI that it cannot map to an address 3101 based on information that it has locally cached? 3103 It seems that some modification to the resolver library (to 3104 explicitly convey HIP information rather than spoofing IP addresses), 3105 as well as modifications to socket API to explicitly let the kernel 3106 know that the application is HIP aware, are the cleanest long-term 3107 solution, but what to do about legacy applications?? -- still 3108 partially an open issue. The HUT team has been considering these 3109 problems. 3111 In summary, there seems to be two schools of thought, and their 3112 approaches can be summarized as follows: 3114 1. Have the resolver return an LSI in place of an actual IP address, 3115 and have applications use the LSI instead of the IP address in 3116 socket calls. By making LSI fall into an unassigned IP address 3117 space, the kernel can distinguish between calls made with an LSI 3118 and calls made with an IP address. This is the approach 3119 currently recommended in this specification. 3121 Now some complications with this approach are the following: 3123 1. One probably does not want to invoke a HIP exchange just 3124 because an application did a DNS lookup on a hostname; 3125 applications use resolver for other reasons than just prior 3126 to initiating a flow. Since LSIs are a subset of the HIT 3127 bits, we could avoid having to do the HIP exchange to find 3128 the LSIs, if it weren't for the possibility of collision. 3129 So, this approach seems to be pointing us towards doing HIP 3130 exchanges prior to the application's initial socket calls. 3131 Note that this would also break the opportunity to piggyback 3132 data on the I2/R2. 3134 2. Some applications might actually want IP addresses 3135 explicitly, such as diagnostic applcations. 3137 3. Some applications likely will obtain addresses out-of-band, 3138 so even in this scenario, the kernel may be faced with a case 3139 where it would like to use HIP from a policy standpoint, but 3140 the invoking application called connect() with an IP address. 3142 One way around might be to have a separate resolver call that 3143 returns an LSI, or enhance the data structure returned by 3144 resolver to include LSI in addition to IP address, but this then 3145 throws the burden on applications to be HIP-aware. 3147 2. Have the LSI be kept in kernel land, with the kernel doing the 3148 right housekeeping. Unless the application is HIP aware and can 3149 explicitly signal that it wants to use HIP (such as with a 3150 setsockopt() flag), the use of HIP is coordinated by a policy 3151 table that temporarily traps packets going to particular IP 3152 addresses until a HIP exchange completes and the security 3153 association is set up. In this case, the kernel does the right 3154 checksum munging and handles readdressing, in a manner 3155 transparent to the applications, which just think that they have 3156 connected to an IP address as before. This essentially means 3157 that the is responsible for managing the association between IP 3158 address (as perceived by an application) and actual destination 3159 identity. This is similar to the way that opportunistic IPsec 3160 works today. 3162 This solution has the following drawbacks: 3164 1. One is architecturally forced back into the mode of using IP 3165 addresses to indirectly identify hosts, at least initially. 3166 The IP stack has to maintain tables that say things like "if 3167 a socket call comes in for address X, do a HIP exchange to 3168 that address." (note that this may require an opportunistic 3169 exchange) This constrains the kinds of mobility that the 3170 system can handle. 3172 2. One can construct scenarios for which the kernel and 3173 applications are out of sync with respect to IP addresses, 3174 and flows may escape their intended IPsec envelope. Example: 3175 I open FTP control connection to address X. That host moves 3176 to address Y. Some other host takes up address X. I next 3177 receive a connect() to address X. Which host does that 3178 process want to connect to? 3180 Appendix B. Probabilities of HIT collisions 3182 The birthday paradox sets a bound for the expectation of collisions. 3183 It is based on the square root of the number of values. A 64-bit 3184 hash, then, would put the chances of a collision at 50-50 with 2^32 3185 hosts (4 billion). A 1% chance of collision would occur in a 3186 population of 640M and a .001% collision chance in a 20M population. 3187 A 128 bit hash will have the same .001% collision chance in a 9x10^16 3188 population. 3190 Appendix C. Probabilities in the cookie calculation 3192 A question: Is it guaranteed that the Initiator is able to solve the 3193 puzzle in this way when the K value is large? 3195 Answer: No, it is not guaranteed. But it is not guaranteed even in 3196 the old mechanism, since the Initiator may start far away from J and 3197 arrive to J after far too many steps. If we wanted to make sure that 3198 the Initiator finds a value, we would need to give some hint of a 3199 suitable J, and I don't think we want to do that. 3201 In general, if we model the hash function with a random function, the 3202 probability that one iteration gives are result with K zero bits is 3203 2^-K. Thus, the probablity that one iteration does *not* give K zero 3204 bits is (1 - 2^-K). Consequently, the probablity that 2^K iterations 3205 does not give K zero bits is (1 - 2^-K)^(2^K). 3207 Since my calculus starts to be rusty, I made a small experiment and 3208 found out that 3210 lim (1 - 2^-k)^(2^k) = 0.36788 3211 k->inf 3213 lim (1 - 2^-k)^(2^(k+1)) = 0.13534 3214 k->inf 3216 lim (1 - 2^-k)^(2^(k+2)) = 0.01832 3217 k->inf 3219 lim (1 - 2^-k)^(2^(k+3)) = 0.000335 3220 k->inf 3222 Thus, if hash functions were random functions, we would need about 3223 2^(K+3) iterations to make sure that the probability of a failure is 3224 less than 1% (actually less than 0.04%). Now, since my perhaps 3225 flawed understanding of hash functions is that they are "flatter" 3226 than random functions, 2^(K+3) is probably an overkill. OTOH, the 3227 currently suggested 2^K is clearly too little. The draft has been 3228 changed to read 2^(K+2). 3230 Appendix D. Using responder cookies 3232 As mentioned in Section 4.1.1, the Responder may delay state creation 3233 and still reject most spoofed I2s by using a number of pre-calculated 3234 R1s and a local selection function. This appendix defines one 3235 possible implementation in detail. The purpose of this appendix is 3236 to give the implementators an idea on how to implement the mechanism. 3237 The method described in this appendix SHOULD NOT be used in any real 3238 implementation. If the implementation is based on this appendix, it 3239 SHOULD contain some local modification that makes an attacker's task 3240 harder. 3242 The basic idea is to create a cheap, varying local mapping function 3243 f: 3245 f( IP-I, IP-R, HIT-I, HIT-R ) -> cookie-index 3247 That is, given the Initiator's and Responder's IP addresses and 3248 HITs, the function returns an index to a cookie. When processing an 3249 I1, the cookie is embedded in an pre-computed R1, and the Responder 3250 simply sends that particular R1 to the Initiator. When processing an 3251 I2, the cookie may still be embedded in the R1, or the R1 may be 3252 depracated (and replaced with a new one), but the cookie is still 3253 there. If the received cookie does not match with the R1 or saved 3254 cookie, the I2 is simply dropped. That prevents the Initiator from 3255 generating spoofed I2s with a probability that depends on the number 3256 of pre-computed R1s. 3258 As a concrete example, let us assume that the Responder has an array 3259 of R1s. Each slot in the array contains a timestamp, an R1, and an 3260 old cookie that was sent in the previous R1 that occupied that 3261 particular slot. The Responder replaces one R1 in the array every 3262 few minutes, thereby replacing all the R1s gradually. 3264 To create a varying mapping function, the Responder generates a 3265 random number every few minutes. The octets in the IP addresses and 3266 HITs are XORed together, and finally the result is XORed with the 3267 random number. Using pseudo-code, the function looks like the 3268 following. 3270 Pre-computation: 3271 r1 := random number 3273 Index computation: 3274 index := r1 XOR hit_r[0] XOR hit_r[1] XOR ... XOR hit_r[15] 3275 index := index XOR hit_i[0] XOR hit_i[1] XOR ... XOR hit_i[15] 3276 index := index XOR ip_r[0] XOR ip_r[1] XOR ... XOR ip_r[15] 3277 index := index XOR ip_i[0] XOR ip_i[1] XOR ... XOR ip_i[15] 3279 The index gives the slot used in the array. 3281 It is possible that an Initiator receives an I1, and while it is 3282 computing I2, the Responder deprecates an R1 and/or chooses a new 3283 random number for the mapping function. Therefore the Responder must 3284 remember the cookies used in deprecated R1s and the previous random 3285 number. 3287 To check an received I2, the Responder can use a simple algorithm, 3288 expressed in pseudo-code as follows. 3290 If I2.hit_r does not match my_hits, drop the packet. 3292 index := compute_index(current_random_number, I2) 3293 If current_cookie[index] == I2.cookie, go to cookie check. 3294 If previous_cookie[index] == I2.cookie, go to cookie check. 3296 index := compute_index(previous_random_number, I2) 3297 If current_cookie[index] == I2.cookie, go to cookie check. 3298 If previous_cookie[index] == I2.cookie, go to cookie check. 3300 Drop packet. 3302 cookie_check: 3303 V := Ltrunc( SHA-1( I2.I, I2.hit_i, I2.hit_r, I2.J ), K ) 3304 if V != 0, drop the packet. 3306 Whenever the Responder receives an I2 that fails on the index check, 3307 it can simply drop the packet on the floor and forget about it. New 3308 I2s with the same or other spoofed parameters will get dropped with a 3309 reasonable probability and minimal effort. 3311 If a Responder receives an I2 that passes the index check but fails 3312 on the puzzle check, it should create a state indicating this. After 3313 two or three failures the Responder should cease checking the puzzle 3314 but drop the packets directly. This saves the Responder from the 3315 SHA-1 calculations. Such block should not last long, however, or 3316 there would be a danger that a legitimite Initiator could be blocked 3317 from getting connections. 3319 A key for the success of the defined scheme is that the mapping 3320 function must be considerably cheaper than computing SHA-1. It also 3321 must detect any changes in the IP addresses, and preferably most 3322 changes in the HITs. Checking the HITs is not that essential, 3323 though, since HITs are included in the cookie computation, too. 3325 The effectivity of the method can be varied by varying the size of 3326 the array containing pre-computed R1s. If the array is large, the 3327 probability that an I2 with a spoofed IP address or HIT happens to 3328 map to the same slot is fairly slow. However, a large array means 3329 that each R1 has a fairly long life time, thereby allowing an 3330 attacker to utilize one solved puzzle for a longer time. 3332 Appendix E. Running HIP over IPv4 UDP 3334 In the IPv4 world, with the deployed NAT devices, it may make sense 3335 to run HIP over UDP. When running HIP over UDP, the following packet 3336 structure is used. The structure is followed by the HITs, as usual. 3337 Both the Source and Destionation port MUST be 272. 3339 0 1 2 3 3340 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 3341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ 3342 | Source port | Destination port | \ 3343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >UDP 3344 | Length | Checksum | / 3345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+< 3346 | HIP Controls | HIP pkt Type | Ver. | Res. | >HIP 3347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ 3349 It is currently undefined how the actual data transfer, using ESP, is 3350 handled. Plain ESP may not go through all NAT devices. 3352 It is currently FORBIDDEN to use this packet format with IPv6. 3354 Intellectual Property Statement 3356 The IETF takes no position regarding the validity or scope of any 3357 intellectual property or other rights that might be claimed to 3358 pertain to the implementation or use of the technology described in 3359 this document or the extent to which any license under such rights 3360 might or might not be available; neither does it represent that it 3361 has made any effort to identify any such rights. Information on the 3362 IETF's procedures with respect to rights in standards-track and 3363 standards-related documentation can be found in BCP-11. Copies of 3364 claims of rights made available for publication and any assurances of 3365 licenses to be made available, or the result of an attempt made to 3366 obtain a general license or permission for the use of such 3367 proprietary rights by implementors or users of this specification can 3368 be obtained from the IETF Secretariat. 3370 The IETF invites any interested party to bring to its attention any 3371 copyrights, patents or patent applications, or other proprietary 3372 rights which may cover technology that may be required to practice 3373 this standard. Please address the information to the IETF Executive 3374 Director. 3376 Full Copyright Statement 3378 Copyright (C) The Internet Society (2003). All Rights Reserved. 3380 This document and translations of it may be copied and furnished to 3381 others, and derivative works that comment on or otherwise explain it 3382 or assist in its implementation may be prepared, copied, published 3383 and distributed, in whole or in part, without restriction of any 3384 kind, provided that the above copyright notice and this paragraph are 3385 included on all such copies and derivative works. However, this 3386 document itself may not be modified in any way, such as by removing 3387 the copyright notice or references to the Internet Society or other 3388 Internet organizations, except as needed for the purpose of 3389 developing Internet standards in which case the procedures for 3390 copyrights defined in the Internet Standards process must be 3391 followed, or as required to translate it into languages other than 3392 English. 3394 The limited permissions granted above are perpetual and will not be 3395 revoked by the Internet Society or its successors or assignees. 3397 This document and the information contained herein is provided on an 3398 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 3399 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 3400 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 3401 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 3402 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3404 Acknowledgement 3406 Funding for the RFC Editor function is currently provided by the 3407 Internet Society.