idnits 2.17.1 draft-moskowitz-hip-09.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 24 instances of too long lines in the document, the longest one being 12 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. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1106 has weird spacing: '...ariable publ...' == Line 1302 has weird spacing: '...c Value the ...' == Line 1417 has weird spacing: '... Length len...' == Line 1418 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 (February 10, 2004) is 7371 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 1427 -- Looks like a reference, but probably isn't: 'RFC3110' on line 1428 == Missing Reference: '0' is mentioned on line 3370, but not defined == Unused Reference: '5' is defined on line 3062, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 3088, 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-05 == Outdated reference: A later version (-17) exists of draft-ietf-ipsec-ikev2-07 == 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: August 10, 2004 Corporation 5 P. Nikander 6 P. Jokela (editor) 7 Ericsson Research Nomadiclab 8 T. Henderson 9 The Boeing Company 10 February 10, 2004 12 Host Identity Protocol 13 draft-moskowitz-hip-09 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 August 10, 2004. 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). 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 . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . 13 76 4.1 HIP base exchange . . . . . . . . . . . . . . . . . . . . 13 77 4.1.1 HIP Cookie Mechanism . . . . . . . . . . . . . . . . . . . 14 78 4.1.2 Authenticated Diffie-Hellman protocol . . . . . . . . . . 16 79 4.1.3 HIP Birthday . . . . . . . . . . . . . . . . . . . . . . . 17 80 4.2 Sending data on HIP packets . . . . . . . . . . . . . . . 17 81 4.3 Rekey . . . . . . . . . . . . . . . . . . . . . . . . . . 17 82 4.4 Bootstrap support . . . . . . . . . . . . . . . . . . . . 18 83 4.5 Certificate distribution . . . . . . . . . . . . . . . . . 18 84 5. HIP packet flow and state machine . . . . . . . . . . . . 19 85 5.1 HIP Scenarios . . . . . . . . . . . . . . . . . . . . . . 19 86 5.2 Refusing a HIP exchange . . . . . . . . . . . . . . . . . 20 87 5.3 Reboot and SA timeout restart of HIP . . . . . . . . . . . 20 88 5.4 HIP State Machine . . . . . . . . . . . . . . . . . . . . 20 89 5.4.1 HIP States . . . . . . . . . . . . . . . . . . . . . . . . 21 90 5.4.2 HIP State Processes . . . . . . . . . . . . . . . . . . . 21 91 5.4.3 Simplified HIP State Diagram . . . . . . . . . . . . . . . 24 92 6. Packet formats . . . . . . . . . . . . . . . . . . . . . . 26 93 6.1 Payload format . . . . . . . . . . . . . . . . . . . . . . 26 94 6.1.1 HIP Controls . . . . . . . . . . . . . . . . . . . . . . . 27 95 6.1.2 Checksum . . . . . . . . . . . . . . . . . . . . . . . . . 27 96 6.2 HIP parameters . . . . . . . . . . . . . . . . . . . . . . 28 97 6.2.1 TLV format . . . . . . . . . . . . . . . . . . . . . . . . 29 98 6.2.2 Defining new parameters . . . . . . . . . . . . . . . . . 30 99 6.2.3 SPI_LSI . . . . . . . . . . . . . . . . . . . . . . . . . 31 100 6.2.4 BIRTHDAY_COOKIE . . . . . . . . . . . . . . . . . . . . . 33 101 6.2.5 DIFFIE_HELLMAN . . . . . . . . . . . . . . . . . . . . . . 33 102 6.2.6 HIP_TRANSFORM . . . . . . . . . . . . . . . . . . . . . . 34 103 6.2.7 ESP_TRANSFORM . . . . . . . . . . . . . . . . . . . . . . 35 104 6.2.8 HOST_ID . . . . . . . . . . . . . . . . . . . . . . . . . 36 105 6.2.9 CERT . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 106 6.2.10 HMAC . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 107 6.2.11 HIP_SIGNATURE . . . . . . . . . . . . . . . . . . . . . . 39 108 6.2.12 HIP_SIGNATURE_2 . . . . . . . . . . . . . . . . . . . . . 39 109 6.2.13 NES . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 110 6.2.14 ENCRYPTED . . . . . . . . . . . . . . . . . . . . . . . . 41 111 7. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 43 112 7.1 I1 - the HIP initiator packet . . . . . . . . . . . . . . 43 113 7.2 R1 - the HIP responder packet . . . . . . . . . . . . . . 44 114 7.3 I2 - the second HIP initiator packet . . . . . . . . . . . 45 115 7.4 R2 - the second HIP responder packet . . . . . . . . . . . 46 116 7.5 UPDATE - the HIP New SPI Packet . . . . . . . . . . . . . 46 117 7.6 BOS - the HIP Bootstrap Packet . . . . . . . . . . . . . . 47 118 7.7 CER - the HIP Certificate Packet . . . . . . . . . . . . . 48 119 7.8 PAYLOAD - the HIP Payload Packet . . . . . . . . . . . . . 48 120 8. Packet processing . . . . . . . . . . . . . . . . . . . . 50 121 8.1 Processing outgoing application data . . . . . . . . . . . 50 122 8.2 Processing incoming application data . . . . . . . . . . . 51 123 8.3 HMAC and SIGNATURE calculation and verification . . . . . 52 124 8.3.1 HMAC calculation . . . . . . . . . . . . . . . . . . . . . 52 125 8.3.2 Signature calculation . . . . . . . . . . . . . . . . . . 53 126 8.4 Initiation of a HIP exchange . . . . . . . . . . . . . . . 53 127 8.4.1 Sending multiple I1s in parallel . . . . . . . . . . . . . 54 128 8.4.2 Processing incoming ICMP Protocol Unreachable messages . . 55 129 8.5 Processing incoming I1 packets . . . . . . . . . . . . . . 55 130 8.5.1 R1 Management . . . . . . . . . . . . . . . . . . . . . . 56 131 8.6 Processing incoming R1 packets . . . . . . . . . . . . . . 56 132 8.7 Processing incoming I2 packets . . . . . . . . . . . . . . 58 133 8.8 Processing incoming R2 packets . . . . . . . . . . . . . . 60 134 8.9 Initiating rekeying . . . . . . . . . . . . . . . . . . . 61 135 8.10 Processing UPDATE packets . . . . . . . . . . . . . . . . 62 136 8.10.1 Processing an initial UPDATE packet . . . . . . . . . . . 63 137 8.10.2 Processing a reply UPDATE packet . . . . . . . . . . . . . 64 138 8.11 Processing BOS packets . . . . . . . . . . . . . . . . . . 65 139 8.12 Processing CER packets . . . . . . . . . . . . . . . . . . 65 140 8.13 Processing PAYLOAD packets . . . . . . . . . . . . . . . . 65 141 9. HIP KEYMAT . . . . . . . . . . . . . . . . . . . . . . . . 66 142 10. HIP Fragmentation Support . . . . . . . . . . . . . . . . 68 143 11. ESP with HIP . . . . . . . . . . . . . . . . . . . . . . . 69 144 11.1 ESP Security Associations . . . . . . . . . . . . . . . . 69 145 11.2 Updating ESP SAs during rekeying . . . . . . . . . . . . . 69 146 11.3 Security Association Management . . . . . . . . . . . . . 70 147 11.4 Security Parameter Index (SPI) . . . . . . . . . . . . . . 70 148 11.5 Supported Transforms . . . . . . . . . . . . . . . . . . . 70 149 11.6 Sequence Number . . . . . . . . . . . . . . . . . . . . . 70 150 12. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . 72 151 13. Security Considerations . . . . . . . . . . . . . . . . . 73 152 14. IANA Considerations . . . . . . . . . . . . . . . . . . . 75 153 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 76 154 Normative references . . . . . . . . . . . . . . . . . . . 77 155 Informative references . . . . . . . . . . . . . . . . . . 79 156 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 79 157 A. Backwards compatibility API issues . . . . . . . . . . . . 81 158 B. Probabilities of HIT collisions . . . . . . . . . . . . . 84 159 C. Probabilities in the cookie calculation . . . . . . . . . 85 160 D. Using responder cookies . . . . . . . . . . . . . . . . . 86 161 E. Running HIP over IPv4 UDP . . . . . . . . . . . . . . . . 89 162 F. Example checksums for HIP packets . . . . . . . . . . . . 90 163 F.1 IPv6 HIP example (I1) . . . . . . . . . . . . . . . . . . 90 164 F.2 IPv4 HIP packet (I1) . . . . . . . . . . . . . . . . . . . 90 165 F.3 TCP segment . . . . . . . . . . . . . . . . . . . . . . . 90 166 Intellectual Property and Copyright Statements . . . . . . 92 168 1. Introduction 170 The Host Identity Protocol (HIP) provides a rapid exchange of Host 171 Identities between two hosts. The exchange also establishes a pair 172 IPsec Security Associations (SA), to be used with IPsec Encapsulated 173 Security Payload (ESP) [15]. The HIP protocol is designed to be 174 resistant to Denial-of-Service (DoS) and Man-in-the-middle (MitM) 175 attacks, and when used to enable ESP, provides DoS and MitM 176 protection for upper layer protocols, such as TCP and UDP. 178 1.1 A new name space and identifiers 180 The Host Identity Protocol introduces a new namespace, the Host 181 Identity. The effects of this change are explained in the companion 182 document, the HIP architecture [17] specification. 184 There are three representations of the Host Identity, the full Host 185 Identifier (HI), the Host Identity Tag (HIT), and the Local Scope 186 Identifier (LSI). Three representations are used, as each meets a 187 different design goal of HIP, and none of them can be removed and 188 meet these goals. The HI represents directly the Identity. It is a 189 public key. Since there are different public key algorithms that can 190 be used with different key lengths, the HI is not good for using as a 191 packet identifier, or as a index into the various operational tables 192 needed to support HIP. 194 A hash of the HI, the Host Identity Tag (HIT), thus becomes the 195 operational representation. It is 128 bits long. It is used in the 196 HIP payloads, and it is intended be used to index the corresponding 197 state in the end hosts. 199 In many environments, 128 bits is still considered large. For 200 example, currently used IPv4 based applications are constrained with 201 32 bit API fields. Thus, the third representation, the 32 bit LSI, 202 is needed. The LSI provides a compression of the HIT with only a 203 local scope so that it can be carried efficiently in any application 204 level packet and used in API calls. 206 1.2 The HIP protocol 208 The base HIP exchange consists of four packets. The four-packet 209 design helps to make HIP DoS resilient. The protocol exchanges 210 Diffie-Hellman keys in the 2nd and 3rd packets, and authenticates the 211 parties in the 3rd and 4th packets. Additionally, it starts the 212 cookie exchange in the 2nd packet, completing it in the 3rd packet. 214 The exchange uses the Diffie-Hellman exchange to hide the Host 215 Identity of the Initiator in packet 3. The Responder's Host Identity 216 is not protected. It should be noted, however, that both the 217 Initiator's and the Responder's HITs are transported as such (in 218 cleartext) in the packets, allowing an eavesdropper with a priori 219 knowledge about the parties to verify their identities. 221 Data packets start after the 4th packet. The 3rd and 4th HIP packets 222 may carry a data payload in the future. However, the details of this 223 are to be defined later as more implementation experience is gained. 225 Finally, HIP is designed as an end-to-end authentication and key 226 establishment protocol. It lacks much of the fine-grain policy 227 control found in IKE that allows IKE to support complex gateway 228 policies. Thus, HIP is not a complete replacement for IKE. 230 2. Conventions used in this document 232 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 233 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 234 document are to be interpreted as described in RFC2119 [3]. 236 3. Host Identifier (HI) and its representations 238 The structure of the Host Identifier (HI) is the public key of an 239 asymmetric key pair. Correspondingly, the host itself is entity that 240 holds the private key from the key pair. See the HIP architecture 241 specification [17] for more details about the difference between an 242 identity and the corresponding identifier. 244 DSA is the MUST implement public key algorithm for all HIP 245 implementations, other algorithms MAY be supported. DSA was chosen 246 as the default algorithm due to its small signature size. 248 A Host Identity Tag (HIT) is used in protocols to represent the Host 249 Identity. Another representation of the Host Identity, the Local 250 Scope Identifier (LSI), can also be used in protocols and APIs. 251 LSI's advantage over HIT is its size; its disadvantage is its local 252 scope. 254 3.1 Host Identity Tag (HIT) 256 The Host Identity Tag is a 128 bit value -- a hash of the Host 257 Identifier. There are two advantages of using a hash over the actual 258 Identity in protocols. Firstly, its fixed length makes for easier 259 protocol coding and also better manages the packet size cost of this 260 technology. Secondly, it presents a consistent format to the 261 protocol whatever underlying identity technology is used. 263 There are two types of HITs. HITs of the first type, called *type 1 264 HIT*, consist of an initial 2 bit prefix of 01, followed by 126 bits 265 of the SHA-1 hash of the public key. HITs of the second type consist 266 of an initial 2 bit prefix of 10, a Host Assigning Authority (HAA) 267 field, and only the last 64 bits come from a SHA-1 hash of the Host 268 Identity. This latter format for HIT is recommended for 'well known' 269 systems. It is possible to support a resolution mechanism for these 270 names in hierarchical directories, like the DNS. Another use of HAA 271 is in policy controls, see Section 12. 273 This document fully specifies only type 1 HITs. HITs that consists 274 of the HAA field and the hash are specified in [20]. 276 Any conforming implementation MUST be able to deal with both types of 277 HITs. When handling other than type 1 HITs, the implementation is 278 RECOMMENDED to explicitly learn and record the binding between the 279 Host Identifier and the HIT, as it may not be able generate such HITs 280 from Host Identifiers. 282 3.1.1 Generating a HIT from a HI 284 The 126 or 64 hash bits in a HIT MUST be generated by taking the 285 least significant 126 or 64 bits of the SHA-1 [18] hash of the Host 286 Identifier as it is represented in the Host Identity field in a HIP 287 payload packet. 289 For Identities that are DSA public keys, the HIT is formed as 290 follows: 292 1. The DSA public key is encoded as defined in RFC2536 [10] Section 293 2, taking the fields T, Q, P, G, and Y, concatenated. Thus, the 294 data to be hashed is 1 + 20 + 3 * 64 + 3 * 8 * T octets long, 295 where T is the size parameter as defined in RFC2536 [10]. The 296 size parameter T, affecting the field lengths, MUST be selected 297 as the minimum value that is long enough to accommodate P, G, and 298 Y. The fields MUST be encoded in network byte order, as defined 299 in RFC2536 [10]. 301 2. A SHA-1 hash [18] is calculated over the encoded key. 303 3. The least significant 126 or 64 bits of the hash result are used 304 to create the HIT, as defined above. 306 The following pseudo-code illustrates the process. The symbol := 307 denotes assignment; the symbol += denotes appending. The 308 pseudo-function encode_in_network_byte_order takes two parameters, an 309 integer (bignum) and a length in bytes, and returns the integer 310 encoded into a byte string of the given length. 312 buffer := encode_in_network_byte_order ( DSA.T , 1 ) 313 buffer += encode_in_network_byte_order ( DSA.Q , 20 ) 314 buffer += encode_in_network_byte_order ( DSA.P , 64 + 8 * T ) 315 buffer += encode_in_network_byte_order ( DSA.G , 64 + 8 * T ) 316 buffer += encode_in_network_byte_order ( DSA.Y , 64 + 8 * T ) 318 digest := SHA-1 ( buffer ) 320 hit_126 := concatenate ( 01 , low_order_bits ( digest, 126 ) ) 321 hit_haa := concatenate ( 10 , HAA, low_order_bits ( digest, 64 ) ) 323 3.2 Local Scope Identifier (LSI) 325 LSIs are 32-bit localized representations of a Host Identity. The 326 purpose of an LSI is to facilitate using Host Identities in existing 327 IPv4 based protocols and APIs. The owner of the Host Identity does 328 not set the LSI that other hosts use for it; each host selects the 329 LSIs that it uses for representing its partners. 331 A *local LSI* is an LSI that a remote host has assigned to a host. 332 In some implementations, local LSIs may be assigned to some interface 333 as an IP address. A *remote LSI* is an LSI that the host has 334 assigned to represent a remote host (and that the remote host has 335 accepted). 337 The LSIs MUST be allocated from the 1.0.0.0/8 subnet. That makes it 338 easier to differentiate between LSIs and IPv4 addresses at the API 339 level. By default, the low order 24 bits of an LSI SHOULD be equal 340 with the low order 24 bits of the corresponding HIT. That allows 341 easier mapping between LSIs and HITs, and makes the LSI assigned to a 342 host to be a fixed one. 344 If a host is forming a remote LSI for a HIT whose low order 24 bits 345 are equal with another already existing remote LSI, the host MAY 346 select another LSI to represent that host. If the low order 24 bits 347 of a remote HIT are equal to the low order 24 bits of a local LSI, 348 the host MAY select a different LSI to represent the remote host. In 349 either case, the host SHOULD assign the low order 24 bits of the LSI 350 randomly. All hosts SHOULD be prepared to handle local LSIs whose 351 low order 24 bits do not match with any of their own HITs. Note that 352 any such mechanisms may be subject to implementation complications, 353 see Appendix A. 355 If the LSI assigned by a peer to represent a host is unacceptable, 356 the host MAY terminate the HIP four-way handshake and start anew. 358 It is possible that the HITs of two remote hosts have equal low order 359 24 bits. Since HITs are basically random, if a host is communicating 360 with 1000 other hosts, the risk of such collision is roughly 0.006%, 361 and for a host communicating with 10000 other hosts, the risk is 362 about 0.06%. However, given a population of 100000 hosts, each 363 communicating with 1000 other hosts, the probability that there were 364 no collisions at all is only about 2%. In other words, even though 365 collisions are fairly rare events for any given host, they will 366 happen, and there must be a way to handle them. However, this 367 specification does not currently specify any such way. A future 368 version of this specification is expected to include a definition; 369 see also the discussion in Appendix A. 371 3.3 Security Parameter Index (SPI) 373 SPIs are used in ESP to find the right security association for 374 received packets. The ESP SPIs have added significance when used 375 with HIP; they are a compressed representation of the HITs in every 376 packet. Thus, SPIs MAY be used by intermediary systems in providing 377 services like address mapping. Note that since the SPI has 378 significance at the receiver, only the < DST, SPI >, where DST is a 379 destination IP address, uniquely identifies the receiver HIT at every 380 given point of time. The same SPI value may be used by several 381 hosts. A single < DST, SPI > value may denote different hosts at 382 different points of time, depending on which host is currently 383 reachable at the DST. 385 Each host selects for itself the SPI it wants to see in packets 386 received from its peer. This allows it to select different SPIs for 387 different peers. The SPI selection SHOULD be random; the rules of 388 Section 2.1 of the ESP specification [15] must be followed. A 389 different SPI SHOULD be used for each HIP exchange with a particular 390 host; this is to avoid a replay attack. Additionally, when a host 391 rekeys, the SPI MUST be changed. Furthermore, if a host changes over 392 to use a different IP address, it MAY change the SPI. 394 One method for SPI creation that meets these criteria would be to 395 concatenate the HIT with a 32 bit random or sequential number, hash 396 this (using SHA1), and then use the high order 32 bits as the SPI. 398 The selected SPI is communicated to the peer in the third (I2) and 399 fourth (R2) packets of the base HIP exchange. Changes in SPI are 400 signaled with NES packets. 402 3.4 Difference between an LSI and the SPI 404 There is a subtle difference between an LSI and a SPI. 406 The LSI is designed to be relatively long-lived. A system selects 407 the LSI it locally uses to represent its peer, and it SHOULD reuse a 408 previous LSI for a HIT during a subsequent HIP exchange. This could 409 be important in a timeout recovery situation. The LSI only appears 410 in the 3rd and 4th HIP packets. The LSI is used anywhere in system 411 processes where IP addresses have traditionally have been used, like 412 in TCBs, IPv4 API calls, and FTP PORT commands. 414 The SPI is short-lived. It changes with each HIP exchange and with a 415 HIP rekey. A system notifies its peer of the SPI to use in ESP 416 packets sent to it. Since the SPI is in all but the first two HIP 417 packets, it can be used in intermediary systems to assist in address 418 remapping. 420 3.5 TCP and UDP pseudo-header computation 422 When computing TCP and UDP checksums on sockets bound to HITs or 423 LSIs, the IPv6 pseudo-header format [8] is used. Additionally, the 424 HITs MUST be used in the place of the IPv6 addresses in the IPv6 425 pseudo-header. Note that the pseudo-header for actual HIP payloads 426 is computed differently; see Section 6.1.2. 428 4. Host Identity Protocol 430 The Host Identity Protocol is IP protocol TBD. The HIP payload could 431 be carried in every datagram. However, since HIP datagrams are 432 relatively large (at least 40 bytes), and ESP already has all of the 433 functionality to maintain and protect state, the HIP payload is 434 'compressed' into an ESP payload after the HIP exchange. Thus in 435 practice, HIP packets only occur in datagrams to establish or change 436 HIP state. 438 For testing purposes, the protocol number 99 is currently used. 440 4.1 HIP base exchange 442 The base HIP exchange serves to manage the establishment of state 443 between an Initiator and a Responder. The Initiator first sends a 444 trigger packet, I1, to the Responder. The second packet, R1, starts 445 the actual exchange. It contains a puzzle, that is, a cryptographic 446 challenge that the Initiator must solve before continuing the 447 exchange. In its reply, I2, the Initiator must display the solution. 448 Without a solution the I2 message is simply discarded. 450 The last three packets of the exchange, R1, I2, and R2, constitute a 451 standard authenticated Diffie-Hellman key exchange. The base 452 exchange is illustrated below. 454 Initiator Responder 456 I1: trigger exchange 457 --------------------------> 458 select pre-computed R1 459 R1: puzzle, D-H, key, sig 460 <------------------------- 461 check sig remain stateless 462 solve puzzle 463 I2: solution, D-H, {key}, sig 464 --------------------------> 465 compute D-H check cookie 466 check puzzle 467 check sig 468 R2: sig 469 <-------------------------- 470 check sig compute D-H 472 In this section we cover the overall design of the base exchange. 473 The details are the subject of the rest of this memo. 475 4.1.1 HIP Cookie Mechanism 477 The purpose of the HIP cookie mechanism is to protect the Responder 478 from a number of denial-of-service threats. It allows the Responder 479 to delay state creation until receiving I2. Furthermore, the puzzle 480 included in the cookie allows the Responder to use a fairly cheap 481 calculation to check that the Initiator is "sincere" in the sense 482 that it has churned CPU cycles in solving the puzzle. 484 The Cookie mechanism has been explicitly designed to give space for 485 various implementation options. It allows a responder implementation 486 to completely delay session specific state creation until a valid I2 487 is received. In such a case a validly formatted I2 can be rejected 488 earliest only once the Responder has checked its validity by 489 computing one hash function. On the other hand, the design also 490 allows a responder implementation to keep state about received I1s, 491 and match the received I2s against the state, thereby allowing the 492 implementation to avoid the computational cost of the hash function. 493 The drawback of this latter approach is the requirement of creating 494 state. Finally, it also allows an implementation to use any 495 combination of the space-saving and computation-saving mechanisms. 497 One possible way for a Responder to remain stateless but drop most 498 spoofed I2s is to base the selection of the cookie on some function 499 over the Initiator's Host Identity. The idea is that the Responder 500 has a (perhaps varying) number of pre-calculated R1 packets, and it 501 selects one of these based on the information carried in I1. When 502 the Responder then later receives I2, it checks that the cookie in 503 the I2 matches with the cookie sent in the R1, thereby making it 504 impractical for the attacker to first exchange one I1/R1, and then 505 generate a large number of spoofed I2s that seemingly come from 506 different IP addresses or use different HITs. The method does not 507 protect from an attacker that uses fixed IP addresses and HITs, 508 though. Against such an attacker it is probably best to create a 509 piece of local state, and remember that the puzzle check has 510 previously failed. See Appendix D for one possible implementation. 511 Note, however, that the implementations MUST NOT use the exact 512 implementation given in the appendix, and SHOULD include sufficient 513 randomness to the algorithm so that algorithm complexity attacks 514 become impossible [22]. 516 The Responder can set the difficulty for Initiator, based on its 517 concern of trust of the Initiator. The Responder SHOULD use 518 heuristics to determine when it is under a denial-of-service attack, 519 and set the difficulty value K appropriately. 521 The Responder starts the cookie exchange when it receives an I1. The 522 Responder supplies a random number I, and requires the Initiator to 523 find a number J. To select a proper J, the Initiator must create the 524 concatenation of I, the HITs of the parties, and J, and take a SHA-1 525 hash over this concatenation. The lowest order K bits of the result 526 MUST be zeros. 528 To generate a proper number J, the Initiator will have to generate a 529 number of Js until one produces the hash target of zero. The 530 Initiator SHOULD give up after trying 2^(K+2) times, and start over 531 the exchange. (See Appendix C.) The Responder needs to re-create 532 the concatenation of I, the HITs, and the provided J, and compute the 533 hash once to prove that the Initiator did its assigned task. 535 To prevent pre-computation attacks, the Responder MUST select the 536 number I in such a way that the Initiator cannot guess it. 537 Furthermore, the construction MUST allow the Responder to verify that 538 the value was indeed selected by it and not by the Initiator. See 539 Appendix D for an example on how to implement this. 541 It is RECOMMENDED that the Responder generates a new cookie and a new 542 R1 once every few minutes. Furthermore, it is RECOMMENDED that the 543 Responder remembers an old cookie at least 60 seconds after it has 544 been deprecated. These time values allow a slower Initiator to solve 545 the cookie puzzle while limiting the usability that an old, solved 546 cookie has to an attacker. 548 NOTE: The protocol developers explicitly considered whether R1 should 549 include a timestamp in order to protect the Initiator from replay 550 attacks. The decision was NOT to include a timestamp. 552 In R1, the values I and K are sent in network byte order. Similarly, 553 in I2 the values I and J are sent in network byte order. The SHA-1 554 hash is created by concatenating, in network byte order, the 555 following data, in the following order: 557 64-bit random value I, in network byte order, as appearing in R1 558 and I2. 560 128-bit initiator HIT, in network byte order, as appearing in the 561 HIP Payload in R1 and I2. 563 128-bit responder HIT, in network byte order, as appearing in the 564 HIP Payload in R1 and I2. 566 64-bit random value J, in network byte order, as appearing in I2. 568 In order to be a valid response cookie, the K low-order bits of the 569 resulting SHA-1 digest must be zero. 571 Notes: 573 The length of the data to be hashed is 48 bytes. 575 All the data in the hash input MUST be in network byte order. 577 The order of the initiator and responder HITs are different in the 578 R1 and I2 packets, see Section 6.1. Care must be taken to copy 579 the values in right order to the hash input. 581 Precomputation by the Responder Sets up the challenge difficulty K. 583 Generates a random number I. 584 Creates a signed R1 and caches it. 586 Responder Selects a suitable cached R1. 588 Sends I and K in a HIP Cookie in the R1. 589 Saves I and K for a Delta time. 591 Initiator Generates repeated attempts to solve the challenge until a 592 matching J is found: 594 Ltrunc( SHA-1( I | HIT-I | HIT-R | J ), K ) == 0 595 Sends I and J in HIP Cookie in a I2. 597 Responder Verifies that the received I is a saved one. 599 Finds the right K based on I. 600 Computes V := Ltrunc( SHA-1( I | HIT-I | HIT-R | J ), K ) 601 Rejects if V != 0 602 Accept if V == 0 604 The Ltrunc (SHA-1(), K) denotes the lowest order K bits of the SHA-1 605 result. 607 4.1.2 Authenticated Diffie-Hellman protocol 609 The packets R1, I2, and R2 implement a standard authenticated 610 Diffie-Hellman exchange. The Responder sends its public 611 Diffie-Hellman key and its public authentication key, i.e., its host 612 identity, in R1. The signature in R1 allows the Initiator to verify 613 that the R1 has been once generated by the Responder. However, since 614 it is precomputed and therefore does not cover all of the packet, it 615 does not protect from replay attacks. 617 When the Initiator receives an R1, it computes the Diffie-Hellman 618 session key. It creates a HIP security association using keying 619 material from the session key (see Section 9), and uses the security 620 association to encrypt its public authentication key, i.e., host 621 identity. The resulting I2 contains the Initiator's Diffie-Hellman 622 key and its the encrypted public authentication key. The signature 623 in I2 covers all of the packet. 625 The Responder extracts the Initiator Diffie-Hellman public key from 626 the I2, computes the Diffie-Hellman session key, creates a 627 corresponding HIP security association, and decrypts the Initiator's 628 public authentication key. It can then verify the signature using 629 the authentication key. 631 The final message, R2, is needed to protect the Initiator from replay 632 attacks. 634 4.1.3 HIP Birthday 636 The HIP Birthday is a reboot count used to manage state 637 re-establishment when one peer rebooted or timed out its SA. The 638 Birthday is increased every time the system boots. The Birthday also 639 has to be increased in accordance with the system's SA timeout 640 parameter. If the system has open SAs, it MUST increase its 641 Birthday. This impacts a system's approach to precomputing R1 642 packets. 644 Birthday SHOULD be a counter. It MUST NOT be reset by the user and a 645 system is unlikely to need a birthday larger than 2^64. Date-time in 646 GMT MAY be used if a cross-boot counter is not possible, but it has a 647 potential problem if the system time is set back by the user. 649 4.2 Sending data on HIP packets 651 A future version of this document may define how to include ESP 652 protected data on various HIP packets. However, currently the HIP 653 header is a terminal header, and not followed by any other headers. 655 The OPTIONAL PAYLOAD packet (see Section 7.8) MAY be used to transfer 656 data. 658 4.3 Rekey 660 HIP includes a simple rekey mechanism, allowing the hosts to 661 introduce new keying material at any time by introducing a new 662 Diffie-Hellman public key; see Section 7.5. All conforming HIP 663 implementations MUST support rekeying. 665 4.4 Bootstrap support 667 This memo defines an OPTIONAL HIP based bootstrap mechanism, intended 668 for ad hoc like environments; see Section 7.6. There is little 669 operational experience of the usability of this mechanism, and it may 670 be dropped or completely revised in some future protocol version. 672 4.5 Certificate distribution 674 HIP does not define how to use certificates. However, it does define 675 a simple certificate transport mechanisms that MAY be used to 676 implement certificate based security policies. The certificate 677 payload is defined in Section 6.2.9, and the certificate packet in 678 Section 7.7. 680 5. HIP packet flow and state machine 682 A typical HIP packet flow is shown below. 684 I --> Directory: lookup of R 685 I <-- Directory: return R's addresses, and HI and/or HIT 686 I1 I --> R (Hi. Here is my I1, let's talk HIP) 687 R1 I <-- R (OK. Here is my R1, handle this HIP cookie) 688 I2 I --> R (Compute, compute, here is my counter I2) 689 R2 I <-- R (OK. Let's finish HIP with my R2) 690 I --> R (ESP protected data) 691 I <-- R (ESP protected data) 693 5.1 HIP Scenarios 695 The HIP protocol and state machine is designed to recover from one of 696 the parties crashing and losing its state. The following scenarios 697 describe the main use cases covered by the design. 699 No prior state between the two systems. 701 The system with data to send is the Initiator. The process 702 follows standard 4 packet base exchange, establishing the SAs. 704 The system with data to send has no state with the receiver, but 705 the receiver has a residual SA. 707 Initiator acts as in no prior state, sending I1 and getting R1. 708 When the Receiver gets an I2, the old SAs are 'discovered' and 709 deleted; the new SAs are established. 711 The system with data to send has an SA, but the receiver does not. 713 The receiver 'detects' the situation when it receives an ESP 714 packet that contains an unknown SPI. The receiver sends an R1 715 with a NULL initiator HIT. The sender gets the R1 with a later 716 birthday, discards old SA, and continues the base exchange to 717 establish new SAs for sending data. 719 A peer determines that it needs to reset Sequence number or rekey. 721 It sends UPDATE. Receiver sends UPDATE response, establishes 722 new SAs for peers. 724 5.2 Refusing a HIP exchange 726 A HIP aware host may choose not to accept a HIP exchange. If the 727 host's policy is to only be an initiator, it should begin its own HIP 728 exchange. A host MAY choose to have such a policy since only the 729 initiator HI is protected in the exchange. There is a risk of a race 730 condition if each host's policy is to only be an Initiator, at which 731 point the HIP exchange will fail. 733 If the host's policy does not permit it to enter into a HIP exchange 734 with the Initiator, it should send an ICMP 'Destination Unreachable, 735 Administratively Prohibited' message. A more complex HIP packet is 736 not used here as it actually opens up more potential DoS attacks than 737 a simple ICMP message. 739 5.3 Reboot and SA timeout restart of HIP 741 Simulating a loss of state is a potential DoS attack. The following 742 process has been crafted to manage state recovery without presenting 743 a DoS opportunity. 745 If a host reboots or times out, it has lost its HIP state. If the 746 system that lost state has a datagram to deliver to its peer, it 747 simply restarts the HIP exchange. The peer sends an R1 HIP packet, 748 but does not reset its state until it receives the I2 HIP packet. 749 The I2 packet MUST have a Birthday greater than the current SA's 750 Birthday. This is to handle DoS attacks that simulate a reboot of a 751 peer. Note that either the original Initiator or the Responder could 752 end up restarting the exchange, becoming the new Initiator. 754 If a system receives an ESP packet for an unknown SPI, it is possible 755 that it has lost the state and its peer has not. In this case, the 756 system MAY initiate a new HIP exchange for re-establishing the SA. 757 The RESYNC bit in the I1 packet is set to indicate the peer about the 758 possible state loss. 760 The initiating host cannot know, if the SA indicated by the received 761 ESP packet is either a HIP SA or and IKE SA. If the old SA was not a 762 HIP SA, the peer may not respond to the I1 packet. 764 After sending the I1, the HIP negotiation proceeds as normally and, 765 when successful, the SA is created at the initiating end. The peer 766 end removes the OLD SA and replaces it with the new one. 768 5.4 HIP State Machine 770 The HIP protocol itself has very little state. In the HIP base 771 exchange, there is an Initiator and a Responder. Once the SAs are 772 established, this distinction is lost. If the HIP state needs to be 773 re-established, the controlling parameters are which peer still has 774 state and which has a datagram to send to its peer. The following 775 state machine attempts to capture these processes. 777 The state machine is presented in a single system view, representing 778 either an Initiator or a Responder. There is not a complete overlap 779 of processing logic here and in the packet definitions. Both are 780 needed to completely implement HIP. 782 Implementors must understand that the state machine, as described 783 here, is informational. Specific implementations are free to 784 implement the actual functions differently. 786 5.4.1 HIP States 788 UNASSOCIATED State machine start 790 I1-SENT Initiating HIP 792 I2-SENT Waiting to finish HIP 794 ESTABLISHED HIP SA established 796 REKEYING HIP SA established, rekeying 798 RESYNC Peer lost state, resyncing 800 E-FAILED HIP SA establishment failed 802 5.4.2 HIP State Processes 804 +------------+ 805 |UNASSOCIATED| Start state 806 +------------+ 808 Datagram to send, send I1 and go to I1-SENT 809 Receive I1, send R1 and stay at UNASSOCIATED 810 Receive I2, process 811 if successful, send R2 and go to ESTABLISHED 812 if fail, stay at UNASSOCIATED 814 Receive ESP for unknown SA, send I1 and go to I1-SENT 815 Receive ANYOTHER, drop and stay at UNASSOCIATED 817 +---------+ 818 | I1-SENT | Initiating HIP 819 +---------+ 821 Receive I1, send R1 and stay at I1-SENT 822 Receive I2, process 823 if successful, send R2 and go to ESTABLISHED 824 if fail, stay at I1-SENT 825 Receive R1, process 826 if successful, send I2 and go to I2-SENT 827 if fail, go to E-FAILED 829 Receive ANYOTHER, drop and stay at I1-SENT 830 Timeout, increment timeout counter 831 If counter is less than I1_RETRIES_MAX, send I1 and stay at I1-SENT 832 If counter is greater than I1_RETRIES_MAX, go to E-FAILED 834 +---------+ 835 | I2-SENT | Waiting to finish HIP 836 +---------+ 838 Receive I1, send R1 and stay at I2-SENT 839 Receive I2, process 840 if successful, send R2 and go to ESTABLISHED 841 if fail, stay at I2-SENT 842 Receive R2, process 843 if successful, go to ESTABLISHED 844 if fail, go to E-FAILED 846 Receive ANYOTHER, drop and stay at I2-SENT 847 Timeout, increment timeout counter 848 If counter is less than I2_RETRIES_MAX, send I2 and stay at I2-SENT 849 If counter is greater than I2_RETRIES_MAX, go to E-FAILED 851 +------------+ 852 |ESTABLISHED | HIP SA established 853 +------------+ 855 Receive I1, send R1 and go to RESYNC 856 Receive I2, process with Birthday check 857 if successful, send R2, drop old SAs, establish new SA, reenter 858 ESTABLISHED 859 if fail, stay at ESTABLISHED 860 Receive R1, drop and stay at ESTABLISHED 861 Receive R2, drop and stay at ESTABLISHED 863 Receive ESP for SA, process and stay at ESTABLISHED 864 Receive UPDATE, process 865 if successful, send UPDATE and stay at ESTABLISHED 866 if failed, stay at ESTABLISHED 868 Need rekey, 869 send UPDATE and go to REKEYING 871 +----------+ 872 | REKEYING | HIP SA established, rekey pending 873 +----------+ 875 Receive I1, send R1 and stay at REKEYING 876 Receive I2, process with Birthday check 877 if successful, send R2, drop old SA and go to ESTABLISHED 878 if fail, stay at REKEYING 879 Receive R1, drop and stay at REKEYING 880 Receive R2, drop and stay at REKEYING 882 Receive ESP for SA, process and stay at REKEYING 883 Receive UPDATE, process 884 if successful, replace SAs and go to ESTABLISHED 885 if failed, stay at REKEYING 886 Timeout, increment timeout counter 887 If counter is less than UPDATE_RETRIES_MAX, send UPDATE and stay at REKEYING 888 If counter is greater than UPDATE_RETRIES_MAX, go to E-FAILED 890 +--------+ 891 | RESYNC | HIP SA established, resync pending 892 +--------+ 894 Receive I1, send R1 and cycle at RESYNC 895 Receive I2, process with Birthday check 896 if successful, send R2, drop old SA and go to ESTABLISHED 897 if fail, stay at RESYNC 898 Receive R1, drop and stay at RESYNC 899 Receive R2, drop and stay at RESYNC 901 Receive ESP for SA, process and go to ESTABLISHED 902 Receive UPDATE, process 903 if successful, send UPDATE and go to ESTABLISHED 904 if failed, stay at RESYNC 905 Timeout, increment timeout counter 906 if counter is less than UPDATE_RETRIES_MAX, send I2 and stay at RESYNC 907 if counter is greater than UPDATE_RETRIES_MAX, go to ESTABLISHED 909 +----------+ 910 | E-FAILED | HIP failed to establish association with peer 911 +----------+ 913 Move to UNASSOCIATED after an implementation specific time. Re-negotiation 914 is possible after moving to UNASSOCIATED state. 916 5.4.3 Simplified HIP State Diagram 918 Receive packets cause a move to a new state. 920 +------------+ 921 |UNASSOCIATED|>---+ 922 +------------+ | 923 | ^ | | 924 | | | Dgm to | 925 +-+ | send, | 926 I1 | ESP- | (note: ESP- means ESP with unknown SPI) 927 | | 928 v | 929 +---------+ | 930 | I1-SENT |>---|----------+ 931 +---------+ | | 932 | | | 933 | R1 | | 934 | |I2 |I2 935 v | | 936 +---------+ | | 937 | I2-SENT |>---|----------|-----+ 938 | | | | | 939 +---------+ | | | 940 | | | | 941 | R2 | | |I2 942 | | | | 943 v | | | 944 +-----------+<-+ | | 945 | | | | 946 |ESTABLISHED|<------------+ | 947 | |<------------------+ 948 | |<------------------+ 949 | |>-------------+ | 950 | |<-------+ | | 951 | |---+ | | | 952 +-----------+ | | | | 953 | ^ ^ | | | | 954 | | | | | | | 955 +--+ | | | | | 956 ESP, | rekey| |I2 | | 957 UPDATE,| | | | | 958 I2 |UPDATE | | | | 959 | | | | | 960 | | | | | 961 | | | | | 962 +---------+ | | | | 963 | |<-----+ | | | 964 |REKEYING |>---------+ | | 965 +---------+ | | 966 | ^ | | I2, ESP 967 | | I1 | | UPDATE, Timeout 968 +--+ | | 969 ESP, | | 970 I1 | | 971 v ^ 972 +--------+ 973 | RESYNC | 974 +--------+ 975 | ^ 976 | | 977 +--+ 978 I1 980 6. Packet formats 982 6.1 Payload format 984 All HIP packets start with a fixed header. 986 0 1 2 3 987 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 988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 989 | Next Header | Payload Len | Type | VER. | RES. | 990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 991 | Controls | Checksum | 992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 993 | Sender's Host Identity Tag (HIT) | 994 | | 995 | | 996 | | 997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 998 | Receiver's Host Identity Tag (HIT) | 999 | | 1000 | | 1001 | | 1002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1003 | | 1004 / HIP Parameters / 1005 / / 1006 | | 1007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1009 The HIP header is logically an IPv6 extension header. However, this 1010 document does not describe processing for Next Header values other 1011 than decimal 59, IPPROTO_NONE, the IPV6 no next header value. Future 1012 documents MAY do so. However, implementations MUST ignore trailing 1013 data if a Next Header value is received that is not implemented. 1015 The Header Length field contains the length of the HIP Header and the 1016 length of HIP parameters in 8 bytes units, excluding the first 8 1017 bytes. Since all HIP headers MUST contain the sender's and 1018 receiver's HIT fields, the minimum value for this field is 4, and 1019 conversely, the maximum length of the HIP Parameters field is 1020 (255*8)-32 = 2008 bytes. 1022 The Packet Type indicates the HIP packet type. The individual packet 1023 types are defined in the relevant sections. If a HIP host receives a 1024 HIP packet that contains an unknown packet type, it MUST drop the 1025 packet. 1027 The HIP Version is four bits. The current version is 1. The version 1028 number is expected to be incremented only if there are incompatible 1029 changes to the protocol. Most extensions can be handled by defining 1030 new packet types, new parameter types, or new controls. 1032 The following four bits are reserved for future use. They MUST be 1033 zero when sent, and they SHOULD be ignored when handling a received 1034 packet. 1036 The HIT fields are always 128 bits (16 bytes) long. 1038 6.1.1 HIP Controls 1040 The HIP control section transfers information about the structure of 1041 the packet and capabilities of the host. 1043 The following fields have been defined: 1045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1046 | | | | | | | | | | | | | |C|R|A| 1047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1049 C - Certificate One or more certificate packets (CER) follows this 1050 HIP packet (see Section 7.7). 1052 R - Resync Indicating that the sender has lost state and is trying to 1053 resynchronize. See Section 5.3. 1055 A - Anonymous If this is set, the sender's HI in this packet is 1056 anonymous, i.e., one not listed in a directory. Anonymous HIs 1057 SHOULD NOT be stored. This control is set in packets R1 and/or 1058 I2. The peer receiving an anonymous HI may choose to refuse it by 1059 silently dropping the exchange. 1061 The rest of the fields are reserved for future use and MUST be set to 1062 zero on sent packets and ignored on received packets. 1064 6.1.2 Checksum 1066 The checksum field is located at the same location within the header 1067 as the checksum field in UDP packets, enabling hardware assisted 1068 checksum generation and verification. Note that since the checksum 1069 covers the source and destination addresses in the IP header, it must 1070 be recomputed on HIP based NAT boxes. 1072 If IPv6 is used to carry the HIP packet, the pseudo-header [8] 1073 contains the source and destination IPv6 addresses, HIP packet length 1074 in the pseudo-header length field, a zero field, and the HIP protocol 1075 number (TBD) in the Next Header field. The length field is in bytes 1076 and can be calculated from the HIP header length field: (HIP Header 1077 Length + 1) * 8. 1079 In case of using IPv4, the IPv4 UDP pseudo header format [1] is used. 1080 In the pseudo header, the source and destination addresses are those 1081 used in the IP header, the zero field is obviously zero, the protocol 1082 is the HIP protocol number (TBD), and the length is calculated as in 1083 the IPv6 case. 1085 6.2 HIP parameters 1087 The HIP Parameters are used to carry the public key associated with 1088 the sender's HIT, together with other related security information. 1089 The HIP Parameters consists of ordered parameters, encoded in TLV 1090 format. 1092 The following parameter types are currently defined. 1094 TLV Type Length Data 1096 SPI_LSI 1 16 Remote's SPI, Remote's LSI. 1098 BIRTHDAY_COOKIE 3/5 32 System Boot Counter plus 1099 two 64-bit fields: 1100 - Random #I 1101 - K or random #J 1103 NES 9 Old SPI, New SPI and other 1104 info needed for UPDATE 1106 DIFFIE_HELLMAN 13 variable public key 1108 HIP_TRANSFORM 17 variable HIP Encryption and Integrity 1109 Transform 1111 ESP_TRANSFORM 19 variable ESP Encryption and 1112 Authentication Transform 1114 ENCRYPTED 21 variable Encrypted part of I2 or CER 1115 packets 1117 HOST_ID 35 variable Host Identity with Fully 1118 Qualified Domain Name 1120 CERT 64 variable HI certificate 1122 HMAC 65245 24 HMAC based message 1123 authentication code, with 1124 key material from HIP_TRANSFORM 1126 HIP_SIGNATURE2 65277 variable Signature of the R1 packet 1128 HIP_SIGNATURE 65279 variable Signature of the packet 1130 6.2.1 TLV format 1132 The TLV encoded parameters are described in the following 1133 subsections. The type-field value also describes the order of these 1134 fields in the packet. The parameters MUST be included into the 1135 packet so that the types form an increasing order. If the order does 1136 not follow this rule, the packet is considered to be malformed and it 1137 MUST be discarded. 1139 All the TLV parameters have a length which is a multiple of 8 bytes. 1141 When needed, padding MUST be added to the end of the parameter so 1142 that the total length becomes a multiple of 8 bytes. This rule 1143 ensures proper alignment of data. If padding is added, the Length 1144 field MUST NOT include the padding. Any added padding bytes MUST be 1145 set zero by the sender, but their content SHOULD NOT be checked on 1146 the receiving end. 1148 Consequently, the Length field indicates the length of the Contents 1149 field (in bytes). The total length of the TLV parameter (including 1150 Type, Length, Contents, and Padding) is related to the Length field 1151 according to the following formula: 1153 Total Length = 11 + Length - (Length + 3) % 8; 1155 0 1 2 3 1156 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 1157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1158 | Type |C| Length | 1159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1160 | | 1161 / Contents / 1162 / +-+-+-+-+-+-+-+-+ 1163 | | Padding | 1164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1166 Type Type code for the parameter 1167 C Critical. One if this parameter is critical, and 1168 MUST be recognized by the recipient, zero otherwise. 1169 The C bit is considered to be a part of the Type field. 1170 Consequently, critical parameters are always odd 1171 and non-critical ones have an even value. 1172 Length Length of the parameter, in bytes. 1173 Contents Parameter specific, defined by Type 1174 Padding Padding, 0-7 bytes, added if needed 1176 Critical parameters MUST be recognized by the recipient. If a 1177 recipient encounters a critical parameter that it does not recognize, 1178 it MUST NOT process the packet any further. 1180 Non-critical parameters MAY be safely ignored. If a recipient 1181 encounters a non-critical parameter that it does not recognize, it 1182 SHOULD proceed as if the parameter was not present in the received 1183 packet. 1185 6.2.2 Defining new parameters 1187 Future specifications may define new parameters as needed. When 1188 defining new parameters, care must be taken to ensure that the 1189 parameter type values are appropriate and leave suitable space for 1190 other future extensions. One must remember that the parameters MUST 1191 always be arranged in the increasing order by the type code, thereby 1192 limiting the order of parameters. 1194 The following rules must be followed when defining new parameters. 1196 1. The low order bit C of the Type code is used to distinguish 1197 between critical and non-critical parameters. 1199 2. A new parameter may be critical only if an old recipient ignoring 1200 it would cause security problems. In general, new parameters 1201 SHOULD be defined as non-critical, and expect a reply from the 1202 recipient. 1204 3. If a system implements a new critical parameter, it MUST provide 1205 the ability to configure the associated feature off, such that 1206 the critical parameter is not sent at all. The configuration 1207 option must be well documented. By default, sending of such a 1208 new critical parameter SHOULD be off. In other words, the 1209 management interface MUST allow vanilla standards only mode as a 1210 default configuration setting, and MAY allow new critical 1211 payloads to be configured on (and off). 1213 4. The following type codes are reserved for future base protocol 1214 extensions, and may be assigned only through an appropriate WG or 1215 RFC action. 1217 0 - 511 1219 65024 - 65535 1221 5. The following type codes are reserved for experimentation and 1222 private use. Types SHOULD be selected in a random fashion from 1223 this range, thereby reducing the probability of collisions. A 1224 method employing genuine randomness (such as flipping a coin) 1225 SHOULD be used. 1227 32768 - 49141 1229 6. All other parameter type codes MUST be registered by the IANA. 1230 See Section 14. 1232 6.2.3 SPI_LSI 1234 The SPI_LSI parameter contains the SPI that the receiving host must 1235 use when sending data to the sending host, and the LSI that the 1236 receiving host must use to represent itself when talking to the 1237 sending host. 1239 0 1 2 3 1240 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 1241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1242 | Type | Length | 1243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1244 | Reserved | 1245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1246 | SPI | 1247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1248 | LSI | 1249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1251 Type 1 1252 Length 12 1253 Reserved Zero when sent, ignored when received 1254 SPI Security Parameter Index 1255 LSI Local Scope Identifier 1257 6.2.4 BIRTHDAY_COOKIE 1259 0 1 2 3 1260 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 1261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1262 | Type | Length | 1263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1264 | Reserved | 1265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1266 | Birthday, 8 bytes | 1267 | | 1268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1269 | Random # I, 8 bytes | 1270 | | 1271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1272 | K or Random # J, 8 bytes | 1273 | | 1274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1276 Type 3 (in R1) or 5 (in I2) 1277 Length 28 1278 Reserved Zero when sent, ignored when received 1279 Birthday System boot counter 1280 Random # I random number 1281 K K is the number of verified bits (in R1 packet) 1282 Random # J random number (in I2 packet) 1284 Birthday, Random #I, K, and Random #J are represented as 64-bit 1285 integers, in network byte order. 1287 6.2.5 DIFFIE_HELLMAN 1289 0 1 2 3 1290 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 1291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1292 | Type | Length | 1293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1294 | Group ID | Public Value / 1295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1296 / | padding | 1297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1299 Type 13 1300 Length length in octets, excluding Type, Length, and padding 1301 Group ID defines values for p and g 1302 Public Value the sender's public Diffie-Hellman key 1304 The following Group IDs have been defined: 1306 Group Value 1307 Reserved 0 1308 384-bit group 1 1309 OAKLEY well known group 1 2 1310 1536-bit MODP group 3 1311 3072-bit MODP group 4 1312 6144-bit MODP group 5 1313 8192-bit MODP group 6 1315 The MODP Diffie-Hellman groups are defined in [14]. The OAKLEY group 1316 is defined in [6]. The OAKLEY well known group 5 is the same as the 1317 1536-bit MODP group. 1319 A HIP implementation MUST support Group IDs 1 and 3. The 384-bit 1320 group can be used when lower security is enough (e.g. web surfing) 1321 or when the equipment is not powerful enough (e.g. some PDAs). 1322 Equipment powerful enough SHOULD implement also group ID 5. 1324 To avoid unnecessary failures during the 4-way handshake, the rest of 1325 the groups SHOULD be implemented in hosts where resources are 1326 adequate. 1328 6.2.6 HIP_TRANSFORM 1330 0 1 2 3 1331 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 1332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1333 | Type | Length | 1334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1335 | Transform-ID #1 | Transform-ID #2 | 1336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1337 | Transform-ID #n | Padding | 1338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1340 Type 17 1341 Length length in octets, excluding Type, Length, and padding 1342 Transform-ID Defines the HIP Suite to be used 1344 The Suite-IDs are identical to those defined in Section 6.2.7. 1346 There MUST NOT be more than six (6) HIP Suite-IDs in one HIP 1347 transform TLV. The limited number of transforms sets the maximum size 1348 of HIP_TRANSFORM TLV. The HIP_TRANSFORM TLV MUST contain at least one 1349 of the mandatory Suite-IDs. 1351 Mandatory implementations: ENCR-3DES-CBC with HMAC-SHA1 and ENCR-NULL 1352 with HMAC-SHA1. 1354 6.2.7 ESP_TRANSFORM 1356 0 1 2 3 1357 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 1358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1359 | Type | Length | 1360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1361 | Reserved |E| Suite-ID #1 | 1362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1363 | Suite-ID #2 | Suite-ID #3 | 1364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1365 | Suite-ID #n | Padding | 1366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1368 Type 19 1369 Length length in octets, excluding Type, Length, and padding 1370 E One if the ESP transform requires 64-bit sequence 1371 numbers 1372 (see 1373 Section 11.6 1374 ) 1375 Reserved zero when sent, ignored when received 1376 Suite-ID defines the ESP Suite to be used 1378 The following Suite-IDs are defined ([16],[19]): 1380 Suite-ID Value 1382 RESERVED 0 1383 ESP-AES-CBC with HMAC-SHA1 1 1384 ESP-3DES-CBC with HMAC-SHA1 2 1385 ESP-3DES-CBC with HMAC-MD5 3 1386 ESP-BLOWFISH-CBC with HMAC-SHA1 4 1387 ESP-NULL with HMAC-SHA1 5 1388 ESP-NULL with HMAC-MD5 6 1390 There MUST NOT be more than six (6) ESP Suite-IDs in one 1391 ESP_TRANSFORM TLV. The limited number of Suite-IDs sets the maximum 1392 size of ESP_TRANSFORM TLV. The ESP_TRANSFORM MUST contain at least 1393 one of the mandatory Suite-IDs. 1395 Mandatory implementations: ESP-3DES-CBC with HMAC-SHA1 and ESP-NULL 1396 with HMAC-SHA1. 1398 6.2.8 HOST_ID 1400 0 1 2 3 1401 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 1402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1403 | Type | Length | 1404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1405 | HI Length | FQDN Length | 1406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1407 | Host Identity / 1408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1409 / | FQDN / 1410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1411 / | Padding | 1412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1414 Type 35 1415 Length length in octets, excluding Type, Length, and Padding 1416 HI Length length of the Host Identity in octets 1417 FQDN Length length of the FQDN in octets 1418 Host Identity actual host identity 1419 FQDN Fully Qualified Domain Name, in the binary format. 1421 The Host Identity is represented in RFC2535 [9] format. The 1422 algorithms used in RDATA format are the following: 1424 Algorithms Values 1426 RESERVED 0 1427 DSA 3 [RFC2536] (REQUIRED) 1428 RSA 5 [RFC3110] (OPTIONAL) 1430 The format for the FQDN is defined in RFC1035 [2] Section 3.1. If 1431 there is no FQDN, the FQDN Length field is set to zero. 1433 6.2.9 CERT 1435 0 1 2 3 1436 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 1437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1438 | Type | Length | 1439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1440 | Cert count | Cert ID | Cert type | / 1441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1442 / Certificate / 1443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1444 / | Padding | 1445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1447 Type 64 1448 Length length in octets, excluding Type, Length, and padding 1449 Cert count total count of certificates that are sent, possibly 1450 in several consecutive CER packets 1451 Cert ID the order number for this certificate 1452 Cert Type describes the type of the certificate 1454 The receiver must know the total number (Cert count) of certificates 1455 that it will receive from the sender, related to the R1 or I2. The 1456 Cert ID identifies the particular certificate and its order in the 1457 certificate chain. The numbering in Cert ID MUST go from 1 to Cert 1458 count. 1460 The following certificate types are defined: 1462 Cert format Type number 1463 X.509 v3 1 1465 The encoding format for X.509v3 certificate is defined in [11]. 1467 6.2.10 HMAC 1469 0 1 2 3 1470 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 1471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1472 | Type | Length | 1473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1474 | | 1475 | HMAC | 1476 | | 1477 | | 1478 | | 1479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1481 Type 65245 1482 Length 20 1483 HMAC 160 low order bits of the HMAC computed over the HIP 1484 packet, excluding the HMAC parameter and any 1485 following HIP_SIGNATURE or HIP_SIGNATURE2 1486 parameters. The checksum field MUST be set to zero 1487 and the HIP header length in the HIP common header 1488 MUST be calculated not to cover any excluded 1489 parameters when the HMAC is calculated. 1491 The HMAC calculation and verification process is presented in Section 1492 8.3.1 1494 6.2.11 HIP_SIGNATURE 1496 0 1 2 3 1497 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 1498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1499 | Type | Length | 1500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1501 | SIG alg | Signature / 1502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1503 / | Padding | 1504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1506 Type 65279 (2^16-2^8-1) 1507 Length length in octets, excluding Type, Length, and Padding 1508 SIG alg Signature algorithm 1509 Signature the signature is calculated over the HIP packet, 1510 excluding the HIP_SIGNATURE TLV field, but including 1511 the HMAC field, if present. The checksum field MUST 1512 be set to zero and the HIP header length in the HIP 1513 common header MUST be calculated to the beginning of 1514 the HIP_SIGNATURE TLV when the signature is 1515 calculated. 1517 The signature algorithms are defined in Section 6.2.8. The signature 1518 in the Signature field is encoded using the proper method depending 1519 on the signature algorithm (e.g. in case of DSA, according to [10]). 1521 The HIP_SIGNATURE calculation and verification process is presented 1522 in Section 8.3.2 1524 6.2.12 HIP_SIGNATURE_2 1526 The TLV structure is the same as in Section 6.2.11. The fields are: 1528 Type 65277 (2^16-2^8-3) 1529 Length length in octets, excluding Type, Length, and Padding 1530 SIG alg Signature algorithm 1531 Signature the signature is calculated over the R1 packet, 1532 excluding the HIP_SIGNATURE_2 TLV field, but 1533 including the HMAC field, if present. Initiator's 1534 HIT and Checksum field MUST be set to zero and the 1535 HIP packet length in the HIP header MUST be 1536 calculated to the beginning of the HIP_SIGNATURE_2 1537 TLV when the signature is calculated. 1539 Zeroing the Initiator's HIT makes it possible to create R1 packets 1540 beforehand to minimize the effects of possible DoS attacks. 1542 Signature calculation and verification follows the process in Section 1543 8.3.2. 1545 6.2.13 NES 1547 The UPDATE payload is used to reset Security Associations. It 1548 introduces a new SPI to be used when sending data to the sender of 1549 the UPDATE packet. The keys for the new Security Association will be 1550 drawn from KEYMAT. If the packet contains a Diffie-Hellman 1551 parameter, the KEYMAT is first recomputed before drawing the new 1552 keys. 1554 0 1 2 3 1555 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 1556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1557 | Type | Length | 1558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1559 |R| Keymat Index | UPDATE ID | 1560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1561 | Old SPI | 1562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1563 | New SPI | 1564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1566 Type 9 1567 Length 12 1568 R One if the NES is a reply to another UPDATE, 1569 otherwise zero. 1570 Keymat Index Index, in bytes, where to continue to draw ESP keys 1571 from KEYMAT. If the packet includes a new 1572 Diffie-Hellman key, the field MUST be zero. Note 1573 that the length of this field limits the amount of 1574 keying material that can be drawn from KEYMAT. If 1575 that amount is exceeded, the NES packet MUST contain 1576 a new Diffie-Hellman key. 1577 UPDATE ID Packet identifier. Used to tie UPDATE packets 1578 into pairs. Initialized to zero and incremented 1579 for each UPDATE. 1580 Old SPI Old SPI for data sent to the source address of 1581 this packet 1582 New SPI New SPI for data sent to the source address of 1583 this packet 1585 Note that the NES used to include the SPI used in reverse direction, 1586 too. However, since UPDATE packets are now always sent in pairs, 1587 that is not needed any more. Any middleboxes between the 1588 communicating hosts will learn the reverse mappings from the UPDATE 1589 reply. 1591 6.2.14 ENCRYPTED 1593 0 1 2 3 1594 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 1595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1596 | Type | Length | 1597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1598 | Reserved | 1599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1600 | IV / 1601 / / 1602 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 1604 / Encrypted data / 1605 / / 1606 / +-------------------------------+ 1607 / | Padding | 1608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1610 Type 21 1611 Length length in octets, excluding Type, Length, and padding 1612 Reserved zero when sent, ignored when received 1613 IV Initialization vector, if needed, otherwise nonexistent. 1614 The length of the IV is inferred from the HIP transform. 1615 Encrypted The data is encrypted using an encryption algorithm as 1616 data defined in HIP transform. 1617 Padding Any Padding, if necessary, to make the TLV a multiple 1618 of 8 bytes. 1620 The encrypted data is in TLV format itself. Consequently, the first 1621 fields in the contents are Type and Length, allowing the contents to 1622 be easily parsed after decryption. Each of the TLVs to be encrypted, 1623 must be padded according to rules in Section 6.2.1 before encryption. 1625 If the encryption algorithm requires the length of the data to be 1626 encrypted to be a multiple of the cipher algorithm block size, 1627 thereby necessitating padding, and if the encryption algorithm does 1628 not specify the padding contents, then an implementation MUST append 1629 the TLV parameter that is to be encrypted with an additional padding, 1630 so that the length of the resulting cleartext is a multiple of the 1631 cipher block size length. Such a padding MUST be constructed as 1632 specified in [15] Section 2.4. On the other hand, if the data to be 1633 encrypted is already a multiple of the block size, or if the 1634 encryption algorithm does specify padding as per [15] Section 2.4, 1635 then such additional padding SHOULD NOT be added. 1637 The Length field in the inside, to be encrypted TLV does not include 1638 the padding. The Length field in the outside ENCRYPTED TLV is the 1639 length of the data after encryption (including the Reserved field, 1640 the IV field, and the output from the encryption process specified 1641 for that suite, but not any additional external padding). Note that 1642 the length of the cipher suite output may be smaller or larger than 1643 the length of the data to be encrypted, since the encryption process 1644 may compress the data or add additional padding to the data. 1646 The ENCRYPTED payload may contain additional external padding, if the 1647 result of encryption, the TLV header and the IV is not a multiple of 1648 8 bytes. The contents of this external padding MUST follow the rules 1649 given in Section 6.2.1. 1651 7. HIP Packets 1653 There are eight basic HIP packets. Four are for the base HIP 1654 exchange, one is for rekeying, one is a broadcast for use when there 1655 is no IP addressing (e.g., before DHCP exchange), one is used to send 1656 certificates, and one is for sending unencrypted data. 1658 Packets consist of the fixed header as described in Section 6.1, 1659 followed by the parameters. The parameter part, in turn, consists of 1660 zero or more TLV coded parameters. 1662 In addition to the base packets, other packets types will be defined 1663 later in separate specifications. For example, support for mobility 1664 and multi-homing is not included in this specification. 1666 Packet representation uses the following operations: 1668 () parameter 1669 x{y} operation x on content y 1670 i x exists i times 1671 [] optional parameter 1672 x | y x or y 1674 In the future, an OPTIONAL upper layer payload MAY follow the HIP 1675 header. The payload proto field in the header indicates if there is 1676 additional data following the HIP header. The HIP packet, however, 1677 MUST NOT be fragmented. This limits the size of the possible 1678 additional data in the packet. 1680 7.1 I1 - the HIP initiator packet 1682 The HIP header values for the I1 packet: 1684 Header: 1685 Packet Type = 1 1686 SRC HIT = Initiator's HIT 1687 DST HIT = Responder's HIT, or NULL 1689 IP ( HIP () ) 1691 The I1 packet contains only the fixed HIP header. 1693 Valid control bits: R 1695 The Initiator gets the Responder's HIT either from a DNS lookup of 1696 the Responder's FQDN, from some other repository, or from a local 1697 table. If the Initiator does not know the Responder's HIT, it may 1698 attempt opportunistic mode by using NULL (all zeros) as the 1699 Responder's HIT. 1701 Since this packet is so easy to spoof even if it were signed, no 1702 attempt is made to add to its generation or processing cost. 1704 Implementation MUST be able to handle a storm of received I1 packets, 1705 discarding those with common content that arrive within a small time 1706 delta. 1708 If a host has rebooted and it is trying to re-establish a Security 1709 Association based on incoming and unidentified ESP traffic, it sends 1710 an I1 packet with R bit set. 1712 7.2 R1 - the HIP responder packet 1714 The HIP header values for the R1 packet: 1716 Header: 1717 Packet Type = 2 1718 SRC HIT = Responder's HIT 1719 DST HIT = Initiator's HIT 1721 IP ( HIP ( BIRTHDAY_COOKIE, 1722 DIFFIE_HELLMAN, 1723 HIP_TRANSFORM, 1724 ESP_TRANSFORM, 1725 HOST_ID, 1726 HIP_SIGNATURE_2 ) ) 1728 Valid control bits: C, A 1730 The R1 packet may be followed by one or more CER packets. In this 1731 case, the C-bit in the control field MUST be set. 1733 If the responder HI is an anonymous one, the A control MUST be set. 1735 The initiator HIT MUST match the one received in I1. If the R1 is a 1736 response to an ESP packet with an unknown SPI, the Initiator HIT 1737 SHOULD be zero. If the Responder has multiple HIs, the responder HIT 1738 used MUST match Initiator's request. If the Initiator used 1739 opportunistic mode, the Responder may select freely among its HIs. 1741 The Birthday is a reboot count used to manage state re-establishment 1742 when one peer rebooted or timed out its SA. 1744 The Cookie contains a random # I and the difficulty K. The 1745 difficulty K is the number of bits that the Initiator must get zero 1746 in the puzzle. 1748 The Diffie-Hellman value is ephemeral, but can be reused over a 1749 number of connections. In fact, as a defense against I1 storms, an 1750 implementation MAY use the same Diffie-Hellman value for a period of 1751 time, for example, 15 minutes. By using a small number of different 1752 Cookies for a given Diffie-Hellman value, the R1 packets can be 1753 pre-computed and delivered as quickly as I1 packets arrive. A 1754 scavenger process should clean up unused DHs and Cookies. 1756 The HIP_TRANSFORM contains the encryption and integrity algorithms 1757 supported by the Responder to protect the HI exchange, in the order 1758 of preference. All implementations MUST support the 3DES [7] with 1759 HMAC-SHA-1-96 [4]. 1761 The ESP_TRANSFORM contains the ESP modes supported by the Responder, 1762 in the order of preference. All implementations MUST support 3DES 1763 [7] with HMAC-SHA-1-96 [4]. 1765 The signature is calculated over the whole HIP envelope, after 1766 setting the initiator HIT and header checksum temporarily to zero. 1767 This allows the Responder to use precomputed R1s. The Initiator 1768 SHOULD validate this signature. It SHOULD check that the responder 1769 HI received matches with the one expected, if any. 1771 7.3 I2 - the second HIP initiator packet 1773 The HIP header values for the I2 packet: 1775 Header: 1776 Type = 3 1777 SRC HIT = Initiator's HIT 1778 DST HIT = Responder's HIT 1780 IP ( HIP ( SPI_LSI, 1781 BIRTHDAY_COOKIE, 1782 DIFFIE_HELLMAN, 1783 HIP_TRANSFORM, 1784 ESP_TRANSFORM, 1785 ENCRYPTED { HOST_ID }, 1786 HIP_SIGNATURE ) ) 1788 Valid control bits: C, A 1790 The HITs used MUST match the ones used previously. 1792 If the initiator HI is an anonymous one, the A control MUST be set. 1794 The Birthday is a reboot count used to manage state re-establishment 1795 when one peer rebooted or timed out its SA. 1797 The Cookie contains the random # I from R1 and the computed # J. The 1798 low order K bits of the SHA-1(I | ... | J) MUST be zero. 1800 The Diffie-Hellman value is ephemeral. If precomputed, a scavenger 1801 process should clean up unused DHs. 1803 The HIP_TRANSFORM contains the encryption and integrity used to 1804 protect the HI exchange selected by the Initiator. All 1805 implementations MUST support the 3DES transform [7]. 1807 The Initiator's HI is encrypted using the HIP_TRANSFORM encryption 1808 algorithm. The keying material is derived from the Diffie-Hellman 1809 exchanged as defined in Section 9. 1811 The ESP_TRANSFORM contains the ESP mode selected by the Initiator. 1812 All implementations MUST support 3DES [7] with HMAC-SHA-1-96 [4]. 1814 The signature is calculated over whole HIP envelope. The Responder 1815 MUST validate this signature. It MAY use either the HI in the packet 1816 or the HI acquired by some other means. 1818 7.4 R2 - the second HIP responder packet 1820 The HIP header values for the R2 packet: 1822 Header: 1823 Packet Type = 4 1824 SRC HIT = Responder's HIT 1825 DST HIT = Initiator's HIT 1827 IP ( HIP ( SPI_LSI, HMAC, HIP_SIGNATURE ) ) 1829 Valid control bits: none 1831 The HMAC and signature are calculated over whole HIP envelope. The 1832 Initiator MUST validate both the HMAC and the signature. 1834 7.5 UPDATE - the HIP New SPI Packet 1836 The UPDATE packet is MANDATORY. 1838 The UPDATE serves three functions. Firstly, it provides the peer 1839 system with a new SPI to use when sending packets. Secondly, it 1840 optionally provides a new Diffie-Hellman key to produce new keying 1841 material. Thirdly, it provides any intermediate system with the 1842 mapping of the old SPI to the new one. This is important to systems 1843 like NATs [21] that use SPIs to maintain address translation state. 1845 The UPDATE packet is a HIP packet with NES and optional 1846 DIFFIE_HELLMAN in the HIP payload. The NES parameter contains the 1847 old and new SPI values. It also contains a UPDATE ID and HMAC to 1848 provide DoS and replay protection. Each system must have a UPDATE ID 1849 counter, initialized to zero and incremented on each UPDATE. 1851 The HIP header values for the UPDATE packet: 1853 Header: 1854 Packet Type = 5 1855 SRC HIT = Sender's HIT 1856 DST HIT = Recipient's HIT 1858 IP ( HIP ( NES, [ DIFFIE_HELLMAN, ] HMAC, HIP_SIGNATURE ) ) 1860 Valid control bits: None 1862 During the life of an SA established by HIP, one of the hosts may 1863 need to reset the Sequence Number to one (to prevent wrapping) and 1864 rekey. The reason for rekeying might be an approaching sequence 1865 number wrap in ESP, or a local policy on use of a key. Rekeying ends 1866 the current SAs and starts new ones on both peers. 1868 UPDATE packets are always used in pairs, one in both directions, with 1869 identical UPDATE IDs. In the case both parties decide to rekey at 1870 the same time, the result is four UPDATE packets, two in both 1871 directions. 1873 Intermediate systems that use the SPI will have to inspect HIP 1874 packets for a UPDATE packet. The packet is signed for the benefit of 1875 the intermediate systems. Since intermediate systems may need the 1876 new SPI values, the contents of this packet cannot be encrypted. 1878 Processing UPDATE signatures is a potential DoS attack against 1879 intermediate systems. 1881 7.6 BOS - the HIP Bootstrap Packet 1883 The BOS packet is OPTIONAL. 1885 In some situations, an Initiator may not be able to learn of a 1886 Responder's information from DNS or another repository. Some examples 1887 of this are DHCP and NetBIOS servers. Thus, a packet is needed to 1888 provide information that would otherwise be gleaned from a 1889 repository. This HIP packet is either self-signed in applications 1890 like SoHo, or from a trust anchor in large private or public 1891 deployments. This packet MAY be broadcasted in IPv4 or multicasted 1892 to the all hosts multicast group in IPv6. The packet MUST NOT be 1893 sent more often than once in every second. Implementations MAY 1894 ignore received BOS packets. 1896 The HIP header values for the BOS packet: 1898 Header: 1899 Packet Type = 7 1900 SRC HIT = Announcer's HIT 1901 DST HIT = NULL 1903 IP ( HIP ( HOST_ID, HIP_SIGNATURE ) ) 1905 The BOS packet may be followed by a CER packet if the HI is signed. 1906 In this case, the C-bit in the control field MUST be set. If the BOS 1907 packet is broadcasted or multicasted, the following CER packet(s) 1908 MUST be broadcasted or multicasted to the same multicast group and 1909 scope, respectively. 1911 Valid control bits: C, A 1913 7.7 CER - the HIP Certificate Packet 1915 The CER packet is OPTIONAL. 1917 The Optional CER packets over the Announcer's HI by a higher level 1918 authority known to the Recipient is an alternative method for the 1919 Recipient to trust the Announcer's HI (over DNSSEC or PKI). 1921 The HIP header values for CER packet: 1923 Header: 1924 Packet Type = 8 1925 SRC HIT = Announcer's HIT 1926 DST HIT = Recipient's HIT 1928 IP ( HIP ( i , HIP_SIGNATURE ) ) or 1930 IP ( HIP ( ENCRYPTED { i }, HIP_SIGNATURE ) ) 1932 Valid control bits: None 1934 Certificates in the CER packet MAY be encrypted. The encryption 1935 algorithm is provided in the HIP transform of the previous (R1 or I2) 1936 packet. 1938 7.8 PAYLOAD - the HIP Payload Packet 1940 The PAYLOAD packet is OPTIONAL. 1942 The HIP header values for the PAYLOAD packet: 1944 Header: 1945 Packet Type = 64 1946 SRC HIT = Sender's HIT 1947 DST HIT = Recipient's HIT 1949 IP ( HIP ( ), payload ) 1951 Valid control bits: None 1953 Payload Proto field in the Header MUST be set to correspond the 1954 correct protocol number of the payload. 1956 The PAYLOAD packet is used to carry a non-ESP protected data. By 1957 using the HIP header we ensure interoperability with NAT and other 1958 middle boxes. 1960 Processing rules of the PAYLOAD packet are the following: 1962 Receiving: If there is an existing HIP security association with the 1963 given HITs, and the IP addresses match the IP addresses associated 1964 with the HITs, pass the packet to the upper layer, tagged with 1965 metadata indicating that the packet was NOT integrity or 1966 confidentiality protected. 1968 Sending: If the IPsec SPD defines BYPASS for a given destination 1969 HIT, send it with the PAYLOAD packet. Otherwise use ESP as 1970 specified in the SPD. 1972 8. Packet processing 1974 Each host is assumed to have a separate HIP protocol implementation 1975 that manages the host's HIP associations and handles requests for new 1976 ones. Each HIP association is governed by a state machine, with 1977 states defined above in Section 5.4. The HIP implementation can 1978 simultaneously maintain HIP associations with more than one host. 1979 Furthermore, the HIP implementation may have more than one active HIP 1980 association with another host; in this case, HIP associations are 1981 distinguished by their respective HITs and IPsec SPIs. It is not 1982 possible to have more than one HIP associations between any given 1983 pair of HITs. Consequently, the only way for two hosts to have more 1984 than one parallel associations is to use different HITs, at least in 1985 one end. 1987 The processing of packets depends on the state of the HIP 1988 association(s) with respect to the authenticated or apparent 1989 originator of the packet. A HIP implementation determines whether it 1990 has an active association with the originator of the packet based on 1991 the HITs or the SPI of the packet. 1993 8.1 Processing outgoing application data 1995 In a HIP host, an application can send application level data using 1996 HITs or LSIs as source and destination identifiers. The HITs and LSIs 1997 may be specified via a backwards compatible API (see Appendix A) or a 1998 completely new API. However, whenever there is such outgoing data, 1999 the stack has to protect the data with ESP, and send the resulting 2000 datagram using appropriate source and destination IP addresses. 2001 Here, we specify the processing rules only for the base case where 2002 both hosts have only single usable IP addresses; the multi-address 2003 multi-homing case will be specified separately. 2005 If the IPv4 backward compatible APIs and therefore LSIs are 2006 supported, it is assumed that the LSIs will be converted into proper 2007 HITs somewhere in the stack. The exact location of the conversion is 2008 an implementation specific issue and not discussed here. The 2009 following conceptual algorithm discusses only HITs, with the 2010 assumption that the LSI-to-HIT conversion takes place somewhere. 2012 The following steps define the conceptual processing rules for 2013 outgoing datagrams destined to a HIT. 2015 1. If the datagram has a specified source address, it MUST be a HIT. 2016 If it is not, the implementation MAY replace the source address 2017 with a HIT. Otherwise it MUST drop the packet. 2019 2. If the datagram has an unspecified source address, the 2020 implementation must choose a suitable source HIT for the 2021 datagram. In selecting a proper local HIT, the implementation 2022 SHOULD consult the table of currently active HIP sessions, and 2023 preferably select a HIT that already has an active session with 2024 the target HIT. 2026 3. If there no active HIP session with the given < source, 2027 destination > HIT pair, one must be created by running the base 2028 exchange. The implementation SHOULD queue at least one packet 2029 per a HIP session to be formed, and it MAY queue more than one. 2031 4. Once there is an active HIP session for the given < source, 2032 destination > HIT pair, the outgoing datagram is protected using 2033 the associated ESP security association. In a typical 2034 implementation, this will result in an transport mode ESP 2035 datagram that still has HITs in the place of IP addresses. 2037 5. The HITs in the datagram are replaced with suitable IP addresses. 2038 For IPv6, the rules defined in [12] SHOULD be followed. Note 2039 that this HIT-to-IP-address conversion step MAY also be performed 2040 at some other point in the stack, e.g., before ESP processing. 2041 However, care must be taken to make sure that the right ESP SA is 2042 employed. 2044 8.2 Processing incoming application data 2046 Incoming HIP datagrams arrive as ESP protected packets. In the usual 2047 case the receiving host has a corresponding ESP security association, 2048 identified by the SPI and destination IP address in the packet. 2049 However, if the host has crashed or otherwise lost its HIP state, it 2050 may not have such an SA. 2052 The following steps define the conceptual processing rules for 2053 incoming ESP protected datagrams targeted to an ESP security 2054 association created with HIP. 2056 1. Detect the proper IPsec SA using the SPI. If the resulting SA is 2057 a non-HIP ESP SA, process the packet according to standard IPsec 2058 rules. If there are no SAs identified with the SPI, the host MAY 2059 send an I1 with a NULL Responder HIT and the R-bit set indicating 2060 re-establishment of an SA. Sending such I1s MUST be rate 2061 limited. 2063 2. If a proper HIP ESP SA is found, the packet is processed normally 2064 by ESP, as if the packet were a transport mode packet. The 2065 packet may be dropped by ESP, as usual. In a typical 2066 implementation, the result of successful ESP decryption and 2067 verification is a datagram with the original IP addresses as 2068 source and destination. 2070 3. The IP addresses in the datagram are replaced with the HITs 2071 associated with the ESP SA. Note that this IP-address-to-HIT 2072 conversion step MAY also be performed at some other point in the 2073 stack, e.g., before ESP processing. 2075 4. The datagram is delivered to the upper layer. Demultiplexing the 2076 datagram the right upper layer socket is based on the HITs (or 2077 LSIs). 2079 8.3 HMAC and SIGNATURE calculation and verification 2081 The following subsections define the actions for processing HMAC, 2082 HIP_SIGNATURE and HIP_SIGNATURE2 TLVs. 2084 8.3.1 HMAC calculation 2086 The HMAC TLV is defined in Section 6.2.10. HMAC calculation and 2087 verification process: 2089 Packet sender: 2091 1. Create the HIP packet, without the HMAC or any possible 2092 HIP_SIGNATURE or HIP_SIGNATURE2 TLVs. 2094 2. Calculate the Length field in the HIP header. 2096 3. Compute the HMAC. 2098 4. Add the HMAC TLV to the packet and any HIP_SIGNATURE or 2099 HIP_SIGNATURE2 TLVs that may follow. 2101 5. Recalculate the Length field in the HIP header. 2103 Packet receiver: 2105 1. Verify the HIP header Length field. 2107 2. Remove the HMAC TLV, and if the packet contains any HIP_SIGNATURE 2108 or HIP_SIGNATURE2 fields, remove them too, saving the contents if 2109 they will be needed later. 2111 3. Recalculate the HIP packet length in the HIP header and clear the 2112 Checksum field (set it to all zeros). 2114 4. Compute the HMAC and verify it against the received HMAC. 2116 8.3.2 Signature calculation 2118 The following process applies both to the HIP_SIGNATURE and 2119 HIP_SIGNATURE2 TLVs. When processing HIP_SIGNATURE2, the only 2120 difference is that instead of HIP_SIGNATURE TLV the HIP_SIGNATURE2 2121 TLV is used, and the Initiator's HIT is cleared (set to all zeros) 2122 before computing the signature. The HIP_SIGNATURE TLV is defined in 2123 Section 6.2.11 and the HIP_SIGNATURE2 TLV in Section 6.2.12. 2125 Signature calculation and verification process: 2127 Packet sender: 2129 1. Create the HIP packet without the HIP_SIGNATURE TLV. 2131 2. Calculate the Length field in the HIP header. 2133 3. Compute the signature. 2135 4. Add the HIP_SIGNATURE TLV to the packet. 2137 5. Recalculate the Length field in the HIP header. 2139 Packet receiver: 2141 1. Verify the HIP header Length field. 2143 2. Save the contents of the HIP_SIGNATURE TLV and remove it from the 2144 packet. 2146 3. Recalculate the HIP packet Length in the HIP header and clear the 2147 Checksum field (set it to all zeros). 2149 4. Compute the signature and verify it against the received 2150 signature. 2152 The verification can use either the HI received from a HIP packet, 2153 the HI from a DNS query, if the FQDN has been received either in the 2154 HOST_ID or in the CER packet, or one received by some other means. 2156 8.4 Initiation of a HIP exchange 2158 An implementation may originate a HIP exchange to another host based 2159 on a local policy decision, usually triggered by an application 2160 datagram, in much the same way that an IPsec IKE key exchange can 2161 dynamically create a Security Association. Alternatively, a system 2162 may initiate a HIP exchange if it has rebooted or timed out, or 2163 otherwise lost its HIP state, as described in Section 5.3. 2165 The implementation prepares an I1 packet and sends it to the IP 2166 address that corresponds to the peer host. The IP address of the 2167 peer host may be obtained via conventional mechanisms, such as DNS 2168 lookup. The I1 contents are specified in Section 7.1. The selection 2169 of which host identity to use, if a host has more than one to choose 2170 from, is typically a policy decision. 2172 The following steps define the conceptual processing rules for 2173 initiating a HIP exchange: 2175 1. The Initiator gets the Responder's HIT and one or more addresses 2176 either from a DNS lookup of the responder's FQDN, from some other 2177 repository, or from a local table. If the initiator does not know 2178 the responder's HIT, it may attempt opportunistic mode by using 2179 NULL (all zeros) as the responder's HIT. 2181 2. The Initiator sends an I1 to one of the Responder's addresses. 2182 The selection of which address to use is a local policy decision. 2184 3. Upon sending an I1, the sender shall transition to state I1-SENT, 2185 start a timer whose timeout value should be larger than the 2186 worst-case anticipated RTT, and shall increment a timeout counter 2187 associated with the I1. 2189 4. Upon timeout, the sender SHOULD retransmit the I1 and restart the 2190 timer, up to a maximum of I1_RETRIES_MAX tries. 2192 8.4.1 Sending multiple I1s in parallel 2194 For the sake of minimizing the session establishment latency, an 2195 implementation MAY send the same I1 to more than one of the 2196 Responder's addresses. However, it MUST NOT send to more than three 2197 (3) addresses in parallel. Furthermore, upon timeout, the 2198 implementation MUST refrain from sending the same I1 packet to 2199 multiple addresses. These limitations are placed order to avoid 2200 congestion of the network, and potential DoS attacks that might 2201 happen, e.g., because someone claims to have hundreds or thousands of 2202 addresses. 2204 As the Responder is not guaranteed to distinguish the duplicate I1's 2205 it receives at several of its addresses (because it avoids to store 2206 states when it answers back an R1), the Initiator may receive several 2207 duplicate R1's. 2209 The Initiator SHOULD then select the destination address using the 2210 source address of the first received R1 as a source address for the 2211 next I2, and discards subsequent R1's. This strategy seems to be 2212 quite good in terms of RTT. 2214 8.4.2 Processing incoming ICMP Protocol Unreachable messages 2216 A host may receive an ICMP Destination Protocol Unreachable message 2217 as a response to sending an HIP I1 packet. Such a packet may be an 2218 indication that the peer does not support HIP, or it may be an 2219 attempt to launch an attack by making the Initiator to believe that 2220 the Responder does not support HIP. 2222 When a system receives an ICMP Destination Protocol Unreachable 2223 message while it is waiting for an R1, it MUST NOT terminate the 2224 wait. It MAY continue as if it had not received the ICMP message, 2225 and send a few more I1s. Alternatively, it MAY take the ICMP message 2226 as a hint that the peer most probably does not support HIP, and 2227 return to state UNASSOCIATED earlier than otherwise. However, at 2228 minimum, it MUST continue waiting for an R1 for a reasonable time 2229 before returning to UNASSOCIATED. 2231 8.5 Processing incoming I1 packets 2233 An implementation SHOULD reply to an I1 with an R1 packet, unless the 2234 implementation is unable or unwilling to setup a HIP association. If 2235 the implementation is unable to setup a HIP association, the host 2236 SHOULD send an ICMP Destination Protocol Unreachable, 2237 Administratively Prohibited, message to the I1 source address. If 2238 the implementation is unwilling to setup a HIP association, the host 2239 MAY ignore the I1. This latter case may occur during a DoS attack 2240 such as an I1 flood. 2242 The implementation MUST be able to handle a storm of received I1 2243 packets, discarding those with common content that arrive within a 2244 small time delta. 2246 A spoofed I1 can result in an R1 attack on a system. An R1 sender 2247 MUST have a mechanism to rate limit R1s to an address. 2249 Under no circumstances does the HIP state machine transition upon 2250 sending an R1. 2252 The following steps define the conceptual processing rules for 2253 responding to an I1 packet: 2255 1. The responder MUST check that the responder HIT in the received 2256 I1 is either one of its own HITs, or NULL. 2258 2. If the responder is in ESTABLISHED state, the incoming I1 packet 2259 MUST have the R bit set. The responder MAY respond to this with 2260 an R1 packet, prepare to drop existing SAs and move to RESYNC 2261 state. 2263 3. If the responder is in UNASSOCIATED state and the incoming I1 has 2264 the R bit set, the responder MAY respond with an R1. It may be 2265 that the initiator is now under an attack, or both the initiator 2266 and the responder have lost the state. 2268 4. If the implementation chooses to respond to the I1 with and R1 2269 packet, it creates a new R1 or selects a precomputed R1 according 2270 to the format described in Section 7.2. 2272 5. The R1 MUST contain the received responder HIT, unless the 2273 received HIT is NULL, in which case the Responder may freely 2274 select among its HITs. 2276 6. The responder sends the R1 to the source IP address of the I1 2277 packet. 2279 8.5.1 R1 Management 2281 All compliant implementations MUST produce R1 packets. An R1 packet 2282 MAY be precomputed. An R1 packet MAY be reused for time Delta T, 2283 which is implementation dependent. R1 information MUST not be 2284 discarded until Delta S after T. Time S is the delay needed for the 2285 last I2 to arrive back to the responder. 2287 An implementation MAY keep state about received I1s and match the 2288 received I2s against the state, as discussed in Section 4.1.1. 2290 8.6 Processing incoming R1 packets 2292 A system receiving an R1 MUST first check to see if it has sent an I1 2293 to the originator of the R1 (i.e., it is in state I1-SENT). If so, 2294 it SHOULD process the R1 as described below, send an I2, and go to 2295 state I2-SENT, setting a timer to protect the I2. If the system is in 2296 any other state with respect to that host, it SHOULD silently drop 2297 the R1. 2299 The following steps define the conceptual processing rules for 2300 responding to an R1 packet: 2302 1. A system receiving an R1 MUST first check to see if it has sent 2303 an I1 to the originator of the R1 (i.e., it has a HIP 2304 association that is in state I1-SENT and that is associated with 2305 the HITs in the R1). If so, it should process the R1 as 2306 described below. 2308 2. Otherwise, if the system is in any other state than I1-SENT with 2309 respect to the HITs included in the R1, it SHOULD silently drop 2310 the R1 and remain in the current state. 2312 3. If the HIP association state is I1-SENT, the received 2313 Initiator's HIT MUST correspond to the HIT used in the original, 2314 I1 and the Responder's HIT MUST correspond to the one used, 2315 unless the I1 contained a NULL HIT. 2317 4. The system SHOULD validate the R1 signature before applying 2318 further packet processing, according to Section 6.2.12. 2320 5. The R1 packet may have the C bit set -- in this case, the system 2321 should anticipate the receipt of HIP CER packets that contain 2322 the host identity corresponding to the responder's HIT. 2324 6. The R1 packet may have the A bit set -- in this case, the system 2325 MAY choose to refuse it by dropping the R1 and returning to 2326 state UNASSOCIATED. The system SHOULD consider dropping the R1 2327 only if it used a NULL HIT in I1. If the A bit is set, the 2328 Responder's HIT is anonymous and should not be stored. 2330 7. The system SHOULD attempt to validate the HIT against the 2331 received Host Identity. 2333 8. The system MUST store the received Birthday count for future 2334 reference. 2336 9. The attempts to solve the cookie puzzle in R1. The system MUST 2337 terminate the search after a number of tries, the minimum of the 2338 degree of difficulty specified by the K value or an 2339 implementation- or policy-defined maximum retry count. It is 2340 RECOMMENDED that the system does not try more than 2^(K+2) 2341 times. If the cookie puzzle is not successfully solved, the 2342 implementation may either resend I1 within the retry bounds or 2343 abandon the HIP exchange. 2345 10. The system computes standard Diffie-Hellman keying material 2346 according to the public value and Group ID provided in the 2347 DIFFIE_HELLMAN parameter. The Diffie-Hellman keying material 2348 Kij is used for key extraction as specified in Section 9. If 2349 the received Diffie-Hellman Group ID is not supported, the 2350 implementation may either resend I1 within the retry bounds or 2351 abandon the HIP exchange. 2353 11. The system selects the HIP transform and ESP transform from the 2354 choices presented in the R1 packet and uses the selected values 2355 subsequently when generating and using encryption keys, and when 2356 sending the I2. If the proposed alternatives are not acceptable 2357 to the system, it may either resend I1 within the retry bounds 2358 or abandon the HIP exchange. 2360 12. The system prepares and creates an incoming IPsec ESP security 2361 association. It may also prepare a security association for 2362 outgoing traffic, but since it does not have the correct SPI 2363 value yet, it cannot activate it. 2365 13. The system initialized the remaining variables in the associated 2366 state, including UPDATE ID counters. 2368 14. The system prepares and sends an I2, as described in Section 2369 7.3. 2371 15. The system SHOULD start a timer whose timeout value should be 2372 larger than the worst-case anticipated RTT, and MUST increment a 2373 timeout counter associated with the I2. The sender SHOULD 2374 retransmit the I2 upon a timeout and restart the timer, up to a 2375 maximum of I2_RETRIES_MAX tries. 2377 16. If the system is in state I1-SENT, it shall transition to state 2378 I2-SENT. If the system is in any other state, it remains in the 2379 current state. 2381 8.7 Processing incoming I2 packets 2383 Upon receipt of an I2, the system MAY perform initial checks to 2384 determine whether the I2 corresponds to a recent R1 that has been 2385 sent out, if the Responder keeps such state. For example, the sender 2386 could check whether the I2 is from an address or HIT that has 2387 recently received an R1 from it. If the I2 is considered to be 2388 suspect, it MAY be silently discarded by the system. 2390 Otherwise, the HIP implementation SHOULD process the I2. This 2391 includes validation of the cookie puzzle solution, generating the 2392 Diffie-Hellman key, decrypting the Initiator's Host Identity, 2393 verifying the signature, creating state, and finally sending an R2. 2395 The following steps define the conceptual processing rules for 2396 responding to an I2 packet: 2398 1. The system MAY perform checks to verify that the I2 corresponds 2399 to a recently sent R1. Such checks are implementation 2400 dependent. See Appendix D for a description of an example 2401 implementation. 2403 2. The system MUST check that the Responder's HIT corresponds to 2404 one of its own HITs. 2406 3. The system MUST validate the solution to the cookie puzzle by 2407 computing the SHA-1 hash described in Section 7.3. 2409 4. The I2 MUST have a single value in each of the HIP_TRANSFORM and 2410 ESP_TRANSFORM parameters, which MUST each match one of the 2411 values offered to the Initiator in the R1 packet. 2413 5. The system must derive Diffie-Hellman keying material Kij based 2414 on the public value and Group ID in the DIFFIE_HELLMAN 2415 parameter. This key is used to derive the HIP and ESP 2416 association keys, as described in Section 9. If the 2417 Diffie-Hellman Group ID is unsupported, the I2 packet is 2418 silently dropped. 2420 6. The encrypted HOST_ID decrypted by the Initiator encryption key 2421 defined in Section 9. If the decrypted data is not an HOST_ID 2422 parameter, the I2 packet is silently dropped. 2424 7. The implementation SHOULD also verify that the Initiator's HIT 2425 in the I2 corresponds to the Host Identity sent in the I2. 2427 8. The system MUST verify the HIP_SIGNATURE according to Section 2428 6.2.11 and Section 7.3. 2430 9. If the system is in state ESTABLISHED with respect to the HITs, 2431 the system MUST perform the birthday cookie check as defined in 2432 Section 5.3. 2434 10. If the checks above are valid, then the system proceeds with 2435 further I2 processing; otherwise, it discards the I2 and remains 2436 in the same state. 2438 11. The I2 packet may have the C bit set -- in this case, the system 2439 should anticipate the receipt of HIP CER packets that contain 2440 the host identity corresponding to the responder's HIT. 2442 12. The I2 packet may have the A bit set -- in this case, the system 2443 MAY choose to refuse it by dropping the I2 and returning to 2444 state UNASSOCIATED. If the A bit is set, the Initiator's HIT is 2445 anonymous and should not be stored. 2447 13. The Birthday count is extracted from the BIRTHDAY_COOKIE 2448 parameter and stored for future use. 2450 14. The SPI_LSI field is parsed to obtain the SPI that will be used 2451 for the Security Association outbound from the Responder and 2452 inbound to the Initiator. 2454 15. If the system supports LSIs, it should check that the received 2455 LSI is an acceptable representation of its own identity, and 2456 create an appropriate state. If the LSI is not acceptable, the 2457 behaviour is currently undefined; see Appendix A. 2459 16. The system prepares and creates both incoming and outgoing ESP 2460 security associations. 2462 17. The system initialized the remaining variables in the associated 2463 state, including UPDATE ID counters. 2465 18. Upon successful processing of an I2 in states UNASSOCIATED, 2466 I1-SENT, and I2-SENT, an R2 is sent and the state machine 2467 transitions to state ESTABLISHED. 2469 19. Upon successful processing of an I2 in state ESTABLISHED/ 2470 REKEYING/RESYNC (which includes a successful Birthday check), 2471 the old Security Association is dropped and a new one is 2472 installed, an R2 is sent, and the state machine transitions to 2473 ESTABLISHED, dropping any possibly ongoing rekeying attempt. 2475 8.8 Processing incoming R2 packets 2477 An R2 received in states UNASSOCIATED, I1-SENT, ESTABLISHED, REKEYING 2478 or RESYNC results in the R2 being dropped and the state machine 2479 staying in the same state. If an R2 is received in state I2-SENT, it 2480 SHOULD be processed. 2482 The following steps define the conceptual processing rules for 2483 incoming R2 packet: 2485 1. The system MUST verify that the HITs in use correspond to the 2486 HITs that were received in R1. 2488 2. The system MUST verify the HMAC according to the procedures in 2489 Section 6.2.10. 2491 3. The system MUST verify the HIP signature according to the 2492 procedures in Section 6.2.11. 2494 4. If any of the checks above fail, there is a high probability of 2495 an ongoing man-in-the-middle or other security attack. The 2496 system SHOULD act accordingly, based on its local policy. 2498 5. If the system is in any other state than I2-SENT, the R2 is 2499 silently dropped. 2501 6. The SPI_LSI field is parsed to obtain the SPI that will be used 2502 for the ESP Security Association inbound to the Responder. The 2503 system uses this SPI to create or activate the outgoing ESP 2504 security association used to send packets to the peer. 2506 7. If the system supports LSIs, it should check that the received 2507 LSI is an acceptable representation of its own identity, and 2508 create an appropriate state. If the LSI is not acceptable, the 2509 behaviour is currently undefined; see Appendix A. 2511 8. Upon successful processing of the R2, the state machine moves to 2512 state ESTABLISHED. 2514 8.9 Initiating rekeying 2516 A system may initiate the rekey procedure at any time. It MUST 2517 initiate a rekey if its incoming ESP sequence counter is about to 2518 overflow. 2520 The following steps define the conceptual processing rules for 2521 initiating a rekey: 2523 1. The system SHOULD generate a new Diffie-Hellman public key. 2525 2. The system MUST increment its outgoing UPDATE ID counter. 2527 3. The system creates a UPDATE packet, which SHOULD contain a 2528 Diffie-Hellman parameter. If the UPDATE packet contains the 2529 Diffie-Hellman parameter, the Keymat Index in the NES parameter 2530 MUST be zero. 2532 4. The system sends the UPDATE packet and transitions to state 2533 REKEYING. 2535 5. The system SHOULD start a timer whose timeout value should be 2536 larger than the worst-case anticipated RTT, and MUST increment a 2537 timeout counter associated with UPDATE. The sender SHOULD 2538 retransmit the UPDATE upon a timeout and restart the timer, up to 2539 a maximum of UPDATE_RETRIES_MAX tries. 2541 6. The system MUST NOT delete its existing SAs, but continue using 2542 them if its policy still allows. The UPDATE procedure SHOULD be 2543 initiated prior enough in order to make sure that the SA replay 2544 counters do not overflow. 2546 8.10 Processing UPDATE packets 2548 When a system receives a UPDATE packet, its processing depends on 2549 whether the packet is a reply to a previously sent UPDATE packet or 2550 the UPDATE is a new packet. 2552 The following steps define the conceptual processing rules responding 2553 handling a received UPDATE packet: 2555 1. If the system is in state ESTABLISHED and the UPDATE has the 2556 R-bit set in the NES TLV, the packet is silently dropped. 2558 2. If the UPDATE ID in the received UPDATE is smaller than the 2559 stored incoming UPDATE ID, the packet MUST BE dropped. Note 2560 that if the UPDATE ID is equal to the stored value, the packet 2561 can be expected to be a retransmission, and acted accordingly. 2562 However, the HMAC verification (next step) MUST NOT be skipped. 2563 (A byte-by-byte comparison of the received and a store packet 2564 would be OK, though.) 2566 3. The system MUST verify the HMAC in the UPDATE packet. If the 2567 verification fails, the packet MUST be dropped. 2569 4. If the received UPDATE contains a Diffie-Hellman parameter, the 2570 received Keymat Index MUST be zero. If this test fails, the 2571 packet SHOULD be dropped and the system SHOULD log an error 2572 message. 2574 5. If the received UPDATE does not contain a Diffie-Hellman 2575 parameter, the received Keymat Index MUST be larger or equal to 2576 the index of the next byte to be drawn from the current KEYMAT. 2577 If this test fails, the packet SHOULD be dropped and the system 2578 SHOULD log an error message. 2580 6. The system MAY verify the SIGNATURE in the UPDATE packet. If the 2581 verification fails, the packet SHOULD be dropped and an error 2582 message logged. 2584 7. The system MUST record the UPDATE ID in the received packet, for 2585 replay protection. 2587 8. If the system is in state ESTABLISHED, and the UPDATE does not 2588 have the R-bit set in the NES TLV, the packet is processed as 2589 specified in Section 8.10.1. 2591 9. If the system is in state REKEYING, and the UPDATE has the R-bit 2592 set in the NES TLV, the packet is processed as specified in 2593 Section 8.10.2. 2595 10. If the system is in state REKEYING, and the UPDATE doesn't have 2596 the R-bit set in the NES TLV, there are apparently two UPDATE 2597 packets crossing each other in the network. Consequently, the 2598 R-bit-less packet is handled as specified in Section 8.10.1. 2599 However, in order not to unnecessarily spend cycles in 2600 Diffie-Hellman computations, there are minor differences to the 2601 case of receiving such a packet in state ESTABLISHED. 2603 8.10.1 Processing an initial UPDATE packet 2605 When a system receives an initial UPDATE packet, i.e. one that does 2606 not have the R-bit set, it prepares new incoming and outgoing SAs, 2607 but does not change the outgoing SA yet. Once it has the new SAs in 2608 place, it sends a reply UPDATE. The contents of the reply UPDATE 2609 depend on whether the system was in state ESTABLISHED or REKEYING 2610 upon receiving the initial UPDATE packet. 2612 The following steps define the conceptual processing rules responding 2613 handling a received initial UPDATE packet: 2615 1. If the system is in state ESTABLISHED, it consults its policy to 2616 see if it needs to generate a new Diffie-Hellman key, and 2617 generates a new key if needed. If the system is in state 2618 REKEYING, it may already have generated a new Diffie-Hellman key, 2619 and SHOULD use it. 2621 2. If either the received UPDATE contains a new Diffie-Hellman key, 2622 the system has a new Diffie-Hellman key from the previous step, 2623 or both, the system generates new KEYMAT. If there is only one 2624 new Diffie-Hellman key, the other old key is used. 2626 3. If the system generated new KEYMAT in the previous step, it sets 2627 Keymat Index to zero, independent on whether the received UPDATE 2628 included a Diffie-Hellman key or not. 2630 4. The system draws keys for new incoming and outgoing ESP SAs, 2631 starting from the Keymat Index, and prepares new incoming and 2632 outgoing ESP SAs. The SPI for the outgoing SA is the new SPI 2633 value from the received UPDATE. The SPI for the incoming SA is 2634 locally generated, and SHOULD be random. The system MUST NOT 2635 start using the new outgoing SA before it receives traffic on the 2636 new incoming SA. 2638 5. The system prepares a reply UPDATE packet, with the R-bit one in 2639 the NES TLV, Keymat Index being the one used above, UPDATE ID 2640 being equal to the one in the received UPDATE, old SPI being the 2641 current incoming SPI, and new SPI being the newly generated 2642 incoming SPI. If the system generated a new Diffie-Hellman key 2643 above, the new key is included in the packet in the 2644 Diffie-Hellman payload. Note that if the system is in state 2645 REKEYING, the new Diffie-Hellman key was probably generated and 2646 sent already earlier, in which case it MUST NOT be included into 2647 the reply packet. 2649 8.10.2 Processing a reply UPDATE packet 2651 When a system receives a reply UPDATE packet, i.e. one that has the 2652 R-bit set in the NES TLV, it starts to use the new outgoing SA. It 2653 must also complete its new incoming SA. 2655 The following steps define the conceptual processing rules responding 2656 handling a received reply UPDATE packet: 2658 1. If either the received UPDATE contains a new Diffie-Hellman key, 2659 the system has a new Diffie-Hellman key from initiating rekey, or 2660 both, the system generates new KEYMAT. If there is only one new 2661 Diffie-Hellman key, the old key is used as the other key. 2663 2. If the system generated new KEYMAT in the previous step, it sets 2664 Keymat Index to zero, independent on whether the received UPDATE 2665 included a Diffie-Hellman key or not. 2667 3. The system draws keys for new incoming and outgoing ESP SAs, 2668 starting from the Keymat Index, and prepares new incoming and 2669 outgoing ESP SAs. The SPI for the outgoing SA is the new SPI 2670 value from the UPDATE. The SPI for the incoming SA was generated 2671 when rekey was initiated. 2673 4. The system starts to send to the new outgoing SA. It should 2674 start receiving data on the new incoming SA as soon as the peer 2675 receives data on the new SA. 2677 5. If the system has no data to send for 500ms, it SHOULD send an 2678 ESP packet anyway. The purpose of this packet is to acknowledge 2679 the other party that the UPDATE reply came through, and to allow 2680 the other party to switch over to the new outgoing SA. It is 2681 RECOMMENDED that the system sends an empty ESP packet, i.e., one 2682 where the Next Header field is IPPROTO_NONE (decimal 59). 2684 8.11 Processing BOS packets 2686 Processing BOS packets is OPTIONAL, and currently undefined. 2688 8.12 Processing CER packets 2690 Processing CER packets is OPTIONAL, and currently undefined. 2692 8.13 Processing PAYLOAD packets 2694 Processing PAYLOAD packets is OPTIONAL, and currently undefined. 2696 9. HIP KEYMAT 2698 HIP keying material is derived from the Diffie-Hellman Kij produced 2699 during the base HIP exchange. The Initiator has Kij during the 2700 creation of the I2 packet, and the Responder has Kij once it receives 2701 the I2 packet. This is why I2 can already contain encrypted 2702 information. 2704 The KEYMAT is derived by feeding Kij and the HITs into the following 2705 operation; the | operation denotes concatenation. 2707 KEYMAT = K1 | K2 | K3 | ... 2708 where 2710 K1 = SHA-1( Kij | sort(HIT-I | HIT-R) | 0x01 ) 2711 K2 = SHA-1( Kij | K1 | 0x02 ) 2712 K3 = SHA-1( Kij | K2 | 0x03 ) 2713 ... 2714 K255 = SHA-1( Kij | K254 | 0xff ) 2715 K256 = SHA-1( Kij | K255 | 0x00 ) 2716 etc. 2718 Sort(HIT-I | HIT-R) is defined as the network byte order 2719 concatenation of the two HITs, with the smaller HIT preceding the 2720 larger HIT, resulting from the numeric comparison of the two HITs 2721 interpreted as positive (unsigned) 128-bit integers in network byte 2722 order. 2724 The initial keys are drawn sequentially in the following order: 2726 HIP-IR encryption key for Initiator's outgoing HIP packets 2728 HIP-IR integrity (HMAC) key for Initiator's outgoing HIP packets 2730 HIP-RI encryption key (currently unused) for Responder's outgoing 2731 HIP packets 2733 HIP-RI integrity (HMAC) key for Responder's outgoing HIP packets 2735 SA-IR ESP encryption key for Initiator's outgoing traffic 2737 SA-IR ESP authentication key for Initiator's outgoing traffic 2739 SA-RI ESP encryption key for Responder's outgoing traffic 2741 SA-RI ESP authentication key for Responder's outgoing traffic 2743 The IR and RI denotes the direction of the traffic where the key is 2744 applied. The IR describes "from the Initiator to the Responder" 2745 -direction and the RI the other direction. 2747 The number of bits drawn for a given algorithm is the "natural" size 2748 of the keys. For the mandatory algorithms, the following sizes 2749 apply: 2751 3DES 192 bits 2753 SHA-1 160 bits 2755 NULL 0 bits 2757 The four HIP keys are only drawn from KEYMAT during a HIP I1->R2 2758 exchange. Subsequent rekeys using UPDATE will only draw the four ESP 2759 keys from KEYMAT. Section 8.10 describes the rules for reusing or 2760 regenerating KEYMAT based on the UPDATE exchange. 2762 10. HIP Fragmentation Support 2764 A HIP implementation must support IP fragmentation / reassembly. 2765 Fragment reassembly MUST be implemented in both IPv4 and IPv6, but 2766 fragment generation MUST be implemented only in IPv4 (IPv4 stacks and 2767 networks will usually do this by default) and SHOULD be implemented 2768 in IPv6. In the IPv6 world, the minimum MTU is larger, 1280 bytes, 2769 than in the IPv4 world. The larger MTU size is usually sufficient for 2770 most HIP packets, and therefore fragment generation may not be 2771 needed. If a host expects to send HIP packets that are larger than 2772 the minimum IPv6 MTU, it MUST implement fragment generation even for 2773 IPv6. 2775 In the IPv4 world, HIP packets may encounter low MTUs along their 2776 routed path. Since HIP does not provide a mechanism to use multiple 2777 IP datagrams for a single HIP packet, support of path MTU discovery 2778 does not bring any value to HIP in the IPv4 world. HIP aware NAT 2779 systems MUST perform any IPv4 reassembly/fragmentation. 2781 All HIP implementations MUST employ a reassembly algorithm that is 2782 sufficiently resistant against DoS attacks. 2784 11. ESP with HIP 2786 XXX: Since HIP is designed for host usage, not for gateways, only ESP 2787 transport mode is supported with HIP. The SA is not bound to an IP 2788 address; all internal control of the SA is by the HIT and LSI. XXX 2789 BEET mode. 2791 Since HIP does not negotiate any lifetimes, all lifetimes are local 2792 policy. The only lifetimes a HIP implementation MUST support are 2793 sequence number rollover (for replay protection), and SA timeout. An 2794 SA times out if no packets are received using that SA. The default 2795 timeout value is 15 minutes. Implementations MAY support lifetimes 2796 for the various ESP transforms. 2798 11.1 ESP Security Associations 2800 Each HIP association is linked with two ESP SAs, one incoming and one 2801 outgoing. The Initiator's incoming SA corresponds with the 2802 Responder's outgoing one. The initiator defines the SPI for this 2803 association, as defined in Section 3.3. This SA is called SA-RI, and 2804 the corresponding SPI is called SPI-RI. Respectively, the Responder's 2805 incoming SA corresponds with the Initiator's outgoing SA and is 2806 called SA-IR, with the SPI-IR. 2808 The Initiator creates SA-RI as a part of R1 processing, before 2809 sending out the I2, as explained in Section 8.6. The keys are derived 2810 from KEYMAT, as defined in Section 9. The Responder creates SA-RI as 2811 a part of I2 processing, see Section 8.7. 2813 The Responder creates SA-IR as a part of I2 processing, before 2814 sending out R2, see Step 17 in Section 8.7. The Initiator creates 2815 SA-IR when processing R2, see Step 7 in Section 8.8. 2817 11.2 Updating ESP SAs during rekeying 2819 After the initial 4-way handshake and SA establishment, both hosts 2820 are in state ESTABLISHED. There are no longer Initiator and 2821 Responder roles and the association is symmetric. In this 2822 subsection, the initiating party of the rekey procedure is denoted 2823 with I' and the peer with R'. 2825 The I' initiates the rekeying process when needed (see Section 8.9). 2826 It creates a UPDATE packet with required information and sends it to 2827 the peer node. The old SAs are still in use. 2829 The R', after receiving and processing the UPDATE (see Section 8.10), 2830 generates new SAs: SA-I'R' and SA-R'I'. It does not take the new 2831 outgoing SA into use, but uses still the old one, so there exists two 2832 SA pairs towards the same peer host. For the new outgoing SA, the 2833 SPI-R'I' value is picked from the received UPDATE packet. The R' 2834 generates the new SPI value for the incoming SA, SPI-I'R', and 2835 includes it in the response UPDATE packet. 2837 When the I' receives a response UPDATE from the R', it generates new 2838 SAs, as described in Section 8.10: SA-I'R' and SA-R'I'. It starts 2839 using the new outgoing SA immediately. 2841 The R' starts using the new outgoing SA when it receives traffic from 2842 the new incoming SA. After this, the R' can remove old SAs. 2843 Similarly, when the I' receives traffic from the new incoming SA, it 2844 can safely remove old SAs. 2846 11.3 Security Association Management 2848 An SA pair is indexed by the 2 SPIs and 2 HITs (both HITs since a 2849 system can have more than one HIT). An inactivity timer is 2850 recommended for all SAs. If the state dictates the deletion of an 2851 SA, a timer is set to allow for any late arriving packets. 2853 11.4 Security Parameter Index (SPI) 2855 The SPIs in ESP provide a simple compression of the HIP data from all 2856 packets after the HIP exchange. This does require a per HIT- pair 2857 Security Association (and SPI), and a decrease of policy granularity 2858 over other Key Management Protocols like IKE. 2860 When a host rekeys, it gets a new SPI from its partner. 2862 11.5 Supported Transforms 2864 All HIP implementations MUST support 3DES [7] and HMAC-SHA-1-96 [4]. 2865 If the Initiator does not support any of the transforms offered by 2866 the Responder in the R1 HIP packet, it MUST use 3DES and 2867 HMAC-SHA-1-96 and state so in the I2 HIP packet. 2869 In addition to 3DES, all implementations MUST implement the ESP NULL 2870 encryption and authentication algorithms. These algorithms are 2871 provided mainly for debugging purposes, and SHOULD NOT be used in 2872 production environments. The default configuration in 2873 implementations MUST be to reject NULL encryption or authentication. 2875 11.6 Sequence Number 2877 The Sequence Number field is MANDATORY in ESP. Anti-replay 2878 protection MUST be used in an ESP SA established with HIP. 2880 This means that each host MUST rekey before its sequence number 2881 reaches 2^32, or if extended sequence numbers are used, 2^64. Note 2882 that in HIP rekeying, unlike IKE rekeying, only one Diffie-Hellman 2883 key can be changed, that of the rekeying host. However, if one host 2884 rekeys, the other host SHOULD rekey as well. 2886 In some instances, a 32 bit sequence number is inadequate. In the 2887 ESP_TRANSFORM parameter, a peer MAY require that a 64 bit sequence 2888 number be used. In this case the higher 32 bits are NOT included in 2889 the ESP header, but are simply kept local to both peers. 64 bit 2890 sequence numbers must only be used for ciphers that will not be open 2891 to cryptanalysis as a result. AES is one such cipher. 2893 12. HIP Policies 2895 There are a number of variables that will influence the HIP exchanges 2896 that each host must support. All HIP implementations MUST support 2897 more than one simultaneous HIs, at least one of which SHOULD be 2898 reserved for anonymous usage. Although anonymous HIs will be rarely 2899 used as responder HIs, they will be common for Initiators. Support 2900 for more than two HIs is RECOMMENDED. 2902 Many Initiators would want to use a different HI for different 2903 Responders. The implementations SHOULD provide for an ACL of 2904 initiator HIT to responder HIT. This ACL SHOULD also include 2905 preferred transform and local lifetimes. For HITs with HAAs, 2906 wildcarding SHOULD be supported. Thus if a Community of Interest, 2907 like Banking, gets an RAA, a single ACL could be used. A global 2908 wildcard would represent the general policy to be used. Policy 2909 selection would be from most specific to most general. 2911 The value of K used in the HIP R1 packet can also vary by policy. K 2912 should never be greater than 20, but for trusted partners it could be 2913 as low as 0. 2915 Responders would need a similar ACL, representing which hosts they 2916 accept HIP exchanges, and the preferred transform and local 2917 lifetimes. Wildcarding SHOULD be supported for this ACL also. 2919 13. Security Considerations 2921 HIP is designed to provide secure authentication of hosts and to 2922 provide a fast key exchange for IPsec ESP. HIP also attempts to 2923 limit the exposure of the host to various denial-of-service and man- 2924 in-the-middle attacks. In so doing, HIP itself is subject to its own 2925 DoS and MitM attacks that potentially could be more damaging to a 2926 host's ability to conduct business as usual. 2928 HIP enabled ESP is IP address independent. This might seem to make 2929 it easier for an attacker, but ESP with replay protection is already 2930 as well protected as possible, and the removal of the IP address as a 2931 check should not increase the exposure of ESP to DoS attacks. 2932 Furthermore, this is in line with the forthcoming revision of ESP. 2934 Denial-of-service attacks take advantage of the cost of start of 2935 state for a protocol on the Responder compared to the 'cheapness' on 2936 the Initiator. HIP makes no attempt to increase the cost of the 2937 start of state on the Initiator, but makes an effort to reduce the 2938 cost to the Responder. This is done by having the Responder start 2939 the 3-way cookie exchange instead of the Initiator, making the HIP 2940 protocol 4 packets long. In doing this, packet 2 becomes a 'stock' 2941 packet that the Responder MAY use many times. The duration of use is 2942 a paranoia versus throughput concern. Using the same Diffie- Hellman 2943 values and random puzzle I has some risk. This risk needs to be 2944 balanced against a potential storm of HIP I1 packets. 2946 This shifting of the start of state cost to the Initiator in creating 2947 the I2 HIP packet, presents another DoS attack. The attacker spoofs 2948 the I1 HIP packet and the Responder sends out the R1 HIP packet. 2949 This could conceivably tie up the 'initiator' with evaluating the R1 2950 HIP packet, and creating the I2 HIP packet. The defense against this 2951 attack is to simply ignore any R1 packet where a corresponding I1 or 2952 ESP data was not sent. 2954 A second form of DoS attack arrives in the I2 HIP packet. Once the 2955 attacking Initiator has solved the cookie challenge, it can send 2956 packets with spoofed IP source addresses with either invalid 2957 encrypted HIP payload component or a bad HIP signature. This would 2958 take resources in the Responder's part to reach the point to discover 2959 that the I2 packet cannot be completely processed. The defense 2960 against this attack is after N bad I2 packets, the Responder would 2961 discard any I2s that contain the given Initiator HIT. Thus will shut 2962 down the attack. The attacker would have to request another R1 and 2963 use that to launch a new attack. The Responder could up the value of 2964 K while under attack. On the downside, valid I2s might get dropped 2965 too. 2967 A third form of DoS attack is emulating the restart of state after a 2968 reboot of one of the partners. To protect from such an attack, a 2969 system Birthday is included in the R1 and I2 packets to prove loss of 2970 state to a peer. The inclusion of the Birthday creates a very 2971 deterministic process for state restart. Any other action is a DoS 2972 attack. 2974 A fourth form of DoS attack is emulating the end of state. HIP has 2975 no end of state packet. It relies on a local policy timer to end 2976 state. 2978 Man-in-the-middle attacks are difficult to defend against, without 2979 third-party authentication. A skillful MitM could easily handle all 2980 parts of HIP; but HIP indirectly provides the following protection 2981 from a MitM attack. If the Responder's HI is retrieved from a signed 2982 DNS zone, a certificate, or through some other secure means, the 2983 Initiator can use this to validate the R1 HIP packet. 2985 Likewise, if the Initiator's HI is in a secure DNS zone, a trusted 2986 certificate, or otherwise securely available, the Responder can 2987 retrieve it after it gets the I2 HIP packet and validate that. 2988 However, since an Initiator may choose to use an anonymous HI, it 2989 knowingly risks a MitM attack. The Responder may choose not to 2990 accept a HIP exchange with an anonymous Initiator. 2992 Since not all hosts will ever support HIP, ICMP 'Destination Protocol 2993 Unreachable' are to be expected and present a DoS attack. Against an 2994 Initiator, the attack would look like the Responder does not support 2995 HIP, but shortly after receiving the ICMP message, the Initiator 2996 would receive a valid R1 HIP packet. Thus to protect from this 2997 attack, an Initiator should not react to an ICMP message until a 2998 reasonable delta time to get the real Responder's R1 HIP packet. A 2999 similar attack against the Responder is more involved. First an ICMP 3000 message is expected if the I1 was a DoS attack and the real owner of 3001 the spoofed IP address does not support HIP. The Responder SHOULD 3002 NOT act on this ICMP message to remove the minimal state from the R1 3003 HIP packet (if it has one), but wait for either a valid I2 HIP packet 3004 or the natural timeout of the R1 HIP packet. This is to allow for a 3005 sophisticated attacker that is trying to break up the HIP exchange. 3006 Likewise, the Initiator should ignore any ICMP message while waiting 3007 for an R2 HIP packet, deleting state only after a natural timeout. 3009 14. IANA Considerations 3011 IANA has assigned IP Protocol number TBD to HIP. 3013 15. Acknowledgments 3015 The drive to create HIP came to being after attending the MALLOC 3016 meeting at IETF 43. Baiju Patel and Hilarie Orman really gave the 3017 original author, Bob Moskowitz, the assist to get HIP beyond 5 3018 paragraphs of ideas. It has matured considerably since the early 3019 drafts thanks to extensive input from IETFers. Most importantly, its 3020 design goals are articulated and are different from other efforts in 3021 this direction. Particular mention goes to the members of the 3022 NameSpace Research Group of the IRTF. Noel Chiappa provided the 3023 framework for LSIs and Keith Moore the impetus to provide 3024 resolvability. Steve Deering provided encouragement to keep working, 3025 as a solid proposal can act as a proof of ideas for a research group. 3027 Many others contributed; extensive security tips were provided by 3028 Steve Bellovin. Rob Austein kept the DNS parts on track. Paul 3029 Kocher taught Bob Moskowitz how to make the cookie exchange expensive 3030 for the Initiator to respond, but easy for the Responder to validate. 3031 Bill Sommerfeld supplied the Birthday concept to simplify reboot 3032 management. Rodney Thayer and Hugh Daniels provide extensive 3033 feedback. In the early times of this draft, John Gilmore kept Bob 3034 Moskowitz challenged to provide something of value. 3036 During the later stages of this document, when the editing baton was 3037 transfered to Pekka Nikander, the input from the early implementors 3038 were invaluable. Without having actual implementations, this 3039 document would not be on the level it is now. 3041 In the usual IETF fashion, a large number of people have contributed 3042 to the actual text or ideas. The list of these people include Jeff 3043 Ahrenholz, Francis Dupont, Derek Fawcus, George Gross, Andrew 3044 McGregor, Julien Laganier, Miika Komu, Mika Kousa, Jan Melen, Henrik 3045 Petander, Michael Richardson, Tim Shepard, and Jukka Ylitalo. Our 3046 apologies to anyone who's name is missing. 3048 Normative references 3050 [1] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 3051 1980. 3053 [2] Mockapetris, P., "Domain names - implementation and 3054 specification", STD 13, RFC 1035, November 1987. 3056 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 3057 Levels", BCP 14, RFC 2119, March 1997. 3059 [4] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP 3060 and AH", RFC 2404, November 1998. 3062 [5] Maughan, D., Schneider, M. and M. Schertler, "Internet Security 3063 Association and Key Management Protocol (ISAKMP)", RFC 2408, 3064 November 1998. 3066 [6] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, 3067 November 1998. 3069 [7] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", 3070 RFC 2451, November 1998. 3072 [8] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 3073 Specification", RFC 2460, December 1998. 3075 [9] Eastlake, D., "Domain Name System Security Extensions", RFC 3076 2535, March 1999. 3078 [10] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System 3079 (DNS)", RFC 2536, March 1999. 3081 [11] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 3082 Public Key Infrastructure Certificate and Certificate 3083 Revocation List (CRL) Profile", RFC 3280, April 2002. 3085 [12] Draves, R., "Default Address Selection for Internet Protocol 3086 version 6 (IPv6)", RFC 3484, February 2003. 3088 [13] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 3089 Addressing Architecture", RFC 3513, April 2003. 3091 [14] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 3092 Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3093 3526, May 2003. 3095 [15] Kent, S., "IP Encapsulating Security Payload (ESP)", 3096 draft-ietf-ipsec-esp-v3-05 (work in progress), April 2003. 3098 [16] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 3099 draft-ietf-ipsec-ikev2-07 (work in progress), April 2003. 3101 [17] Moskowitz, R., "Host Identity Protocol Architecture", 3102 draft-moskowitz-hip-arch-03 (work in progress), May 2003. 3104 [18] NIST, "FIPS PUB 180-1: Secure Hash Standard", April 1995. 3106 Informative references 3108 [19] Bellovin, S. and W. Aiello, "Just Fast Keying (JFK)", 3109 draft-ietf-ipsec-jfk-04 (work in progress), July 2002. 3111 [20] Moskowitz, R. and P. Nikander, "Using Domain Name System (DNS) 3112 with Host Identity Protocol (HIP)", draft-nikander-hip-dns-00 3113 (to be issued) (work in progress), June 2003. 3115 [21] Nikander, P., "SPI assisted NAT traversal (SPINAT) with Host 3116 Identity Protocol (HIP)", draft-nikander-hip-nat-00 (to be 3117 issued) (work in progress), June 2003. 3119 [22] Crosby, SA. and DS. Wallach, "Denial of Service via Algorithmic 3120 Complexity Attacks", in Proceedings of Usenix Security 3121 Symposium 2003, Washington, DC., August 2003. 3123 Authors' Addresses 3125 Robert Moskowitz 3126 ICSAlabs, a Division of TruSecure Corporation 3127 1000 Bent Creek Blvd, Suite 200 3128 Mechanicsburg, PA 3129 USA 3131 EMail: rgm@icsalabs.com 3133 Pekka Nikander 3134 Ericsson Research Nomadiclab 3136 JORVAS FIN-02420 3137 FINLAND 3139 Phone: +358 9 299 1 3140 EMail: pekka.nikander@nomadiclab.com 3142 Petri Jokela 3143 Ericsson Research Nomadiclab 3145 JORVAS FIN-02420 3146 FINLAND 3148 Phone: +358 9 299 1 3149 EMail: petri.jokela@nomadiclab.com 3150 Thomas R. Henderson 3151 The Boeing Company 3152 P.O. Box 3707 3153 Seattle, WA 3154 USA 3156 EMail: thomas.r.henderson@boeing.com 3158 Appendix A. Backwards compatibility API issues 3160 Tom Henderson has several times expressed the thought that that the 3161 LSI could be completely local and does not need to be exchanged. 3162 Applications could continue to use IP addresses in socket calls, and 3163 kernel does whatever NATting (including application NATting) is 3164 required. It was pointed out that this approach was going to be 3165 prone to some kinds of data flows escaping the HIP protection, unless 3166 the local housekeeping in an implementation was especially good. 3167 Example: FTP opens control connection to IP address. One or both 3168 parties move. FTP later opens data connection to the old IP address. 3169 Kernel must identify that the application really means to connect to 3170 the host that was previously at that IP address -- but obviously if 3171 the old address is reused by another host, this becomes difficult. 3173 Related to this, the discussion also opened up the question of DNS 3174 resolution. Should the HIT/LSI be returned to applications as a 3175 (spoofed) address in the resolution process, allowing apps to use the 3176 socket API with HIT or LSI values instead of an IP address? While 3177 this seems to be the original intention of LSIs, there are a couple 3178 of difficulties especially in the IPv4 case: 3180 How does kernel know whether value being passed in a socket call 3181 is an IP address or an LSI? The fact that a name resolver library 3182 gave an application an LSI is no guarantee that the application 3183 will use that information in its socket call. It may also have 3184 cached some IP address from before or received an IP address as 3185 side information. This difficulty is now relieved as the LSIs are 3186 constrained to the well-known private subnet space. 3188 Handing an LSI may confuse legacy applications that assume that 3189 what is being passed to them is an IP address. Good examples of 3190 this are diagnostic tools such as dig and ping. The conclusion is 3191 that HIP should not be used with diagnostic applications. 3193 What does kernel do with an LSI that it cannot map to an address 3194 based on information that it has locally cached? 3196 It seems that some modification to the resolver library (to 3197 explicitly convey HIP information rather than spoofing IP addresses), 3198 as well as modifications to socket API to explicitly let the kernel 3199 know that the application is HIP aware, are the cleanest long-term 3200 solution, but what to do about legacy applications?? -- still 3201 partially an open issue. The HUT team has been considering these 3202 problems. 3204 In summary, there seems to be two schools of thought, and their 3205 approaches can be summarized as follows: 3207 1. Have the resolver return an LSI in place of an actual IP address, 3208 and have applications use the LSI instead of the IP address in 3209 socket calls. By making LSI fall into an unassigned IP address 3210 space, the kernel can distinguish between calls made with an LSI 3211 and calls made with an IP address. This is the approach 3212 currently recommended in this specification. 3214 Now some complications with this approach are the following: 3216 1. One probably does not want to invoke a HIP exchange just 3217 because an application did a DNS lookup on a hostname; 3218 applications use resolver for other reasons than just prior 3219 to initiating a flow. Since LSIs are a subset of the HIT 3220 bits, we could avoid having to do the HIP exchange to find 3221 the LSIs, if it weren't for the possibility of collision. 3222 So, this approach seems to be pointing us towards doing HIP 3223 exchanges prior to the application's initial socket calls. 3224 Note that this would also break the opportunity to piggyback 3225 data on the I2/R2. 3227 2. Some applications might actually want IP addresses 3228 explicitly, such as diagnostic applications. 3230 3. Some applications likely will obtain addresses out-of-band, 3231 so even in this scenario, the kernel may be faced with a case 3232 where it would like to use HIP from a policy standpoint, but 3233 the invoking application called connect() with an IP address. 3235 One way around might be to have a separate resolver call that 3236 returns an LSI, or enhance the data structure returned by 3237 resolver to include LSI in addition to IP address, but this then 3238 throws the burden on applications to be HIP-aware. 3240 2. Have the LSI be kept in kernel land, with the kernel doing the 3241 right housekeeping. Unless the application is HIP aware and can 3242 explicitly signal that it wants to use HIP (such as with a 3243 setsockopt() flag), the use of HIP is coordinated by a policy 3244 table that temporarily traps packets going to particular IP 3245 addresses until a HIP exchange completes and the security 3246 association is set up. In this case, the kernel does the right 3247 checksum munging and handles readdressing, in a manner 3248 transparent to the applications, which just think that they have 3249 connected to an IP address as before. This essentially means 3250 that the is responsible for managing the association between IP 3251 address (as perceived by an application) and actual destination 3252 identity. This is similar to the way that opportunistic IPsec 3253 works today. 3255 This solution has the following drawbacks: 3257 1. One is architecturally forced back into the mode of using IP 3258 addresses to indirectly identify hosts, at least initially. 3259 The IP stack has to maintain tables that say things like "if 3260 a socket call comes in for address X, do a HIP exchange to 3261 that address." (note that this may require an opportunistic 3262 exchange) This constrains the kinds of mobility that the 3263 system can handle. 3265 2. One can construct scenarios for which the kernel and 3266 applications are out of sync with respect to IP addresses, 3267 and flows may escape their intended IPsec envelope. Example: 3268 I open FTP control connection to address X. That host moves 3269 to address Y. Some other host takes up address X. I next 3270 receive a connect() to address X. Which host does that 3271 process want to connect to? 3273 Appendix B. Probabilities of HIT collisions 3275 The birthday paradox sets a bound for the expectation of collisions. 3276 It is based on the square root of the number of values. A 64-bit 3277 hash, then, would put the chances of a collision at 50-50 with 2^32 3278 hosts (4 billion). A 1% chance of collision would occur in a 3279 population of 640M and a .001% collision chance in a 20M population. 3280 A 128 bit hash will have the same .001% collision chance in a 9x10^16 3281 population. 3283 Appendix C. Probabilities in the cookie calculation 3285 A question: Is it guaranteed that the Initiator is able to solve the 3286 puzzle in this way when the K value is large? 3288 Answer: No, it is not guaranteed. But it is not guaranteed even in 3289 the old mechanism, since the Initiator may start far away from J and 3290 arrive to J after far too many steps. If we wanted to make sure that 3291 the Initiator finds a value, we would need to give some hint of a 3292 suitable J, and I don't think we want to do that. 3294 In general, if we model the hash function with a random function, the 3295 probability that one iteration gives are result with K zero bits is 3296 2^-K. Thus, the probability that one iteration does *not* give K 3297 zero bits is (1 - 2^-K). Consequently, the probability that 2^K 3298 iterations does not give K zero bits is (1 - 2^-K)^(2^K). 3300 Since my calculus starts to be rusty, I made a small experiment and 3301 found out that 3303 lim (1 - 2^-k)^(2^k) = 0.36788 3304 k->inf 3306 lim (1 - 2^-k)^(2^(k+1)) = 0.13534 3307 k->inf 3309 lim (1 - 2^-k)^(2^(k+2)) = 0.01832 3310 k->inf 3312 lim (1 - 2^-k)^(2^(k+3)) = 0.000335 3313 k->inf 3315 Thus, if hash functions were random functions, we would need about 3316 2^(K+3) iterations to make sure that the probability of a failure is 3317 less than 1% (actually less than 0.04%). Now, since my perhaps 3318 flawed understanding of hash functions is that they are "flatter" 3319 than random functions, 2^(K+3) is probably an overkill. OTOH, the 3320 currently suggested 2^K is clearly too little. The draft has been 3321 changed to read 2^(K+2). 3323 Appendix D. Using responder cookies 3325 As mentioned in Section 4.1.1, the Responder may delay state creation 3326 and still reject most spoofed I2s by using a number of pre-calculated 3327 R1s and a local selection function. This appendix defines one 3328 possible implementation in detail. The purpose of this appendix is 3329 to give the implementors an idea on how to implement the mechanism. 3330 The method described in this appendix SHOULD NOT be used in any real 3331 implementation. If the implementation is based on this appendix, it 3332 SHOULD contain some local modification that makes an attacker's task 3333 harder. 3335 The basic idea is to create a cheap, varying local mapping function 3336 f: 3338 f( IP-I, IP-R, HIT-I, HIT-R ) -> cookie-index 3340 That is, given the Initiator's and Responder's IP addresses and 3341 HITs, the function returns an index to a cookie. When processing an 3342 I1, the cookie is embedded in an pre-computed R1, and the Responder 3343 simply sends that particular R1 to the Initiator. When processing an 3344 I2, the cookie may still be embedded in the R1, or the R1 may be 3345 deprecated (and replaced with a new one), but the cookie is still 3346 there. If the received cookie does not match with the R1 or saved 3347 cookie, the I2 is simply dropped. That prevents the Initiator from 3348 generating spoofed I2s with a probability that depends on the number 3349 of pre-computed R1s. 3351 As a concrete example, let us assume that the Responder has an array 3352 of R1s. Each slot in the array contains a timestamp, an R1, and an 3353 old cookie that was sent in the previous R1 that occupied that 3354 particular slot. The Responder replaces one R1 in the array every 3355 few minutes, thereby replacing all the R1s gradually. 3357 To create a varying mapping function, the Responder generates a 3358 random number every few minutes. The octets in the IP addresses and 3359 HITs are XORed together, and finally the result is XORed with the 3360 random number. Using pseudo-code, the function looks like the 3361 following. 3363 Pre-computation: 3364 r1 := random number 3366 Index computation: 3367 index := r1 XOR hit_r[0] XOR hit_r[1] XOR ... XOR hit_r[15] 3368 index := index XOR hit_i[0] XOR hit_i[1] XOR ... XOR hit_i[15] 3369 index := index XOR ip_r[0] XOR ip_r[1] XOR ... XOR ip_r[15] 3370 index := index XOR ip_i[0] XOR ip_i[1] XOR ... XOR ip_i[15] 3372 The index gives the slot used in the array. 3374 It is possible that an Initiator receives an I1, and while it is 3375 computing I2, the Responder deprecates an R1 and/or chooses a new 3376 random number for the mapping function. Therefore the Responder must 3377 remember the cookies used in deprecated R1s and the previous random 3378 number. 3380 To check an received I2, the Responder can use a simple algorithm, 3381 expressed in pseudo-code as follows. 3383 If I2.hit_r does not match my_hits, drop the packet. 3385 index := compute_index(current_random_number, I2) 3386 If current_cookie[index] == I2.cookie, go to cookie check. 3387 If previous_cookie[index] == I2.cookie, go to cookie check. 3389 index := compute_index(previous_random_number, I2) 3390 If current_cookie[index] == I2.cookie, go to cookie check. 3391 If previous_cookie[index] == I2.cookie, go to cookie check. 3393 Drop packet. 3395 cookie_check: 3396 V := Ltrunc( SHA-1( I2.I, I2.hit_i, I2.hit_r, I2.J ), K ) 3397 if V != 0, drop the packet. 3399 Whenever the Responder receives an I2 that fails on the index check, 3400 it can simply drop the packet on the floor and forget about it. New 3401 I2s with the same or other spoofed parameters will get dropped with a 3402 reasonable probability and minimal effort. 3404 If a Responder receives an I2 that passes the index check but fails 3405 on the puzzle check, it should create a state indicating this. After 3406 two or three failures the Responder should cease checking the puzzle 3407 but drop the packets directly. This saves the Responder from the 3408 SHA-1 calculations. Such block should not last long, however, or 3409 there would be a danger that a legitimate Initiator could be blocked 3410 from getting connections. 3412 A key for the success of the defined scheme is that the mapping 3413 function must be considerably cheaper than computing SHA-1. It also 3414 must detect any changes in the IP addresses, and preferably most 3415 changes in the HITs. Checking the HITs is not that essential, 3416 though, since HITs are included in the cookie computation, too. 3418 The effectivity of the method can be varied by varying the size of 3419 the array containing pre-computed R1s. If the array is large, the 3420 probability that an I2 with a spoofed IP address or HIT happens to 3421 map to the same slot is fairly slow. However, a large array means 3422 that each R1 has a fairly long life time, thereby allowing an 3423 attacker to utilize one solved puzzle for a longer time. 3425 Appendix E. Running HIP over IPv4 UDP 3427 In the IPv4 world, with the deployed NAT devices, it may make sense 3428 to run HIP over UDP. When running HIP over UDP, the following packet 3429 structure is used. The structure is followed by the HITs, as usual. 3430 Both the Source and Destination port MUST be 272. 3432 0 1 2 3 3433 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 3434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ 3435 | Source port | Destination port | \ 3436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >UDP 3437 | Length | Checksum | / 3438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+< 3439 | HIP Controls | HIP pkt Type | Ver. | Res. | >HIP 3440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ 3442 It is currently undefined how the actual data transfer, using ESP, is 3443 handled. Plain ESP may not go through all NAT devices. 3445 It is currently FORBIDDEN to use this packet format with IPv6. 3447 Appendix F. Example checksums for HIP packets 3449 The HIP checksum for HIP packets is specified in Section 6.1.2. 3450 Checksums for TCP and UDP packets running over HIP-enabled security 3451 associations are specified in Section 3.5. The examples below use IP 3452 addresses of 192.168.0.1 and 192.168.0.2 (and their respective 3453 IPv4-compatible IPv6 formats), and type 1 HITs with the first two 3454 bits "01" followed by 124 zeroes followed by a decimal 1 or 2, 3455 respectively. 3457 F.1 IPv6 HIP example (I1) 3459 Source Address: ::c0a8:0001 3460 Destination Address: ::c0a8:0002 3461 Upper-Layer Packet Length: 40 0x28 3462 Next Header: 99 0x63 3463 Payload Protocol: 59 0x3b 3464 Header Length: 4 0x04 3465 Packet Type: 1 0x01 3466 Version: 1 0x1 3467 Reserved: 0 0x0 3468 Control: 0 0x0000 3469 Checksum: 49672 0xc208 3470 Sender's HIT: 4000::0001 3471 Receiver's HIT: 4000::0002 3473 F.2 IPv4 HIP packet (I1) 3475 The IPv4 checksum value for the same example I1 packet is the same as 3476 the IPv6 checksum (since the checksums due to the IPv4 and IPv6 3477 pseudo-header components are the same). 3479 F.3 TCP segment 3481 Regardless of whether IPv6 or IPv4 is used, the TCP and UDP sockets 3482 use the IPv6 pseudo-header format [8], with the HITs used in place of 3483 the IPv6 addresses. 3485 Sender's HIT: 4000::0001 3486 Receiver's HIT: 4000::0002 3487 Upper-Layer Packet Length: 20 0x14 3488 Next Header: 6 0x06 3489 Source port: 32769 0x8001 3490 Destination port: 22 0x0016 3491 Sequence number: 1 0x00000001 3492 Acknowledgment number: 0 0x00000000 3493 Header length: 20 0x14 3494 Flags: SYN 0x02 3495 Window size: 5840 0x16d0 3496 Checksum: 54519 0xd4f7 3497 Urgent pointer: 0 0x0000 3499 Intellectual Property Statement 3501 The IETF takes no position regarding the validity or scope of any 3502 intellectual property or other rights that might be claimed to 3503 pertain to the implementation or use of the technology described in 3504 this document or the extent to which any license under such rights 3505 might or might not be available; neither does it represent that it 3506 has made any effort to identify any such rights. Information on the 3507 IETF's procedures with respect to rights in standards-track and 3508 standards-related documentation can be found in BCP-11. Copies of 3509 claims of rights made available for publication and any assurances of 3510 licenses to be made available, or the result of an attempt made to 3511 obtain a general license or permission for the use of such 3512 proprietary rights by implementors or users of this specification can 3513 be obtained from the IETF Secretariat. 3515 The IETF invites any interested party to bring to its attention any 3516 copyrights, patents or patent applications, or other proprietary 3517 rights which may cover technology that may be required to practice 3518 this standard. Please address the information to the IETF Executive 3519 Director. 3521 Full Copyright Statement 3523 Copyright (C) The Internet Society (2004). All Rights Reserved. 3525 This document and translations of it may be copied and furnished to 3526 others, and derivative works that comment on or otherwise explain it 3527 or assist in its implementation may be prepared, copied, published 3528 and distributed, in whole or in part, without restriction of any 3529 kind, provided that the above copyright notice and this paragraph are 3530 included on all such copies and derivative works. However, this 3531 document itself may not be modified in any way, such as by removing 3532 the copyright notice or references to the Internet Society or other 3533 Internet organizations, except as needed for the purpose of 3534 developing Internet standards in which case the procedures for 3535 copyrights defined in the Internet Standards process must be 3536 followed, or as required to translate it into languages other than 3537 English. 3539 The limited permissions granted above are perpetual and will not be 3540 revoked by the Internet Society or its successors or assignees. 3542 This document and the information contained herein is provided on an 3543 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 3544 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 3545 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 3546 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 3547 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3549 Acknowledgment 3551 Funding for the RFC Editor function is currently provided by the 3552 Internet Society.