idnits 2.17.1 draft-moskowitz-hip-07.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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 11 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1035 has weird spacing: '... Target calcu...' == Line 1162 has weird spacing: '...dentity actua...' == Line 1192 has weird spacing: '... length len...' == Line 1193 has weird spacing: '...dentity actua...' == Line 1217 has weird spacing: '...t count total...' == (4 more instances...) == 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. 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. A spoofed I1 can result in an R1 attack on a system. An R1 sender MUST have a mechanism to rate limit R1s to an address. -- 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 (June 19, 2003) is 7611 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 1170 -- Looks like a reference, but probably isn't: 'RFC3110' on line 1171 == Missing Reference: '0' is mentioned on line 2282, but not defined == Unused Reference: '6' is defined on line 2059, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 2082, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2373 (ref. '3') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2406 (ref. '5') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2408 (ref. '6') (Obsoleted by RFC 4306) ** Downref: Normative reference to an Informational RFC: RFC 2412 (ref. '7') ** Obsolete normative reference: RFC 2459 (ref. '9') (Obsoleted by RFC 3280) ** Obsolete normative reference: RFC 2460 (ref. '10') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2535 (ref. '11') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 2671 (ref. '13') (Obsoleted by RFC 6891) == Outdated reference: A later version (-17) exists of draft-ietf-ipsec-ikev2-08 -- Possible downref: Normative reference to a draft: ref. '16' -- Possible downref: Non-RFC (?) normative reference: ref. '17' == Outdated reference: A later version (-06) exists of draft-moskowitz-hip-arch-03 -- Possible downref: Normative reference to a draft: ref. '18' -- Possible downref: Normative reference to a draft: ref. '19' -- Unexpected draft version: The latest known version of draft-moskowitz-hip-impl is -01, but you're referring to -02. -- Possible downref: Normative reference to a draft: ref. '20' -- Possible downref: Non-RFC (?) normative reference: ref. '21' Summary: 11 errors (**), 0 flaws (~~), 15 warnings (==), 11 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: December 18, 2003 Corporation 5 P. Nikander 6 P. Jokela 7 Ericsson Research Nomadic Lab 8 June 19, 2003 10 Host Identity Protocol 11 draft-moskowitz-hip-07 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at http:// 28 www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on December 18, 2003. 35 Copyright Notice 37 Copyright (C) The Internet Society (2003). All Rights Reserved. 39 Abstract 41 This memo specifies the details of the Host Identity Protocol (HIP). 42 The overall description of protocol and the underlying architectural 43 thinking is available in the separate HIP architecture specification. 44 The Host Identity Protocol is used to establish a rapid 45 authentication between two hosts and to provide continuity of 46 communications between those hosts independent of the networking 47 layer. 49 The various forms of the Host Identity (HI), Host Identity Tag (HIT), 50 and Local Scope Identifier (LSI), are covered in detail. It is 51 described how they are used to support authentication and the 52 establishment of keying material, which is then used by IPsec 53 Encapsulated Security payload (ESP) to establish a two-way secured 54 communication channel between the hosts. The basic state machine for 55 HIP provides a HIP compliant host with the resiliency to avoid many 56 denial-of-service (DoS) attacks. The basic HIP exchange for two 57 public hosts shows the actual packet flow. Other HIP exchanges, 58 including those that work across NATs are covered elsewhere. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 63 1.1 A new name space and identifiers . . . . . . . . . . . . . 4 64 1.2 The HIP protocol . . . . . . . . . . . . . . . . . . . . . 4 65 2. Conventions used in this document . . . . . . . . . . . . 6 66 3. Host Identifiers . . . . . . . . . . . . . . . . . . . . . 7 67 3.1 Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 7 68 3.1.1 Generating a HIT from a HI . . . . . . . . . . . . . . . . 7 69 3.2 Local Scope Identity (LSI) . . . . . . . . . . . . . . . . 8 70 3.3 Security Parameter Index (SPI) . . . . . . . . . . . . . . 9 71 3.4 Difference between an LSI and the SPI . . . . . . . . . . 10 72 3.5 TCP and UDP pseudoheader computation . . . . . . . . . . . 10 73 4. The Host Identity Protocol . . . . . . . . . . . . . . . . 11 74 4.1 Base HIP exchange . . . . . . . . . . . . . . . . . . . . 11 75 4.1.1 HIP Cookie Mechanism . . . . . . . . . . . . . . . . . . . 11 76 4.1.2 Authenticated Diffie-Hellman protocol . . . . . . . . . . 14 77 4.1.3 HIP Birthday . . . . . . . . . . . . . . . . . . . . . . . 14 78 4.2 Sending data on HIP packets . . . . . . . . . . . . . . . 14 79 4.3 Distributing certificates . . . . . . . . . . . . . . . . 14 80 5. The Host Identity Protocol packet flow and state machine . 16 81 5.1 HIP Scenarios . . . . . . . . . . . . . . . . . . . . . . 16 82 5.2 Refusing a HIP exchange . . . . . . . . . . . . . . . . . 16 83 5.3 Reboot and SA timeout restart of HIP . . . . . . . . . . . 17 84 5.4 HIP State Machine . . . . . . . . . . . . . . . . . . . . 18 85 5.4.1 HIP States . . . . . . . . . . . . . . . . . . . . . . . . 18 86 5.4.2 HIP State Processes . . . . . . . . . . . . . . . . . . . 18 87 5.4.3 Simplified HIP State Diagram . . . . . . . . . . . . . . . 19 88 6. Packet formats . . . . . . . . . . . . . . . . . . . . . . 21 89 6.1 Payload format . . . . . . . . . . . . . . . . . . . . . . 21 90 6.1.1 HIP Controls . . . . . . . . . . . . . . . . . . . . . . . 22 91 6.1.2 CRC . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 92 6.2 HIP parameters . . . . . . . . . . . . . . . . . . . . . . 23 93 6.3 TLV format . . . . . . . . . . . . . . . . . . . . . . . . 24 94 6.3.1 SPI_LSI . . . . . . . . . . . . . . . . . . . . . . . . . 24 95 6.3.2 BIRTHDAY_COOKIE . . . . . . . . . . . . . . . . . . . . . 25 96 6.3.3 DIFFIE_HELLMAN . . . . . . . . . . . . . . . . . . . . . . 25 97 6.3.4 HIP_TRANSFORM . . . . . . . . . . . . . . . . . . . . . . 26 98 6.3.5 ESP_TRANSFORM . . . . . . . . . . . . . . . . . . . . . . 27 99 6.3.6 HOST_ID . . . . . . . . . . . . . . . . . . . . . . . . . 28 100 6.3.7 HOST_ID_FQDN . . . . . . . . . . . . . . . . . . . . . . . 28 101 6.3.8 CERT . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 102 6.3.9 HIP_SIGNATURE . . . . . . . . . . . . . . . . . . . . . . 30 103 6.3.10 HIP_SIGNATURE_2 . . . . . . . . . . . . . . . . . . . . . 31 104 6.3.11 NES_INFO . . . . . . . . . . . . . . . . . . . . . . . . . 31 105 6.3.12 ENCRYPTED . . . . . . . . . . . . . . . . . . . . . . . . 32 106 7. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 33 107 7.1 I1 - the HIP Initiator packet . . . . . . . . . . . . . . 33 108 7.2 R1 - the HIP Responder packet . . . . . . . . . . . . . . 34 109 7.3 I2 - the HIP Second Initiator packet . . . . . . . . . . . 35 110 7.4 R2 - the HIP Second Responder packet . . . . . . . . . . . 36 111 7.5 NES - the HIP New SPI Packet . . . . . . . . . . . . . . . 36 112 7.6 BOS - the HIP Bootstrap Packet . . . . . . . . . . . . . . 37 113 7.7 CER - the HIP Certificate Packet . . . . . . . . . . . . . 38 114 7.8 PAYLOAD - the HIP Payload Packet . . . . . . . . . . . . . 38 115 8. Packet processing . . . . . . . . . . . . . . . . . . . . 40 116 8.1 R1 Management . . . . . . . . . . . . . . . . . . . . . . 40 117 8.2 Processing NES packets . . . . . . . . . . . . . . . . . . 40 118 9. HIP KEYMAT . . . . . . . . . . . . . . . . . . . . . . . . 42 119 10. HIP Fragmentation Support . . . . . . . . . . . . . . . . 44 120 11. ESP with HIP . . . . . . . . . . . . . . . . . . . . . . . 45 121 11.1 Security Association Management . . . . . . . . . . . . . 45 122 11.2 Security Parameters Index (SPI) . . . . . . . . . . . . . 45 123 11.3 Supported Transforms . . . . . . . . . . . . . . . . . . . 45 124 11.4 Sequence Number . . . . . . . . . . . . . . . . . . . . . 46 125 12. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . 47 126 13. Security Considerations . . . . . . . . . . . . . . . . . 48 127 14. IANA Considerations . . . . . . . . . . . . . . . . . . . 51 128 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 52 129 References . . . . . . . . . . . . . . . . . . . . . . . . 53 130 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 54 131 A. Backwards compatibility API issues . . . . . . . . . . . . 56 132 B. Probabilities of HIT collisions . . . . . . . . . . . . . 57 133 C. Probabilities in the cookie calculation . . . . . . . . . 58 134 D. Using responder cookies . . . . . . . . . . . . . . . . . 59 135 Intellectual Property and Copyright Statements . . . . . . 62 137 1. Introduction 139 The Host Identity Protocol (HIP) provides a rapid exchange of Host 140 Identities (HI) between two hosts. The exchange also establishes a 141 pair IPsec Security Associations (SA), to be used with IPsec 142 Encapsulated Security Payload (ESP) [5]. The HIP protocol is 143 designed to be resistant to Denial-of-Service (DoS) and 144 Man-in-the-middle (MitM) attacks, and when used to enable ESP, 145 provides DoS and MitM protection to upper layer protocols, such as 146 TCP and UDP. 148 1.1 A new name space and identifiers 150 The Host Identity Protocol introduces a new namespace, the Host 151 Identity. The affects of this change are explained in the companion 152 document, the HIP architecture [18] specification. 154 There are three representations of the Host Identity, the full Host 155 Identifier (HI), the Host Identity Tag (HIT), and the Local Scope 156 Identity (LSI). Three representations are used, as each meets a 157 different design goal of HIP, and none of them can be removed and 158 meet these goals. The HI represents directly the Identity, a public 159 key. Since there are different public key algorithms that can be 160 used with different key lengths, the HI is not good for using as the 161 HIP packet identifier, or as a index into the various operational 162 tables needed to support HIP. 164 A hash of the HI, the Host Identity Tag (HIT), thus becomes the 165 operational representation. It is 128 bits long. It is used in the 166 HIP payloads, and it is intended be used to index the corresponding 167 state in the end hosts. 169 In many environments, 128 bits is still considered large. For 170 example, currently used IPv4 based applications are constrained with 171 32 bit API fields. Thus, the third representation, the 32 bit LSI, 172 is needed. The LSI provides a compression of the HIT with only a 173 local scope so that it can be carried efficiently in any application 174 level packet and used in API calls. 176 1.2 The HIP protocol 178 The base HIP exchange consists of four packets. The four-packet 179 design helps to make HIP DoS resilient. The protocol exchanges 180 Diffie-Hellman keys in the 2nd and 3rd packets, and authenticates the 181 parties in the 3rd and 4th packets. Additionally, it starts the 182 cookie exchange in the 2nd packet, completing it with the 3rd packet. 184 The exchange uses the Diffie-Hellman exchange to hide the Host 185 Identity of the Initiator in packet 3. The Responder's Host Identity 186 is not protected. It should be noted, however, that both the 187 Initiator and the Responder HITs are transported as such (in 188 cleartext) in the packets, allowing an eavesdropper with a priori 189 knowledge about the parties to verify their identies. 191 Data packets start after the 4th packet. The 3rd and 4th HIP packets 192 may carry a data payload in the future. However, the details of this 193 are to be defined later as more implementation experience is gained. 195 Finally, HIP is designed as an end-to-end authentication and key 196 establishment protocol. It lacks much of the fine-grain policy 197 control found in IKE that allows IKE to support complex gateway 198 policies. Thus, HIP is not a complete replacement for IKE. 200 2. Conventions used in this document 202 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 203 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 204 document are to be interpreted as described in RFC2119 [2]. 206 3. Host Identifiers 208 The structure of the Host Identifier is the public key of an 209 asymmetric key pair. Correspondingly, the host itself is entity that 210 holds the private key from the key pair. See the HIP architecture 211 specification [18] for more details about the difference between an 212 identity and the corresponding identifier. 214 DSA is the MUST implement algorithm for all HIP implementations, 215 other algorithms MAY be supported. DSA was chosen as the default 216 algorithm due to its small signature size. 218 A Host Identity Tag (HIT) is used in protocols to represent the Host 219 Identity. Another representation of the Host Identity, the Local 220 Scope Identity (LSI), can also be used in protocols and APIs. LSI's 221 advantage over HIT is its size; its disadvantage is its local scope. 223 3.1 Host Identity Tag (HIT) 225 The Host Identity Tag is a 128 bit entity. There are two advantages 226 of using a hash over the actual Identity in protocols. Firstly, its 227 fix length makes for easier protocol coding and also better manages 228 the packet size cost of this technology. Secondly, it presents a 229 consistent format to the protocol whatever underlying identity 230 technology is used. 232 There are two types of HITs. HITs of the first type, called *type 1 233 HIT*, consist of an initial 2 bit prefix of 01, followed by 126 bits 234 of the SHA-1 hash of the public key. HITs of the second type consist 235 of a Host Assigning Authority (HAA) field, and only the last 64 bits 236 come from a SHA-1 hash of the Host Identity. This latter format for 237 HIT is recommended for 'well known' systems. It is possible to 238 support a resolution mechanism for these names in hierarchical 239 directories, like the DNS. Another use of HAA is in policy controls, 240 see Section 12. 242 This document fully specifies only type 1 HITs. HITs that consists 243 of the HAA field and the hash are specified in [19]. 245 Any conforming implementation MUST be able to deal with HITs that are 246 not type 1 ones. However, in that case the implementation must 247 explicitly learn and record the binding between the Host Identifier 248 and the HIT, and it may not be able form such HITs from Host 249 Identifiers. 251 3.1.1 Generating a HIT from a HI 253 The 126 or 64 hash bits in a HIT MUST be generated by taking the 254 least significant 126 or 64 bits of the SHA-1 [17] hash of the Host 255 Identifier as it is represented in the Host Identity field in a HIP 256 payload packet. 258 For Identities that are DSA public keys, the HIT is formed as 259 follows. 261 1. The DSA public key is encoded as defined in RFC2536 [12] Section 262 2, taking the fields T, Q, P, G, and Y, concatenated. Thus, the 263 length of the data to be hashed is 1 + 20 + 3 * 64 + 3 * 8 * T 264 octets long, where T is the size parameter as defined in RFC2536 265 [12]. The size parameter T, affecting the field lengths, MUST be 266 selected as the minimum value that is long enough to accomodate 267 P, G, and Y. The fields MUST be encoded in network byte order, 268 as defined in RFC2536 [12]. 270 2. A SHA-1 hash [17] is calculated over the encoded key. 272 3. The least signification 126 or 64 bits of the hash result are 273 used to create the HIT, as defined above. 275 The following pseudo-code illustrates the process. The symbol := 276 denotes assignment; the symbol += denotes appending. The 277 pseudo-function encode_in_network_byte_order takes two parameters, an 278 integer (bignum) and length, and returns the integer encoded into a 279 byte string of the given length. 281 buffer := encode_in_network_byte_order ( DSA.T , 1 ) 282 buffer += encode_in_network_byte_order ( DSA.Q , 20 ) 283 buffer += encode_in_network_byte_order ( DSA.P , 64 + 8 * T ) 284 buffer += encode_in_network_byte_order ( DSA.G , 64 + 8 * T ) 285 buffer += encode_in_network_byte_order ( DSA.Y , 64 + 8 * T ) 287 digest := SHA-1 ( buffer ) 289 hit_126 := concatenate ( 01 , low_order_bits ( digest, 126 ) ) 290 hit_haa := concatenate ( 10 , HAA, low_order_bits ( digest, 64 ) ) 292 3.2 Local Scope Identity (LSI) 294 LSIs are 32-bit localized representations of a Host Identity. The 295 purpose of an LSI is to facilitate using Host Identities in existing 296 IPv4 based protocols and APIs. The owner of the Host Identity does 297 not set its own LSI; each host selects its partner's 32 bit 298 representation for a Host Identity. 300 A *local LSI* is an LSI that a remote host has assigned to a host. 302 In some implementations, local LSIs may be assigned to some interface 303 as an IP address. A *remote LSI* is an LSI that the host has 304 assigned to represent some remote host (and that the remote host has 305 accepted). 307 The LSIs MUST be allocated from the 1.0.0.0/8 subnet. That makes it 308 easier to differentiate between LSIs and IPv4 addresses at the API 309 level. By default, the low order 24 bits SHOULD be equal with the 310 low order 24 bits of the corresponding HIT. That allows easier 311 mapping between LSIs and HITs, and makes the LSI assigned to a host 312 to be a fixed one. 314 It is possible that the HITs of two remote hosts have equal low order 315 24 bits. Since HITs are basically random, if a host is communicating 316 with 1000 other hosts, the risk of such collision is roughly 0.006%, 317 and for a host communicating with 10000 other hosts, the risk is 318 about 0.06%. However, given a population of 100000 hosts, each 319 communicating with 1000 other hosts, the probability that there was 320 no collisions at all is only about 2%. In other words, even though 321 collisions are fairly rare events for any given host, they will 322 happen, and the hosts MUST be able to cope with them. 324 If a host is forming a remote LSI for a HIT whose low order 24 bits 325 are equal with another already existing remote LSI, the host MUST 326 select another LSI to represent that host. It may also be hard for a 327 host to use a remote LSI that is equal to its own local LSI. Thus, 328 if the low order 24 bits of a remote HIT are equal to the low order 329 24 bits of a local LSI, the host MAY select a different LSI to 330 represent the remote host. In either case, the host SHOULD assing 331 the low order 24 bits of the LSI randomly. All hosts MUST be 332 prepared to handle local LSIs whose low order 24 bits do not match 333 with any of their own HITs. 335 If the LSI assigned by a peer to represent a host is unacceptable, 336 the host MAY terminate the HIP four-way handshake and start anew. 338 3.3 Security Parameter Index (SPI) 340 SPIs are used in ESP to find the right security association for 341 received packets. The ESP SPIs have added significance when used 342 with HIP; they are a compressed representation of the HIT in every 343 packet. Thus they MAY be used by intermediary systems in providing 344 services like address mapping. Note that since the SPI has 345 significance at the receiver, only the < DST, SPI >, where DST is a 346 destination IP address, uniquely identifies the receiver HIT at every 347 given point of time. The same SPI value may be used by several 348 hosts. The same < DST, SPI > may denote different hosts at different 349 points of time, depending on which host is currently reachable at the 350 DST. 352 Each host selects for itself the SPI it wants to see in packets 353 received from its peer. This allows it to select different SPIs for 354 different peers. The SPI selection SHOULD be random. A different 355 SPI SHOULD be used for each HIP exchange with a particular host; this 356 is to avoid a replay attack. Additionally, when a host rekeys, the 357 SPI MUST change. Furthermore, if a host changes over to use a 358 different IP address, it MAY change the SPI used. 360 One method for SPI creation that meets these criteria, would be to 361 concatenate the HIT with a 32 bit random or sequential number, hash 362 this (using SHA1), and then use the high order 32 bits as the SPI. 364 The selected SPI is communicated to the peer in the third (I2) and 365 fourth (R2) packets of the base HIP exchange. Changes in SPI are 366 signalled with NES packets. 368 3.4 Difference between an LSI and the SPI 370 There is a subtle difference between an LSI and a SPI. 372 The LSI is relatively longed lived. A system selects the LSI it 373 locally uses to represent its peer, it SHOULD reuse a previous LSI 374 for a HIT during a HIP exchange. This COULD be important in a 375 timeout recovery situation. The LSI ONLY appears in the 3rd and 4th 376 HIP packets (each system providing the other with its LSI). The LSI 377 is used anywhere in system processes where IP addresses have 378 traditionally have been used, like in TCBs and FTP port commands. 380 The SPI is short-lived. It changes with each HIP exchange and with a 381 HIP rekey and/or movement. A system notifies its peer of the SPI to 382 use in ESP packets sent to it. Since the SPI is in all but the first 383 two HIP packets, it can be used in intermediary systems to assist in 384 address remapping. 386 3.5 TCP and UDP pseudoheader computation 388 When computing TCP and UDP checksums on sockets bound to HITs or 389 LSIs, the IPv6 pseudo-header format [10] is used. Additionally, the 390 HITs MUST be used in the place of the IPv6 addresses in the IPv6 391 pseudoheader. Note that the pseudo-header for actual HIP payloads is 392 computed differently; see Section 6.1.2. 394 4. The Host Identity Protocol 396 The Host Identity Protocol is IP protocol TBD. The HIP payload could 397 be carried in every datagram. However, since HIP datagrams are 398 relatively large (at least 40 bytes), and ESP already has all of the 399 functionality to maintain and protect state, the HIP payload is 400 'compressed' into an ESP payload after the HIP exchange. Thus in 401 practice, HIP packets only occur in datagrams to establish or change 402 HIP state. 404 4.1 Base HIP exchange 406 The base HIP exchange serves to manage the establishment of state 407 between an Initiator and a Responder. The Initiator first sends a 408 trigger packet, I1, to the responder. The second packet, R1, starts 409 the actual exchange. In contains a puzzle, a cryptographic challenge 410 that the Initiator must solve before continuing the exchange. In its 411 reply, I2, the Initiator must display the solution. Without a 412 solution the I2 message is simply discarded. 414 The last three packets of the exchange, R1, I2, and R2, constitute a 415 standard authenticated Diffie-Hellman key exchange. The base 416 exchange is illustrated below. 418 Initiator Responder 420 I1: trigger exchange 421 --------------------------> 422 select pre-computed R1 423 R1: puzzle, D-H, sig 424 <------------------------- 425 check sig remain stateless 426 solve puzzle 427 I2: solution, D-H, sig 428 --------------------------> 429 compute D-H check cookie 430 check puzzle 431 check sig 432 R2: sig 433 <-------------------------- 434 check sig compute D-H 436 4.1.1 HIP Cookie Mechanism 438 The purpose of the HIP cookie mechanism is to protect the Responder 439 from a number of denial-of-service threats. It allows the Responder 440 to delay state creation until receiving I2. Furthermore, the puzzle 441 included in the cookie allows the Responder to use a fairly cheap 442 calculation to check that the Initiator is "sincere" in the sense 443 that it has churned CPU cycles in solving the puzzle. 445 The Cookie mechanism has been explicitly designed to give space for 446 various implementation options. It allows a responder implementation 447 to completely delay session specific state creation until a valid I2 448 is received. In such a case a validly formatted I2 can be rejected 449 earliest only once the responder has checked its validity by 450 computing one hash function. On the other hand, the design also 451 allows a responder implementation to keep state about received I1s, 452 and match the received I2s against the state, thereby allowing the 453 implementation to avoid the computational cost of the hash function. 454 The drawback of this latter approach is the requirement of creating 455 state. Finally, it also allows an implementation to use any 456 combination of the space-saving and computation-saving mechanism. 458 One possible way how a Responder can remain stateless but drop most 459 spoofed I2s is to base the selection of the cookie on some function 460 over the Initiator's identity. The idea is that the Responder has a 461 (perhaps varying) number of pre-calculated R1 packets, and it selects 462 one of these based on the information carried in I1. When the 463 Responder then later receives I2, it checks that the cookie in the I2 464 matches with the cookie send in the R1, thereby making it impractical 465 for the attacker to first exchange one I1/R1, and then generate a 466 large number of spoofed I2s that seemingly come from different IP 467 addresses or use different HITs. The method does not protect from an 468 attacker that uses fixed IP addresses and HITs, though. Against such 469 an attacker it is probably best to create a piece of local state, and 470 remember that the puzzle check has previously failed. See Appendix D 471 for one possible implementation. Note, however, that the 472 implementations MUST NOT use the exact implementation given in the 473 appendix, and SHOULD include sufficient randomness to the algorithm 474 so that algorithm complexity attacks become impossible [21]. 476 The Responder can set the difficulty for Initiator, based on its 477 concern of trust of the Initiator. The Responder SHOULD use 478 heuristics to determine when it is under a denial-of-service attack, 479 and set the difficulty value K appropriately. 481 The Responder starts the cookie exchange when it receives an I1. The 482 Responder supplies a random number I, and requires the Initiator to 483 find a number J. To select a proper J, the Initator must create the 484 concatenation of I, the HITs of the parties, and J, and take a SHA-1 485 hash over this concatenation. The lowest order K bits of the result 486 MUST be zeros. To accomplish this, the Initiator will have to 487 generate a number of Js until one produces the hash target. The 488 Initiator SHOULD give up after trying 2^(K+2) times, and start over 489 the exchange. (See Appendix C.) The Responder needs to re-create 490 the contactenation of I, the HITs, and the provided J, and compute 491 the hash once to prove that the Initiator did its assigned task. 493 To prevent pre-computation attacks, the Responder MUST select I in 494 such a way that the Inititiator cannot guess it. Furthermore, the 495 construction MUST allow the Responder to verify that the value were 496 indeed selected by it and not by the Initiator. See Appendix D for 497 an example on how to implement this. 499 It is RECOMMENDED that the Responder generates a new cookie and a new 500 R1 once every few minutes. Furthermore, it is RECOMMENDED that the 501 responder remembers an old cookie at least 60 seconds after it has 502 been deprecated. These time values allow a slower Initiator to solve 503 the cookie puzzle while limiting the usability that an old, solved 504 cookie has to an attacker. 506 In R1, the values I and K are sent in network byte order. Similarily, 507 in I2 the values I and J are sent in network byte order. The SHA-1 508 hash is created by concatenating, in network byte order, the 509 following data, in the following order: 511 64-bit random value I, in network byte order, as appearing in R1 512 and I2. 514 128-bit Initiator HIT, in network byte order, as appearing in the 515 HIP Payload in R1 and I2. 517 128-bit Responder HIT, in network byte order, as appearing in the 518 HIP Payload in R1 and I2. 520 64-bit random value J, in network byte order, as appearing in I2. 522 In order to be a valid response cookie, the K low-order bits of the 523 resulting SHA-1 digest must be zero. 525 Notes: 527 The length of the data to be hashed is 48 bytes. 529 All the data in the hash input MUST be in network byte order. 531 The order of the Initiator and Responder HITs are different in the 532 R1 and I2 packets, See Section 6.1. Care must be taken to copy the 533 values in right order to the hash input. 535 Precomputation by the Responder Sets up the challenge difficulty K. 537 Generates a random number I. 538 Creates a signed R1 and caches it. 540 Responder Sends I and K in a HIP Cookie in an R1. 542 Saves I and K for a Delta time. 544 Initiator Generates repeated attempts to solve the challenge until a 545 matching J is found: 547 Ltrunc( SHA-1( I | HIT-I | HIT-R | J ), K ) == 0 548 Send I and J in HIP Cookie in I2. 550 Responder Verify that the received I is a saved one. 552 Match the Response with a K based on I. 553 Compute V := Ltrunc( SHA-1( I | HIT-I | HIT-R | J ), K ) 554 Reject if V != 0 555 Accept if V == 0 557 4.1.2 Authenticated Diffie-Hellman protocol 559 4.1.3 HIP Birthday 561 The Birthday is a reboot count used to manage state reestablishment 562 when one peer rebooted or timed out its SA. The Birthday is 563 increased every time the system boots. The Birthday also has to be 564 increased in accordance with the system's SA timeout parameter. If 565 the system has open SAs, it MUST increase its Birthday. This impacts 566 a system's approach to precomputing R1 packets. 568 Birthday SHOULD be a counter. It cannot be reset by the user and a 569 system is unlikely to need a birthday larger than 2^64. Date-time in 570 GMT can be used if a cross-boot counter is not possible, but it has a 571 potential problem if the system time is set back by the user. 573 4.2 Sending data on HIP packets 575 A future version of this document may define how to send ESP 576 protected data on various HIP packets. However, currently the HIP 577 header is a terminal header, and not followed by any other headers. 579 4.3 Distributing certificates 581 Certificates MAY be distributed using the CERT packet. [XXX: This 582 section needs more text.]. 584 5. The Host Identity Protocol packet flow and state machine 586 A typical HIP packet flow is shown below. 588 I --> Directory: lookup of R 589 I <-- Directory: return R's addresses, HI, and HIT 590 I1 I --> R (Hi. Here is my I1, let's talk HIP) 591 R1 I <-- R (OK. Here is my R1, handle this HIP cookie) 592 I2 I --> R (Compute, compute, here is my counter I2) 593 R2 I <-- R (OK. Let's finish HIP with my R2) 594 I --> R (ESP protected data) 595 I <-- R (ESP protected data) 597 5.1 HIP Scenarios 599 The HIP protocol and state machine is designed to recover from one of 600 the parties crashing and losing its state. The following scenarios 601 describe the main use cases covered by the design. 603 No prior state between the two systems. 605 The system with data to send is the Initiator. The process 606 follows standard 4 packet exchange, establishing the SAs. 608 The system with data to send has no state with receiver, but 609 receiver has a residual SA. 611 Intiator acts as in no prior state, sending I1 and getting R1. 612 When Receiver gets I2, the old SA is 'discovered' and deleted; 613 the new SAs are established. 615 System with data to send has an SA, but receiver does not. 617 Receiver 'detects' when it receives an unknown SPI. Receiver 618 sends an R1 with a NULL Initiator HIT. Sender gets the R1 with 619 a later birthdate, discards old SA and continues exchange to 620 establish new SAs for sending data. 622 A peer determines that it needs to reset Sequence number or rekey. 624 It sends NES. Receiver sends NES response, establishes new SAs 625 for peers. 627 5.2 Refusing a HIP exchange 629 A HIP aware host may choose not to accept a HIP exchange. If the 630 host's policy is to only be an initiator, it should begin its own HIP 631 exchange. A host MAY choose to have such a policy since only the 632 Initiator HI is protected in the exchange. There is a risk of a race 633 condition if each host's policy is to only be an initiator, at which 634 point the HIP exchange will fail. 636 If the host's policy does not permit it to enter into a HIP exchange 637 with the Initiator, it should send an ICMP Protocol Unreachable, 638 Administratively Prohibited message. A more complex HIP packet is 639 not used here as it actually opens up more potential DoS attacks than 640 a simple ICMP message. 642 5.3 Reboot and SA timeout restart of HIP 644 Simulating a loss of state is a potential DoS attack. The following 645 process has been crafted to manage state recovery without presenting 646 a DoS opportunity. 648 If a host reboots or times out, it has lost its HIP state. If the 649 system that lost state has a datagram to deliver to its peer, it 650 simply restarts the HIP exchange. The peer sends an R1 HIP packet, 651 but does not reset its state until it receives the I2 HIP packet. 652 The I2 packet MUST have a Birthday greater than the current SA's 653 Birthday. This is to handle DoS attacks that simulate a reboot of a 654 peer. Note that either the original Initiator or the Responder could 655 end up restarting the exchange, becoming the new Initiator. An 656 example of the initial Responder needing to send a datagram but not 657 having state occurs when the SAs timed out and a server on the 658 Responder sends a keep-alive to the Initiator. 660 If a system receives an ESP packet for an unknown SPI, the assumption 661 is that it has lost the state and its peer did not. In this case, 662 the system treats the ESP packet like an I1 packet and sends an R1 663 packet. The Initiator HIT is typically NULL in the R1, since the 664 system usually does not know the peer's HIT any more. 666 The system receiving the R1 packet first checks to see if it has an 667 established and recently used SA with the party sending the R1. If 668 such an SA exists, the system checks the Birthday, if the Birthday is 669 greater than the current SA's Birthday, it processes the R1 packet 670 and resends the ESP packet (along with or) after the I2 packet. The 671 peer system processes the I2 in the normal manner, and replies with 672 an R2. This will reestablish state between the two peers. [XXX: 673 Potential DoS attack if hundreds of peers 'loose' their state and all 674 send R1 packets at once to a server. However, that would require the 675 attacker having specific knowledge about the SAs used, and an ability 676 to trigger R1s as the SAs are used.] 678 5.4 HIP State Machine 680 HIP has very little state. In the base HIP exchange, there is an 681 Initiator and a Responder. Once the SAs are established, this 682 distinction is lost. If the HIP state needs to be re-established, 683 the controlling parameters are which peer still has state and which 684 has a datagram to send to its peer. The following state machine 685 attempts to capture these processes. 687 The state machine is presented in a single system view, reresenting 688 either an Initiator or a Responder. There is not a complete overlap 689 of processing logic here and in the packet definitions. Both are 690 needed to completely implement HIP. 692 5.4.1 HIP States 694 E0 State machine start 696 E1 Initiating HIP 698 E2 Waiting to finish HIP 700 E3 HIP SA established 702 E-FAILED HIP SA establishment failed 704 5.4.2 HIP State Processes 706 +---------+ 707 | E0 | Start state 708 +---------+ 710 Datagram to send, send I1 and go to E1 711 Receive I1, send R1 and stay at E0 712 Receive I2, process 713 if successful, send R2 and go to E3 714 if fail, stay at E0 715 Receive ESP for unknown SA, send R1 and stay at E0 716 Receive ANYOTHER, drop and stay at E0 718 +---------+ 719 | E1 | Initiating HIP 720 +---------+ 722 Receive I1, send R1 and stay at E1 723 Receive I2, process 724 if successful, send R2 and go to E3 725 if fail, stay at E1 726 Receive R1, process 727 if successful, send I2 and go to E2 728 if fail, go to E-FAILED 729 Receive ANYOTHER, drop and stay at E1 730 Timeout, increment timeout counter 731 If counter is less than N1, send I1 and stay at E1 732 If counter is greater than N1, go to E-FAILED 734 +---------+ 735 | E2 | Waiting to finish HIP 736 +---------+ 738 Receive I1, send R1 and stay at E2 739 Receive I2, process 740 if successful, send R2 and go to E3 741 if fail, stay at E2 742 Receive R2, process 743 if successful, go to E3 744 if fail, go to E-FAILED 745 Receive ANYOTHER, drop and stay at E2 746 Timeout, increment timeout counter 747 If counter is less than N2, send I2 and stay at E2 748 If counter is greater than N2, go to E-FAILED 750 +---------+ 751 | E3 | HIP SA established 752 +---------+ 754 Receive I1, send R1 and stay at E3 755 Receive I2, process with Birthday check 756 if successful, send R2, drop old SA and cycle at E3 757 if fail, stay at E3 758 Receive R1, process with SA and Birthday check 759 if successful, send I2 with last datagram, drop old SA 760 and go to E2 761 if fail, stay at E3 762 Receive R2, drop and stay at E3 764 Receive ESP for SA, process and stay at E3 765 Receive NES, process 766 if successful, send NES and stay at E3 767 if failed, stay at E3 769 5.4.3 Simplified HIP State Diagram 770 Receive packets cause a move to new state 772 +---------+ 773 | E0 |>---+ 774 +---------+ | 775 | ^ | | 776 | | | Dgm to | 777 +-+ | send | 778 I1 | | (note: ESP- means ESP with unknown SPI) 779 ESP- | | 780 v | 781 +---------+ | 782 | E1 |>---|----------+ 783 +---------+ | | 784 | | | 785 | R1 | | 786 | |I2 |I2 787 v | | 788 +---------+ | | 789 | E2 |>---|----------|-----+ 790 | |<---|-----+ | | 791 +---------+ | | | | 792 | | | | | 793 | R2 | |R1 | |I2 794 | | | | | 795 v | | | | 796 +---------+<---+ | | | 797 | |----------+ | | 798 | E3 |<--------------+ | 799 | |<--------------------+ 800 +---------+ 801 | ^ 802 | | 803 +--+ 804 ESP, 805 NES, 806 I1, 807 I2 809 6. Packet formats 811 6.1 Payload format 813 All HIP packets start with a fixed header. 815 0 1 2 3 816 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 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 | Next Header | Payload Len | Type | VER. | RES. | 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 | Controls | CRC | 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 | Sender's Host Identity Tag (HIT) | 823 | | 824 | | 825 | | 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 | Receiver's Host Identity Tag (HIT) | 828 | | 829 | | 830 | | 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 | | 833 / HIP Parameters / 834 / / 835 | | 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 838 The HIP header is logically an IPv6 destination option. However, this 839 document does not describe processing for Next Header values other 840 than decimal 59, IPPROTO_NONE, the IPV6 no next header value. Future 841 documents MAY do so. However, implementations MUST ignore trailing 842 data if a Next Header value is received that is not implemented. 844 The Header Length field contains the length of the HIP Header and the 845 length of HIP parameters in 8 bytes units, excluding the first 8 846 bytes. Since all HIP headers MUST contain the sender's and 847 receiver's HIT fields, the minimum value for this field is 4, and 848 conversely, the maximum length of the HIP Parameters field is 849 (255*8)-32 = 2008 bytes. 851 The Packet Type indicates the HIP packet type. The individual packet 852 types are defined in the relevant sections. If a HIP host receives a 853 HIP packet that contains an unknown packet type, it MUST silently 854 drop the packet. 856 The HIP Version is four bits. The current version is 1. The version 857 number is expected to be incremented only if there are incompatible 858 changes to the protocol. Most extensions can be handled by defining 859 new packet types, new parameter types, or new controls. 861 The following four bits are reserved for future use. They MUST be 862 zero when send, and they SHOULD be ignored when handling a received 863 packet. 865 The HIT fields are always 128 bits (16 bytes) long. 867 6.1.1 HIP Controls 869 The HIP control section transfers information about the structure of 870 the packet and capabilities of the host. 872 The following fields have been defined: 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 | | | | | | | | | | | | | |C|E|A| 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 878 C - Certificate One or more certificate packets (CER) follows this 879 HIP packet (see Section 7.7). 881 E - ESP sequence numbers The ESP transform requires 64-bit sequence 882 numbers. See Section 11.4 for processing this control. 884 A - Anonymous If this is set, the senders HI in this packet is 885 anonymous, i.e., one not listed in a directory. Anonymous HIs 886 SHOULD NOT be stored. This control is set in packets R1 and/or 887 I2. The peer receiving an anonymous HI may choose to refuse it by 888 silently dropping the exchange. 890 The rest of the fields are reserved for future use and MUST be set to 891 zero on sent packets and ignored on received packets. 893 6.1.2 CRC 895 The checksum field is located at the same location within the header 896 as the checksum field in UDP packets, enabling hardware assisted 897 checksum generation and verification. Note that since the checksum 898 covers the source and destination addresses in the IP header, it must 899 be recomputed on HIP based NAT boxes. 901 If IPv6 is used to carry the HIP packet, the pseudo-header [10] 902 contains the source and destination IPv6 addresses, HIP packet length 903 in the pseudo-header length field, a zero field, and the HIP protocol 904 number (TBD) in the Next Header field. The length field is in bytes 905 and can be calculated from the HIP header length field: (HIP Header 906 Length + 1) * 8. 908 In case of using IPv4, the the IPv6 pseudo header format [10] is 909 still used, but in the pseudo-header source and destination addresses 910 are IPv4 addresses expressed in IPv4-in-IPv6 format [3]. 912 6.2 HIP parameters 914 The HIP Parameters are used to carry the public key associated with 915 the sender's HIT, together with other related security information. 916 The HIP Parameters consists of ordered parameters, encoded in TLV 917 format. 919 The following parameter types are currently defined. 921 TLV Type Length Data 923 SPI_LSI 16 Remote's SPI, Remote's LSI. 925 BIRTHDAY_COOKIE 40 System Boot Counter plus 926 3 64 bit fields: 927 Random #I, K or random # J, 928 Hash target 930 DIFFIE_HELLMAN variable public key 932 HIP_TRANSFORM variable HIP Encryption Transform 934 ESP_TRANSFORM variable ESP Encryption and 935 Authentication Transform 937 HOST_ID variable Host Identity 939 HOST_ID_FQDN variable Host Identity with Fully 940 Qualified Domain Name 942 CERT variable HI certificate 944 NES_INFO XXX ESP sequence number, 945 Old SPI, New SPI 947 ENCRYPTED variable Encrypted part of I2 or CER 948 packets 950 HIP_SIGNATURE variable Signature of the packet 951 HIP_SIGNATURE2 variable Signature of the packet R1 953 6.3 TLV format 955 The TLV encoded parameters are described in the following 956 subsections. The type-field value also describes the order of these 957 fields in the packet. The parameters MUST be included into the 958 packet so that the types form an increasing order. If the order does 959 not follow this rule, the packet is considered to be malformed and it 960 MUST be discarded. 962 All the TLV parameters have a length which is a multiple of 8 bytes. 963 When needed, padding MUST be added to the end of the parameter so 964 that the total length becomes a multiple of 8 bytes. This rule 965 ensures proper alignment of data. If padding is added, the Length 966 field MUST NOT include the padding. 968 Consequently, the Length field indicates the length of the Contents 969 field (in bytes). The total length of the TLV parameter (including 970 Type, Length, Contents, and Padding) is related to the Length field 971 according to the following formula: 973 Total Length = 11 + Length - (Length + 3) % 8; 975 0 1 2 3 976 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 977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 978 | Type | Length | 979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 980 | | 981 / Contents / 982 / +-+-+-+-+-+-+-+-+ 983 | | Padding | 984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 6.3.1 SPI_LSI 988 0 1 2 3 989 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 990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 991 | Type | Length | 992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 993 | Reserved | 994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 995 | SPI | 996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 997 | LSI | 998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1000 Type 1 1001 Length 12 1002 Reserved Zero when sent, ignored when received 1003 SPI Security Parameter Index 1004 LSI Local Scope Identifier 1006 6.3.2 BIRTHDAY_COOKIE 1008 0 1 2 3 1009 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 1010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1011 | Type | Length | 1012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1013 | Reserved | 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 | Birthday, 8 bytes | 1016 | | 1017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1018 | Random # I, 8 bytes | 1019 | | 1020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1021 | Random # J or K, 8 bytes | 1022 | | 1023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1024 | Hash Target, 8 bytes | 1025 | | 1026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1028 Type 2 (in R1) or 3 (in I2) 1029 Length 36 1030 Reserved Zero when sent, ignored when received 1031 Birthday System boot counter 1032 Random # I random number 1033 K or K is the number of verified bits (in R1 packet) 1034 Random # J random number (in I2 packet) 1035 Hash Target calculated hash value 1037 Birthday, Random #I, K, Random #J, and Hash Target are in network 1038 byte order. 1040 6.3.3 DIFFIE_HELLMAN 1042 0 1 2 3 1043 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 1045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1046 | Type | Length | 1047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1048 | Group ID | public value / 1049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1050 / | padding | 1051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 Type 6 1054 Length length in octets, excluding T and L fields and padding 1055 Group ID defines values for p and g 1056 public value 1058 The following Group IDs have been defined: 1060 Group Value 1061 Reserved 0 1062 OAKLEY well known group 1 1 1063 OAKLEY well known group 2 2 1064 1536-bit MODP group 3 1065 2048-bit MODP group 4 1066 3072-bit MODP group 5 1067 4096-bit MODP group 6 1068 6144-bit MODP group 7 1069 8192-bit MODP group 8 1071 MODP Diffie-Hellman groups are defined in [14]. OAKLEY groups are 1072 defined in [7]. The OAKLEY well known group 5 is the same as 1536-bit 1073 MODP group. 1075 6.3.4 HIP_TRANSFORM 1077 0 1 2 3 1078 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 1079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1080 | Type | Length | 1081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1082 | Transform-ID #1 | Transform-ID #2 | 1083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1084 | Transform-ID #n | Padding | 1085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1087 Type 16 1088 Length length in octets, excluding T and L fields and padding 1089 Transform-ID Defines the HIP Transform to be used 1091 The following encryption algorithms are defined. 1093 Transform-ID Value 1095 RESERVED 0 1096 ENCR_NULL 1 1097 ENCR_3DES 2 1098 ENCR_AES_128 3 1100 There MUST NOT be more than three (3) HIP Transform-IDs in one HIP 1101 transform TLV. The limited number of transforms sets the maximum size 1102 of HIP_TRANSFORM TLV. The HIP_TRANSFORM TLV MUST contain at least one 1103 of the mandatory Transform-IDs. 1105 Mandatory implementations: ENCR_3DES and ENCR_NULL 1107 6.3.5 ESP_TRANSFORM 1109 0 1 2 3 1110 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 1111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1112 | Type | Length | 1113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1114 | Suite-ID #1 | Suite-ID #2 | 1115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1116 | Suite-ID #n | Padding | 1117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 Type 18 1120 Length length in octets, excluding T and L fields and padding 1121 Suite-ID Defines the ESP Suite to be used 1123 The following Suite-IDs are defined ([15],[16]): 1125 Suite-ID Value 1127 RESERVED 0 1128 ESP-AES-CBC with HMAC-SHA1 1 1129 ESP-3DES-CBC with HMAC-SHA1 2 1130 ESP-3DES-CBC with HMAC-MD5 3 1131 ESP-BLOWFISH-CBC with HMAC-SHA1 4 1132 ESP-NULL with HMAC-SHA1 5 1133 ESP-NULL with HMAC-MD5 6 1135 There MUST NOT be more than six (6) ESP Suite-IDs in one 1136 ESP_TRANSFORM TLV. The limited number of Suite-IDs sets the maximum 1137 size of ESP_TRANSFORM TLV. The ESP_TRANSFORM MUST contain at least 1138 one of the mandatory Suite-IDs. 1140 Mandatory implementations: ESP-3DES-CBC with HMAC-SHA1 and ESP-NULL 1141 with HMAC-SHA1 1143 6.3.6 HOST_ID 1145 When the host sends a Host Identity to a peer, it MAY send the 1146 identity without any verification information or use certificates to 1147 proof the HI. If certificates are sent, they are sent in a separate 1148 HIP packet (CER). 1150 0 1 2 3 1151 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 1152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1153 | Type | Length | 1154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1155 | Host Identity / 1156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1157 / | padding | 1158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1160 Type 32 1161 Length length in octets, excluding T and L fields and padding 1162 Host Identity actual host identity 1164 The Host Identity is represented in RFC2535 [11] format. The 1165 algorithms used in RDATA format are the following: 1167 Algorithms Values 1169 RESERVED 0 1170 DSA 3 [RFC2536] (REQUIRED) 1171 RSA 5 [RFC3110] (OPTIONAL) 1173 6.3.7 HOST_ID_FQDN 1175 0 1 2 3 1176 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 1177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1178 | Type | Length | 1179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1180 | HI Length | FQDN Length | 1181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1182 | Host Identity / 1183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1184 / | FDQN / 1185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1186 / | Padding | 1187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1188 Type 33 1189 Length length in octets, excluding T and L fields and padding 1190 Host Identity 1191 length length of the HI 1192 FQDN length length of the FQDN 1193 Host Identity actual host identity 1194 FQDN Fully Qualified Domain Name, in the binary format. 1196 The Host Identity is represented in RFC2535 [11] format. The format 1197 for the FQDN is defined in RFC1035 [1] Sect. 3.1. 1199 If there is no FQDN, the HOST_ID TLV is sent instead. 1201 6.3.8 CERT 1203 0 1 2 3 1204 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 1205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1206 | Type | Length | 1207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1208 | Cert count | Cert ID | Cert type | / 1209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1210 / Certificate / 1211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1212 / | Padding | 1213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1215 Type 64 1216 Length length in octets, excluding T and L fields and padding 1217 Cert count total count of certificates that are sent, possibly 1218 in different CER packets 1219 Cert ID the order number for this certificate 1220 Cert Type describes the type of the certificate 1222 The receiver must know the total number (Cert count) of certificates 1223 that it will receive from the sender, related to the R1 or I2. The 1224 Cert ID identifies the particular certificate and its order in the 1225 certificate chain. The numbering in Cert ID MUST go from 1 to Cert 1226 count. 1228 The following certificate types have been identified: 1230 Cert format Type number 1231 X.509 v3 1 1233 The encoding format for X.509v3 certificate is defined in [9]. 1235 6.3.9 HIP_SIGNATURE 1237 0 1 2 3 1238 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 1239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1240 | Type | Length | 1241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1242 | SIG alg | Signature / 1243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1244 / | padding | 1245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1247 Type 65534 (2^16-2) 1248 Length length in octets, excluding T and L fields and padding 1249 SIG alg Signature algorithm 1250 Signature the signature is calculated over the HIP packet, 1251 excluding the HIP_SIGNATURE TLV field. The checksum 1252 field MUST be set to zero and the HIP header length in 1253 the HIP common header MUST be calculated to the 1254 beginning of the HIP_SIGNATURE TLV when the signature is 1255 calculated. 1257 Signature calculation and verification process: 1259 Packet sender: 1261 1. Create the HIP packet without the HIP_SIGNATURE TLV 1263 2. Calculate the length field in the HIP header 1265 3. Compute the signature 1267 4. Add the HIP_SIGNATURE TLV to the packet 1269 5. Recalculate the length field in the HIP header 1271 Packet receiver: 1273 1. Verify the HIP header length field 1275 2. Save the HIP_SIGNATURE TLV and remove it from the packet 1277 3. Recalculate the HIP packet length in the HIP header and zero 1278 checksum field. 1280 4. Compute the signature and verify it against the received 1281 signature 1283 The signature algorithms are defined in Section 6.3.5. The signature 1284 in the Signature field is encoded using the proper method depending 1285 on the signature algorithm (e.g. in case of DSA, according to [12]). 1287 The verification can use either the HI received from a HIP packet, 1288 the HI from a DNS query, if the FQDN has been received either in the 1289 HOST_ID_FQDN or in the CER packet, or one reveived by some other 1290 means. 1292 6.3.10 HIP_SIGNATURE_2 1294 The TLV structure is the same as in Section 6.3.9. The fields are: 1296 Type 65533 (2^16-3) 1297 Length length in octets, excluding T and L fields and padding 1298 SIG alg Signature algorithm 1299 Signature the signature is calculated over the R1 packet, 1300 excluding the HIP_SIGNATURE_2 TLV field. Initiator's HIT 1301 and Checksum field MUST be set to zero and the HIP 1302 packet length in the HIP header MUST be calculated to 1303 the beginning of the HIP_SIGNATURE_2 TLV when the 1304 signature is calculated. 1306 Zeroing the Initiator's HIT makes it possible to create R1 packets 1307 beforehand to minimize the effects of possible DoS attacks. 1309 Signature calculation and verification process: see the process in 1310 Section 6.3.9 HIP_SIGNATURE. Just replace the HIP_SIGNATURE with 1311 HIP_SIGNATURE_2 and zero Initiator's HIT at the receiver's end-point. 1313 The signature algorithms are defined in Section 6.3.5. The signature 1314 in the Signature field is encoded using the proper method depending 1315 on the signature algorithm (e.g. in case of DSA, according to [12]). 1317 The verification can use either the HI received from a HIP packet, 1318 the HI from a DNS query, if the FQDN has been received either in the 1319 HOST_ID_FQDN or in the CER packet, or one reveived by some other 1320 means. 1322 6.3.11 NES_INFO 1324 [XXX: The contents of the NES_INFO payload are subject to change, 1325 since it is desireable to unify the NES and REA functionality. 1326 However, the details of that need to be worked out.] 1328 0 1 2 3 1329 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 1330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1331 | Type | Length | 1332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1333 | Reserved | 1334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1335 | Current SPI in reverse direction | 1336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1337 | Current SPI | 1338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1339 | New SPI | 1340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1341 | Keymaterial index | packet ID | 1342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1344 Type 4 1345 Length length in octets, excluding T and L fields 1346 ESP sequence 1347 number 1348 Old SPI 1349 New SPI 1351 6.3.12 ENCRYPTED 1353 0 1 2 3 1354 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 1355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1356 | Type | Length | 1357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1358 | Reserved | 1359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1360 | IV | 1361 | | 1362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1363 | Encrypted data / 1364 / | 1365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1367 Type 20 1368 Length length in octets, excluding T and L fields 1369 Reserved zero when sent, ignored when received 1370 IV Initialization vector, if needed, zero otherwise 1371 Encrypted the data is encrypted using an encryption algorithm as 1372 data defined in HIP transform 1374 The encrypted data is in TLV format itself. Consequently, the first 1375 fields in the contents are Type and Length. 1377 7. HIP Packets 1379 There are eight basic HIP packets. Four are for the base HIP 1380 exchange,one is for rekeying, one is a broadcast for use when there 1381 is no IP addressing (e.g., before DHCP exchange), one is used to send 1382 certificates and one is for sending unencrypted data. 1384 Packets consist of the fixed header as described in Section 6.1, 1385 followed by the parameters. The parameter part in turn consists of 1386 zero or more TLV coded parameters. 1388 In addition to the base packets, some other packets may be defined 1389 later in separate standards. E.g. the mobility and multihoming 1390 management support is not included in this base specification. 1392 Packet representation uses the following operations: 1394 () parameter 1395 x{y} operation x on content y 1396 i x exists i times 1397 [] optional parameter 1398 x|y x or y 1400 An OPTIONAL upper layer payload MAY follow the HIP header. The 1401 payload proto field in the header indicates if there is additional 1402 data following the HIP header. The P-bit in the control field of the 1403 HIP packet header indicates whether the sender is capable of sending 1404 and receiving this additional data. The HIP packet, however, MUST NOT 1405 be fragmented. This limits the size of the possible additional data 1406 in the packet. 1408 7.1 I1 - the HIP Initiator packet 1410 The HIP header values for the I1 packet: 1412 Type = 1 1413 SRC HIT = Initiator's HIT 1414 DST HIT = Responder's HIT, or NULL 1416 IP(HIP()) 1418 The I1 packet contains only the fixed HIP header. 1420 Valid control bits: None 1422 The Initiator gets the Responder's HIT either from a DNS lookup of 1423 the responder's FQDN, from some other repository, or from a local 1424 table. If the initiator does not know the responder's HIT, it may 1425 attempt anonymous mode by using NULL (all zeros) as the responder's 1426 HIT. 1428 Since this packet is so easy to spoof even if it were signed, no 1429 attempt is made to add to its generation or processing cost. 1431 Implementation MUST be able to handle a storm of reveived I1 packets, 1432 discarding those with common content that arrive within a small time 1433 delta. 1435 7.2 R1 - the HIP Responder packet 1437 The HIP header values for the R1 packet: 1439 Header: 1440 Packet Type = 2 1441 SRC HIT = Responder's HIT 1442 DST HIT = Initiator's HIT 1444 IP ( HIP ( BIRTHDAY_COOKIE, 1445 DIFFIE_HELLMAN, 1446 HIP_TRANSFORM, 1447 ESP_TRANSFORM, 1448 ( HOST_ID | HOST_ID_FQDN ), 1449 HIP_SIGNATURE_2 ) ) 1451 Valid control bits: C, A 1453 The R1 packet may be followed by one or more CER packets. In this 1454 case, the C-bit in the control field MUST be set. 1456 If the Responder has multiple HIs, the HIT used MUST match 1457 Initiator's request. If the Initiator used anonymous mode, the 1458 Responder may select freely among its HIs. 1460 The Initiator HIT MUST match the one received in I1. If the R1 is a 1461 response to an ESP packet with an unknown SPI, the Initiator HIT 1462 SHOULD be zero. 1464 The Birthday is a reboot count used to manage state reestablishment 1465 when one peer rebooted or timed out its SA. 1467 The Cookie contains random I and difficulty K. K is number of bits 1468 that the Initiator must match get zero in the puzzle. 1470 The Diffie-Hellman value is ephemeral, but can be reused over a 1471 number of connections. In fact, as a defense against I1 storms, an 1472 implementation MAY use the same Diffie-Hellman value for a period of 1473 time, for example, 15 minutes. By using a small number of different 1474 Cookies for a given Diffie-Hellman value, the R1 packets can be 1475 pre-computed and delivered as quickly as I1 packets arrive. A 1476 scavenger process should clean up unused DHs and Cookies. 1478 The HIP_TRANSFORM contains the encryption algorithms supported by the 1479 responder to protect the HI exchange, in order of preference. All 1480 implementations MUST support the 3DES [8] transform. 1482 The ESP_TRANSFORM contains the ESP modes supported by the responder, 1483 in order of preference. All implementations MUST support 3DES [8] 1484 with HMAC-SHA-1-96 [4]. 1486 The SIG is calculated over the whole HIP envelope, after setting the 1487 Initiator HIT and header checksum temporarily to zero. This allows 1488 the Responder to use precomputed R1s. The Initiator SHOULD validate 1489 this SIG. It SHOULD check that the HI received matches with the one 1490 expected, if any. 1492 7.3 I2 - the HIP Second Initiator packet 1494 The HIP header values for the I2 packet: 1496 Type = 3 1497 SRC HIT = Initiator's HIT 1498 DST HIT = Responder's HIT 1500 IP ( HIP ( SPI_LSI, 1501 BIRTHDAY_COOKIE, 1502 DIFFIE_HELLMAN, 1503 HIP_TRANSFORM, 1504 ESP_TRANSFORM, 1505 ENCRYPTED { HOST_ID | HOST_ID_FQDN }, 1506 HIP_SIGNATURE ) ) 1508 Valid control bits: C, E, A 1510 The HITs used MUST match the ones used previously. 1512 The Birthday is a reboot count used to manage state reestablishment 1513 when one peer rebooted or timed out its SA. 1515 The Cookie contains I from R1 and the computed J. The low order K 1516 bits of the SHA-1(I | ... | J) MUST match be zero. 1518 The Diffie-Hellman value is ephemeral. If precomputed, a scavenger 1519 process should clean up unused DHs. 1521 The HIP_TRANSFORM contains the encryption used to protect the HI 1522 exchange selected by the initiator. All implementations MUST support 1523 the 3DES transform. 1525 The Initiator's HI is encrypted using the HIP_TRANSFORM. The keying 1526 material is derived from the Diffie-Hellman exchanged as defined in 1527 Section 9. 1529 The ESP_TRANSFORM contains the ESP mode selected by the initiator. 1530 All implementations MUST support 3DES [8] with HMAC-SHA-1-96 [4]. 1532 The HIP SIG is calculated over whole HIP envelope. The Responder 1533 MUST validate this SIG. It MAY use either the HI in the packet or 1534 the HI acquired by some other means. 1536 7.4 R2 - the HIP Second Responder packet 1538 The HIP header values for the R2 packet: 1540 Packet Type = 4 1541 SRC HIT = Responder's HIT 1542 DST HIT = Initiator's HIT 1544 IP ( HIP ( SPI_LSI, 1545 HIP_SIGNATURE ) ) 1547 Valid control bits: E 1549 The signature is calculated over whole HIP envelope. The Initiator 1550 MUST validate this signature. 1552 7.5 NES - the HIP New SPI Packet 1554 The HIP New SPI Packet serves three functions. Firstly, it provides 1555 the peer system with a new SPI to use when sending packets. 1556 Secondly, it optionally provides a new Diffie-Hellman key to produce 1557 new keying material. Thirdly, it provides any intermediate system 1558 with the mapping of the old SPI to the new one. This is important to 1559 systems like NATs [20] that use SPIs to maintain address translation 1560 state. 1562 The new SPI Packet is a HIP packet with SPI and D-H in the HIP 1563 payload. The HIP packet contains the current ESP Sequence Number and 1564 SPI to provide DoS and replay protection. 1566 The HIP header values for the NES packet: 1568 Packet Type = 5 1569 SRC HIT = Sender's HIT 1570 DST HIT = Recipients's HIT 1572 IP ( HIP ( [ DIFFIE_HELLMAN, ] NES_INFO , HIP_SIGNATURE ) ) 1574 Valid control bits: None 1576 During the life of an SA established by HIP, one of the hosts may 1577 need to reset the Sequence Number to one (to prevent wrapping) and 1578 rekey. The reason for rekeying might be an approaching sequence 1579 number wrap in ESP, or a local policy on use of a key. A new SPI or 1580 rekeying ends the current SAs and starts a new ones on both peers. 1581 Intermediate systems that use the SPI will have to inspect HIP 1582 packets for a HIP New SPI packet. The packet is signed for the 1583 benefit of the Intermediate systems. 1585 This packet has a potential DoS attack of a packet within the replay 1586 window and proper SPI, but a malformed signature. Implementations 1587 MUST recognize when they are under attack and manage the attack. If 1588 it is still receiving ESP packets with increasing Sequence Numbers, 1589 the NES packets are obviously attacks and can be ignored. 1591 Since intermediate systems may need the new SPI values, the contents 1592 of this packet cannot be encrypted. 1594 Intermediate systems that use the SPI will have to inspect ALL HIP 1595 packets for a NES packet. This is a potential DoS attack against the 1596 Intermediate system, as the signature processing may be relatively 1597 expensive. A further step against attack for the Intermediate 1598 systems is to implement ESP's replay protection of windowing the 1599 sequence number. This requires the intermediate system to track ALL 1600 ESP packets to follow the Sequence Number. 1602 7.6 BOS - the HIP Bootstrap Packet 1604 In some situations, an initiator may not be able to learn of a 1605 responder's information from DNS or another repository. Some examples 1606 of this are DHCP and NetBios servers. Thus, a packet is needed to 1607 provide information that would otherwise be gleaned from a 1608 repository. This HIP packet is either self-signed in applications 1609 like SoHo, or from a trust anchor in large private or public 1610 deployments. This packet MAY be broadcasted in IPv4 or multicasted 1611 to the all hosts multicast group in IPv6. The packet MUST NOT be 1612 sent more often than once in every second. Implementations MAY 1613 ignore received BOS packets. 1615 The HIP header values for the BOS packet: 1617 Packet Type = 7 1618 SRC HIT = Announcer's HIT 1619 DST HIT = NULL 1621 IP ( HIP ( ( HOST_ID | HOST_ID_FQDN ), HIP_SIGNATURE ) ) 1623 The BOS packet may be followed by a CER packet if the HI is signed. 1624 In this case, the C-bit in the control field MUST be set. If the BOS 1625 packet is broadcasted or multicasted, the following CER packet(s) 1626 MUST be broadcasted or multicasted to the same multicast group and 1627 scope, respectively. 1629 Valid control bits: C, A 1631 7.7 CER - the HIP Certificate Packet 1633 The Optional CER packets over the Announcer's HI by a higher level 1634 authority known to the Recipient is an alternative method for the 1635 Recipient to trust the Announcer's HI (over DNSSEC or PKI). 1637 The HIP header values for CER packet: 1639 Packet Type = 8 1640 SRC HIT = Announcer's HIT 1641 DST HIT = Recipients's HIT 1643 IP ( HIP ( ENCRYPTED { i }, HIP_SIGNATURE ) ) 1645 Valid control bits: None 1647 Certificates in the CER packet MAY be encrypted. The encryption 1648 algorithm is provided in the HIP transform of the previous (R1 or I2) 1649 packet. 1651 7.8 PAYLOAD - the HIP Payload Packet 1653 The HIP header values for the PAYLOAD packet: 1655 Packet Type = 64 1657 IP ( HIP ( ), payload ) 1659 Valid control bits: None 1661 Payload Proto field in the Header MUST be set to correspond the 1662 correct protocol number of the payload. 1664 The PAYLOAD packet is used to carry a non-ESP protected data. By 1665 usign HIP header we ensure interoperability with NAT and other middle 1666 boxes. 1668 Processing rules of the PAYLOAD packet are the following: 1670 Receiving: if there is an existing HIP security association with the 1671 given HITs, and the IP addresses match the IP addresses associated 1672 with the HITs, pass the packet to the upper layer, associated with 1673 metadata indicating that the packet was NOT integrity or 1674 confidentiality protected. 1676 Sending: if the IPsec SPD defines BYPASS for a given destination 1677 HIT, send it with the PAYLOAD packet. Otherwise use the ESP as 1678 specified in the SPD. 1680 8. Packet processing 1682 [XXX: This section is currently in its very beginning. It needs much 1683 more text.] 1685 8.1 R1 Management 1687 All compliant implementations MUST produce R1 packets. An R1 packet 1688 MAY be precomputed. An R1 packet MAY be reused for time Delta T. R1 1689 information MUST not be discarded until Delta S after T. Time S is 1690 the delay needed for the last I2 to arrive back to the responder. A 1691 spoofed I1 can result in an R1 attack on a system. An R1 sender MUST 1692 have a mechanism to rate limit R1s to an address. 1694 8.2 Processing NES packets 1696 The ESP Sequence Number and current SPI are included to provide 1697 replay protection for the receiving peer. The old SA MUST NOT be 1698 deleted until all ESP packets with a lower Sequence Number have been 1699 received and processed, or a reasonable time has elapsed (to account 1700 for lost packets). If the Sequence Number is the replay window is 1701 greater than the number in the NES packet, the NES packet MUST be 1702 ignored. If the SPI number does not match with an existing SPI 1703 number used, the NES packet must be ignored. 1705 The peer that initiates a New SPI exchange MUST include a Diffie- 1706 Hellmen key. Its peer MUST respond with a New SPI packet, an MAY 1707 include a Diffie-Hellman key if the receiving system's policy is to 1708 increase the new KEYMAT by changing its key pair. 1710 When a host receives a New SPI Packet with a Diffie-Hellman, its next 1711 ESP packet MUST use the KEYMAT generated by the new Kij. The sending 1712 host MUST expect at least a replay window worth of ESP packets using 1713 the old Kij. Out of order delivery could result in needing the old 1714 Kij after packets start arriving using the new SA's Kij. Once past 1715 the rekeying start, the sending host can drop the old SA and its Kij. 1717 The first packet sent by the receiving system MUST be a HIP New SPI 1718 packet. It MAY also include a datagram, using the new SAs. This 1719 packet supplies the new SPI for the rekeying system, which cannot 1720 send any packets until it receives this packet. If it does not 1721 receive a HIP New SPI packet within a reasonable round trip delta, it 1722 MUST assume it or the HIP Rekey packet was lost and MAY resend the 1723 HIP New SPI packet or renegotiate HIP as if in a reboot condition. 1724 The choice is a local policy decision. 1726 This packet MAY contain a Diffie-Hellman key, if the receiving 1727 system's policy is to increase the new KEYMAT by changing its key 1728 pair. 1730 9. HIP KEYMAT 1732 HIP keying material is derived from the Diffie-Hellman Kij produced 1733 during the base HIP exchange. The initiator has Kij during the 1734 creation of the I2 packet, and the responder has Kij once it receives 1735 the I2 packet. This is why I2 can already contain encrypted 1736 information. 1738 The KEYMAT is derived by feeding Kij and the HITs into the following 1739 operation; the | operation denotes concatenation. 1741 KEYMAT = K1 | K2 | K3 | ... 1742 where 1744 K1 = SHA-1( Kij | sort(HIT-I | HIT-R) | 0x01 ) 1745 K2 = SHA-1( Kij | K1 | 0x02 ) 1746 K3 = SHA-1( Kij | K2 | 0x03 ) 1747 ... 1748 K255 = SHA-1( Kij | K254 | 0xff ) 1749 K256 = SHA-1( Kij | K255 | 0x00 ) 1750 etc. 1752 Sort(HIT-I | HIT-R) is defined as the numeric network byte order 1753 comparison of the HITs, with lower HIT preceding higher HIT, 1754 resulting in the concatenation of the HITs in the said order. The 1755 initial keys are drawn sequentially in the following order: 1757 HIP Initiator key 1759 HIP Responder key (currently unused) 1761 Initiator ESP key 1763 Initiator AUTH key 1765 Responder ESP key 1767 Responder AUTH key 1769 The number of bits drawn for a given algorithm is the "natural" size 1770 of the keys. For the manatory algorithms, the following sizes apply: 1772 3DES 192 bits 1774 SHA-1 160 bits 1775 NULL 0 bits 1777 Subsequent rekeys without Diffie-Hellman just requre drawing out more 1778 sets of ESP keys. In the situation where Kij is the result of a HIP 1779 rekey exchange with Diffie-Hellman, there is only the need from one 1780 set of ESP keys, without the HIP keys. These are then the only keys 1781 taken from the KEYMAT. 1783 10. HIP Fragmentation Support 1785 A HIP implementation must support IP fragmentation / reassembly. 1786 Fragment reassembly MUST be implemented in both IPv4 and IPv6, but 1787 fragment generation MUST be implemented only in IPv4 (IPv4 stacks and 1788 networks will usually do this by default) and SHOULD be implemented 1789 in IPv6. In the IPv6 world, the minimum MTU is larger, 1280 bytes, 1790 than in the IPv4 world. The larger MTU size is usually sufficient for 1791 most HIP packets, and therefore fragment generation may not be 1792 needed. If a host expects to send HIP packets that are larger than 1793 the minimum IPv6 MTU, it MUST implement fragment generation even for 1794 IPv6. 1796 In the IPv4 world, HIP packets may encounter low MTUs along their 1797 routed path. Since HIP does not provide a mechanism to use multiple 1798 IP datagrams for a single HIP packet, support of path MTU discovery 1799 does not bring any value to HIP in the IPv4 world. HIP aware NAT 1800 systems MUST perform any IPv4 reassembly/fragmentation. 1802 All HIP implementations MUST employ a reassembly algorithm that is 1803 sufficiently resistant against DoS attacks. 1805 11. ESP with HIP 1807 HIP sets up a pair of Security Associations (SA) to enable ESP in an 1808 end-to-end manner that can span addressing realms (i.e. across NATs). 1809 This is accomplished through the various informations that are 1810 exchanged within HIP. Since HIP is designed for host usage, not for 1811 gateways, only ESP transport mode is supported with HIP. The SA is 1812 not bound to an IP address; all internal control of the SA is by the 1813 HIT and LSI. Thus a host can easily change its address using Mobile 1814 IP, DHCP, PPP, or IPv6 readdressing and still maintain the SAs. And 1815 since the transports are bound to the SA (LSI or HIT), any active 1816 transport is also maintained. Thus, real world conditions like loss 1817 of a PPP connection and its reestablishment or a mobile cell change 1818 will not require a HIP negotiation or disruption of transport 1819 services. 1821 Since HIP does not negotiate any lifetimes, all lifetimes are local 1822 policy. The only lifetimes a HIP implementation MUST support are 1823 sequence number rollover (for replay protection), and SA timeout. An 1824 SA times out if no packets are received using that SA. The default 1825 timeout value is 15 minutes. Implementations MAY support lifetimes 1826 for the various ESP transforms. Note that HIP does not offer any 1827 service comparable with IKE's Quick Mode. A Diffie-Hellman 1828 calculation is needed for each rekeying. 1830 11.1 Security Association Management 1832 An SA is indexed by the 2 SPIs and 2 HITs (both HITs since a system 1833 can have more than one HIT). An inactivity timer is recommended for 1834 all SAs. If the state dictates the deletion of an SA, a timer is set 1835 to allow for any late arriving packets. The SA MUST include the I 1836 that created it for replay detection. 1838 11.2 Security Parameters Index (SPI) 1840 The SPIs in ESP provide a simple compression of the HIP data from all 1841 packets after the HIP exchange. This does require a per HIT- pair 1842 Security Association (and SPI), and a decrease of policy granularity 1843 over other Key Management Protocols like IKE. 1845 When a host rekeys, it gets a new SPI from its partner. 1847 11.3 Supported Transforms 1849 All HIP implementations MUST support 3DES [8] and HMAC-SHA-1-96 [4]. 1850 If the Initiator does not support any of the transforms offered by 1851 the Responder in the R1 HIP packet, it MUST use 3DES and 1852 HMAC-SHA-1-96 and state so in the I2 HIP packet. 1854 In addition to 3DES, all implementations MUST implement the ESP NULL 1855 encryption and authentication algorithms. These algoritms are 1856 provided mainly for debugging purposes, and SHOULD NOT be used in 1857 production environments. The default configuration in 1858 implementations MUST be to reject NULL encryption or authentication. 1860 11.4 Sequence Number 1862 The Sequence Number field is MANDATORY in ESP. Anti-replay 1863 protection MUST be used in an ESP SA established with HIP. 1865 This means that each host MUST rekey before its sequence number 1866 reaches 2^32. Note that in HIP rekeying, unlike IKE rekeying, only 1867 one Diffie-Hellman key can be changed, that of the rekeying host. 1868 However, if one host rekeys, the other host SHOULD rekey as well. 1870 In some instances, a 32 bit sequence number is inadequate. In either 1871 the I2 or R2 packets, a peer MAY require that a 64 bit sequence 1872 number be used. In this case the higher 32 bits are NOT included in 1873 the ESP header, but are simply kept local to both peers. 64 bit 1874 sequence numbers must only be used for ciphers that will not be open 1875 to cryptoanalysis as a result. AES is one such cipher. 1877 12. HIP Policies 1879 There are a number of variables that will influence the HIP exchanges 1880 that each host must support. All HIP implementations MUST support 1881 more than one simultaneous HIs, at least one one of which SHOULD be 1882 reserved for anonymous usage. Although anonymous HIs will be rarely 1883 used as responder HIs, they will be common for initiators. Support 1884 for more than two HIs is RECOMMENDED. 1886 Many initiators would want to use a different HI for different 1887 responders. The implementations SHOULD provide for an ACL of 1888 initiator HIT to responder HIT. This ACL SHOULD also include 1889 preferred transform and local lifetimes. For HITs with HAAs, 1890 wildcarding SHOULD be supported. Thus if a Community of Interest, 1891 like Banking, gets an RAA, a single ACL could be used. A global 1892 wildcard would represent the general policy to be used. Policy 1893 selection would be from most specific to most general. 1895 The value of K used in the HIP R1 packet can also vary by policy. K 1896 should never be greater than 20, but for trusted partners it could be 1897 as low as 0. 1899 Responders would need a similar ACL, representing which hosts they 1900 accept HIP exchanges, and the preferred transform and local 1901 lifetimes. Wildcarding SHOULD be support supported for this ACL 1902 also. 1904 13. Security Considerations 1906 HIP is designed to provide secure authentication of hosts and to 1907 provide a fast key exchange for IPsec ESP. HIP also attempts to 1908 limit the exposure of the host to various denial-of-service and man- 1909 in-the-middle attacks. In so doing, HIP itself is subject to its own 1910 DoS and MitM attacks that potentially could be more damaging to a 1911 host's ability to conduct business as usual. 1913 HIP enabled ESP is IP address independent. This might seem to make 1914 it easier for an attacker, but ESP with replay protection is already 1915 as well protected as possible, and the removal of the IP address as a 1916 check should not increase the exposure of ESP to DoS attacks. 1917 Furthermore, this is in line with the forthcoming revision of ESP. 1919 Denial-of-service attacks take advantage of the cost of start of 1920 state for a protocol on the responder compared to the 'cheapness' on 1921 the initiator. HIP makes no attempt to increase the cost of the 1922 start of state on the initiator, but makes an effort to reduce the 1923 cost to the responder. This is done by having the responder start 1924 the 3-way cookie exchange instead of the initiator, making the HIP 1925 protocol 4 packets long. In doing this, packet 2 becomes a 'stock' 1926 packet that the responder MAY use many times. The duration of use is 1927 a paranoia versus throughput concern. Using the same Diffie- Hellman 1928 values and random puzzle I has some risk. This risk needs to be 1929 balanced against a potential storm of HIP I1 packets. 1931 This shifting of the start of state cost to the initiator in creating 1932 the I2 HIP packet, presents another DoS attack. The attacker spoofs 1933 the I1 HIP packet and the responder sends out the R1 HIP packet. 1934 This could conceivably tie up the 'initiator' with evaluating the R1 1935 HIP packet, and creating the I2 HIP packet. The defense against this 1936 attack is to simply ignore any R1 packet where a corresponding I1 or 1937 ESP data was not sent. 1939 A second form of DoS attack arrives in the I2 HIP packet. Once the 1940 attacking initiator has solved the cookie challenge, it can send 1941 packets with spoofed IP source addresses with either invalid 1942 encrypted HIP payload component or a bad HIP SIG. This would take 1943 resources in the responder's part to reach the point to discover that 1944 the I2 packet cannot be completely processed. The defense against 1945 this attack is after N bad I2 packets, the responder would discard 1946 any I2s that contain the given Initiator HIT. Thus will shut down 1947 the attack. The attacker would have to request another R1 and use 1948 that to launch a new attack. The responder could up the value of K 1949 while under attack. On the downside, valid I2s might get dropped 1950 too. 1952 A third form of DoS attack is emulating the restart of state after a 1953 reboot of one of the partners. To protect against such an attack, a 1954 system Birthday is included in the R1 and I2 packets to prove loss of 1955 state to a peer. The inclusion of the Birthday creates a very 1956 deterministic process for state restart. Any other action is a DoS 1957 attack. 1959 A fourth form of DoS attack is emulating the end of state. HIP has 1960 no end of state packet. It relies on a local policy timer to end 1961 state. 1963 Man-in-the-middle attacks are difficult to defend against, without 1964 third-party authentication. A skillful MitM could easily handle all 1965 parts of HIP; but HIP indirectly provides the following protection 1966 from a MitM attack. If the responder's HI is retrieved from a signed 1967 DNS zone, a certificate, or through some other secure means, the 1968 initiator can use this to validate the R1 HIP packet. 1970 Likewise, if the initiator's HI is in a secure DNS zone, a trusted 1971 certificate, or otherwise securely available, the responder can 1972 retrieve it after it gets the I2 HIP packet and validate that. 1973 However, since an initiator may choose to use an anonymous HI, it 1974 knowingly risks a MitM attack. The responder may choose not to 1975 accept a HIP exchange with an anonymous initiator. 1977 New SPIs and rekeying provide another opportunity for an attacker. 1978 Replay protection is included to prevent a system from accepting an 1979 old new SPI packet. There is still the opening for an attacker to 1980 produce a packet with exactly the right Sequence Number and old SPI 1981 with a malformed signature, consuming considerable computing 1982 resources. All implementations must design to mitigate this attack. 1983 If ESP protected datagrams are still being received, there is an 1984 obvious attack. If the peer is quiet, it is easier for an attacker 1985 to launch this sort of attack, but again, the system should be able 1986 to recognize a regular influx of malformed signatures and take some 1987 action. 1989 There is a similar attack centered on the readdress packet. Similar 1990 defense mechanisms are appropriate here. 1992 Since not all hosts will ever support HIP, ICMP 'Destination Protocol 1993 Unreachable' are to be expected and present a DoS attack. Against an 1994 Initiator, the attack would look like the responder does not support 1995 HIP, but shortly after receiving the ICMP message, the initiator 1996 would receive a valid R1 HIP packet. Thus to protect against this 1997 attack, an initiator should not react to an ICMP message until a 1998 reasonable delta time to get the real responder's R1 HIP packet. A 1999 similar attack against the responder is more involved. First an ICMP 2000 message is expected if the I1 was a DoS attack and the real owner of 2001 the spoofed IP address does not support HIP. The responder SHOULD 2002 NOT act on this ICMP message to remove the minimal state from the R1 2003 HIP packet (if it has one), but wait for either a valid I2 HIP packet 2004 or the natural timeout of the R1 HIP packet. This is to allow for a 2005 sophisticated attacker that is trying to break up the HIP exchange. 2006 Likewise, the initiator should ignore any ICMP message while waiting 2007 for an R2 HIP packet, deleting state only after a natural timeout. 2009 14. IANA Considerations 2011 IANA has assigned IP Protocol number TBD to HIP. 2013 15. Acknowledgments 2015 The drive to create HIP came to being after attending the MALLOC 2016 meeting at IETF 43. Baiju Patel and Hilarie Orman really gave the 2017 original author, Bob Moskowitz, the assist to get HIP beyond 5 2018 paragraphs of ideas. It has matured considerably since the early 2019 drafts thanks to extensive input from IETFers. Most importantly, its 2020 design goals are articulated and are different from other efforts in 2021 this direction. Particular mention goes to the members of the 2022 NameSpace Research Group of the IRTF. Noel Chiappa provided the 2023 framework for LSIs and Kieth Moore the impetuous to provide 2024 resolvability. Steve Deering provided encouragement to keep working, 2025 as a solid proposal can act as a proof of ideas for a research group. 2027 Many others contributed; extensive security tips were provided by 2028 Steve Bellovin. Rob Austein kept the DNS parts on track. Paul 2029 Kocher taught the original authors, Bob Moskowitz, how to make the 2030 cookie exchange expensive for the Initiator to respond, but easy for 2031 the Responder to validate. Bill Sommerfeld supplied the Birthday 2032 concept to simplify reboot management. Rodney Thayer and Hugh 2033 Daniels provide extensive feedback. In the early times of this 2034 draft, John Gilmore kept Bob Moskowitz challenged to provide 2035 something of value. 2037 During the later stages of this document, when the editing baton was 2038 transfered to Pekka Nikander, the input from the early implementors 2039 were invaluable. Without having actual implementations, this 2040 document would not be on the level it is now. 2042 References 2044 [1] Mockapetris, P., "Domain names - implementation and 2045 specification", STD 13, RFC 1035, November 1987. 2047 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2048 Levels", BCP 14, RFC 2119, March 1997. 2050 [3] Hinden, R. and S. Deering, "IP Version 6 Addressing 2051 Architecture", RFC 2373, July 1998. 2053 [4] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP 2054 and AH", RFC 2404, November 1998. 2056 [5] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload 2057 (ESP)", RFC 2406, November 1998. 2059 [6] Maughan, D., Schneider, M. and M. Schertler, "Internet Security 2060 Association and Key Management Protocol (ISAKMP)", RFC 2408, 2061 November 1998. 2063 [7] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, 2064 November 1998. 2066 [8] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", 2067 RFC 2451, November 1998. 2069 [9] Housley, R., Ford, W., Polk, T. and D. Solo, "Internet X.509 2070 Public Key Infrastructure Certificate and CRL Profile", RFC 2071 2459, January 1999. 2073 [10] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 2074 Specification", RFC 2460, December 1998. 2076 [11] Eastlake, D., "Domain Name System Security Extensions", RFC 2077 2535, March 1999. 2079 [12] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System 2080 (DNS)", RFC 2536, March 1999. 2082 [13] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, 2083 August 1999. 2085 [14] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 2086 Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 2087 3526, May 2003. 2089 [15] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 2090 draft-ietf-ipsec-ikev2-08 (work in progress), June 2003. 2092 [16] Bellovin, S. and W. Aiello, "Just Fast Keying (JFK)", 2093 draft-ietf-ipsec-jfk-04 (work in progress), July 2002. 2095 [17] NIST, "FIPS PUB 180-1: Secure Hash Standard", April 1995. 2097 [18] Moskowitz, R. and P. Nikander, "Host Identity Protocol 2098 Architecture", draft-moskowitz-hip-arch-03 (work in progress), 2099 May 2003. 2101 [19] Moskowitz, R. and P. Nikander, "Using Domain Name System (DNS) 2102 with Host Identity Protocol (HIP)", draft-nikander-hip-dns-00 2103 (work in progress), June 2003. 2105 [20] Moskowitz, R., "Host Identity Payload Implementation", 2106 draft-moskowitz-hip-impl-02 (work in progress), January 2001. 2108 [21] Crosby, SA. and DS. Wallach, "Denial of Service via Algorithmic 2109 Complexity Attacks", in Proceedings of Usenix Security 2110 Symposium 2003, Washington, DC., August 2003. 2112 Authors' Addresses 2114 Robert Moskowitz 2115 ICSAlabs, a Division of TruSecure Corporation 2116 1000 Bent Creek Blvd, Suite 200 2117 Mechanicsburg, PA 2118 USA 2120 EMail: rgm@icsalabs.com 2122 Pekka Nikander 2123 Ericsson Research Nomadic Lab 2125 JORVAS FIN-02420 2126 FINLAND 2128 Phone: +358 9 299 1 2129 EMail: pekka.nikander@nomadiclab.com 2130 Petri Jokela 2131 Ericsson Research Nomadic Lab 2133 JORVAS FIN-02420 2134 FINLAND 2136 Phone: +358 9 299 1 2137 EMail: petri.jokela@nomadiclab.com 2139 Appendix A. Backwards compatibility API issues 2141 Tom Henderson floated again the thought that that the LSI could be 2142 completely local and does not need to be exchanged. Applications 2143 continue to use IP addresses in socket calls, and kernel does 2144 whatever NATting (including application NATting) is required. It was 2145 pointed out that this approach was going to be prone to some kinds of 2146 data flows escaping the HIP protection, unless the local housekeeping 2147 in an implementation was especially good. Example: FTP opens control 2148 connection to IP address. One or both parties move. FTP later opens 2149 data connection to the old IP address. Kernel must identify that the 2150 application really means to connect to the host that was previously 2151 at that IP address -- but obviously if the old address is reused by 2152 another host, this becomes difficult. 2154 Related to this, the discussion also opened up the question of DNS 2155 resolution. Should the HIT/LSI be returned to applications as a 2156 (spoofed) address in the resolution process, allowing apps to use the 2157 socket API with HIT or LSI values instead of an IP address? While 2158 this seems to be the original intention of LSIs, there are a couple 2159 of difficulties especially in the IPv4 case: 2161 How does kernel know whether value being passed in a socket call 2162 is an IP address or an LSI? The fact that a name resolver library 2163 gave an application an LSI is no guarantee that the application 2164 will use that information in its socket call. It may also have 2165 cached some IP address from before or received an IP address as 2166 side information. This difficulty is now relieved as the LSIs are 2167 constrained to the well-known private subnet space. 2169 Handing an LSI may confuse legacy applications that assume that 2170 what is being passed to them is an IP address. Good examples of 2171 this are diagnostic tools such as dig and ping. The conclusion is 2172 that HIP should most not be used with diagnostic applications. 2174 What does kernel do with an LSI that it cannot map to an address 2175 based on information that it has locally cached? 2177 It seems that some modification to the resolver library (to 2178 explicitly convey HIP information rather than spoofing IP addresses), 2179 as well as modifications to socket API to explicitly let the kernel 2180 know that the application is HIP aware, are the cleanest long-term 2181 solution, but what to do about legacy applications?? -- still 2182 partially an open issue. The HUT team has been considering these 2183 problems. 2185 Appendix B. Probabilities of HIT collisions 2187 The birthday paradox sets a bound for the expectation of collisions. 2188 It is based on the square root of the number of values. A 64-bit 2189 hash, then, would put the chances of a collision at 50-50 with 2^32 2190 hosts (4 billion). A 1% chance of collision would occur in a 2191 population of 640M and a .001% collision chance in a 20M population. 2192 A 128 bit hash will have the same .001% collision chance in a 9x10^16 2193 population. 2195 Appendix C. Probabilities in the cookie calculation 2197 A question: Is it guaranteed that the Initiator is able to solve the 2198 puzzle in this way when the K value is large? 2200 Answer: No, it is not guaranteed. But it is not guaranteed even in 2201 the old mechanism, since the Initiator may start far away from J and 2202 arrive to J after far too many steps. If we wanted to make sure that 2203 the Initiator finds a value, we would need to give some hint of a 2204 suitable J, and I don't think we want to do that. 2206 In general, if we model the hash function with a random function, the 2207 probability that one iteration gives are result with K zero bits is 2208 2^-K. Thus, the probablity that one iteration does *not* give K zero 2209 bits is (1 - 2^-K). Consequently, the probablity that 2^K iterations 2210 does not give K zero bits is (1 - 2^-K)^(2^K). 2212 Since my calculus starts to be rusty, I made a small experiment and 2213 found out that 2215 lim (1 - 2^-k)^(2^k) = 0.36788 2216 k->inf 2218 lim (1 - 2^-k)^(2^(k+1)) = 0.13534 2219 k->inf 2221 lim (1 - 2^-k)^(2^(k+2)) = 0.01832 2222 k->inf 2224 lim (1 - 2^-k)^(2^(k+3)) = 0.000335 2225 k->inf 2227 Thus, if hash functions were random functions, we would need about 2228 2^(K+3) iterations to make sure that the probability of a failure is 2229 less than 1% (actually less than 0.04%). Now, since my perhaps 2230 flawed understanding of hash functions is that they are "flatter" 2231 than random functions, 2^(K+3) is probably an overkill. OTOH, the 2232 currently suggested 2^K is clearly too little. The draft has been 2233 changed to read 2^(K+2). 2235 Appendix D. Using responder cookies 2237 As mentioned in Section 4.1.1, the responder may delay state creation 2238 and still reject most spoofed I2s by using a number of pre-calculated 2239 R1s and a local selection function. This appendix defines one 2240 possible implementation in detail. The purpose of this appendix is 2241 to give the implementators an idea on how to implement the mechanism. 2242 The method described in this appendix SHOULD NOT be used in any real 2243 implementation. If the implementation is based on this appendix, it 2244 SHOULD contain some local modification that makes an attacker's task 2245 harder. 2247 The basic idea is to create a cheap, varying local mapping function 2248 f: 2250 f( IP-I, IP-R, HIT-I, HIT-R ) -> cookie-index 2252 That is, given the Initiators and Responders IP addresses and HITs, 2253 the function returns an index to a cookie. When processing an I1, 2254 the cookie is embedded in an pre-computed R1, and the Responder 2255 simply sends that particular R1 to the Initiator. When processing an 2256 I2, the cookie may still be embedded in the R1, or the R1 may be 2257 depracated (and replaced with a new one), but the cookie is still 2258 there. If the received cookie does not match with the R1 or saved 2259 cookie, the I2 is simply dropped. That prevents the Initiator from 2260 generating spoofed I2s with a probability that depends on the number 2261 of pre-computed R1s. 2263 As a concrete example, let us assume that the Responder has an array 2264 of R1s. Each slot in the array contains a timestamp, an R1, and an 2265 old cookie that was sent in the previous R1 that occupied that 2266 particular slot. The Responder replaces one R1 in the array every 2267 few minutes, thereby replacing all the R1s gradually. 2269 To create a varying mapping function, the Responder generates a 2270 random number every few minutes. The octets in the IP addresses and 2271 HITs are XORed together, and finally the result is XORed with the 2272 random number. Using pseudo-code, the function looks like the 2273 following. 2275 Pre-computation: 2276 r1 := random number 2278 Index computation: 2279 index := r1 XOR hit_r[0] XOR hit_r[1] XOR ... XOR hit_r[15] 2280 index := index XOR hit_i[0] XOR hit_i[1] XOR ... XOR hit_i[15] 2281 index := index XOR ip_r[0] XOR ip_r[1] XOR ... XOR ip_r[15] 2282 index := index XOR ip_i[0] XOR ip_i[1] XOR ... XOR ip_i[15] 2284 The index gives the slot used in the array. 2286 It is possible that an Initator receives an I1, and while it is 2287 computing I2, the Responder deprecates an R1 and/or chooses a new 2288 random number for the mapping function. Therefore the Responder must 2289 remember the cookies used in deprecated R1s and the previous random 2290 number. 2292 To check an received I2, the Responder can use a simple algorithm, 2293 expressed in pseudo-code as follows. 2295 If I2.hit_r does not match my_hits, drop the packet. 2297 index := compute_index(current_random_number, I2) 2298 If current_cookie[index] == I2.cookie, go to cookie check. 2299 If previous_cookie[index] == I2.cookie, go to cookie check. 2301 index := compute_index(previous_random_number, I2) 2302 If current_cookie[index] == I2.cookie, go to cookie check. 2303 If previous_cookie[index] == I2.cookie, go to cookie check. 2305 Drop packet. 2307 cookie_check: 2308 V := Ltrunc( SHA-1( I2.I, I2.hit_i, I2.hit_r, I2.J ), K ) 2309 if V != 0, drop the packet. 2311 Whenever the Responder receives an I2 that fails on the index check, 2312 it can simply drop the packet on the floor and forget about it. New 2313 I2s with the same or other spoofed parameters will get dropped with a 2314 reasonable probability and minimal effort. 2316 If a Responder receives an I2 that passes the index check but fails 2317 on the puzzle check, it should create a state indicating this. After 2318 two or three failures the Responder should cease checking the puzzle 2319 but drop the packets directly. This saves the Responder from the 2320 SHA-1 calculations. Such block should not last long, however, or 2321 there would be a danger that a legitimite Initiator could be blocked 2322 from getting connections. 2324 A key for the success of the defined scheme is that the mapping 2325 function must be considerably cheaper than computing SHA-1. It also 2326 must detect any changes in the IP addresses, and preferably most 2327 changes in the HITs. Checking the HITs is not that essential, 2328 though, since HITs are included in the cookie computation, too. 2330 The effectivity of the method can be varied by varying the size of 2331 the array containing pre-computed R1s. If the array is large, the 2332 probability that an I2 with a spoofed IP address or HIT happens to 2333 map to the same slot is fairly slow. However, a large array means 2334 that each R1 has a fairly long life time, thereby allowing an 2335 attacker to utilize one solved puzzle for a longer time. 2337 Intellectual Property Statement 2339 The IETF takes no position regarding the validity or scope of any 2340 intellectual property or other rights that might be claimed to 2341 pertain to the implementation or use of the technology described in 2342 this document or the extent to which any license under such rights 2343 might or might not be available; neither does it represent that it 2344 has made any effort to identify any such rights. Information on the 2345 IETF's procedures with respect to rights in standards-track and 2346 standards-related documentation can be found in BCP-11. Copies of 2347 claims of rights made available for publication and any assurances of 2348 licenses to be made available, or the result of an attempt made to 2349 obtain a general license or permission for the use of such 2350 proprietary rights by implementors or users of this specification can 2351 be obtained from the IETF Secretariat. 2353 The IETF invites any interested party to bring to its attention any 2354 copyrights, patents or patent applications, or other proprietary 2355 rights which may cover technology that may be required to practice 2356 this standard. Please address the information to the IETF Executive 2357 Director. 2359 Full Copyright Statement 2361 Copyright (C) The Internet Society (2003). All Rights Reserved. 2363 This document and translations of it may be copied and furnished to 2364 others, and derivative works that comment on or otherwise explain it 2365 or assist in its implementation may be prepared, copied, published 2366 and distributed, in whole or in part, without restriction of any 2367 kind, provided that the above copyright notice and this paragraph are 2368 included on all such copies and derivative works. However, this 2369 document itself may not be modified in any way, such as by removing 2370 the copyright notice or references to the Internet Society or other 2371 Internet organizations, except as needed for the purpose of 2372 developing Internet standards in which case the procedures for 2373 copyrights defined in the Internet Standards process must be 2374 followed, or as required to translate it into languages other than 2375 English. 2377 The limited permissions granted above are perpetual and will not be 2378 revoked by the Internet Society or its successors or assignees. 2380 This document and the information contained herein is provided on an 2381 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2382 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2383 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2384 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2385 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2387 Acknowledgement 2389 Funding for the RFC Editor function is currently provided by the 2390 Internet Society.