idnits 2.17.1 draft-ietf-hip-base-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 4023. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 4000. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 4007. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 4013. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 abstract seems to contain references ([24], [REF]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1570 has weird spacing: '...c Value the ...' == 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: The UPDATE packet contains zero or one SEQ parameter. The presence of a SEQ parameter indicates that the receiver MUST ack the UPDATE. An UPDATE that does not contain a SEQ parameter is simply an ACK of a previous UPDATE and itself MUST not be acked. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: All compliant implementations MUST produce R1 packets. An R1 packet MAY be precomputed. An R1 packet MAY be reused for time Delta T, which is implementation dependent. R1 information MUST not be discarded until Delta S after T. Time S is the delay needed for the last I2 to arrive back to the Responder. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 23, 2005) is 6881 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'REF' on line 225 -- Looks like a reference, but probably isn't: 'RFC2536' on line 1671 -- Looks like a reference, but probably isn't: 'RFC3110' on line 1672 == Unused Reference: '7' is defined on line 3664, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 3696, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 3706, but no explicit reference was found in the text == Unused Reference: '28' is defined on line 3734, but no explicit reference was found in the text == Unused Reference: '31' is defined on line 3746, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1885 (ref. '4') (Obsoleted by RFC 2463) ** Obsolete normative reference: RFC 2408 (ref. '7') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2409 (ref. '8') (Obsoleted by RFC 4306) ** Downref: Normative reference to an Informational RFC: RFC 2412 (ref. '9') ** Obsolete normative reference: RFC 2434 (ref. '10') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2460 (ref. '11') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2535 (ref. '12') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 2898 (ref. '14') (Obsoleted by RFC 8018) ** Obsolete normative reference: RFC 3484 (ref. '16') (Obsoleted by RFC 6724) ** Obsolete normative reference: RFC 3513 (ref. '17') (Obsoleted by RFC 4291) == Outdated reference: A later version (-10) exists of draft-ietf-ipsec-esp-v3-05 == Outdated reference: A later version (-17) exists of draft-ietf-ipsec-ikev2-07 == Outdated reference: A later version (-06) exists of draft-ietf-radext-rfc2486bis-03 -- Possible downref: Non-RFC (?) normative reference: ref. '23' -- Possible downref: Normative reference to a draft: ref. '24' == Outdated reference: A later version (-06) exists of draft-moskowitz-hip-arch-03 == Outdated reference: A later version (-09) exists of draft-ietf-hip-dns-00 -- No information found for draft-nikander-hip-nat - is the name correct? == Outdated reference: A later version (-09) exists of draft-nikander-esp-beet-mode-00 == Outdated reference: A later version (-03) exists of draft-henderson-hip-applications-00 Summary: 14 errors (**), 0 flaws (~~), 18 warnings (==), 14 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 25, 2005 Corporation 5 P. Nikander 6 P. Jokela (editor) 7 Ericsson Research NomadicLab 8 T. Henderson 9 The Boeing Company 10 June 23, 2005 12 Host Identity Protocol 13 draft-ietf-hip-base-03 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on December 25, 2005. 40 Copyright Notice 42 Copyright (C) The Internet Society (2005). 44 Abstract 46 This memo specifies the details of the Host Identity Protocol (HIP). 47 HIP provides a rapid exchange of Host Identities (public keys) 48 between hosts and uses a Sigma-compliant [REF] Diffie-Hellman key 49 exchange to establish shared secrets between such endpoints. The 50 protocol is designed to be resistant to Denial-of-Service (DoS) and 51 Man-in-the-middle (MitM) attacks, and when used together with another 52 suitable security protocol, such as Encapsulated Security Payload 53 (ESP) [24], it provides encryption and/or authentication protection 54 for upper layer protocols such as TCP and UDP, while enabling 55 continuity of communications across network layer address changes. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 60 1.1 A New Name Space and Identifiers . . . . . . . . . . . . . 5 61 1.2 The HIP Base Exchange . . . . . . . . . . . . . . . . . . 5 62 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . 7 63 2.1 Requirements Terminology . . . . . . . . . . . . . . . . . 7 64 2.2 Notation . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 2.3 Definitions . . . . . . . . . . . . . . . . . . . . . . . 7 66 3. Host Identifier (HI) and its Representations . . . . . . . . 8 67 3.1 Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 8 68 3.2 Generating a HIT from a HI . . . . . . . . . . . . . . . . 9 69 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 11 70 4.1 Creating a HIP Association . . . . . . . . . . . . . . . . 11 71 4.1.1 HIP Cookie Mechanism . . . . . . . . . . . . . . . . . 12 72 4.1.2 Authenticated Diffie-Hellman Protocol . . . . . . . . 14 73 4.1.3 HIP Replay Protection . . . . . . . . . . . . . . . . 15 74 4.1.4 Refusing a HIP Exchange . . . . . . . . . . . . . . . 16 75 4.2 Updating a HIP Association . . . . . . . . . . . . . . . . 16 76 4.3 Error Processing . . . . . . . . . . . . . . . . . . . . . 17 77 4.4 HIP State Machine . . . . . . . . . . . . . . . . . . . . 17 78 4.4.1 HIP States . . . . . . . . . . . . . . . . . . . . . . 18 79 4.4.2 HIP State Processes . . . . . . . . . . . . . . . . . 18 80 4.4.3 Simplified HIP State Diagram . . . . . . . . . . . . . 22 81 4.5 User Data Considerations . . . . . . . . . . . . . . . . . 24 82 4.5.1 TCP and UDP Pseudo-header Computation for User Data . 24 83 4.5.2 Sending Data on HIP Packets . . . . . . . . . . . . . 24 84 4.5.3 Transport Formats . . . . . . . . . . . . . . . . . . 24 85 4.5.4 Reboot and SA Timeout Restart of HIP . . . . . . . . . 24 86 4.6 Certificate Distribution . . . . . . . . . . . . . . . . . 25 87 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 26 88 5.1 Payload Format . . . . . . . . . . . . . . . . . . . . . . 26 89 5.1.1 HIP Controls . . . . . . . . . . . . . . . . . . . . . 27 90 5.1.2 Checksum . . . . . . . . . . . . . . . . . . . . . . . 28 91 5.1.3 HIP Fragmentation Support . . . . . . . . . . . . . . 28 92 5.1.4 Solving the Puzzle . . . . . . . . . . . . . . . . . . 28 93 5.2 HIP Parameters . . . . . . . . . . . . . . . . . . . . . . 30 94 5.2.1 TLV Format . . . . . . . . . . . . . . . . . . . . . . 32 95 5.2.2 Defining New Parameters . . . . . . . . . . . . . . . 33 96 5.2.3 R1_COUNTER . . . . . . . . . . . . . . . . . . . . . . 34 97 5.2.4 PUZZLE . . . . . . . . . . . . . . . . . . . . . . . . 35 98 5.2.5 SOLUTION . . . . . . . . . . . . . . . . . . . . . . . 36 99 5.2.6 DIFFIE_HELLMAN . . . . . . . . . . . . . . . . . . . . 36 100 5.2.7 HIP_TRANSFORM . . . . . . . . . . . . . . . . . . . . 37 101 5.2.8 HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 38 102 5.2.9 HMAC . . . . . . . . . . . . . . . . . . . . . . . . . 40 103 5.2.10 HMAC_2 . . . . . . . . . . . . . . . . . . . . . . . 40 104 5.2.11 HIP_SIGNATURE . . . . . . . . . . . . . . . . . . . 41 105 5.2.12 HIP_SIGNATURE_2 . . . . . . . . . . . . . . . . . . 41 106 5.2.13 SEQ . . . . . . . . . . . . . . . . . . . . . . . . 42 107 5.2.14 ACK . . . . . . . . . . . . . . . . . . . . . . . . 43 108 5.2.15 ENCRYPTED . . . . . . . . . . . . . . . . . . . . . 44 109 5.2.16 NOTIFY . . . . . . . . . . . . . . . . . . . . . . . 45 110 5.2.17 ECHO_REQUEST . . . . . . . . . . . . . . . . . . . . 48 111 5.2.18 ECHO_RESPONSE . . . . . . . . . . . . . . . . . . . 49 112 5.3 HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 49 113 5.3.1 I1 - the HIP Initiator Packet . . . . . . . . . . . . 50 114 5.3.2 R1 - the HIP Responder Packet . . . . . . . . . . . . 50 115 5.3.3 I2 - the Second HIP Initiator Packet . . . . . . . . . 52 116 5.3.4 R2 - the Second HIP Responder Packet . . . . . . . . . 53 117 5.3.5 UPDATE - the HIP Update Packet . . . . . . . . . . . . 54 118 5.3.6 NOTIFY - the HIP Notify Packet . . . . . . . . . . . . 55 119 5.3.7 CLOSE - the HIP association closing packet . . . . . . 55 120 5.3.8 CLOSE_ACK - the HIP Closing Acknowledgment Packet . . 55 121 5.4 ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 56 122 5.4.1 Invalid Version . . . . . . . . . . . . . . . . . . . 56 123 5.4.2 Other Problems with the HIP Header and Packet 124 Structure . . . . . . . . . . . . . . . . . . . . . . 56 125 5.4.3 Invalid Cookie Solution . . . . . . . . . . . . . . . 56 126 5.4.4 Non-existing HIP Association . . . . . . . . . . . . . 57 127 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . 58 128 6.1 Processing Outgoing Application Data . . . . . . . . . . . 58 129 6.2 Processing Incoming Application Data . . . . . . . . . . . 59 130 6.3 HMAC and SIGNATURE Calculation and Verification . . . . . 60 131 6.3.1 HMAC Calculation . . . . . . . . . . . . . . . . . . . 60 132 6.3.2 Signature Calculation . . . . . . . . . . . . . . . . 61 133 6.4 HIP KEYMAT Generation . . . . . . . . . . . . . . . . . . 62 134 6.5 Initiation of a HIP Exchange . . . . . . . . . . . . . . . 63 135 6.5.1 Sending Multiple I1s in Parallel . . . . . . . . . . . 64 136 6.5.2 Processing Incoming ICMP Protocol Unreachable 137 Messages . . . . . . . . . . . . . . . . . . . . . . . 64 138 6.6 Processing Incoming I1 Packets . . . . . . . . . . . . . . 65 139 6.6.1 R1 Management . . . . . . . . . . . . . . . . . . . . 66 140 6.6.2 Handling Malformed Messages . . . . . . . . . . . . . 66 141 6.7 Processing Incoming R1 Packets . . . . . . . . . . . . . . 66 142 6.7.1 Handling Malformed Messages . . . . . . . . . . . . . 68 143 6.8 Processing Incoming I2 Packets . . . . . . . . . . . . . . 68 144 6.8.1 Handling Malformed Messages . . . . . . . . . . . . . 71 146 6.9 Processing Incoming R2 Packets . . . . . . . . . . . . . . 71 147 6.10 Sending UPDATE Packets . . . . . . . . . . . . . . . . . 71 148 6.11 Receiving UPDATE Packets . . . . . . . . . . . . . . . . 72 149 6.11.1 Handling a SEQ paramaeter in a received UPDATE 150 message . . . . . . . . . . . . . . . . . . . . . . 72 151 6.11.2 Handling an ACK Parameter in a Received UPDATE 152 Packet . . . . . . . . . . . . . . . . . . . . . . . 73 153 6.12 Processing NOTIFY Packets . . . . . . . . . . . . . . . 74 154 6.13 Processing CLOSE Packets . . . . . . . . . . . . . . . . 74 155 6.14 Processing CLOSE_ACK Packets . . . . . . . . . . . . . . 74 156 6.15 Dropping HIP Associations . . . . . . . . . . . . . . . 74 157 7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 75 158 8. Security Considerations . . . . . . . . . . . . . . . . . . 76 159 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 79 160 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 84 161 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 85 162 11.1 Normative References . . . . . . . . . . . . . . . . . . 85 163 11.2 Informative References . . . . . . . . . . . . . . . . . 86 164 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 87 165 A. Probabilities of HIT Collisions . . . . . . . . . . . . . . 89 166 B. Probabilities in the Cookie Calculation . . . . . . . . . . 90 167 C. Using Responder Cookies . . . . . . . . . . . . . . . . . . 91 168 D. Generating a HIT from a HI . . . . . . . . . . . . . . . . . 92 169 E. Example Checksums for HIP Packets . . . . . . . . . . . . . 93 170 E.1 IPv6 HIP Example (I1) . . . . . . . . . . . . . . . . . . 93 171 E.2 IPv4 HIP Packet (I1) . . . . . . . . . . . . . . . . . . . 93 172 E.3 TCP Segment . . . . . . . . . . . . . . . . . . . . . . . 93 173 F. 384-bit Group . . . . . . . . . . . . . . . . . . . . . . . 95 174 Intellectual Property and Copyright Statements . . . . . . . 96 176 1. Introduction 178 This memo specifies the details of the Host Identity Protocol (HIP). 179 A high-level description of the protocol and the underlying 180 architectural thinking is available in the separate HIP architecture 181 description [25]. Briefly, the HIP architecture proposes an 182 alternative to the dual use of IP addresses as "locators" (routing 183 labels) and "identifiers" (endpoint, or host, identifiers). Instead, 184 in HIP, the host identifiers are public keys of a public/private key 185 pair. By using public keys (and their representations) as host 186 identifiers, to which higher layer protocols are bound instead of an 187 IP address, dynamic changes to IP address sets can be directly 188 authenticated between hosts, and if desired, strong authentication 189 between hosts at the TCP/IP stack level can be obtained. 191 This memo specifies the base HIP protocol ("base exchange") used 192 between hosts to establish communications context (keying material, 193 per-packet context tags) prior to communications. It also defines a 194 packet format and procedures for updating an active HIP association. 195 Other elements of the HIP architecture are specified in other 196 documents, including how HIP can be combined with a variant of the 197 Encapsulating Security Payload (ESP) for encryption and/or 198 authentication protection, mobility and host multihoming extensions, 199 DNS extensions for storing host identities, HIP-related 200 infrastructure in the network, techniques for NAT traversal, and 201 possibly other future extensions. 203 1.1 A New Name Space and Identifiers 205 The Host Identity Protocol introduces a new namespace, the Host 206 Identity. Some ramifications of this new namespace are explained in 207 the companion document, the HIP architecture [25] specification. 209 There are two main representations of the Host Identity, the full 210 Host Identifier (HI) and the Host Identity Tag (HIT). The HI is a 211 public key and directly represents the Identity. Since there are 212 different public key algorithms that can be used with different key 213 lengths, the HI is not good for use as a packet identifier, or as an 214 index into the various operational tables needed to support HIP. 215 Consequently, a hash of the HI, the Host Identity Tag (HIT), becomes 216 the operational representation. It is 128 bits long and is used in 217 the HIP payloads and to index the corresponding state in the end 218 hosts. The HIT has an important security property in that it is 219 self-certifying (see Section 3). 221 1.2 The HIP Base Exchange 223 The HIP base exchange is a two-party cryptographic protocol used to 224 establish communications context between hosts. The base exchange is 225 a Sigma-compliant [REF] four packet exchange. The first party is 226 called the Initiator and the second party the Responder. The four- 227 packet design helps to make HIP DoS resilient. The protocol 228 exchanges Diffie-Hellman keys in the 2nd and 3rd packets, and 229 authenticates the parties in the 3rd and 4th packets. Additionally, 230 the Responder starts a cookie puzzle exchange in the 2nd packet, with 231 the Initiator completing it in the 3rd packet before the Responder 232 stores any state from the exchange. 234 The exchange can use the Diffie-Hellman output to encrypt the Host 235 Identity of the Initiator in packet 3 (although Aura et al. [29] 236 notes that such operation may interfere with packet-inspecting 237 middleboxes), or the Host Identity may instead be sent unencrypted. 238 The Responder's Host Identity is not protected. It should be noted, 239 however, that both the Initiator's and the Responder's HITs are 240 transported as such (in cleartext) in the packets, allowing an 241 eavesdropper with a priori knowledge about the parties to verify 242 their identities. 244 Data packets start to flow after the 4th packet. The 3rd and 4th HIP 245 packets may carry a data payload in the future. However, the details 246 of this are to be defined later as more implementation experience is 247 gained. 249 Finally, HIP is designed as an end-to-end authentication and key 250 establishment protocol, to be used with Encapsulated Security Payload 251 (ESP) [24] and other end-to-end security protocols. The base 252 protocol lacks the details for security association management and 253 much of the fine-grained policy control found in Internet Key 254 Exchange IKE RFC2409 [8] that allows IKE to support complex gateway 255 policies. Thus, HIP is not a replacement for IKE. 257 2. Terms and Definitions 259 2.1 Requirements Terminology 261 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 262 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 263 document are to be interpreted as described in RFC2119 [5]. 265 2.2 Notation 267 [x] indicates that x is optional. 269 {x} indicates that x is encrypted. 271 y indicates that "x" is encrypted with the key "y". 273 --> signifies "Initiator to Responder" communication (requests). 275 <-- signifies "Responder to Initiator" communication (replies). 277 | signifies concatenation of information-- e.g. X | Y is the 278 concatenation of X with Y. 280 Ltrunc (SHA-1(), K) denotes the lowest order K bits of the SHA-1 281 result. 283 (This section needs work.) 285 2.3 Definitions 287 (This section needs work. Examples from IKE include "Perfect Forward 288 Secrecy", "Security Association") 290 Unused Association Lifetime (UAL): Implementation-specific time for 291 which, if no packet is sent or received for this time interval, a 292 host MAY begin to tear down an active association. 294 HIT Hash Algorithm: hash algorithm used to generate a Host Identity 295 Tag (HIT) from the Host Identity public key. Currently SHA-1 [23] is 296 used. 298 3. Host Identifier (HI) and its Representations 300 A public key of an asymmetric key pair is used as the Host Identifier 301 (HI). Correspondingly, the host itself is defined as the entity that 302 holds the private key from the key pair. See the HIP architecture 303 specification [25] for more details about the difference between an 304 identity and the corresponding identifier. 306 HIP implementations MUST support the Rivest Shamir Adelman (RSA) [15] 307 public key algorithm, and SHOULD support the Digital Signature 308 Algorithm (DSA) [13] algorithm; other algorithms MAY be supported. 310 A hash of the HI, the Host Identity Tag (HIT), is used in protocols 311 to represent the Host Identity. The HIT is 128 bits long and has the 312 following three key properties: i) it is the same length as an IPv6 313 address and can be used in address-sized fields in APIs and 314 protocols, ii) it is self-certifying (i.e., given a HIT, it is 315 computationally hard to find a Host Identity key that matches the 316 HIT), and iii) the probability of HIT collision between two hosts is 317 very low. 319 Finally, HIs and HITs are not expected to be carried explicitly in 320 the headers of user data packets, due to their sizes. Depending on 321 the form of further communication, other methods are used to map the 322 data packet to the these representatives of host identities. For 323 example, if ESP is used to protect data traffic, the Security 324 Parameter Index (SPI) can be used for this purpose. In some cases, 325 this makes it possible to use HIP without an additional explicit 326 protocol header. 328 3.1 Host Identity Tag (HIT) 330 The Host Identity Tag is a 128 bits long value -- a hash of the Host 331 Identifier. There are two advantages of using a hash over the actual 332 Host Identity public key in protocols. Firstly, its fixed length 333 makes for easier protocol coding and also better manages the packet 334 size cost of this technology. Secondly, it presents a consistent 335 format to the protocol whatever underlying identity technology is 336 used. 338 There are two types of HITs. HITs of the first type, called _Type 1 339 HIT_, consist of an 8-bit prefix followed by 120 bits of the hash of 340 the public key. HITs of the second type (Type 2 HIT) consist of a 341 Host Assigning Authority Field (HAA), and only the last 64 bits come 342 from a SHA-1 hash of the Host Identity. This latter format for HIT 343 is recommended for 'well known' systems. It is possible to support a 344 resolution mechanism for these names in hierarchical directories, 345 like the DNS. Another use of HAA is in policy controls, see 346 Section 7. 348 This document fully specifies only Type 1 HITs. HITs that consists 349 of the HAA field and the hash are specified in [27]. 351 Any conforming implementation MUST be able to deal with Type 1 HITs. 352 When handling other than Type 1 HITs, the implementation is 353 RECOMMENDED to explicitly learn and record the binding between the 354 Host Identifier and the HIT, as it may not be able to generate such 355 HITs from the Host Identifiers. It is a matter of policy whether a 356 host will accept a HIP connection when such binding is not known. 358 The following figure shows the structure of a Type 1 HIT. 360 1 361 0 2 362 0 1 2 3 4 5 6 7 8 ... 7 363 +-+-+-+-+-+-+-+-+-+-//-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Prefix | Hash | 365 +-+-+-+-+-+-+-+-+-+-//-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 Prefix (8 bits) - Fixed prefix, TBD. All other values reserved. 369 0x40 - SHA-1 hash algorithm 370 All other values reserved. 372 Hash (120 bits) - Lower-order bits of the hash (as specified by 373 the hash algorithm) of the public key 375 Additional values for the prefix (including different hash 376 algorithms, or other information) may be defined in the future. A 377 host may receive a HIT for which it does not understand the prefix. 378 In such a case, it will not be able to check the mapping between HI 379 and HIT. 381 3.2 Generating a HIT from a HI 383 The 120 or 64 hash bits in a HIT MUST be generated by taking the 384 least significant 120 or 64 bits of the HIT Hash Algorithm hash of 385 the Host Identifier as it is represented in the Host Identity field 386 in a HIP payload packet. 388 For Identities that are either RSA or DSA public keys, the HIT is 389 formed as follows: 391 1. The public key is encoded as specified in the corresponding 392 DNSSEC document, taking the algorithm specific portion of the 393 RDATA part of the KEY RR. There is currently only two defined 394 public key algorithms: RSA and DSA. Hence, either of the 395 following applies: 397 The RSA public key is encoded as defined in RFC3110 [15] 398 Section 2, taking the exponent length (e_len), exponent (e) 399 and modulus (n) fields concatenated. The length (n_len) of 400 the modulus (n) can be determined from the total HI length 401 (hi_len) and the preceding HI fields including the exponent 402 (e). Thus, the data to be hashed has the same length as the 403 HI (hi_len). The fields MUST be encoded in network byte 404 order, as defined in RFC3110 [15]. 406 The DSA public key is encoded as defined in RFC2536 [13] 407 Section 2, taking the fields T, Q, P, G, and Y, concatenated. 408 Thus, the data to be hashed is 1 + 20 + 3 * 64 + 3 * 8 * T 409 octets long, where T is the size parameter as defined in 410 RFC2536 [13]. The size parameter T, affecting the field 411 lengths, MUST be selected as the minimum value that is long 412 enough to accommodate P, G, and Y. The fields MUST be encoded 413 in network byte order, as defined in RFC2536 [13]. 415 2. A SHA-1 hash [23] is calculated over the encoded key. 417 3. The least significant 120 or 64 bits of the hash result are used 418 to create the HIT, as defined above. 420 In Appendix D the HIT generation process is illustrated using pseudo- 421 code. 423 4. Protocol Overview 425 The following material is an overview of the HIP protocol operation, 426 and does not contain all details of the packet formats or the packet 427 processing steps. Section 5 and Section 6 describe in more detail 428 the packet formats and packet processing steps, respectively, and are 429 normative in case of any conflicts with this section. 431 The Host Identity Protocol is IP protocol TBD (Editor's note: 432 protocol number will be assigned by IANA; for testing purposes, the 433 protocol number 99 is currently used). The HIP payload (Section 5.1) 434 header could be carried in every IP datagram. However, since HIP 435 headers are relatively large (40 bytes), it is desirable to 436 'compress' the HIP header so that the HIP header only occurs in 437 control packets used to establish or change HIP state. The actual 438 method for header 'compression' and for matching data packets with 439 existing HIP associations (if any) is defined in separate extension 440 documents, describing transport formats and methods. All HIP 441 implementations MUST implement, at minimum, the ESP transport format 442 for HIP [24]. 444 4.1 Creating a HIP Association 446 By definition, the system initiating a HIP exchange is the Initiator, 447 and the peer is the Responder. This distinction is forgotten once 448 the base exchange completes, and either party can become the 449 Initiator in future communications. 451 The HIP base exchange serves to manage the establishment of state 452 between an Initiator and a Responder. The first packet, I1, 453 initiates the exchange, and the last three packets, R1, I2, and R2, 454 constitute a standard authenticated Diffie-Hellman key exchange for 455 session key generation. During the Diffie-Hellman key exchange, a 456 piece of keying material is generated. The HIP association keys are 457 drawn from this keying material. If other cryptographic keys are 458 needed, e.g., to be used with ESP, they are expected to be drawn from 459 the same keying material. 461 The Initiator first sends a trigger packet, I1, to the Responder. 462 The packet contains only the HIT of the Initiator and possibly the 463 HIT of the Responder, if it is known. 465 The second packet, R1, starts the actual exchange. It contains a 466 puzzle-- a cryptographic challenge that the Initiator must solve 467 before continuing the exchange. The level of difficulty of the 468 puzzle can be adjusted based on level of trust with the Initiator, 469 current load, or other factors. In addition, the R1 contains the 470 initial Diffie-Hellman parameters and a signature, covering part of 471 the message. Some fields are left outside the signature to support 472 pre-created R1s. 474 In the I2 packet, the Initiator must display the solution to the 475 received puzzle. Without a correct solution, the I2 message is 476 discarded. The I2 also contains a Diffie-Hellman parameter that 477 carries needed information for the Responder. The packet is signed 478 by the sender. 480 The R2 packet finalizes the base exchange. The packet is signed. 482 The base exchange is illustrated below. The term "key" refers to the 483 host identity public key, and "sig" represents a signature using such 484 key. The packets contain other parameters not shown in this figure. 486 Initiator Responder 488 I1: trigger exchange 489 --------------------------> 490 select pre-computed R1 491 R1: puzzle, D-H, key, sig 492 <------------------------- 493 check sig remain stateless 494 solve puzzle 495 I2: solution, D-H, {key}, sig 496 --------------------------> 497 compute D-H check cookie 498 check puzzle 499 check sig 500 R2: sig 501 <-------------------------- 502 check sig compute D-H 504 4.1.1 HIP Cookie Mechanism 506 The purpose of the HIP cookie mechanism is to protect the Responder 507 from a number of denial-of-service threats. It allows the Responder 508 to delay state creation until receiving I2. Furthermore, the puzzle 509 included in the cookie allows the Responder to use a fairly cheap 510 calculation to check that the Initiator is "sincere" in the sense 511 that it has churned CPU cycles in solving the puzzle. 513 The Cookie mechanism has been explicitly designed to give space for 514 various implementation options. It allows a Responder implementation 515 to completely delay session specific state creation until a valid I2 516 is received. In such a case a correctly formatted I2 can be rejected 517 only once the Responder has checked its validity by computing one 518 hash function. On the other hand, the design also allows a Responder 519 implementation to keep state about received I1s, and match the 520 received I2s against the state, thereby allowing the implementation 521 to avoid the computational cost of the hash function. The drawback 522 of this latter approach is the requirement of creating state. 523 Finally, it also allows an implementation to use other combinations 524 of the space-saving and computation-saving mechanisms. 526 One possible way for a Responder to remain stateless but drop most 527 spoofed I2s is to base the selection of the cookie on some function 528 over the Initiator's Host Identity. The idea is that the Responder 529 has a (perhaps varying) number of pre-calculated R1 packets, and it 530 selects one of these based on the information carried in I1. When 531 the Responder then later receives I2, it checks that the cookie in 532 the I2 matches with the cookie sent in the R1, thereby making it 533 impractical for the attacker to first exchange one I1/R1, and then 534 generate a large number of spoofed I2s that seemingly come from 535 different IP addresses or use different HITs. The method does not 536 protect from an attacker that uses fixed IP addresses and HITs, 537 though. Against such an attacker it is probably best to create a 538 piece of local state, and remember that the puzzle check has 539 previously failed. See Appendix C for one possible implementation. 540 Implementations SHOULD include sufficient randomness to the algorithm 541 so that algorithm complexity attacks become impossible [30]. 543 The Responder can set the puzzle difficulty for Initiator, based on 544 its level of trust of the Initiator. The Responder SHOULD use 545 heuristics to determine when it is under a denial-of-service attack, 546 and set the puzzle difficulty value K appropriately; see below. 548 The Responder starts the cookie exchange when it receives an I1. The 549 Responder supplies a random number I, and requires the Initiator to 550 find a number J. To select a proper J, the Initiator must create the 551 concatenation of I, the HITs of the parties, and J, and take a SHA-1 552 hash over this concatenation. The lowest order K bits of the result 553 MUST be zeros. The value K sets the difficulty of the puzzle. 555 To generate a proper number J, the Initiator will have to generate a 556 number of Js until one produces the hash target of zero. The 557 Initiator SHOULD give up after exceeding the puzzle lifetime in the 558 PUZZLE TLV. The Responder needs to re-create the concatenation of I, 559 the HITs, and the provided J, and compute the hash once to prove that 560 the Initiator did its assigned task. 562 To prevent pre-computation attacks, the Responder MUST select the 563 number I in such a way that the Initiator cannot guess it. 564 Furthermore, the construction MUST allow the Responder to verify that 565 the value was indeed selected by it and not by the Initiator. See 566 Appendix C for an example on how to implement this. 568 Using the Opaque data field in an ECHO_REQUEST parameter, the 569 Responder can include some data in R1 that the Initiator must copy 570 unmodified in the corresponding I2 packet. The Responder can 571 generate the Opaque data in various ways; e.g. using the sent I, some 572 secret, and possibly other related data. Using this same secret, 573 received I in I2 packet and possible other data, the Receiver can 574 verify that it has itself sent the I to the Initiator. The Responder 575 MUST change the secret periodically. 577 It is RECOMMENDED that the Responder generates a new cookie and a new 578 R1 once every few minutes. Furthermore, it is RECOMMENDED that the 579 Responder remembers an old cookie at least 2*lifetime seconds after 580 it has been deprecated. These time values allow a slower Initiator 581 to solve the cookie puzzle while limiting the usability that an old, 582 solved cookie has to an attacker. 584 NOTE: The protocol developers explicitly considered whether R1 should 585 include a timestamp in order to protect the Initiator from replay 586 attacks. The decision was to NOT include a timestamp. 588 NOTE: The protocol developers explicitly considered whether a memory 589 bound function should be used for the puzzle instead of a CPU bound 590 function. The decision was not to use memory bound functions. At 591 the time of the decision the idea of memory bound functions was 592 relatively new and their IPR status were unknown. Once there is more 593 experience about memory bound functions and once their IPR status is 594 better known, it may be reasonable to reconsider this decision. 596 4.1.2 Authenticated Diffie-Hellman Protocol 598 The packets R1, I2, and R2 implement a standard authenticated Diffie- 599 Hellman exchange. The Responder sends its public Diffie-Hellman key 600 and its public authentication key, i.e., its host identity, in R1. 601 The signature in R1 allows the Initiator to verify that the R1 has 602 been once generated by the Responder. However, since it is 603 precomputed and therefore does not cover all of the packet, it does 604 not protect from replay attacks. 606 When the Initiator receives an R1, it computes the Diffie-Hellman 607 session key. It creates a HIP association using keying material from 608 the session key (see Section 6.4), and may use the association to 609 encrypt its public authentication key, i.e., host identity. The 610 resulting I2 contains the Initiator's Diffie-Hellman key and its 611 (optionally) encrypted public authentication key. The signature in 612 I2 covers all of the packet. 614 The Responder extracts the Initiator Diffie-Hellman public key from 615 the I2, computes the Diffie-Hellman session key, creates a 616 corresponding HIP association, and decrypts the Initiator's public 617 authentication key. It can then verify the signature using the 618 authentication key. 620 The final message, R2, is needed to protect the Initiator from replay 621 attacks. 623 4.1.3 HIP Replay Protection 625 The HIP protocol includes the following mechanisms to protect against 626 malicious replays. Responders are protected against replays of I1 627 packets by virtue of the stateless response to I1s with presigned R1 628 messages. Initiators are protected against R1 replays by a 629 monotonically increasing "R1 generation counter" included in the R1. 630 Responders are protected against replays or false I2s by the cookie 631 mechanism (Section 4.1.1 above), and optional use of opaque data. 632 Hosts are protected against replays to R2s and UPDATEs by use of a 633 less expensive HMAC verification preceding HIP signature 634 verification. 636 The R1 generation counter is a monotonically increasing 64-bit 637 counter that may be initialized to any value. The scope of the 638 counter MAY be system-wide but SHOULD be per host identity, if there 639 is more than one local host identity. The value of this counter 640 SHOULD be kept across system reboots and invocations of the HIP base 641 exchange. This counter indicates the current generation of cookie 642 puzzles. Implementations MUST accept puzzles from the current 643 generation and MAY accept puzzles from earlier generations. A 644 system's local counter MUST be incremented at least as often as every 645 time old R1s cease to be valid, and SHOULD never be decremented, lest 646 the host expose its peers to the replay of previously generated, 647 higher numbered R1s. Also, the R1 generation counter MUST NOT roll 648 over; if the counter is about to become exhausted, the corresponding 649 HI must be abandoned and replaced with a new one. 651 A host may receive more than one R1, either due to sending multiple 652 I1s (Section 6.5.1) or due to a replay of an old R1. When sending 653 multiple I1s, an initiator SHOULD wait for a small amount of time 654 after the first R1 reception to allow possibly multiple R1s to 655 arrive, and it SHOULD respond to an R1 among the set with the largest 656 R1 generation counter. If an Initiator is processing an R1 or has 657 already sent an I2 (still waiting for R2) and it receives another R1 658 with a larger R1 generation counter, it MAY elect to restart R1 659 processing with the fresher R1, as if it were the first R1 to arrive. 661 Upon conclusion of an active HIP association with another host, the 662 R1 generation counter associated with the peer host SHOULD be 663 flushed. A local policy MAY override the default flushing of R1 664 counters on a per-HIT basis. The reason for recommending the 665 flushing of this counter is that there may be hosts where the R1 666 generation counter (occasionally) decreases; e.g., due to hardware 667 failure. 669 4.1.4 Refusing a HIP Exchange 671 A HIP aware host may choose not to accept a HIP exchange. If the 672 host's policy is to only be an Initiator, it should begin its own HIP 673 exchange. A host MAY choose to have such a policy since only the 674 Initiator HI is protected in the exchange. There is a risk of a race 675 condition if each host's policy is to only be an Initiator, at which 676 point the HIP exchange will fail. 678 If the host's policy does not permit it to enter into a HIP exchange 679 with the Initiator, it should send an ICMP 'Destination Unreachable, 680 Administratively Prohibited' message. A more complex HIP packet is 681 not used here as it actually opens up more potential DoS attacks than 682 a simple ICMP message. 684 4.2 Updating a HIP Association 686 A HIP association between two hosts may need to be updated over time. 687 Examples include the need to rekey expiring user data security 688 associations, add new security associations, or change IP addresses 689 associated with hosts. The UPDATE packet is used for those and other 690 similar purposes. This document only specifies the UPDATE packet 691 format and basic processing rules, with mandatory TLVs. The actual 692 usage is defined in separate specifications. 694 HIP provides a general purpose UPDATE packet, which can carry 695 multiple HIP parameters, for updating the HIP state between two 696 peers. The UPDATE mechanism has the following properties: 698 UPDATE messages carry a monotonically increasing sequence number 699 and are explicitly acknowledged by the peer. Lost UPDATEs or 700 acknowledgments may be recovered via retransmission. Multiple 701 UPDATE messages may be outstanding. 703 UPDATE is protected by both HMAC and HIP_SIGNATURE parameters, 704 since processing UPDATE signatures alone is a potential DoS attack 705 against intermediate systems. 707 The UPDATE packet is defined in Section 5.3.5. 709 4.3 Error Processing 711 HIP error processing behavior depends on whether there exists an 712 active HIP association or not. In general, if an HIP association 713 exists between the sender and receiver of a packet causing an error 714 condition, the receiver SHOULD respond with a NOTIFY packet. On the 715 other hand, if there are no existing HIP associations between the 716 sender and receiver, or the receiver cannot reasonably determine the 717 identity of the sender, the receiver MAY respond with a suitable ICMP 718 message; see Section 5.4 for more details. 720 The HIP protocol and state machine is designed to recover from one of 721 the parties crashing and losing its state. The following scenarios 722 describe the main use cases covered by the design. 724 No prior state between the two systems. 726 The system with data to send is the Initiator. The process 727 follows the standard four packet base exchange, establishing 728 the HIP association. 730 The system with data to send has no state with the receiver, but 731 the receiver has a residual HIP association. 733 The system with data to send is the Initiator. The Initiator 734 acts as in no prior state, sending I1 and getting R1. When the 735 Responder receives a valid I2, the old association is 736 'discovered' and deleted, and the new association is 737 established. 739 The system with data to send has an HIP association, but the 740 receiver does not. 742 The system sends data on the outbound user data security 743 association. The receiver 'detects' the situation when it 744 receives a user data packet that it cannot match to any HIP 745 association. The receiving host MUST discard this packet. 746 Optionally, the receiving host MAY send an ICMP packet with the 747 Parameter Problem type to inform about non-existing HIP 748 association (see Section 5.4), and it MAY initiate a new HIP 749 negotiation. However, responding with these optional 750 mechanisms is implementation or policy dependent. 752 4.4 HIP State Machine 754 The HIP protocol itself has little state. In the HIP base exchange, 755 there is an Initiator and a Responder. Once the SAs are established, 756 this distinction is lost. If the HIP state needs to be re- 757 established, the controlling parameters are which peer still has 758 state and which has a datagram to send to its peer. The following 759 state machine attempts to capture these processes. 761 The state machine is presented in a single system view, representing 762 either an Initiator or a Responder. There is not a complete overlap 763 of processing logic here and in the packet definitions. Both are 764 needed to completely implement HIP. 766 Implementors must understand that the state machine, as described 767 here, is informational. Specific implementations are free to 768 implement the actual functions differently. Section 6 describes the 769 packet processing rules in more detail. This state machine focuses 770 on the HIP I1, R1, I2, and R2 packets only. Other states may be 771 introduced by mechanisms in other drafts (such as mobility and 772 multihoming). 774 4.4.1 HIP States 776 +---------------------+---------------------------------------------+ 777 | State | Explanation | 778 +---------------------+---------------------------------------------+ 779 | UNASSOCIATED | State machine start | 780 | | | 781 | I1-SENT | Initiating HIP | 782 | | | 783 | I2-SENT | Waiting to finish HIP | 784 | | | 785 | R2-SENT | Waiting to finish HIP | 786 | | | 787 | ESTABLISHED | HIP association established | 788 | | | 789 | CLOSING | HIP association closing, no data can be | 790 | | sent | 791 | | | 792 | CLOSED | HIP association closed, no data can be sent | 793 | | | 794 | E-FAILED | HIP exchange failed | 795 +---------------------+---------------------------------------------+ 797 4.4.2 HIP State Processes 799 +------------+ 800 |UNASSOCIATED| Start state 801 +------------+ 802 User data to send requiring a new HIP association, send I1 and go to 803 I1-SENT 804 Receive I1, send R1 and stay at UNASSOCIATED 805 Receive I2, process 806 if successful, send R2 and go to R2-SENT 807 if fail, stay at UNASSOCIATED 809 Receive user data for unknown HIP association, optionally send ICMP 810 as defined in 811 Section 5.4 812 and stay at UNASSOCIATED 813 Receive CLOSE, optionally send ICMP Parameter Problem and stay 814 in UNASSOCIATED. 816 Receive ANYOTHER, drop and stay at UNASSOCIATED 818 +---------+ 819 | I1-SENT | Initiating HIP 820 +---------+ 822 Receive I1, 823 if the local HIT is smaller than the peer HIT, drop I1 and stay 824 at I1-SENT 825 if the local HIT is greater than the peer HIT, send R1 and stay 826 at I1-SENT 827 Receive I2, process 828 if successful, send R2 and go to R2-SENT 829 if fail, stay at I1-SENT 830 Receive R1, process 831 if successful, send I2 and go to I2-SENT 832 if fail, go to E-FAILED 834 Receive ANYOTHER, drop and stay at I1-SENT 835 Timeout, increment timeout counter 836 If counter is less than I1_RETRIES_MAX, send I1 and stay at 837 I1-SENT 838 If counter is greater than I1_RETRIES_MAX, go to E-FAILED 840 +---------+ 841 | I2-SENT | Waiting to finish HIP 842 +---------+ 844 Receive I1, send R1 and stay at I2-SENT 845 Receive R1, process 846 if successful, send I2 and cycle at I2-SENT 847 if fail, stay at I2-SENT 848 Receive I2, process 849 if successful, and 850 if local HIT is smaller than the peer HIT, drop I2 and stay 851 at I2-SENT 852 if local HIT is greater than the peer HIT, send R2 and go to 853 R2-SENT 854 if fail, stay at I2-SENT 855 Receive R2, process 856 if successful, go to ESTABLISHED 857 if fail, go to E-FAILED 859 Receive ANYOTHER, drop and stay at I2-SENT 860 Timeout, increment timeout counter 861 If counter is less than I2_RETRIES_MAX, send I2 and stay at 862 I2-SENT 863 If counter is greater than I2_RETRIES_MAX, go to E-FAILED 865 +---------+ 866 | R2-SENT | Waiting to finish HIP 867 +---------+ 869 Receive I1, send R1 and stay at R2-SENT 870 Receive I2, process, 871 if successful, send R2, and cycle at R2-SENT 872 if failed, stay at R2-SENT 873 Receive R1, drop and stay at R2-SENT 874 Receive R2, drop and stay at R2-SENT 876 Receive data, move to ESTABLISHED 877 No packet sent/received during UAL minutes, send CLOSE and go to 878 CLOSING 880 +------------+ 881 |ESTABLISHED | HIP association established 882 +------------+ 884 Receive I1, send R1 and stay at ESTABLISHED 885 Receive I2, process with cookie and possible Opaque data verification 886 if successful, send R2, drop old HIP association, establish a 887 new HIP association, to to R2-SENT 888 if fail, stay at ESTABLISHED 889 Receive R1, drop and stay at ESTABLISHED 890 Receive R2, drop and stay at ESTABLISHED 892 Receive user data for HIP association, process and stay at 893 ESTABLISHED 894 No packet sent/received during UAL minutes, send CLOSE and go to 895 CLOSING. 896 Receive CLOSE, process 897 if successful, send CLOSE_ACK and go to CLOSED 898 if failed, stay at ESTABLISHED 900 +---------+ 901 | CLOSING | HIP association has not been used for UAL (Unused 902 +---------+ Association Lifetime) minutes. 904 User data to send, requires the creation of another incarnation 905 of the HIP association, started by sending an I1, 906 and stay at CLOSING 908 Receive I1, send R1 and stay at CLOSING 909 Receive I2, process 910 if successful, send R2 and go to R2-SENT 911 if fail, stay at CLOSING 913 Receive R1, process 914 if successful, send I2 and go to I2-SENT 915 if fail, stay at CLOSING 917 Receive CLOSE, process 918 if successful, send CLOSE_ACK, discard state and go to CLOSED 919 if failed, stay at CLOSING 920 Receive CLOSE_ACK, process 921 if successful, discard state and go to UNASSOCIATED 922 if failed, stay at CLOSING 924 Receive ANYOTHER, drop and stay at CLOSING 926 Timeout, increment timeout sum, reset timer 927 if timeout sum is less than UAL+MSL minutes, retransmit CLOSE 928 and stay at CLOSING 929 if timeout sum is greater than UAL+MSL minutes, go to 930 UNASSOCIATED 932 +--------+ 933 | CLOSED | CLOSE_ACK sent, resending CLOSE_ACK if necessary 934 +--------+ 936 Datagram to send, requires the creation of another incarnation 937 of the HIP association, started by sending an I1, 938 and stay at CLOSED 940 Receive I1, send R1 and stay at CLOSED 941 Receive I2, process 942 if successful, send R2 and go to R2-SENT 943 if fail, stay at CLOSED 945 Receive R1, process 946 if successful, send I2 and go to I2-SENT 947 if fail, stay at CLOSED 949 Receive CLOSE, process 950 if successful, send CLOSE_ACK, stay at CLOSED 951 if failed, stay at CLOSED 953 Receive CLOSE_ACK, process 954 if successful, discard state and go to UNASSOCIATED 955 if failed, stay at CLOSED 957 Receive ANYOTHER, drop and stay at CLOSED 959 Timeout (UAL + 2MSL), discard state and go to UNASSOCIATED 961 +----------+ 962 | E-FAILED | HIP failed to establish association with peer 963 +----------+ 965 Move to UNASSOCIATED after an implementation specific time. 966 Re-negotiation is possible after moving to UNASSOCIATED state. 968 4.4.3 Simplified HIP State Diagram 970 The following diagram shows the major state transitions. Transitions 971 based on received packets implicitly assume that the packets are 972 successfully authenticated or processed. 974 +-+ +---------------------------+ 975 I1 received, send R1 | | | | 976 | v v | 977 Datagram to send +--------------+ I2 received, send R2 | 978 +---------------| UNASSOCIATED |---------------+ | 979 | +--------------+ | | 980 v | | 981 +---------+ I2 received, send R2 | | 982 +---->| I1-SENT |---------------------------------------+ | | 983 | +---------+ | | | 984 | | +------------------------+ | | | 985 | | R1 received, | I2 received, send R2 | | | | 986 | v send I2 | v v v | 987 | +---------+ | +---------+ | 988 | +->| I2-SENT |------------+ | R2-SENT |<----+ | 989 | | +---------+ +---------+ | | 990 | | | || | | 991 | | | ||timeout | | 992 | |receive | || | | 993 | |R1, send | || receive I2,| | 994 | |I2 |R2 received +--------------+ data || send R2| | 995 | | +----------->| ESTABLISHED |<-------+| | | 996 | | +--------------+ | | | 997 | | | | | | | | 998 | | +------------+ | +------------------------+ | 999 | | | | | | | 1000 | | | No packet sent| | | | 1001 | | | /received for | +----+ | | 1002 | | | UAL min, send | V | | 1003 | | | CLOSE | +---------+<-+ timeout | | 1004 | | | +--->| CLOSING |--+ (UAL+MSL) | | 1005 | | | +---------+ retransmit | | 1006 +--|------------|----------------------+ | | | | CLOSE | | 1007 | +------------|------------------------+ | | +----------------+ | 1008 | | | +-----------+ +------------------|--+ 1009 | | +------------+ | receive CLOSE, CLOSE_ACK | | 1010 | | | | send CLOSE_ACK received or | | 1011 | | v v timeout | | 1012 | | +--------+ (UAL+MSL) | | 1013 | +------------------------| CLOSED |---------------------------+ | 1014 +---------------------------+--------+------------------------------+ 1015 Datagram to send ^ | timeout (UAL+2MSL), 1016 +-+ move to UNASSOCIATED 1017 CLOSE received, 1018 send CLOSE_ACK 1020 4.5 User Data Considerations 1022 4.5.1 TCP and UDP Pseudo-header Computation for User Data 1024 When computing TCP and UDP checksums on user data packets that flow 1025 through sockets bound to HITs, the IPv6 pseudo-header format [11] 1026 MUST be used, even if the outer addresses on the packet are IPv4 1027 addresses. Additionally, the HITs MUST be used in the place of the 1028 IPv6 addresses in the IPv6 pseudo-header. Note that the pseudo- 1029 header for actual HIP payloads is computed differently; see 1030 Section 5.1.2. 1032 4.5.2 Sending Data on HIP Packets 1034 A future version of this document may define how to include user data 1035 on various HIP packets. However, currently the HIP header is a 1036 terminal header, and not followed by any other headers. 1038 4.5.3 Transport Formats 1040 The actual data transmission format, used for user data after the HIP 1041 base exchange, is not defined in this document. Such transport 1042 formats and methods are described in separate specifications. All 1043 HIP implementations MUST implement, at minimum, the ESP transport 1044 format for HIP [24]. 1046 When new transport formats are defined, they get the type value from 1047 the HIP Transform type value space 2048 - 4095. The order in which 1048 the transport formats are presented in the R1 packet, is the 1049 preferred order. The last of the transport formats MUST be ESP 1050 transport format, represented by the ESP_TRANSFORM parameter. 1052 4.5.4 Reboot and SA Timeout Restart of HIP 1054 Simulating a loss of state is a potential DoS attack. The following 1055 process has been crafted to manage state recovery without presenting 1056 a DoS opportunity. 1058 If a host reboots or times out, it has lost its HIP state. If the 1059 system that lost state has a datagram to deliver to its peer, it 1060 simply restarts the HIP exchange. The peer replies with an R1 HIP 1061 packet, but does not reset its state until it receives the I2 HIP 1062 packet. The I2 packet MUST have a valid solution to the puzzle and, 1063 if inserted in R1, a valid Opaque data as well as a valid signature. 1064 Note that either the original Initiator or the Responder could end up 1065 restarting the exchange, becoming the new Initiator. 1067 If a system receives a user data packet that cannot be matched to any 1068 existing HIP association, it is possible that it has lost the state 1069 and its peer has not. It MAY send an ICMP packet with the Parameter 1070 Problem type, the Pointer pointing to the referred HIP-related 1071 association information. Reacting to such traffic depends on the 1072 implementation and the environment where the implementation is used. 1074 After sending the I1, the HIP negotiation proceeds as normally and, 1075 when successful, the SA is created at the initiating end. The peer 1076 end removes the OLD SA and replaces it with the new one. 1078 4.6 Certificate Distribution 1080 HIP base specification does not define how to use certificates or how 1081 to transfer them between hosts. These functions are defined in a 1082 separate specification. The parameter type value, used for carrying 1083 certificates, is reserved: CERT, Type 768. 1085 5. Packet Formats 1087 5.1 Payload Format 1089 All HIP packets start with a fixed header. 1091 0 1 2 3 1092 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 1093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1094 | Next Header | Header Length | Packet Type | VER. | RES. | 1095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1096 | Controls | Checksum | 1097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1098 | Sender's Host Identity Tag (HIT) | 1099 | | 1100 | | 1101 | | 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1103 | Receiver's Host Identity Tag (HIT) | 1104 | | 1105 | | 1106 | | 1107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1108 | | 1109 / HIP Parameters / 1110 / / 1111 | | 1112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1114 The HIP header is logically an IPv6 extension header. However, this 1115 document does not describe processing for Next Header values other 1116 than decimal 59, IPPROTO_NONE, the IPV6 no next header value. Future 1117 documents MAY do so. However, implementations MUST ignore trailing 1118 data if an unimplemented Next Header value is received. 1120 The Header Length field contains the length of the HIP Header and HIP 1121 parameters in 8 bytes units, excluding the first 8 bytes. Since all 1122 HIP headers MUST contain the sender's and receiver's HIT fields, the 1123 minimum value for this field is 4, and conversely, the maximum length 1124 of the HIP Parameters field is (255*8)-32 = 2008 bytes. Note: this 1125 sets an additional limit for sizes of TLVs included in the Parameters 1126 field, independent of the individual TLV parameter maximum lengths. 1128 The Packet Type indicates the HIP packet type. The individual packet 1129 types are defined in the relevant sections. If a HIP host receives a 1130 HIP packet that contains an unknown packet type, it MUST drop the 1131 packet. 1133 The HIP Version is four bits. The current version is 1. The version 1134 number is expected to be incremented only if there are incompatible 1135 changes to the protocol. Most extensions can be handled by defining 1136 new packet types, new parameter types, or new controls. 1138 The following four bits are reserved for future use. They MUST be 1139 zero when sent, and they SHOULD be ignored when handling a received 1140 packet. 1142 The HIT fields are always 128 bits (16 bytes) long. 1144 5.1.1 HIP Controls 1146 The HIP Controls section conveys information about the structure of 1147 the packet and capabilities of the host. 1149 The following fields have been defined: 1151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1152 | SHT | DHT | | | | | | | | | |A| 1153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1155 SHT - Sender's HIT Type: Currently the following values are 1156 specified: 1158 0 RESERVED 1160 1 Type 1 HIT 1162 2 Type 2 HIT 1164 3-6 UNASSIGNED 1166 7 RESERVED 1168 DHT - Destination's HIT Type: Uses the same values as the SHT. 1170 A - Anonymous: If this is set, the sender's HI in this packet is 1171 anonymous, i.e., one not listed in a directory. Anonymous HIs 1172 SHOULD NOT be stored. This control is set in packets R1 and/or 1173 I2. The peer receiving an anonymous HI may choose to refuse it. 1175 The rest of the fields are reserved for future use and MUST be set to 1176 zero on sent packets and ignored on received packets. 1178 5.1.2 Checksum 1180 The checksum field is located at the same location in the header as 1181 the checksum field in UDP packets, aiding hardware assisted checksum 1182 generation and verification. Note that since the checksum covers the 1183 source and destination addresses in the IP header, it must be 1184 recomputed on HIP-aware NAT devices. 1186 If IPv6 is used to carry the HIP packet, the pseudo-header [11] 1187 contains the source and destination IPv6 addresses, HIP packet length 1188 in the pseudo-header length field, a zero field, and the HIP protocol 1189 number (TBD, see Section 4) in the Next Header field. The length 1190 field is in bytes and can be calculated from the HIP header length 1191 field: (HIP Header Length + 1) * 8. 1193 In case of using IPv4, the IPv4 UDP pseudo header format [1] is used. 1194 In the pseudo header, the source and destination addresses are those 1195 used in the IP header, the zero field is obviously zero, the protocol 1196 is the HIP protocol number (TBD, see Section 4), and the length is 1197 calculated as in the IPv6 case. 1199 5.1.3 HIP Fragmentation Support 1201 A HIP implementation must support IP fragmentation / reassembly. 1202 Fragment reassembly MUST be implemented in both IPv4 and IPv6, but 1203 fragment generation MUST be implemented only in IPv4 (IPv4 stacks and 1204 networks will usually do this by default) and SHOULD be implemented 1205 in IPv6. In IPv6 networks, the minimum MTU is larger, 1280 bytes, 1206 than in IPv4 networks. The larger MTU size is usually sufficient for 1207 most HIP packets, and therefore fragment generation may not be 1208 needed. If a host expects to send HIP packets that are larger than 1209 the minimum IPv6 MTU, it MUST implement fragment generation even for 1210 IPv6. 1212 In IPv4 networks, HIP packets may encounter low MTUs along their 1213 routed path. Since HIP does not provide a mechanism to use multiple 1214 IP datagrams for a single HIP packet, support for path MTU discovery 1215 does not bring any value to HIP in IPv4 networks. HIP-aware NAT 1216 devices MUST perform any IPv4 reassembly/fragmentation. 1218 All HIP implementations MUST employ a reassembly algorithm that is 1219 sufficiently resistant to DoS attacks. 1221 5.1.4 Solving the Puzzle 1223 This subsection describes the puzzle solving details. 1225 In R1, the values I and K are sent in network byte order. Similarly, 1226 in I2 the values I and J are sent in network byte order. The SHA-1 1227 hash is created by concatenating, in network byte order, the 1228 following data, in the following order: 1230 64-bit random value I, in network byte order, as appearing in R1 1231 and I2. 1233 128-bit Initiator HIT, in network byte order, as appearing in the 1234 HIP Payload in R1 and I2. 1236 128-bit Responder HIT, in network byte order, as appearing in the 1237 HIP Payload in R1 and I2. 1239 64-bit random value J, in network byte order, as appearing in I2. 1241 In order to be a valid response cookie, the K low-order bits of the 1242 resulting SHA-1 digest must be zero. 1244 Notes: 1246 i) The length of the data to be hashed is 48 bytes. 1248 ii) All the data in the hash input MUST be in network byte order. 1250 iii) The order of the Initiator and Responder HITs are different 1251 in the R1 and I2 packets, see Section 5.1. Care must be taken to 1252 copy the values in right order to the hash input. 1254 The following procedure describes the processing steps involved, 1255 assuming that the Responder chooses to precompute the R1 packets: 1257 Precomputation by the Responder: 1258 Sets up the puzzle difficulty K. 1259 Creates a signed R1 and caches it. 1261 Responder: 1262 Selects a suitable cached R1. 1263 Generates a random number I. 1264 Sends I and K in an R1. 1265 Saves I and K for a Delta time. 1267 Initiator: 1268 Generates repeated attempts to solve the puzzle until a matching J 1269 is found: 1270 Ltrunc( SHA-1( I | HIT-I | HIT-R | J ), K ) == 0 1271 Sends I and J in an I2. 1273 Responder: 1274 Verifies that the received I is a saved one. 1275 Finds the right K based on I. 1276 Computes V := Ltrunc( SHA-1( I | HIT-I | HIT-R | J ), K ) 1277 Rejects if V != 0 1278 Accept if V == 0 1280 5.2 HIP Parameters 1282 The HIP Parameters are used to carry the public key associated with 1283 the sender's HIT, together with related security and other 1284 information. They consist of ordered parameters, encoded in TLV 1285 format. 1287 The following parameter types are currently defined. 1289 +-----------------+-------+----------+------------------------------+ 1290 | TLV | Type | Length | Data | 1291 +-----------------+-------+----------+------------------------------+ 1292 | R1_COUNTER | 128 | 12 | System Boot Counter | 1293 | | | | | 1294 | PUZZLE | 257 | 12 | K and Random #I | 1295 | | | | | 1296 | SOLUTION | 321 | 20 | K, Random #I and puzzle | 1297 | | | | solution J | 1298 | | | | | 1299 | SEQ | 385 | 4 | Update packet ID number | 1300 | | | | | 1301 | ACK | 449 | variable | Update packet ID number | 1302 | | | | | 1303 | DIFFIE_HELLMAN | 513 | variable | public key | 1304 | | | | | 1305 | HIP_TRANSFORM | 577 | variable | HIP Encryption and Integrity | 1306 | | | | Transform | 1307 | | | | | 1308 | ENCRYPTED | 641 | variable | Encrypted part of I2 packet | 1309 | | | | | 1310 | HOST_ID | 705 | variable | Host Identity with Fully | 1311 | | | | Qualified Domain Name or NAI | 1312 | | | | | 1313 | CERT | 768 | variable | HI Certificate; used to | 1314 | | | | transfer certificates. Usage | 1315 | | | | defined in a separate | 1316 | | | | document. | 1317 | | | | | 1318 | NOTIFY | 832 | variable | Informational data | 1319 | | | | | 1320 | ECHO_REQUEST | 897 | variable | Opaque data to be echoed | 1321 | | | | back; under signature | 1322 | | | | | 1323 | ECHO_RESPONSE | 961 | variable | Opaque data echoed back; | 1324 | | | | under signature | 1325 | | | | | 1326 | HMAC | 61505 | 20 | HMAC based message | 1327 | | | | authentication code, with | 1328 | | | | key material from | 1329 | | | | HIP_TRANSFORM | 1330 | | | | | 1331 | HMAC_2 | 61569 | 20 | HMAC based message | 1332 | | | | authentication code, with | 1333 | | | | key material from | 1334 | | | | HIP_TRANSFORM | 1335 | | | | | 1336 | HIP_SIGNATURE_2 | 61633 | variable | Signature of the R1 packet | 1337 | HIP_SIGNATURE | 61697 | variable | Signature of the packet | 1338 | | | | | 1339 | ECHO_REQUEST | 63661 | variable | Opaque data to be echoed | 1340 | | | | back; after signature | 1341 | | | | | 1342 | ECHO_RESPONSE | 63425 | variable | Opaque data echoed back; | 1343 | | | | after signature | 1344 +-----------------+-------+----------+------------------------------+ 1346 Because the ordering (from lowest to highest) of HIP parameters is 1347 strictly enforced, the parameter type values for existing parameters 1348 have been spaced to allow for future protocol extensions. Parameters 1349 numbered between 0-1023 are used in HIP handshake and update 1350 procedures and are covered by signatures. Parameters numbered 1351 between 1024-2047 are reserved. Parameters numbered between 2048- 1352 4095 are used for parameters related to HIP transform types. 1353 Parameters numbered between 4096 and (2^16 - 2^12) 61439 are 1354 reserved. Parameters numbered beteween 61440-62463 are used for 1355 signatures and signed MACs. Parameters numbered between 62464-63487 1356 are used for parameters that fall outside of the signed area of the 1357 packet. Parameters numbered between 63488-64511 are used for 1358 rendezvous and other relaying services. Parameters numbered between 1359 64512-65535 are reserved. 1361 5.2.1 TLV Format 1363 The TLV-encoded parameters are described in the following 1364 subsections. The type-field value also describes the order of these 1365 fields in the packet, except for type values from 2048 to 4095 which 1366 are reserved for new transport forms. The parameters MUST be 1367 included in the packet such that their types form an increasing 1368 order. If the order does not follow this rule, the packet is 1369 considered to be malformed and it MUST be discarded. 1371 Parameters using type values from 2048 up to 4095 are transport 1372 formats. Currently, one transport format is defined: the ESP 1373 transport format [24]. The order of these parameters does not follow 1374 the order of their type value, but they are put in the packet in 1375 order of preference. The first of the transport formats it the most 1376 preferred, and so on. 1378 All of the TLV parameters have a length (including Type and Length 1379 fields) which is a multiple of 8 bytes. When needed, padding MUST be 1380 added to the end of the parameter so that the total length becomes a 1381 multiple of 8 bytes. This rule ensures proper alignment of data. If 1382 padding is added, the Length field MUST NOT include the padding. Any 1383 added padding bytes MUST be zeroed by the sender, and their values 1384 SHOULD NOT be checked by the receiver. 1386 Consequently, the Length field indicates the length of the Contents 1387 field (in bytes). The total length of the TLV parameter (including 1388 Type, Length, Contents, and Padding) is related to the Length field 1389 according to the following formula: 1391 Total Length = 11 + Length - (Length + 3) % 8; 1393 0 1 2 3 1394 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 1395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1396 | Type |C| Length | 1397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1398 | | 1399 / Contents / 1400 / +-+-+-+-+-+-+-+-+ 1401 | | Padding | 1402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1404 Type Type code for the parameter. 16 bits long, C-bit 1405 being part of the Type code. 1406 C Critical. One if this parameter is critical, and 1407 MUST be recognized by the recipient, zero otherwise. 1408 The C bit is considered to be a part of the Type 1409 field. Consequently, critical parameters are always 1410 odd and non-critical ones have an even value. 1411 Length Length of the Contents, in bytes. 1412 Contents Parameter specific, defined by Type 1413 Padding Padding, 0-7 bytes, added if needed 1415 Critical parameters MUST be recognized by the recipient. If a 1416 recipient encounters a critical parameter that it does not recognize, 1417 it MUST NOT process the packet any further. It MAY send an ICMP or 1418 NOTIFY, as defined in Section 4.3. 1420 Non-critical parameters MAY be safely ignored. If a recipient 1421 encounters a non-critical parameter that it does not recognize, it 1422 SHOULD proceed as if the parameter was not present in the received 1423 packet. 1425 5.2.2 Defining New Parameters 1427 Future specifications may define new parameters as needed. When 1428 defining new parameters, care must be taken to ensure that the 1429 parameter type values are appropriate and leave suitable space for 1430 other future extensions. One must remember that the parameters MUST 1431 always be arranged in the increasing order by type code, thereby 1432 limiting the order of parameters. 1434 The following rules must be followed when defining new parameters. 1436 1. The low order bit C of the Type code is used to distinguish 1437 between critical and non-critical parameters. 1439 2. A new parameter may be critical only if an old recipient ignoring 1440 it would cause security problems. In general, new parameters 1441 SHOULD be defined as non-critical, and expect a reply from the 1442 recipient. 1444 3. If a system implements a new critical parameter, it MUST provide 1445 the ability to configure the associated feature off, such that 1446 the critical parameter is not sent at all. The configuration 1447 option must be well documented. By default, sending of such a 1448 new critical parameter SHOULD be off. In other words, the 1449 management interface MUST allow vanilla standards-only mode as a 1450 default configuration setting, and MAY allow new critical 1451 payloads to be configured on (and off). 1453 4. See section Section 9 for allocation rules regarding type codes. 1455 5.2.3 R1_COUNTER 1457 0 1 2 3 1458 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 1459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1460 | Type | Length | 1461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1462 | Reserved, 4 bytes | 1463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1464 | R1 generation counter, 8 bytes | 1465 | | 1466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1468 Type 128 1469 Length 12 1470 R1 generation 1471 counter The current generation of valid puzzles 1473 The R1_COUNTER parameter contains an 64-bit unsigned integer in 1474 network byte order, indicating the current generation of valid 1475 puzzles. The sender is supposed to increment this counter 1476 periodically. It is RECOMMENDED that the counter value is 1477 incremented at least as often as old PUZZLE values are deprecated so 1478 that SOLUTIONs to them are no longer accepted. 1480 The R1_COUNTER parameter is optional. It SHOULD be included in the 1481 R1 (in which case it is covered by the signature), and if present in 1482 the R1, it MAY be echoed (including the Reserved field verbatim) by 1483 the Initiator in the I2. 1485 5.2.4 PUZZLE 1487 0 1 2 3 1488 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 1489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1490 | Type | Length | 1491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1492 | K, 1 byte | Lifetime | Opaque, 2 bytes | 1493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1494 | Random # I, 8 bytes | 1495 | | 1496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1498 Type 257 1499 Length 12 1500 K K is the number of verified bits 1501 Lifetime Puzzle lifetime 2^(value-32) seconds 1502 Opaque Data set by the Responder, indexing the puzzle 1503 Random #I random number 1505 Random #I is represented as 64-bit integer, K and Lifetime as 8-bit 1506 integer, all in network byte order. 1508 The PUZZLE parameter contains the puzzle difficulty K and a 64-bit 1509 puzzle random integer #I. The Puzzle Lifetime indicates the time 1510 during which the puzzle solution is valid, and sets a time limit 1511 which should not be exceeded by the Initiator while it attempts to 1512 solve the puzzle. The lifetime is indicated as a power of 2 using 1513 the formula 2^(Lifetime-32) seconds. A puzzle MAY be augmented with 1514 an ECHO_REQUEST parameter included in the R1; the contents of the 1515 ECHO_REQUEST are then echoed back in the ECHO_RESPONSE, allowing the 1516 Responder to use the included information as a part of its puzzle 1517 processing. 1519 The Opaque and Random #I field are not covered by the HIP_SIGNATURE_2 1520 parameter. 1522 5.2.5 SOLUTION 1524 0 1 2 3 1525 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 1526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1527 | Type | Length | 1528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1529 | K, 1 byte | Reserved | Opaque, 2 bytes | 1530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1531 | Random #I, 8 bytes | 1532 | | 1533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1534 | Puzzle solution #J, 8 bytes | 1535 | | 1536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1538 Type 321 1539 Length 20 1540 K K is the number of verified bits 1541 Reserved zero when sent, ignored when received 1542 Opaque copied unmodified from the received PUZZLE TLV 1543 Random #I random number 1544 Puzzle solution 1545 #J random number 1547 Random #I, and Random #J are represented as 64-bit integers, K as an 1548 8-bit integer, all in network byte order. 1550 The SOLUTION parameter contains a solution to a puzzle. It also 1551 echoes back the random difficulty K, the Opaque field, and the puzzle 1552 integer #I. 1554 5.2.6 DIFFIE_HELLMAN 1556 0 1 2 3 1557 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 1558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1559 | Type | Length | 1560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1561 | Group ID | Public Value / 1562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1563 / | padding | 1564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1566 Type 513 1567 Length length in octets, excluding Type, Length, and 1568 padding 1569 Group ID defines values for p and g 1570 Public Value the sender's public Diffie-Hellman key 1572 The following Group IDs have been defined: 1574 Group Value 1575 Reserved 0 1576 384-bit group 1 1577 OAKLEY well known group 1 2 1578 1536-bit MODP group 3 1579 3072-bit MODP group 4 1580 6144-bit MODP group 5 1581 8192-bit MODP group 6 1583 The MODP Diffie-Hellman groups are defined in [18]. The OAKLEY group 1584 is defined in [9]. The OAKLEY well known group 5 is the same as the 1585 1536-bit MODP group. 1587 A HIP implementation MUST support Group IDs 1 and 3. The 384-bit 1588 group can be used when lower security is enough (e.g. web surfing) 1589 and when the equipment is not powerful enough (e.g. some PDAs). 1590 Equipment powerful enough SHOULD implement also group ID 5. The 384- 1591 bit group is defined in Appendix F. 1593 To avoid unnecessary failures during the base exchange, the rest of 1594 the groups SHOULD be implemented in hosts where resources are 1595 adequate. 1597 5.2.7 HIP_TRANSFORM 1599 0 1 2 3 1600 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 1601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1602 | Type | Length | 1603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1604 | Transform-ID #1 | Transform-ID #2 | 1605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1606 | Transform-ID #n | Padding | 1607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1609 Type 577 1610 Length length in octets, excluding Type, Length, and 1611 padding 1612 Transform-ID Defines the HIP Suite to be used 1614 The following Suite-IDs are defined ([21],[26]): 1616 XXX: Deprecate MD5 in the light of recent development? 1617 Suite-ID Value 1619 RESERVED 0 1620 AES-CBC with HMAC-SHA1 1 1621 3DES-CBC with HMAC-SHA1 2 1622 3DES-CBC with HMAC-MD5 3 1623 BLOWFISH-CBC with HMAC-SHA1 4 1624 NULL-ENCRYPT with HMAC-SHA1 5 1625 NULL-ENCRYPT with HMAC-MD5 6 1627 There MUST NOT be more than six (6) HIP Suite-IDs in one HIP 1628 transform TLV. The limited number of transforms sets the maximum 1629 size of HIP_TRANSFORM TLV. The HIP_TRANSFORM TLV MUST contain at 1630 least one of the mandatory Suite-IDs. 1632 The Responder lists supported and desired Suite-IDs in order of 1633 preference in the R1, up to the maximum of six Suite-IDs. In the I2, 1634 the Initiator MUST choose and insert only one of the corresponding 1635 Suite-IDs that will be used for generating the I2. 1637 Mandatory implementations: AES-CBC with HMAC-SHA1 and NULL-ENCRYPTION 1638 with HMAC-SHA1. 1640 5.2.8 HOST_ID 1642 0 1 2 3 1643 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 1644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1645 | Type | Length | 1646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1647 | HI Length |DI-type| DI Length | 1648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1649 | Host Identity / 1650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1651 / | Domain Identifier / 1652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1653 / | Padding | 1654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1656 Type 705 1657 Length length in octets, excluding Type, Length, and 1658 Padding 1659 HI Length Length of the Host Identity in octets 1660 DI-type type of the following Domain Identifier field 1661 DI Length length of the FQDN or NAI in octets 1662 Host Identity actual host identity 1663 Domain Identifier the identifier of the sender 1665 The Host Identity is represented in RFC2535 [12] format. The 1666 algorithms used in RDATA format are the following: 1668 Algorithms Values 1670 RESERVED 0 1671 DSA 3 [RFC2536] (RECOMMENDED) 1672 RSA 5 [RFC3110] (REQUIRED) 1674 The following DI-types have been defined: 1676 Type Value 1677 none included 0 1678 FQDN 1 1679 NAI 2 1681 FQDN Fully Qualified Domain Name, in binary format. 1682 NAI Network Access Identifier 1683 [22] 1685 The format for the FQDN is defined in RFC1035 [3] Section 3.1. 1687 If there is no Domain Identifier, i.e. the DI-type field is zero, 1688 also the DI Length field is set to zero. 1690 5.2.9 HMAC 1692 0 1 2 3 1693 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 1694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1695 | Type | Length | 1696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1697 | | 1698 | HMAC | 1699 | | 1700 | | 1701 | | 1702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1704 Type 61505 1705 Length 20 1706 HMAC 160 low order bits of the HMAC computed over the 1707 HIP packet, excluding the HMAC parameter and any 1708 following parameters, such as HIP_SIGNATURE, 1709 HIP_SIGNATURE_2, ECHO_REQUEST, or ECHO_RESPONSE. 1710 The checksum field MUST be set to zero 1711 and the HIP header length in the HIP common header 1712 MUST be calculated not to cover any excluded 1713 parameters when the HMAC is calculated. 1715 The HMAC calculation and verification process is presented in 1716 Section 6.3.1 1718 5.2.10 HMAC_2 1720 The TLV structure is the same as in Section 5.2.9. The fields are: 1722 Type 61569 1723 Length 20 1724 HMAC 160 low order bits of the HMAC computed over the 1725 HIP packet, excluding the HMAC parameter and any 1726 following parameters such as HIP_SIGNATURE, 1727 HIP_SIGNATURE_2, ECHO_REQUEST, or ECHO_RESPONSE, 1728 and including an additional sender's 1729 HOST_ID TLV during the HMAC calculation. The 1730 checksum field MUST be set to zero and the HIP 1731 header length in the HIP common header MUST be 1732 calculated not to cover any excluded parameters 1733 when the HMAC is calculated. 1735 The HMAC calculation and verification process is presented in 1736 Section 6.3.1 1738 5.2.11 HIP_SIGNATURE 1740 0 1 2 3 1741 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 1742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1743 | Type | Length | 1744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1745 | SIG alg | Signature / 1746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1747 / | Padding | 1748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1750 Type 61697 1751 Length length in octets, excluding Type, Length, and 1752 Padding 1753 SIG alg Signature algorithm 1754 Signature the signature is calculated over the HIP packet, 1755 excluding the HIP_SIGNATURE parameter and any 1756 parameters that follow the HIP_SIGNATURE TLV. 1757 The checksum field MUST be set to zero, and the HIP 1758 header length in the HIP common header MUST be 1759 calculated only to the beginning of the 1760 HIP_SIGNATURE TLV when the signature is calculated. 1762 The signature algorithms are defined in Section 5.2.8. The signature 1763 in the Signature field is encoded using the proper method depending 1764 on the signature algorithm (e.g. according to [15] in case of RSA, or 1765 according to [13] in case of DSA). 1767 The HIP_SIGNATURE calculation and verification process is presented 1768 in Section 6.3.2 1770 5.2.12 HIP_SIGNATURE_2 1772 The TLV structure is the same as in Section 5.2.11. The fields are: 1774 Type 61633 1775 Length length in octets, excluding Type, Length, and 1776 Padding 1777 SIG alg Signature algorithm 1778 Signature the signature is calculated over the HIP R1 packet, 1779 excluding the HIP_SIGNATURE_2 parameter and any 1780 parameters that follow. Initiator's HIT, checksum 1781 field, and the Opaque and Random #I fields in the 1782 PUZZLE TLV MUST be set to zero while computing the 1783 HIP_SIGNATURE_2 signature. Further, the HIP packet 1784 length in the HIP header MUST be calculated to the 1785 beginning of the HIP_SIGNATURE_2 TLV when the 1786 signature is calculated. 1788 Zeroing the Initiator's HIT makes it possible to create R1 packets 1789 beforehand to minimize the effects of possible DoS attacks. Zeroing 1790 the I and Opaque fields allows these fields to be populated 1791 dynamically on precomputed R1s. 1793 Signature calculation and verification follows the process in 1794 Section 6.3.2. 1796 5.2.13 SEQ 1798 0 1 2 3 1799 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 1800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1801 | Type | Length | 1802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1803 | Update ID | 1804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1806 Type 385 1807 Length 4 1808 Update ID 32-bit sequence number 1810 The Update ID is an unsigned quantity, initialized by a host to zero 1811 upon moving to ESTABLISHED state. The Update ID has scope within a 1812 single HIP association, and not across multiple associations or 1813 multiple hosts. The Update ID is incremented by one before each new 1814 UPDATE that is sent by the host (i.e., the first UPDATE packet 1815 originated by a host has an Update ID of 1). 1817 5.2.14 ACK 1819 0 1 2 3 1820 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 1821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1822 | Type | Length | 1823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1824 | peer Update ID | 1825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1827 Type 449 1828 Length variable (multiple of 4) 1829 peer Update ID 32-bit sequence number corresponding to the 1830 Update ID being acked. 1832 The ACK parameter includes one or more Update IDs that have been 1833 received from the peer. The Length field identifies the number of 1834 peer Update IDs that are present in the parameter. 1836 5.2.15 ENCRYPTED 1838 0 1 2 3 1839 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 1840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1841 | Type | Length | 1842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1843 | Reserved | 1844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1845 | IV / 1846 / / 1847 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 1849 / Encrypted data / 1850 / / 1851 / +-------------------------------+ 1852 / | Padding | 1853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1855 Type 641 1856 Length length in octets, excluding Type, Length, and 1857 Padding 1858 Reserved zero when sent, ignored when received 1859 IV Initialization vector, if needed, otherwise 1860 nonexistent. The length of the IV is inferred from 1861 the HIP transform. 1862 Encrypted The data is encrypted using an encryption algorithm 1863 data as defined in HIP transform. 1864 Padding Any Padding, if necessary, to make the TLV a 1865 multiple of 8 bytes. 1867 The ENCRYPTED parameter encapsulates another TLV, the encrypted data, 1868 which is also in TLV format. Consequently, the first fields in the 1869 encapsulated parameter(s) are Type and Length, allowing the contents 1870 to be easily parsed after decryption. 1872 Both the ENCRYPTED parameter and the encapsulated TLV(s) MUST be 1873 padded. The padding needed for the ENCRYPTED parameter is referred 1874 as the "outer" padding. Correspondingly, the padding for the 1875 parameter(s) encapsulated within the ENCRYPTED parameter is referred 1876 as the "inner" padding. 1878 The inner padding follows exactly the rules of Section 5.2.1. The 1879 outer padding also follows the same rules but with an exception. 1880 Namely, some algorithms require that the data to be encrypted must be 1881 a multiple of the cipher algorithm block size. In this case, the 1882 outer padding MUST include extra padding, as specified by the 1883 encryption algorithm. The size of the extra padding is selected so 1884 that the the length of the ENCRYPTED is the minimum value that is 1885 both multiple of eight and the cipher block size. The encryption 1886 algorithm may specify padding bytes other than zero; for example, AES 1887 [33] uses the PKCS5 padding scheme [14] (see section 6.1.1) where the 1888 remaining n bytes to fill the block each have the value n. 1890 Note that the length of the cipher suite output may be smaller or 1891 larger than the length of the data to be encrypted, since the 1892 encryption process may compress the data or add additional padding to 1893 the data. 1895 5.2.16 NOTIFY 1897 The NOTIFY parameter is used to transmit informational data, such as 1898 error conditions and state transitions, to a HIP peer. A NOTIFY 1899 parameter may appear in the NOTIFY packet type. The use of the 1900 NOTIFY parameter in other packet types is for further study. 1902 0 1 2 3 1903 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 1904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1905 | Type | Length | 1906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1907 | Reserved | Notify Message Type | 1908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1909 | / 1910 / Notification data / 1911 / +---------------+ 1912 / | Padding | 1913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1915 Type 832 1916 Length length in octets, excluding Type, Length, and 1917 Padding 1918 Reserved zero when sent, ignored when received 1919 Notify Message Specifies the type of notification 1920 Type 1921 Notification Informational or error data transmitted in addition 1922 Data to the Notify Message Type. Values for this field 1923 are type specific (see below). 1924 Padding Any Padding, if necessary, to make the TLV a 1925 multiple of 8 bytes. 1927 Notification information can be error messages specifying why an SA 1928 could not be established. It can also be status data that a process 1929 managing an SA database wishes to communicate with a peer process. 1930 The table below lists the Notification messages and their 1931 corresponding values. 1933 To avoid certain types of attacks, a Responder SHOULD avoid sending a 1934 NOTIFY to any host with which it has not successfully verified a 1935 puzzle solution. 1937 Types in the range 0 - 16383 are intended for reporting errors. An 1938 implementation that receives a NOTIFY error parameter in response to 1939 a request packet (e.g., I1, I2, UPDATE), SHOULD assume that the 1940 corresponding request has failed entirely. Unrecognized error types 1941 MUST be ignored except that they SHOULD be logged. 1943 Notify payloads with status types MUST be ignored if not recognized. 1945 NOTIFY PARAMETER - ERROR TYPES Value 1946 ------------------------------ ----- 1948 UNSUPPORTED_CRITICAL_PARAMETER_TYPE 1 1950 Sent if the parameter type has the "critical" bit set and the 1951 parameter type is not recognized. Notification Data contains 1952 the two octet parameter type. 1954 INVALID_SYNTAX 7 1956 Indicates that the HIP message received was invalid because 1957 some type, length, or value was out of range or because the 1958 request was rejected for policy reasons. To avoid a denial 1959 of service attack using forged messages, this status may 1960 only be returned for and in an encrypted packet if the 1961 message ID and cryptographic checksum were valid. To avoid 1962 leaking information to someone probing a node, this status 1963 MUST be sent in response to any error not covered by one of 1964 the other status types. To aid debugging, more detailed 1965 error information SHOULD be written to a console or log. 1967 NO_DH_PROPOSAL_CHOSEN 14 1969 None of the proposed group IDs was acceptable. 1971 INVALID_DH_CHOSEN 15 1973 The D-H Group ID field does not correspond to one offered 1974 by the Responder. 1976 NO_HIP_PROPOSAL_CHOSEN 16 1977 None of the proposed HIP Transform crypto suites was 1978 acceptable. 1980 INVALID_HIP_TRANSFORM_CHOSEN 17 1982 The HIP Transform crypto suite does not correspond to 1983 one offered by the Responder. 1985 AUTHENTICATION_FAILED 24 1987 Sent in response to a HIP signature failure. 1989 CHECKSUM_FAILED 26 1991 Sent in response to a HIP checksum failure. 1993 HMAC_FAILED 28 1995 Sent in response to a HIP HMAC failure. 1997 ENCRYPTION_FAILED 32 1999 The Responder could not successfully decrypt the 2000 ENCRYPTED TLV. 2002 INVALID_HIT 40 2004 Sent in response to a failure to validate the peer's 2005 HIT from the corresponding HI. 2007 BLOCKED_BY_POLICY 42 2009 The Responder is unwilling to set up an association 2010 for some policy reason (e.g. received HIT is NULL 2011 and policy does not allow opportunistic mode). 2013 SERVER_BUSY_PLEASE_RETRY 44 2015 The Responder is unwilling to set up an association 2016 as it is suffering under some kind of overload and 2017 has chosen to shed load by rejecting your request. 2018 You may retry if you wish, however you MUST find 2019 another (different) puzzle solution for any such 2020 retries. Note that you may need to obtain a new 2021 puzzle with a new I1/R1 exchange. 2023 I2_ACKNOWLEDGEMENT 46 2024 The Responder has received your I2 but had to queue 2025 the I2 for processing. The puzzle was correctly solved 2026 and the Responder is willing to set up an association 2027 but has currently a number of I2s in processing queue. 2028 R2 will be sent after the I2 has been processed. 2030 NOTIFY MESSAGES - STATUS TYPES Value 2031 ------------------------------ ----- 2033 (None defined at present) 2035 5.2.17 ECHO_REQUEST 2037 0 1 2 3 2038 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 2039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2040 | Type | Length | 2041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2042 | Opaque data (variable length) | 2043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2045 Type 63661 or 897 2046 Length variable 2047 Opaque data Opaque data, supposed to be meaningful only to the 2048 node that sends ECHO_REQUEST and receives a 2049 corresponding ECHO_RESPONSE. 2051 The ECHO_REQUEST parameter contains an opaque blob of data that the 2052 sender wants to get echoed back in the corresponding reply packet. 2054 The ECHO_REQUEST and ECHO_RESPONSE parameters MAY be used for any 2055 purpose where a node wants to carry some state in a request packet 2056 and get it back in a response packet. The ECHO_REQUEST MAY be 2057 covered by the HMAC and SIGNATURE. This is dictated by the Type 2058 field selected for the parameter; Type 897 ECHO_REQUEST is covered 2059 and Type 63661 is not covered. A HIP packet can contain only one 2060 ECHO_REQUEST parameter. 2062 5.2.18 ECHO_RESPONSE 2064 0 1 2 3 2065 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 2066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2067 | Type | Length | 2068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2069 | Opaque data (variable length) | 2070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2072 Type 63425 or 961 2073 Length variable 2074 Opaque data Opaque data, copied unmodified from the ECHO_REQUEST 2075 parameter that triggered this response. 2077 The ECHO_RESPONSE parameter contains an opaque blob of data that the 2078 sender of the ECHO_REQUEST wants to get echoed back. The opaque data 2079 is copied unmodified from the ECHO_REQUEST parameter. 2081 The ECHO_REQUEST and ECHO_RESPONSE parameters MAY be used for any 2082 purpose where a node wants to carry some state in a request packet 2083 and get it back in a response packet. The ECHO_RESPONSE MAY be 2084 covered by the HMAC and SIGNATURE. This is dictated by the Type 2085 field selected for the parameter; Type 961 ECHO_RESPONSE is covered 2086 and Type 63425 is not. 2088 5.3 HIP Packets 2090 There are eight basic HIP packets. Four are for the HIP base 2091 exchange, one is for updating, one is for sending notifications, and 2092 two for closing a HIP association. 2094 Packets consist of the fixed header as described in Section 5.1, 2095 followed by the parameters. The parameter part, in turn, consists of 2096 zero or more TLV coded parameters. 2098 In addition to the base packets, other packets types will be defined 2099 later in separate specifications. For example, support for mobility 2100 and multi-homing is not included in this specification. 2102 Packet representation uses the following operations: 2104 () parameter 2105 x{y} operation x on content y 2106 i x exists i times 2107 [] optional parameter 2108 x | y x or y 2110 In the future, an OPTIONAL upper layer payload MAY follow the HIP 2111 header. The Next Header field in the header indicates if there is 2112 additional data following the HIP header. The HIP packet, however, 2113 MUST NOT be fragmented. This limits the size of the possible 2114 additional data in the packet. 2116 5.3.1 I1 - the HIP Initiator Packet 2118 The HIP header values for the I1 packet: 2120 Header: 2121 Packet Type = 1 2122 SRC HIT = Initiator's HIT 2123 DST HIT = Responder's HIT, or NULL 2125 IP ( HIP () ) 2127 The I1 packet contains only the fixed HIP header. 2129 Valid control bits: none 2131 The Initiator gets the Responder's HIT either from a DNS lookup of 2132 the Responder's FQDN, from some other repository, or from a local 2133 table. If the Initiator does not know the Responder's HIT, it may 2134 attempt opportunistic mode by using NULL (all zeros) as the 2135 Responder's HIT. If the Initiator sends a NULL as the Responder's 2136 HIT, it MUST be able to handle all MUST and SHOULD algorithms from 2137 Section 3, which are currently RSA and DSA. 2139 Since this packet is so easy to spoof even if it were signed, no 2140 attempt is made to add to its generation or processing cost. 2142 Implementations MUST be able to handle a storm of received I1 2143 packets, discarding those with common content that arrive within a 2144 small time delta. 2146 5.3.2 R1 - the HIP Responder Packet 2148 The HIP header values for the R1 packet: 2150 Header: 2151 Packet Type = 2 2152 SRC HIT = Responder's HIT 2153 DST HIT = Initiator's HIT 2155 IP ( HIP ( [ R1_COUNTER, ] 2156 PUZZLE, 2157 DIFFIE_HELLMAN, 2158 HIP_TRANSFORM, 2159 HOST_ID, 2160 [ ECHO_REQUEST, ] 2161 HIP_SIGNATURE_2 ) 2162 [, ECHO_REQUEST ]) 2164 Valid control bits: C, A 2166 If the Responder HI is an anonymous one, the A control MUST be set. 2168 The Initiator HIT MUST match the one received in I1. If the 2169 Responder has multiple HIs, the Responder HIT used MUST match 2170 Initiator's request. If the Initiator used opportunistic mode, the 2171 Responder may select freely among its HIs. 2173 The R1 generation counter is used to determine the currently valid 2174 generation of puzzles. The value is increased periodically, and it 2175 is RECOMMENDED that it is increased at least as often as solutions to 2176 old puzzles are no longer accepted. 2178 The Puzzle contains a random #I and the difficulty K. The difficulty 2179 K is the number of bits that the Initiator must get zero in the 2180 puzzle. The random #I is not covered by the signature and must be 2181 zeroed during the signature calculation, allowing the sender to 2182 select and set the #I into a pre-computed R1 just prior sending it to 2183 the peer. 2185 The Diffie-Hellman value is ephemeral, but can be reused over a 2186 number of connections. In fact, as a defense against I1 storms, an 2187 implementation MAY use the same Diffie-Hellman value for a period of 2188 time, for example, 15 minutes. By using a small number of different 2189 Cookies for a given Diffie-Hellman value, the R1 packets can be pre- 2190 computed and delivered as quickly as I1 packets arrive. A scavenger 2191 process should clean up unused DHs and Cookies. 2193 The HIP_TRANSFORM contains the encryption and integrity algorithms 2194 supported by the Responder to protect the HI exchange, in the order 2195 of preference. All implementations MUST support the AES [19] with 2196 HMAC-SHA-1-96 [6]. 2198 The ECHO_REQUEST contains data that the sender wants to receive 2199 unmodified in the corresponding response packet in the ECHO_RESPONSE 2200 parameter. The ECHO_REQUEST can be either covered by the signature, 2201 or it can be left out from it. In the first case, the ECHO_REQUEST 2202 gets Type number 897 and in the latter case 63661. 2204 The signature is calculated over the whole HIP envelope, after 2205 setting the Initiator HIT, header checksum as well as the Opaque 2206 field and the Random #I in the PUZZLE parameter temporarily to zero, 2207 and excluding any TLVs that follow the signature, as described in 2208 Section 5.2.12. This allows the Responder to use precomputed R1s. 2209 The Initiator SHOULD validate this signature. It SHOULD check that 2210 the Responder HI received matches with the one expected, if any. 2212 5.3.3 I2 - the Second HIP Initiator Packet 2214 The HIP header values for the I2 packet: 2216 Header: 2217 Type = 3 2218 SRC HIT = Initiator's HIT 2219 DST HIT = Responder's HIT 2221 IP ( HIP ( [R1_COUNTER,] 2222 SOLUTION, 2223 DIFFIE_HELLMAN, 2224 HIP_TRANSFORM, 2225 ENCRYPTED { HOST_ID } or HOST_ID, 2226 [ ECHO_RESPONSE ,] 2227 HMAC, 2228 HIP_SIGNATURE 2229 [, ECHO_RESPONSE] ) ) 2231 Valid control bits: C, A 2233 The HITs used MUST match the ones used previously. 2235 If the Initiator HI is an anonymous one, the A control MUST be set. 2237 The Initiator MAY include an unmodified copy of the R1_COUNTER 2238 parameter received in the corresponding R1 packet into the I2 packet. 2240 The Solution contains the random # I from R1 and the computed # J. 2241 The low order K bits of the SHA-1(I | ... | J) MUST be zero. 2243 The Diffie-Hellman value is ephemeral. If precomputed, a scavenger 2244 process should clean up unused DHs. 2246 The HIP_TRANSFORM contains the single encryption and integrity 2247 transform selected by the Initiator, that will be used to protect the 2248 HI exchange. The chosen transform MUST correspond to one offered by 2249 the Responder in the R1. All implementations MUST support the AES 2250 transform [19]. 2252 The Initiator's HI MAY be encrypted using the HIP_TRANSFORM 2253 encryption algorithm. The keying material is derived from the 2254 Diffie-Hellman exchanged as defined in Section 6.4. 2256 The ECHO_RESPONSE contains the the unmodified Opaque data copied from 2257 the corresponding ECHO_REQUEST TLV. The ECHO_RESPONSE can be either 2258 covered by the HMAC and SIGNATURE or not covered. In the former 2259 case, the ECHO_RESPONSE gets Type number 961, in the latter it is 2260 63425. 2262 The HMAC is calculated over whole HIP envelope, excluding any TLVs 2263 after the HMAC, as described in Section 6.3.1. The Responder MUST 2264 validate the HMAC. 2266 The signature is calculated over whole HIP envelope, excluding any 2267 TLVs after the HIP_SIGNATURE, as described in Section 5.2.11. The 2268 Responder MUST validate this signature. It MAY use either the HI in 2269 the packet or the HI acquired by some other means. 2271 5.3.4 R2 - the Second HIP Responder Packet 2273 The HIP header values for the R2 packet: 2275 Header: 2276 Packet Type = 4 2277 SRC HIT = Responder's HIT 2278 DST HIT = Initiator's HIT 2280 IP ( HIP ( HMAC_2, HIP_SIGNATURE ) ) 2282 Valid control bits: none 2284 The HMAC_2 is calculated over whole HIP envelope, with Responder's 2285 HOST_ID TLV concatenated with the HIP envelope. The HOST_ID TLV is 2286 removed after the HMAC calculation. The procedure is described in 2287 8.3.1. 2289 The signature is calculated over whole HIP envelope. 2291 The Initiator MUST validate both the HMAC and the signature. 2293 5.3.5 UPDATE - the HIP Update Packet 2295 Support for the UPDATE packet is MANDATORY. 2297 The HIP header values for the UPDATE packet: 2299 Header: 2300 Packet Type = 6 2301 SRC HIT = Sender's HIT 2302 DST HIT = Recipient's HIT 2304 IP ( HIP ( [SEQ, ACK, ] HMAC, HIP_SIGNATURE ) ) 2306 Valid control bits: None 2308 The UPDATE packet contains mandatory HMAC and HIP_SIGNATURE 2309 parameters, and other optional parameters. 2311 The UPDATE packet contains zero or one SEQ parameter. The presence 2312 of a SEQ parameter indicates that the receiver MUST ack the UPDATE. 2313 An UPDATE that does not contain a SEQ parameter is simply an ACK of a 2314 previous UPDATE and itself MUST not be acked. 2316 An UPDATE packet contains zero or one ACK parameters. The ACK 2317 parameter echoes the SEQ sequence number of the UPDATE packet being 2318 acked. A host MAY choose to ack more than one UPDATE packet at a 2319 time; e.g., the ACK may contain the last two SEQ values received, for 2320 robustness to ack loss. ACK values are not cumulative; each received 2321 unique SEQ value requires at least one corresponding ACK value in 2322 reply. Received ACKs that are redundant are ignored. 2324 The UPDATE packet may contain both a SEQ and an ACK parameter. In 2325 this case, the ACK is being piggybacked on an outgoing UPDATE. In 2326 general, UPDATEs carrying SEQ SHOULD be acked upon completion of the 2327 processing of the UPDATE. A host MAY choose to hold the UPDATE 2328 carrying ACK for a short period of time to allow for the possibility 2329 of piggybacking the ACK parameter, in a manner similar to TCP delayed 2330 acknowledgments. 2332 A sender MAY choose to forego reliable transmission of a particular 2333 UPDATE (e.g., it becomes overcome by events). The semantics are such 2334 that the receiver MUST acknowledge the UPDATE but the sender MAY 2335 choose to not care about receiving the ACK. 2337 UPDATEs MAY be retransmitted without incrementing SEQ. If the same 2338 subset of parameters is included in multiple UPDATEs with different 2339 SEQs, the host MUST ensure that receiver processing of the parameters 2340 multiple times will not result in a protocol error. 2342 5.3.6 NOTIFY - the HIP Notify Packet 2344 The NOTIFY packet is OPTIONAL. The NOTIFY packet MAY be used to 2345 provide information to a peer. Typically, NOTIFY is used to indicate 2346 some type of protocol error or negotiation failure. 2348 The HIP header values for the NOTIFY packet: 2350 Header: 2351 Packet Type = 7 2352 SRC HIT = Sender's HIT 2353 DST HIT = Recipient's HIT, or zero if unknown 2355 IP ( HIP (i, [HOST_ID, ] HIP_SIGNATURE) ) 2357 Valid control bits: None 2359 The NOTIFY packet is used to carry one or more NOTIFY parameters. 2361 5.3.7 CLOSE - the HIP association closing packet 2363 The HIP header values for the CLOSE packet: 2365 Header: 2366 Packet Type = 8 2367 SRC HIT = Sender's HIT 2368 DST HIT = Recipient's HIT 2370 IP ( HIP ( ECHO_REQUEST, HMAC, HIP_SIGNATURE ) ) 2372 Valid control bits: none 2374 The sender MUST include an ECHO_REQUEST used to validate CLOSE_ACK 2375 received in response, and both an HMAC and a signature (calculated 2376 over the whole HIP envelope). 2378 The receiver peer MUST validate both the HMAC and the signature if it 2379 has a HIP association state, and MUST reply with a CLOSE_ACK 2380 containing an ECHO_REPLY corresponding to the received ECHO_REQUEST. 2382 5.3.8 CLOSE_ACK - the HIP Closing Acknowledgment Packet 2384 The HIP header values for the CLOSE_ACK packet: 2386 Header: 2387 Packet Type = 9 2388 SRC HIT = Sender's HIT 2389 DST HIT = Recipient's HIT 2391 IP ( HIP ( ECHO_REPLY, HMAC, HIP_SIGNATURE ) ) 2393 Valid control bits: none 2395 The sender MUST include both an HMAC and signature (calculated over 2396 the whole HIP envelope). 2398 The receiver peer MUST validate both the HMAC and the signature. 2400 5.4 ICMP Messages 2402 When a HIP implementation detects a problem with an incoming packet, 2403 and it either cannot determine the identity of the sender of the 2404 packet or does not have any existing HIP association with the sender 2405 of the packet, it MAY respond with an ICMP packet. Any such replies 2406 MUST be rate limited as described in [4]. In most cases, the ICMP 2407 packet will have the Parameter Problem type (12 for ICMPv4, 4 for 2408 ICMPv6), with the Pointer field pointing to the field that caused the 2409 ICMP message to be generated. 2411 5.4.1 Invalid Version 2413 If a HIP implementation receives a HIP packet that has an 2414 unrecognized HIP version number, it SHOULD respond, rate limited, 2415 with an ICMP packet with type Parameter Problem, the Pointer pointing 2416 to the VER./RES. byte in the HIP header. 2418 5.4.2 Other Problems with the HIP Header and Packet Structure 2420 If a HIP implementation receives a HIP packet that has other 2421 unrecoverable problems in the header or packet format, it MAY 2422 respond, rate limited, with an ICMP packet with type Parameter 2423 Problem, the Pointer pointing to the field that failed to pass the 2424 format checks. However, an implementation MUST NOT send an ICMP 2425 message if the Checksum fails; instead, it MUST silently drop the 2426 packet. 2428 5.4.3 Invalid Cookie Solution 2430 If a HIP implementation receives an I2 packet that has an invalid 2431 cookie solution, the behavior depends on the underlying version of 2432 IP. If IPv6 is used, the implementation SHOULD respond with an ICMP 2433 packet with type Parameter Problem, the Pointer pointing to the 2434 beginning of the Puzzle solution #J field in the SOLUTION payload in 2435 the HIP message. 2437 If IPv4 is used, the implementation MAY respond with an ICMP packet 2438 with the type Parameter Problem, copying enough of bytes from the I2 2439 message so that the SOLUTION parameter fits into the ICMP message, 2440 the Pointer pointing to the beginning of the Puzzle solution #J 2441 field, as in the IPv6 case. Note, however, that the resulting ICMPv4 2442 message exceeds the typical ICMPv4 message size as defined in [2]. 2444 5.4.4 Non-existing HIP Association 2446 If a HIP implementation receives a CLOSE, or UPDATE packet, or any 2447 other packet whose handling requires an existing association, that 2448 has either a Receiver or Sender HIT that does not match with any 2449 existing HIP association, the implementation MAY respond, rate 2450 limited, with an ICMP packet with the type Parameter Problem, the 2451 Pointer pointing to the the beginning of the first HIT that does not 2452 match. 2454 A host MUST NOT reply with such an ICMP if it receives any of the 2455 following messages: I1, R2, I2, R2, and NOTIFY. When introducing new 2456 packet types, a specification SHOULD define the appropriate rules for 2457 sending or not sending this kind of ICMP replies. 2459 6. Packet Processing 2461 Each host is assumed to have a single HIP protocol implementation 2462 that manages the host's HIP associations and handles requests for new 2463 ones. Each HIP association is governed by a conceptual state 2464 machine, with states defined above in Section 4.4. The HIP 2465 implementation can simultaneously maintain HIP associations with more 2466 than one host. Furthermore, the HIP implementation may have more 2467 than one active HIP association with another host; in this case, HIP 2468 associations are distinguished by their respective HITs. It is not 2469 possible to have more than one HIP association between any given pair 2470 of HITs. Consequently, the only way for two hosts to have more than 2471 one parallel association is to use different HITs, at least at one 2472 end. 2474 The processing of packets depends on the state of the HIP 2475 association(s) with respect to the authenticated or apparent 2476 originator of the packet. A HIP implementation determines whether it 2477 has an active association with the originator of the packet based on 2478 the HITs. In the case of user data carried in a specific transport 2479 format, the transport format document specifies how the incoming 2480 packets are matched with the active associations. 2482 6.1 Processing Outgoing Application Data 2484 In a HIP host, an application can send application level data using 2485 HITs or local scope identifiers (LSIs) as source and destination 2486 identifiers. The HITs and LSIs may be specified via a backwards 2487 compatible API (see [32]) or a completely new API. The exact format 2488 and method for transferring the data from the source HIP host to the 2489 destination HIP host is defined in the corresponding transport format 2490 document. The actual data is transmitted in the network using the 2491 appropriate source and destination IP addresses. Here, we specify 2492 the processing rules only for the base case where both hosts have 2493 only single usable IP addresses; the multi-address multi-homing case 2494 will be specified separately. 2496 If the IPv4 or IPv6 backward compatible APIs and therefore LSIs are 2497 supported, it is assumed that the LSIs will be converted into proper 2498 HITs somewhere in the stack. The exact location of the conversion is 2499 an implementation specific issue and not discussed here. The 2500 following conceptual algorithm discusses only HITs, with the 2501 assumption that the LSI-to-HIT conversion takes place somewhere. 2503 The following steps define the conceptual processing rules for 2504 outgoing datagrams destined to a HIT. 2506 1. If the datagram has a specified source address, it MUST be a HIT. 2507 If it is not, the implementation MAY replace the source address 2508 with a HIT. Otherwise it MUST drop the packet. 2510 2. If the datagram has an unspecified source address, the 2511 implementation must choose a suitable source HIT for the 2512 datagram. 2514 3. If there is no active HIP session with the given < source, 2515 destination > HIT pair, one must be created by running the base 2516 exchange. While waiting for the base exchange to complete, the 2517 implementation SHOULD queue at least one packet per HIP session 2518 to be formed, and it MAY queue more than one. 2520 4. Once there is an active HIP session for the given < source, 2521 destination > HIT pair, the outgoing datagram is passed to 2522 transport handling. The possible transport formats are defined 2523 in separate documents, of which the ESP transport format for HIP 2524 is mandatory for all HIP implementations. 2526 5. Before sending the packet, the HITs in the datagram are replaced 2527 with suitable IP addresses. For IPv6, the rules defined in [16] 2528 SHOULD be followed. Note that this HIT-to-IP-address conversion 2529 step MAY also be performed at some other point in the stack, 2530 e.g., before wrapping the packet into the output format. 2532 6.2 Processing Incoming Application Data 2534 The transport format and method (defined in separate specifications) 2535 determines the format in which incoming HIP packets arrive to the 2536 host. The following steps define the conceptual processing rules for 2537 incoming datagrams. The specific transport format and method 2538 specifications define in more detail the packet processing, related 2539 to the method. 2541 1. The incoming datagram is mapped to an existing HIP association, 2542 typically using some information from the packet. For example, 2543 such mapping may be based on ESP Security Parameter Index (SPI). 2545 2. The specific transport format is unwrapped, in a way depending on 2546 the transport format, yielding a packet that looks like a 2547 standard (unencrypted) IP packet. If possible, this step SHOULD 2548 also verify that the packet was indeed (once) sent by the remote 2549 HIP host, as identified by the HIP association. 2551 3. The IP addresses in the datagram are replaced with the HITs 2552 associated with the HIP association. Note that this IP-address- 2553 to-HIT conversion step MAY also be performed at some other point 2554 in the stack. 2556 4. The datagram is delivered to the upper layer. Demultiplexing the 2557 datagram the right upper layer socket is based on the HITs (or 2558 LSIs). 2560 6.3 HMAC and SIGNATURE Calculation and Verification 2562 The following subsections define the actions for processing HMAC, 2563 HIP_SIGNATURE and HIP_SIGNATURE_2 TLVs. 2565 6.3.1 HMAC Calculation 2567 The following process applies both to the HMAC and HMAC_2 TLVs. When 2568 processing HMAC_2, the difference is that the HMAC calculation 2569 includes a pseudo HOST_ID field containing the Responder's 2570 information as sent in the R1 packet earlier. 2572 Both the Initiator and the Responder should take some care when 2573 verifying or calculating the HMAC_2. Specifically, the Responder 2574 should preserve other parameters than the HOST_ID when sending the 2575 R2. Also, the Initiator has to preserve the HOST_ID exactly as it 2576 was received in the R1 packet. 2578 The HMAC TLV is defined in Section 5.2.9 and HMAC_2 TLV in 2579 Section 5.2.10. HMAC calculation and verification process: 2581 Packet sender: 2583 1. Create the HIP packet, without the HMAC or any possible 2584 HIP_SIGNATURE or HIP_SIGNATURE_2 TLVs. 2586 2. In case of HMAC_2 calculation, add a HOST_ID (Responder) TLV to 2587 the packet. 2589 3. Calculate the Length field in the HIP header. 2591 4. Compute the HMAC. 2593 5. In case of HMAC_2, remove the HOST_ID TLV from the packet. 2595 6. Add the HMAC TLV to the packet and any HIP_SIGNATURE or 2596 HIP_SIGNATURE_2 TLVs that may follow. 2598 7. Recalculate the Length field in the HIP header. 2600 Packet receiver: 2602 1. Verify the HIP header Length field. 2604 2. Remove the HMAC or HMAC_2 TLV, and if the packet contains any 2605 HIP_SIGNATURE or HIP_SIGNATURE_2 fields, remove them too, saving 2606 the contents if they will be needed later. 2608 3. In case of HMAC_2, build and add a HOST_ID TLV (with Responder 2609 information) to the packet. The HOST_ID TLV should be identical 2610 to the one previously received from the Responder. 2612 4. Recalculate the HIP packet length in the HIP header and clear the 2613 Checksum field (set it to all zeros). 2615 5. Compute the HMAC and verify it against the received HMAC. 2617 6. In case of HMAC_2, remove the HOST_ID TLV from the packet before 2618 further processing. 2620 6.3.2 Signature Calculation 2622 The following process applies both to the HIP_SIGNATURE and 2623 HIP_SIGNATURE_2 TLVs. When processing HIP_SIGNATURE_2, the only 2624 difference is that instead of HIP_SIGNATURE TLV, the HIP_SIGNATURE_2 2625 TLV is used, and the Initiator's HIT and PUZZLE Opaque and Random #I 2626 fields are cleared (set to all zeros) before computing the signature. 2627 The HIP_SIGNATURE TLV is defined in Section 5.2.11 and the 2628 HIP_SIGNATURE_2 TLV in Section 5.2.12. 2630 Signature calculation and verification process: 2632 Packet sender: 2634 1. Create the HIP packet without the HIP_SIGNATURE TLV or any TLVs 2635 that follow the HIP_SIGNATURE TLV. 2637 2. Calculate the Length field and zero the Checksum field in the HIP 2638 header. 2640 3. Compute the signature. 2642 4. Add the HIP_SIGNATURE TLV to the packet. 2644 5. Add any TLVs that follow the HIP_SIGNATURE TLV. 2646 6. Recalculate the Length field in the HIP header, and calculate the 2647 Checksum field. 2649 Packet receiver: 2651 1. Verify the HIP header Length field. 2653 2. Save the contents of the HIP_SIGNATURE TLV and any TLVs following 2654 the HIP_SIGNATURE TLV and remove them from the packet. 2656 3. Recalculate the HIP packet Length in the HIP header and clear the 2657 Checksum field (set it to all zeros). 2659 4. Compute the signature and verify it against the received 2660 signature. 2662 The verification can use either the HI received from a HIP packet, 2663 the HI from a DNS query, if the FQDN has been received in the HOST_ID 2664 packet, or one received by some other means. 2666 6.4 HIP KEYMAT Generation 2668 HIP keying material is derived from the Diffie-Hellman Kij produced 2669 during the HIP base exchange. The Initiator has Kij during the 2670 creation of the I2 packet, and the Responder has Kij once it receives 2671 the I2 packet. This is why I2 can already contain encrypted 2672 information. 2674 The KEYMAT is derived by feeding Kij and the HITs into the following 2675 operation; the | operation denotes concatenation. 2677 KEYMAT = K1 | K2 | K3 | ... 2678 where 2680 K1 = SHA-1( Kij | sort(HIT-I | HIT-R) | I | J | 0x01 ) 2681 K2 = SHA-1( Kij | K1 | 0x02 ) 2682 K3 = SHA-1( Kij | K2 | 0x03 ) 2683 ... 2684 K255 = SHA-1( Kij | K254 | 0xff ) 2685 K256 = SHA-1( Kij | K255 | 0x00 ) 2686 etc. 2688 Sort(HIT-I | HIT-R) is defined as the network byte order 2689 concatenation of the two HITs, with the smaller HIT preceding the 2690 larger HIT, resulting from the numeric comparison of the two HITs 2691 interpreted as positive (unsigned) 128-bit integers in network byte 2692 order. 2694 I and J values are from the puzzle and its solution that were 2695 exchanged in R1 and I2 messages when this HIP association was set up. 2696 Both hosts have to store I and J values for the HIP association for 2697 future use. 2699 The initial keys are drawn sequentially in the order that is 2700 determined by the numeric comparison of the two HITs, with comparison 2701 method described in the previous paragraph. HOST_g denotes the host 2702 with the greater HIT value, and HOST_l the host with the lower HIT 2703 value. 2705 The drawing order for initial keys: 2707 HIP-gl encryption key for HOST_g's outgoing HIP packets 2709 HIP-gl integrity (HMAC) key for HOST_g's outgoing HIP packets 2711 HIP-lg encryption key (currently unused) for HOST_l's outgoing HIP 2712 packets 2714 HIP-lg integrity (HMAC) key for HOST_l's outgoing HIP packets 2716 The number of bits drawn for a given algorithm is the "natural" size 2717 of the keys. For the mandatory algorithms, the following sizes 2718 apply: 2720 AES 128 bits 2722 SHA-1 160 bits 2724 NULL 0 bits 2726 6.5 Initiation of a HIP Exchange 2728 An implementation may originate a HIP exchange to another host based 2729 on a local policy decision, usually triggered by an application 2730 datagram, in much the same way that an IPsec IKE key exchange can 2731 dynamically create a Security Association. Alternatively, a system 2732 may initiate a HIP exchange if it has rebooted or timed out, or 2733 otherwise lost its HIP state, as described in Section 4.5.4. 2735 The implementation prepares an I1 packet and sends it to the IP 2736 address that corresponds to the peer host. The IP address of the 2737 peer host may be obtained via conventional mechanisms, such as DNS 2738 lookup. The I1 contents are specified in Section 5.3.1. The 2739 selection of which host identity to use, if a host has more than one 2740 to choose from, is typically a policy decision. 2742 The following steps define the conceptual processing rules for 2743 initiating a HIP exchange: 2745 1. The Initiator gets the Responder's HIT and one or more addresses 2746 either from a DNS lookup of the Responder's FQDN, from some other 2747 repository, or from a local table. If the Initiator does not 2748 know the Responder's HIT, it may attempt opportunistic mode by 2749 using NULL (all zeros) as the Responder's HIT. 2751 2. The Initiator sends an I1 to one of the Responder's addresses. 2752 The selection of which address to use is a local policy decision. 2754 3. Upon sending an I1, the sender shall transition to state I1-SENT, 2755 start a timer whose timeout value should be larger than the 2756 worst-case anticipated RTT, and shall increment a timeout counter 2757 associated with the I1. 2759 4. Upon timeout, the sender SHOULD retransmit the I1 and restart the 2760 timer, up to a maximum of I1_RETRIES_MAX tries. 2762 6.5.1 Sending Multiple I1s in Parallel 2764 For the sake of minimizing the session establishment latency, an 2765 implementation MAY send the same I1 to more than one of the 2766 Responder's addresses. However, it MUST NOT send to more than three 2767 (3) addresses in parallel. Furthermore, upon timeout, the 2768 implementation MUST refrain from sending the same I1 packet to 2769 multiple addresses. These limitations are placed order to avoid 2770 congestion of the network, and potential DoS attacks that might 2771 happen, e.g., because someone claims to have hundreds or thousands of 2772 addresses. 2774 As the Responder is not guaranteed to distinguish the duplicate I1's 2775 it receives at several of its addresses (because it avoids to store 2776 states when it answers back an R1), the Initiator may receive several 2777 duplicate R1's. 2779 The Initiator SHOULD then select the initial preferred destination 2780 address using the source address of the selected received R1, and use 2781 the preferred address as a source address for the I2. Processing 2782 rules for received R1s are discussed in Section 6.7. 2784 6.5.2 Processing Incoming ICMP Protocol Unreachable Messages 2786 A host may receive an ICMP Destination Protocol Unreachable message 2787 as a response to sending an HIP I1 packet. Such a packet may be an 2788 indication that the peer does not support HIP, or it may be an 2789 attempt to launch an attack by making the Initiator believe that the 2790 Responder does not support HIP. 2792 When a system receives an ICMP Destination Protocol Unreachable 2793 message while it is waiting for an R1, it MUST NOT terminate the 2794 wait. It MAY continue as if it had not received the ICMP message, 2795 and send a few more I1s. Alternatively, it MAY take the ICMP message 2796 as a hint that the peer most probably does not support HIP, and 2797 return to state UNASSOCIATED earlier than otherwise. However, at 2798 minimum, it MUST continue waiting for an R1 for a reasonable time 2799 before returning to UNASSOCIATED. 2801 6.6 Processing Incoming I1 Packets 2803 An implementation SHOULD reply to an I1 with an R1 packet, unless the 2804 implementation is unable or unwilling to setup a HIP association. If 2805 the implementation is unable to setup a HIP association, the host 2806 SHOULD send an ICMP Destination Protocol Unreachable, 2807 Administratively Prohibited, message to the I1 source address. If 2808 the implementation is unwilling to setup a HIP association, the host 2809 MAY ignore the I1. This latter case may occur during a DoS attack 2810 such as an I1 flood. 2812 The implementation MUST be able to handle a storm of received I1 2813 packets, discarding those with common content that arrive within a 2814 small time delta. 2816 A spoofed I1 can result in an R1 attack on a system. An R1 sender 2817 MUST have a mechanism to rate limit R1s to an address. 2819 It is RECOMMENDED that the HIP state machine does not transition upon 2820 sending an R1. 2822 The following steps define the conceptual processing rules for 2823 responding to an I1 packet: 2825 1. The Responder MUST check that the Responder HIT in the received 2826 I1 is either one of its own HITs, or NULL. 2828 2. If the Responder is in ESTABLISHED state, the Responder MAY 2829 respond to this with an R1 packet, prepare to drop existing SAs 2830 and stay at ESTABLISHED state. 2832 3. If the Responder is in I1-SENT state, it must make a comparison 2833 between the sender's HIT and its own HIT. If the sender's HIT is 2834 greater than its own HIT, it should drop the I1 and stay at I1- 2835 SENT. If the sender's HIT is smaller than its own HIT, it should 2836 send R1 and stay at I1-SENT. The HIT comparison goes similarly 2837 as in Section 6.4. 2839 4. If the implementation chooses to respond to the I1 with an R1 2840 packet, it creates a new R1 or selects a precomputed R1 according 2841 to the format described in Section 5.3.2. 2843 5. The R1 MUST contain the received Responder HIT, unless the 2844 received HIT is NULL, in which case the Responder SHOULD select a 2845 HIT that is constructed with the MUST algorithm in Section 3, 2846 which is currently RSA. Other than that, selecting the HIT is a 2847 local policy matter. 2849 6. The Responder sends the R1 to the source IP address of the I1 2850 packet. 2852 6.6.1 R1 Management 2854 All compliant implementations MUST produce R1 packets. An R1 packet 2855 MAY be precomputed. An R1 packet MAY be reused for time Delta T, 2856 which is implementation dependent. R1 information MUST not be 2857 discarded until Delta S after T. Time S is the delay needed for the 2858 last I2 to arrive back to the Responder. 2860 An implementation MAY keep state about received I1s and match the 2861 received I2s against the state, as discussed in Section 4.1.1. 2863 6.6.2 Handling Malformed Messages 2865 If an implementation receives a malformed I1 message, it SHOULD NOT 2866 respond with a NOTIFY message, as such practice could open up a 2867 potential denial-of-service danger. Instead, it MAY respond with an 2868 ICMP packet, as defined in Section 5.4. 2870 6.7 Processing Incoming R1 Packets 2872 A system receiving an R1 MUST first check to see if it has sent an I1 2873 to the originator of the R1 (i.e., it is in state I1-SENT). If so, 2874 it SHOULD process the R1 as described below, send an I2, and go to 2875 state I2-SENT, setting a timer to protect the I2. If the system is 2876 in state I2-SENT, it MAY respond to an R1 if the R1 has a larger R1 2877 generation counter; if so, it should drop its state due to processing 2878 the previous R1 and start over from state I1-SENT. If the system is 2879 in any other state with respect to that host, it SHOULD silently drop 2880 the R1. 2882 When sending multiple I1s, an Initiator SHOULD wait for a small 2883 amount of time after the first R1 reception to allow possibly 2884 multiple R1s to arrive, and it SHOULD respond to an R1 among the set 2885 with the largest R1 generation counter. 2887 The following steps define the conceptual processing rules for 2888 responding to an R1 packet: 2890 1. A system receiving an R1 MUST first check to see if it has sent 2891 an I1 to the originator of the R1 (i.e., it has a HIP 2892 association that is in state I1-SENT and that is associated with 2893 the HITs in the R1). If so, it should process the R1 as 2894 described below. 2896 2. Otherwise, if the system is in any other state than I1-SENT or 2897 I2-SENT with respect to the HITs included in the R1, it SHOULD 2898 silently drop the R1 and remain in the current state. 2900 3. If the HIP association state is I1-SENT or I2-SENT, the received 2901 Initiator's HIT MUST correspond to the HIT used in the original, 2902 I1 and the Responder's HIT MUST correspond to the one used, 2903 unless the I1 contained a NULL HIT. 2905 4. The system SHOULD validate the R1 signature before applying 2906 further packet processing, according to Section 5.2.12. 2908 5. If the HIP association state is I1-SENT, and multiple valid R1s 2909 are present, the system SHOULD select from among the R1s with 2910 the largest R1 generation counter. 2912 6. If the HIP association state is I2-SENT, the system MAY reenter 2913 state I1-SENT and process the received R1 if it has a larger R1 2914 generation counter than the R1 responded to previously. 2916 7. The R1 packet may have the A bit set -- in this case, the system 2917 MAY choose to refuse it by dropping the R1 and returning to 2918 state UNASSOCIATED. The system SHOULD consider dropping the R1 2919 only if it used a NULL HIT in I1. If the A bit is set, the 2920 Responder's HIT is anonymous and should not be stored. 2922 8. The system SHOULD attempt to validate the HIT against the 2923 received Host Identity. 2925 9. The system MUST store the received R1 generation counter for 2926 future reference. 2928 10. The system attempts to solve the cookie puzzle in R1. The 2929 system MUST terminate the search after exceeding the remaining 2930 lifetime of the puzzle. If the cookie puzzle is not 2931 successfully solved, the implementation may either resend I1 2932 within the retry bounds or abandon the HIP exchange. 2934 11. The system computes standard Diffie-Hellman keying material 2935 according to the public value and Group ID provided in the 2936 DIFFIE_HELLMAN parameter. The Diffie-Hellman keying material 2937 Kij is used for key extraction as specified in Section 6.4. If 2938 the received Diffie-Hellman Group ID is not supported, the 2939 implementation may either resend I1 within the retry bounds or 2940 abandon the HIP exchange. 2942 12. The system selects the HIP transform from the choices presented 2943 in the R1 packet and uses the selected values subsequently when 2944 generating and using encryption keys, and when sending the I2. 2945 If the proposed alternatives are not acceptable to the system, 2946 it may either resend I1 within the retry bounds or abandon the 2947 HIP exchange. 2949 13. The system initialized the remaining variables in the associated 2950 state, including Update ID counters. 2952 14. The system prepares and sends an I2, as described in 2953 Section 5.3.3. 2955 15. The system SHOULD start a timer whose timeout value should be 2956 larger than the worst-case anticipated RTT, and MUST increment a 2957 timeout counter associated with the I2. The sender SHOULD 2958 retransmit the I2 upon a timeout and restart the timer, up to a 2959 maximum of I2_RETRIES_MAX tries. 2961 16. If the system is in state I1-SENT, it shall transition to state 2962 I2-SENT. If the system is in any other state, it remains in the 2963 current state. 2965 6.7.1 Handling Malformed Messages 2967 If an implementation receives a malformed R1 message, it MUST 2968 silently drop the packet. Sending a NOTIFY or ICMP would not help, 2969 as the sender of the R1 typically doesn't have any state. An 2970 implementation SHOULD wait for some more time for a possible good R1, 2971 after which it MAY try again by sending a new I1 packet. 2973 6.8 Processing Incoming I2 Packets 2975 Upon receipt of an I2, the system MAY perform initial checks to 2976 determine whether the I2 corresponds to a recent R1 that has been 2977 sent out, if the Responder keeps such state. For example, the sender 2978 could check whether the I2 is from an address or HIT that has 2979 recently received an R1 from it. The R1 may have had Opaque data 2980 included that was echoed back in the I2. If the I2 is considered to 2981 be suspect, it MAY be silently discarded by the system. 2983 Otherwise, the HIP implementation SHOULD process the I2. This 2984 includes validation of the cookie puzzle solution, generating the 2985 Diffie-Hellman key, decrypting the Initiator's Host Identity, 2986 verifying the signature, creating state, and finally sending an R2. 2988 The following steps define the conceptual processing rules for 2989 responding to an I2 packet: 2991 1. The system MAY perform checks to verify that the I2 corresponds 2992 to a recently sent R1. Such checks are implementation 2993 dependent. See Appendix C for a description of an example 2994 implementation. 2996 2. The system MUST check that the Responder's HIT corresponds to 2997 one of its own HITs. 2999 3. If the system is in the R2-SENT state, it MAY check if the newly 3000 received I2 is similar to the one that triggered moving to R2- 3001 SENT. If so, it MAY retransmit a previously sent R2, reset the 3002 R2-SENT timer, and stay in R2-SENT. 3004 4. If the system is in the I2-SENT state, it makes a comparison 3005 between its local and sender's HITs (similarly as in 3006 Section 6.4). If the local HIT is smaller than the sender's 3007 HIT, it should drop the I2 packet. Otherwise, the system should 3008 process the received I2 packet. 3010 5. To avoid the possibility to end up with different session keys 3011 due to symmetric operation of the peer nodes, the Diffie-Hellman 3012 key, I, and J selection is also based on the HIT comparison. If 3013 the local HIT is smaller than the peer HIT, the system uses peer 3014 Diffie-Hellman key and nonce I from the R1 packet received 3015 earlier. The local Diffie-Hellman key and nonce J are taken 3016 from the I2 packet sent to the peer earlier. Otherwise, it uses 3017 peer Diffie-Hellman key and nonce J from the just arrived I2. 3018 The local Diffie-Hellman key and nonce I are the ones that it 3019 sent ealier in the R1 packet. 3021 6. If the system is in any other state than R2-SENT, it SHOULD 3022 check that the echoed R1 generation counter in I2 is within the 3023 acceptable range. Implementations MUST accept puzzles from the 3024 current generation and MAY accept puzzles from earlier 3025 generations. If the newly received I2 is outside the accepted 3026 range, the I2 is stale (perhaps replayed) and SHOULD be dropped. 3028 7. The system MUST validate the solution to the cookie puzzle by 3029 computing the SHA-1 hash described in Section 5.3.3. 3031 8. The I2 MUST have a single value in the HIP_TRANSFORM parameter, 3032 which MUST match one of the values offered to the Initiator in 3033 the R1 packet. 3035 9. The system must derive Diffie-Hellman keying material Kij based 3036 on the public value and Group ID in the DIFFIE_HELLMAN 3037 parameter. This key is used to derive the HIP association keys, 3038 as described in Section 6.4. If the Diffie-Hellman Group ID is 3039 unsupported, the I2 packet is silently dropped. 3041 10. The encrypted HOST_ID decrypted by the Initiator encryption key 3042 defined in Section 6.4. If the decrypted data is not a HOST_ID 3043 parameter, the I2 packet is silently dropped. 3045 11. The implementation SHOULD also verify that the Initiator's HIT 3046 in the I2 corresponds to the Host Identity sent in the I2. 3048 12. The system MUST verify the HMAC according to the procedures in 3049 Section 5.2.9. 3051 13. The system MUST verify the HIP_SIGNATURE according to 3052 Section 5.2.11 and Section 5.3.3. 3054 14. If the checks above are valid, then the system proceeds with 3055 further I2 processing; otherwise, it discards the I2 and remains 3056 in the same state. 3058 15. The I2 packet may have the A bit set -- in this case, the system 3059 MAY choose to refuse it by dropping the I2 and returning to 3060 state UNASSOCIATED. If the A bit is set, the Initiator's HIT is 3061 anonymous and should not be stored. 3063 16. The system initialized the remaining variables in the associated 3064 state, including Update ID counters. 3066 17. Upon successful processing of an I2 in states UNASSOCIATED, I1- 3067 SENT, I2-SENT, and R2-SENT, an R2 is sent and the state machine 3068 transitions to state R2-SENT. 3070 18. Upon successful processing of an I2 in state ESTABLISHED, the 3071 old HIP association is dropped and a new one is installed, an R2 3072 is sent, and the state machine transitions to R2-SENT. 3074 19. Upon transitioning to R2-SENT, start a timer. Move to 3075 ESTABLISHED if some data has been received on the incoming HIP 3076 association, or an UPDATE packet has been received (or some 3077 other packet that indicates that the peer has moved to 3078 ESTABLISHED). If the timer expires (allowing for maximal 3079 retransmissions of I2s), move to UNASSOCIATED. 3081 6.8.1 Handling Malformed Messages 3083 If an implementation receives a malformed I2 message, the behavior 3084 SHOULD depend on how much checks the message has already passed. If 3085 the puzzle solution in the message has already been checked, the 3086 implementation SHOULD report the error by responding with a NOTIFY 3087 packet. Otherwise the implementation MAY respond with an ICMP 3088 message as defined in Section 5.4. 3090 6.9 Processing Incoming R2 Packets 3092 An R2 received in states UNASSOCIATED, I1-SENT, ESTABLISHED, or 3093 REKEYING results in the R2 being dropped and the state machine 3094 staying in the same state. If an R2 is received in state I2-SENT, it 3095 SHOULD be processed. 3097 The following steps define the conceptual processing rules for 3098 incoming R2 packet: 3100 1. The system MUST verify that the HITs in use correspond to the 3101 HITs that were received in R1. 3103 2. The system MUST verify the HMAC_2 according to the procedures in 3104 Section 5.2.10. 3106 3. The system MUST verify the HIP signature according to the 3107 procedures in Section 5.2.11. 3109 4. If any of the checks above fail, there is a high probability of 3110 an ongoing man-in-the-middle or other security attack. The 3111 system SHOULD act accordingly, based on its local policy. 3113 5. If the system is in any other state than I2-SENT, the R2 is 3114 silently dropped. 3116 6. Upon successful processing of the R2, the state machine moves to 3117 state ESTABLISHED. 3119 6.10 Sending UPDATE Packets 3121 A host sends an UPDATE packet when it wants to update some 3122 information related to a HIP association. There are a number of 3123 likely situations, e.g. mobility management and rekeying of an 3124 existing ESP Security Association. The following paragraphs define 3125 the conceptual rules for sending an UPDATE packet to the peer. 3126 Additional steps can be defined in other documents where the UPDATE 3127 packet is used. 3129 1. The system increments its own Update ID value by one. 3131 2. The system creates an UPDATE packet that contains a SEQ parameter 3132 with the current value of Update ID. The UPDATE packet may also 3133 include an ACK of the Update ID found in a received UPDATE SEQ 3134 parameter, if any. 3136 3. The system sends the created UPDATE packet and starts an UPDATE 3137 timer. The default value for the timer is 2 * RTT estimate. 3139 4. If the UPDATE timer expires, the UPDATE is resent. The UPDATE 3140 can be resent UPDATE_RETRY_MAX times. The UPDATE timer SHOULD be 3141 exponentially backed off for subsequent retransmissions. 3143 6.11 Receiving UPDATE Packets 3145 When a system receives an UPDATE packet, its processing depends on 3146 the state of the HIP association and the presence of and values of 3147 the SEQ and ACK parameters. Typically, an UPDATE message also 3148 carries optional parameters whose handling is defined in separate 3149 documents. 3151 1. If there is no corresponding HIP association, the implementation 3152 MAY reply with an ICMP Parameter Problem, as specified in 3153 Section 5.4.4. 3155 2. If the association is in the ESTABLISHED state and the SEQ 3156 parameter is present, the UPDATE is processed and replied as 3157 described in Section 6.11.1. 3159 3. Additionally (or alternatively), if the association is in the 3160 ESTABLISHED state and there is an ACK (of outstanding Update ID) 3161 in the UPDATE, the UPDATE is processed as described in 3162 Section 6.11.2. 3164 6.11.1 Handling a SEQ paramaeter in a received UPDATE message 3165 1. If the Update ID in the received SEQ is smaller than the stored 3166 Update ID for the peer host, the packet MUST BE dropped as a 3167 duplicate. 3169 2. If the Update ID in the received SEQ is equal to the stored 3170 Update ID for the host, the packet is treated as a 3171 retransmission. The HMAC verification (next step) MUST NOT be 3172 skipped. (A byte-by-byte comparison of the received and a stored 3173 packet would be OK, though.) It is recommended that a host cache 3174 the last packet that was acked to avoid the cost of generating a 3175 new ACK packet to respond to a replayed UPDATE. The system MUST 3176 acknowledge, again, such (apparent) UPDATE message 3177 retransmissions but SHOULD also consider rate-limiting such 3178 retransmission responses to guard against replay attacks. 3180 3. The system MUST verify the HMAC in the UPDATE packet. If the 3181 verification fails, the packet MUST be dropped. 3183 4. The system MAY verify the SIGNATURE in the UPDATE packet. If the 3184 verification fails, the packet SHOULD be dropped and an error 3185 message logged. 3187 5. If a new SEQ parameter is being processed, the system MUST record 3188 the Update ID in the received SEQ parameter, for replay 3189 protection. 3191 6. An UPDATE acknowledgement packet with ACK parameter is prepared 3192 and sent to the peer. 3194 6.11.2 Handling an ACK Parameter in a Received UPDATE Packet 3196 1. The UPDATE packet with ACK must match with an earlier sent UPDATE 3197 packet. If no match is found, the packet MUST be dropped. 3199 2. The system MUST verify the HMAC in the UPDATE packet. If the 3200 verification fails, the packet MUST be dropped. 3202 3. The system MAY verify the SIGNATURE in the UPDATE packet. If the 3203 verification fails, the packet SHOULD be dropped and an error 3204 message logged. 3206 4. The corresponding UPDATE timer is stopped (see Section 6.10) so 3207 that the now acknowledged UPDATE is no longer retransmitted. 3209 6.12 Processing NOTIFY Packets 3211 Processing NOTIFY packets is OPTIONAL. If processed, any errors 3212 noted by the NOTIFY parameter SHOULD be taken into account by the HIP 3213 state machine (e.g., by terminating a HIP handshake), and the error 3214 SHOULD be logged. 3216 6.13 Processing CLOSE Packets 3218 When the host receives a CLOSE message it responds with a CLOSE_ACK 3219 message and moves to CLOSED state. (The authenticity of the CLOSE 3220 message is verified using both HMAC and SIGNATURE). This processing 3221 applies whether or not the HIP association state is CLOSING in order 3222 to handle CLOSE messages from both ends crossing in flight. 3224 The HIP association is not discarded before the host moves from the 3225 UNASSOCIATED state. 3227 Once the closing process has started, any need to send data packets 3228 will trigger creating and establishing of a new HIP association, 3229 starting with sending an I1. 3231 If there is no corresponding HIP association, the implementation MAY 3232 reply to a CLOSE with an ICMP Parameter Problem, as specified in 3233 Section 5.4.4. 3235 6.14 Processing CLOSE_ACK Packets 3237 When a host receives a CLOSE_ACK message it verifies that it is in 3238 CLOSING or CLOSED state and that the CLOSE_ACK was in response to the 3239 CLOSE (using the included ECHO_REPLY in response to the sent 3240 ECHO_REQUEST). 3242 The CLOSE_ACK uses HMAC and SIGNATURE for verification. The state is 3243 discarded when the state changes to UNASSOCIATED and, after that, 3244 NOTIFY is sent as a response to a CLOSE message. 3246 6.15 Dropping HIP Associations 3248 A HIP implementation is free to drop a HIP association at any time, 3249 based on its own policy. If a HIP host decides to drop a HIP 3250 association, it deletes the corresponding HIP state, including the 3251 keying material. The implementation MUST also drop the peer's R1 3252 generation counter value, unless a local policy explicitly defines 3253 that the value of that particular host is stored. An implementation 3254 MUST NOT store R1 generation counters by default, but storing R1 3255 generation counter values, if done, MUST be configured by explicit 3256 HITs. 3258 7. HIP Policies 3260 There are a number of variables that will influence the HIP exchanges 3261 that each host must support. All HIP implementations MUST support 3262 more than one simultaneous HIs, at least one of which SHOULD be 3263 reserved for anonymous usage. Although anonymous HIs will be rarely 3264 used as Responder HIs, they will be common for Initiators. Support 3265 for more than two HIs is RECOMMENDED. 3267 Many Initiators would want to use a different HI for different 3268 Responders. The implementations SHOULD provide for an ACL of 3269 Initiator HIT to Responder HIT. This ACL SHOULD also include 3270 preferred transform and local lifetimes. For HITs with HAAs, 3271 wildcarding SHOULD be supported. Thus if a Community of Interest, 3272 like Banking, gets a HAA, a single ACL could be used. A global 3273 wildcard would represent the general policy to be used. Policy 3274 selection would be from most specific to most general. 3276 The value of K used in the HIP R1 packet can also vary by policy. K 3277 should never be greater than 20, but for trusted partners it could be 3278 as low as 0. 3280 Responders would need a similar ACL, representing which hosts they 3281 accept HIP exchanges, and the preferred transform and local 3282 lifetimes. Wildcarding SHOULD be supported for this ACL also. 3284 8. Security Considerations 3286 HIP is designed to provide secure authentication of hosts. HIP also 3287 attempts to limit the exposure of the host to various denial-of- 3288 service and man-in-the-middle (MitM) attacks. In so doing, HIP 3289 itself is subject to its own DoS and MitM attacks that potentially 3290 could be more damaging to a host's ability to conduct business as 3291 usual. 3293 Denial-of-service attacks take advantage of the cost of start of 3294 state for a protocol on the Responder compared to the 'cheapness' on 3295 the Initiator. HIP makes no attempt to increase the cost of the 3296 start of state on the Initiator, but makes an effort to reduce the 3297 cost to the Responder. This is done by having the Responder start 3298 the 3-way exchange instead of the Initiator, making the HIP protocol 3299 4 packets long. In doing this, packet 2 becomes a 'stock' packet 3300 that the Responder MAY use many times. The duration of use is a 3301 paranoia versus throughput concern. Using the same Diffie-Hellman 3302 values and random puzzle #I has some risk. This risk needs to be 3303 balanced against a potential storm of HIP I1 packets. 3305 This shifting of the start of state cost to the Initiator in creating 3306 the I2 HIP packet, presents another DoS attack. The attacker spoofs 3307 the I1 HIP packet and the Responder sends out the R1 HIP packet. 3308 This could conceivably tie up the 'Initiator' with evaluating the R1 3309 HIP packet, and creating the I2 HIP packet. The defense against this 3310 attack is to simply ignore any R1 packet where a corresponding I1 was 3311 not sent. 3313 A second form of DoS attack arrives in the I2 HIP packet. Once the 3314 attacking Initiator has solved the puzzle, it can send packets with 3315 spoofed IP source addresses with either invalid encrypted HIP payload 3316 component or a bad HIP signature. This would take resources in the 3317 Responder's part to reach the point to discover that the I2 packet 3318 cannot be completely processed. The defense against this attack is 3319 after N bad I2 packets, the Responder would discard any I2s that 3320 contain the given Initiator HIT. Thus will shut down the attack. 3321 The attacker would have to request another R1 and use that to launch 3322 a new attack. The Responder could up the value of K while under 3323 attack. On the downside, valid I2s might get dropped too. 3325 A third form of DoS attack is emulating the restart of state after a 3326 reboot of one of the partners. A host restarting would send an I1 to 3327 a peer, which would respond with an R1 even if it were in the 3328 ESTABLISHED state. If the I1 were spoofed, the resulting R1 would be 3329 received unexpectedly by the spoofed host and would be dropped, as in 3330 the first case above. 3332 A fourth form of DoS attack is emulating the end of state. HIP 3333 relies on timers plus a CLOSE/CLOSE_ACK handshake to explicitly 3334 signals the end of a state. Because both CLOSE and CLOSE_ACK 3335 messages contain an HMAC, an outsider cannot close a connection. The 3336 presence of an additional SIGNATURE allows middle-boxes to inspect 3337 these messages and discard the associated state (for e.g., 3338 firewalling, SPI-based NATing, etc.). However, the optional behavior 3339 of replying to CLOSE with an ICMP Parameter Problem packet (as 3340 described in Section 5.4.4) might allow an IP spoofer sending CLOSE 3341 messages to launch reflection attacks. 3343 A fifth form of DoS attack is replaying R1s to cause the Initiator to 3344 solve stale puzzles and become out of synchronization with the 3345 Responder. The R1 generation counter is a monotonically increasing 3346 counter designed to protect against this attack, as described in 3347 section Section 4.1.3. 3349 Man-in-the-middle attacks are difficult to defend against, without 3350 third-party authentication. A skillful MitM could easily handle all 3351 parts of HIP; but HIP indirectly provides the following protection 3352 from a MitM attack. If the Responder's HI is retrieved from a signed 3353 DNS zone, a certificate, or through some other secure means, the 3354 Initiator can use this to validate the R1 HIP packet. 3356 Likewise, if the Initiator's HI is in a secure DNS zone, a trusted 3357 certificate, or otherwise securely available, the Responder can 3358 retrieve it after it gets the I2 HIP packet and validate that. 3359 However, since an Initiator may choose to use an anonymous HI, it 3360 knowingly risks a MitM attack. The Responder may choose not to 3361 accept a HIP exchange with an anonymous Initiator. 3363 If an Initiator wants to use opportunistic mode, it is vulnerable to 3364 man-in-the-middle attacks. Furthermore, the available HI types are 3365 limited to the MUST implement algorithms, as per Section 3. Hence, 3366 if a future specification deprecates the current MUST implement 3367 algorithm(s) and replaces it (them) with some new one(s), backward 3368 compatibility cannot be preserved. 3370 Since not all hosts will ever support HIP, ICMP 'Destination Protocol 3371 Unreachable' are to be expected and present a DoS attack. Against an 3372 Initiator, the attack would look like the Responder does not support 3373 HIP, but shortly after receiving the ICMP message, the Initiator 3374 would receive a valid R1 HIP packet. Thus to protect from this 3375 attack, an Initiator should not react to an ICMP message until a 3376 reasonable delta time to get the real Responder's R1 HIP packet. A 3377 similar attack against the Responder is more involved. First an ICMP 3378 message is expected if the I1 was a DoS attack and the real owner of 3379 the spoofed IP address does not support HIP. The Responder SHOULD 3380 NOT act on this ICMP message to remove the minimal state from the R1 3381 HIP packet (if it has one), but wait for either a valid I2 HIP packet 3382 or the natural timeout of the R1 HIP packet. This is to allow for a 3383 sophisticated attacker that is trying to break up the HIP exchange. 3384 Likewise, the Initiator should ignore any ICMP message while waiting 3385 for an R2 HIP packet, deleting state only after a natural timeout. 3387 9. IANA Considerations 3389 This document defines a new IP Protocol number to be used for HIP. 3390 This protocol has been assigned the number < To Be Assigned by IANA 3391 -- for testing purposes, the protocol number 99 is currently used >. 3393 This document also creates a set of new name spaces. These are 3394 described below. 3396 Packet Type 3398 The 8-bit Packet Type field in a HIP protocol packet describes the 3399 type of a HIP protocol message. It is defined in Section 5.1. 3400 The current values are defined in Section 5.3.1 through 3401 Section 5.3.8 and are listed below: 3403 * I1 is 1. 3405 * R1 is 2. 3407 * I2 is 3. 3409 * R2 is 4. 3411 * UPDATE is 6. 3413 * NOTIFY is 7. 3415 * CLOSE is 8. 3417 * CLOSE_ACK is 9. 3419 New values are assigned through IETF Consensus [10]. 3421 HIP Version 3423 The four bit Version field in a HIP protocol packet describes the 3424 version of the HIP protocol. It is defined in Section 5.1. The 3425 only currently defined value is 1. New values are assigned 3426 through IETF Consensus. 3428 HIT Type 3430 The three bit HIT Type values appear in the Sender's HIT Type and 3431 Destinations's HIT Type fields the Controls field in a HIP 3432 protocol packet. They are defined in in Section 5.1 and the 3433 currently defined values are listed below: 3435 * Type 1 HIT is 1. 3437 * Type 2 HIT is 2. 3439 * Values 0 and 7 are reserved. 3441 New values either from the unassigned or reserved space are 3442 assigned through IETF Consensus. 3444 Parameter Type 3446 The 16 bit Type field in a HIP parameters describes the type of 3447 the parameter. It is defined in Section 5.2.1. The current 3448 values are defined in Section 5.2.3 through Section 5.2.18 and are 3449 listed below: 3451 * R1_COUNTER is 128. 3453 * PUZZLE is 257. 3455 * SOLUTION is 321. 3457 * SEQ is 385. 3459 * ACK is 449. 3461 * DIFFIE_HELLMAN is 513. 3463 * HIP_TRANSFORM is 577. 3465 * ENCRYPTED is 641. 3467 * HOST_ID is 705. 3469 * CERT is 768. 3471 * NOTIFY is 832. 3473 * ECHO_REQUEST is 897. 3475 * ECHO_RESPONSE is 961. 3477 * HMAC is 61505. 3479 * HMAC_2 is 61569. 3481 * HIP_SIGNATURE_2 is 61633. 3483 * HIP_SIGNATURE is 61697. 3485 * ECHO_REQUEST is 63661. 3487 * ECHO_RESPONSE is 63425. 3489 The type codes 0 through 1023 and 61440 through 65535 are reserved 3490 for future base protocol extensions, and are assigned through IETF 3491 Consensus. 3493 The type codes 32768 through 49141 are reserved for 3494 experimentation and private use. Types SHOULD be selected in a 3495 random fashion from this range, thereby reducing the probability 3496 of collisions. A method employing genuine randomness (such as 3497 flipping a coin) SHOULD be used. 3499 All other type codes are assigned through First Come First Served, 3500 with Specification Required [10]. 3502 Group ID 3504 The eight bit Group ID values appear in the DIFFIE_HELLMAN 3505 parameter, defined in Section 5.2.6. The currently defined values 3506 are listed below: 3508 * 384-bit group is 1. 3510 * OAKLEY well known group 1 is 2. 3512 * 1536-bit MODP group is 3. 3514 * 3072-bit MODP group is 4. 3516 * 6144-bit MODP group is 5. 3518 * 8192-bit MODP group is 6. 3520 * Value 0 is reserved. 3522 New values either from the reserved or unassigned space are 3523 assigned through IETF Consensus. 3525 Suite ID 3527 The 16 bit Suite ID values in a HIP_TRANSFORM parameter are 3528 defined in Section 5.2.7. The currently defined values are listed 3529 below: 3531 * AES-CBC with HMAC-SHA1 is 1. 3533 * 3DES-CBC with HMAC-SHA1 is 2. 3535 * 3DES-CBC with HMAC-MD5 is 3. 3537 * BLOWFISH-CBC with HMAC-SHA1 is 4. 3539 * NULL-ENCRYPT with HMAC-SHA1 is 5. 3541 * NULL-ENCRYPT with HMAC-MD5 is 6. 3543 * Value 0 is reserved. 3545 New values either from the reserved or unassigned space are 3546 assigned through IETF Consensus. 3548 DI-Type 3550 The four bit DI-Type values in a HOST_ID parameter are defined in 3551 Section 5.2.8. The currently defined values are listed below: 3553 * None included is 0. 3555 * FQDN is 1. 3557 * NAI is 2. 3559 New values are assigned through IETF Consensus. 3561 Notify Message Type 3563 The 16 bit Notify Message Type field in a NOTIFY parameter is 3564 defined in Section 5.2.16. The currently defined values are 3565 listed below: 3567 * UNSUPPORTED_CRITICAL_PARAMETER_TYPE is 1. 3569 * INVALID_SYNTAX is 7. 3571 * NO_DH_PROPOSAL_CHOSEN is 14. 3573 * INVALID_DH_CHOSEN is 15. 3575 * NO_HIP_PROPOSAL_CHOSEN is 16. 3577 * INVALID_HIP_TRANSFORM_CHOSEN is 17. 3579 * AUTHENTICATION_FAILED is 24. 3581 * CHECKSUM_FAILED is 26. 3583 * HMAC_FAILED is 28. 3585 * ENCRYPTION_FAILED is 32. 3587 * INVALID_HIT is 40. 3589 * BLOCKED_BY_POLICY is 42. 3591 * SERVER_BUSY_PLEASE_RETRY is 44. 3593 New values are assigned through First Come First Served, with 3594 Specification Required. 3596 10. Acknowledgments 3598 The drive to create HIP came to being after attending the MALLOC 3599 meeting at the 43rd IETF meeting. Baiju Patel and Hilarie Orman 3600 really gave the original author, Bob Moskowitz, the assist to get HIP 3601 beyond 5 paragraphs of ideas. It has matured considerably since the 3602 early drafts thanks to extensive input from IETFers. Most 3603 importantly, its design goals are articulated and are different from 3604 other efforts in this direction. Particular mention goes to the 3605 members of the NameSpace Research Group of the IRTF. Noel Chiappa 3606 provided the framework for LSIs and Keith Moore the impetus to 3607 provide resolvability. Steve Deering provided encouragement to keep 3608 working, as a solid proposal can act as a proof of ideas for a 3609 research group. 3611 Many others contributed; extensive security tips were provided by 3612 Steve Bellovin. Rob Austein kept the DNS parts on track. Paul 3613 Kocher taught Bob Moskowitz how to make the cookie exchange expensive 3614 for the Initiator to respond, but easy for the Responder to validate. 3615 Bill Sommerfeld supplied the Birthday concept, which later evolved 3616 into the R1 generation counter, to simplify reboot management. Erik 3617 Nordmark supplied CLOSE-mechanism for closing connections. Rodney 3618 Thayer and Hugh Daniels provide extensive feedback. In the early 3619 times of this draft, John Gilmore kept Bob Moskowitz challenged to 3620 provide something of value. 3622 During the later stages of this document, when the editing baton was 3623 transfered to Pekka Nikander, the input from the early implementors 3624 were invaluable. Without having actual implementations, this 3625 document would not be on the level it is now. 3627 In the usual IETF fashion, a large number of people have contributed 3628 to the actual text or ideas. The list of these people include Jeff 3629 Ahrenholz, Francis Dupont, Derek Fawcus, George Gross, Andrew 3630 McGregor, Julien Laganier, Miika Komu, Mika Kousa, Jan Melen, Henrik 3631 Petander, Michael Richardson, Tim Shepard, Jorma Wall, and Jukka 3632 Ylitalo. Our apologies to anyone whose name is missing. 3634 Once the HIP Working Group was founded in early 2004, a number of 3635 changes were introduced through the working group process. Most 3636 notably, the original draft was split in two, one containing the base 3637 exchange and the other one defining how to use ESP. Some 3638 modifications to the protocol proposed by Aura et al. [29] were added 3639 at a later stage. 3641 11. References 3643 11.1 Normative References 3645 [1] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 3646 August 1980. 3648 [2] Postel, J., "Internet Control Message Protocol", STD 5, 3649 RFC 792, September 1981. 3651 [3] Mockapetris, P., "Domain names - implementation and 3652 specification", STD 13, RFC 1035, November 1987. 3654 [4] Conta, A. and S. Deering, "Internet Control Message Protocol 3655 (ICMPv6) for the Internet Protocol Version 6 (IPv6)", RFC 1885, 3656 December 1995. 3658 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 3659 Levels", BCP 14, RFC 2119, March 1997. 3661 [6] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP 3662 and AH", RFC 2404, November 1998. 3664 [7] Maughan, D., Schneider, M., and M. Schertler, "Internet 3665 Security Association and Key Management Protocol (ISAKMP)", 3666 RFC 2408, November 1998. 3668 [8] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 3669 RFC 2409, November 1998. 3671 [9] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, 3672 November 1998. 3674 [10] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 3675 Considerations Section in RFCs", BCP 26, RFC 2434, 3676 October 1998. 3678 [11] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 3679 Specification", RFC 2460, December 1998. 3681 [12] Eastlake, D., "Domain Name System Security Extensions", 3682 RFC 2535, March 1999. 3684 [13] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System 3685 (DNS)", RFC 2536, March 1999. 3687 [14] Kaliski, B., "PKCS #5: Password-Based Cryptography 3688 Specification Version 2.0", RFC 2898, September 2000. 3690 [15] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name 3691 System (DNS)", RFC 3110, May 2001. 3693 [16] Draves, R., "Default Address Selection for Internet Protocol 3694 version 6 (IPv6)", RFC 3484, February 2003. 3696 [17] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 3697 Addressing Architecture", RFC 3513, April 2003. 3699 [18] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 3700 Diffie-Hellman groups for Internet Key Exchange (IKE)", 3701 RFC 3526, May 2003. 3703 [19] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher 3704 Algorithm and Its Use with IPsec", RFC 3602, September 2003. 3706 [20] Kent, S., "IP Encapsulating Security Payload (ESP)", 3707 draft-ietf-ipsec-esp-v3-05 (work in progress), April 2003. 3709 [21] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 3710 draft-ietf-ipsec-ikev2-07 (work in progress), April 2003. 3712 [22] Aboba, B., "The Network Access Identifier", 3713 draft-ietf-radext-rfc2486bis-03 (work in progress), 3714 December 2004. 3716 [23] NIST, "FIPS PUB 180-1: Secure Hash Standard", April 1995. 3718 [24] Jokela, P., Moskowitz, R., and P. Nikander, "Using ESP 3719 transport format with HIP", draft-jokela-hip-esp-00 (work in 3720 progress), January 2005. 3722 11.2 Informative References 3724 [25] Moskowitz, R., "Host Identity Protocol Architecture", 3725 draft-moskowitz-hip-arch-03 (work in progress), May 2003. 3727 [26] Bellovin, S. and W. Aiello, "Just Fast Keying (JFK)", 3728 draft-ietf-ipsec-jfk-04 (work in progress), July 2002. 3730 [27] Nikander, P. and J. Laganier, "Host Identity Protocol (HIP) 3731 Domain Name System (DNS) Extensions", draft-ietf-hip-dns-00 3732 (work in progress), October 2004. 3734 [28] Nikander, P., "SPI assisted NAT traversal (SPINAT) with Host 3735 Identity Protocol (HIP)", draft-nikander-hip-nat-00 (to be 3736 issued) (work in progress), June 2003. 3738 [29] Aura, T., Nagarajan, A., and A. Gurtov, "Analysis of the HIP 3739 Base Exchange Protocol", in Proceedings of 10th Australasian 3740 Conference on Information Security and Privacy, July 2003. 3742 [30] Crosby, SA. and DS. Wallach, "Denial of Service via Algorithmic 3743 Complexity Attacks", in Proceedings of Usenix Security 3744 Symposium 2003, Washington, DC., August 2003. 3746 [31] Nikander, P., "A Bound End-to-End Tunnel (BEET) mode for ESP", 3747 draft-nikander-esp-beet-mode-00 (expired) (work in progress), 3748 Oct 2003. 3750 [32] Henderson, T., "Using HIP with Legacy Applications", 3751 draft-henderson-hip-applications-00.txt (work in progress), 3752 Feb 2005. 3754 [33] NIST, "FIPS PUB 197: Advanced Encryption Standard", Nov 2001. 3756 Authors' Addresses 3758 Robert Moskowitz 3759 ICSAlabs, a Division of TruSecure Corporation 3760 1000 Bent Creek Blvd, Suite 200 3761 Mechanicsburg, PA 3762 USA 3764 Email: rgm@icsalabs.com 3766 Pekka Nikander 3767 Ericsson Research NomadicLab 3768 JORVAS FIN-02420 3769 FINLAND 3771 Phone: +358 9 299 1 3772 Email: pekka.nikander@nomadiclab.com 3774 Petri Jokela 3775 Ericsson Research NomadicLab 3776 JORVAS FIN-02420 3777 FINLAND 3779 Phone: +358 9 299 1 3780 Email: petri.jokela@nomadiclab.com 3781 Thomas R. Henderson 3782 The Boeing Company 3783 P.O. Box 3707 3784 Seattle, WA 3785 USA 3787 Email: thomas.r.henderson@boeing.com 3789 Appendix A. Probabilities of HIT Collisions 3791 The birthday paradox sets a bound for the expectation of collisions. 3792 It is based on the square root of the number of values. A 64-bit 3793 hash, then, would put the chances of a collision at 50-50 with 2^32 3794 hosts (4 billion). A 1% chance of collision would occur in a 3795 population of 640M and a .001% collision chance in a 20M population. 3796 A 128 bit hash will have the same .001% collision chance in a 9x10^16 3797 population. 3799 Appendix B. Probabilities in the Cookie Calculation 3801 A question: Is it guaranteed that the Initiator is able to solve the 3802 puzzle in this way when the K value is large? 3804 Answer: No, it is not guaranteed. But it is not guaranteed even in 3805 the old mechanism, since the Initiator may start far away from J and 3806 arrive to J after far too many steps. If we wanted to make sure that 3807 the Initiator finds a value, we would need to give some hint of a 3808 suitable J, and I don't think we want to do that. 3810 In general, if we model the hash function with a random function, the 3811 probability that one iteration gives are result with K zero bits is 3812 2^-K. Thus, the probability that one iteration does _not_ give K 3813 zero bits is (1 - 2^-K). Consequently, the probability that 2^K 3814 iterations does not give K zero bits is (1 - 2^-K)^(2^K). 3816 Since my calculus starts to be rusty, I made a small experiment and 3817 found out that 3819 lim (1 - 2^-k)^(2^k) = 0.36788 3820 k->inf 3822 lim (1 - 2^-k)^(2^(k+1)) = 0.13534 3823 k->inf 3825 lim (1 - 2^-k)^(2^(k+2)) = 0.01832 3826 k->inf 3828 lim (1 - 2^-k)^(2^(k+3)) = 0.000335 3829 k->inf 3831 Thus, if hash functions were random functions, we would need about 3832 2^(K+3) iterations to make sure that the probability of a failure is 3833 less than 1% (actually less than 0.04%). Now, since my perhaps 3834 flawed understanding of hash functions is that they are "flatter" 3835 than random functions, 2^(K+3) is probably an overkill. OTOH, the 3836 currently suggested 2^K is clearly too little. 3838 Appendix C. Using Responder Cookies 3840 As mentioned in Section 4.1.1, the Responder may delay state creation 3841 and still reject most spoofed I2s by using a number of pre-calculated 3842 R1s and a local selection function. This appendix defines one 3843 possible implementation in detail. The purpose of this appendix is 3844 to give the implementors an idea on how to implement the mechanism. 3845 If the implementation is based on this appendix, it MAY contain some 3846 local modification that makes an attacker's task harder. 3848 The Responder creates a secret value S, that it regenerates 3849 periodically. The Responder needs to remember two latest values of 3850 S. Each time the S is regenerated, R1 generation counter value is 3851 incremented by one. 3853 The Responder generates a pre-signed R1 packet. The signature for 3854 pre-generated R1s must be recalculated when the Diffie-Hellman key is 3855 recomputed or when the R1_COUNTER value changes due to S value 3856 regeneration. 3858 When the Initiator sends the I1 packet for initializing a connection, 3859 the Responder gets the HIT and IP address from the packet, and 3860 generates an I-value for the cookie. The I value is set to the pre- 3861 signed R1 packet. 3863 I value calculation: 3864 I = Ltrunc( SHA-1 ( S | HIT-I | HIT-R | IP-I | IP-R ), 64) 3866 From an incoming I2 packet, the Responder gets the required 3867 information to validate the puzzle: HITs, IP addresses, and the 3868 information of the used S value from the R1_COUNTER. Using these 3869 values, the Responder can regenerate the I, and verify it against the 3870 I received in the I2 packet. If the I values match, it can verify 3871 the solution using I, J, and difficulty K. If the I values do not 3872 match, the I2 is dropped. 3874 cookie_check: 3875 V := Ltrunc( SHA-1( I2.I | I2.hit_i | I2.hit_r | I2.J ), K ) 3876 if V != 0, drop the packet 3878 If the puzzle solution is correct, the I and J values are stored for 3879 later use. They are used as input material when keying material is 3880 generated. 3882 The Responder SHOULD NOT keep state about failed puzzle solutions. 3884 Appendix D. Generating a HIT from a HI 3886 The following pseudo-codes illustrate the process to generate a HIT 3887 from a HI for both RSA and DSA. 3889 The symbol := denotes assignment; the symbol += denotes appending. 3890 The pseudo-function encode_in_network_byte_order takes two 3891 parameters, an integer (bignum) and a length in bytes, and returns 3892 the integer encoded into a byte string of the given length. 3894 switch ( HI.algorithm ) 3895 { 3897 case RSA: 3898 buffer := encode_in_network_byte_order ( HI.RSA.e_len, 3899 ( HI.RSA.e_len > 255 ) ? 3 : 1 ) 3900 buffer += encode_in_network_byte_order ( HI.RSA.e, HI.RSA.e_len ) 3901 buffer += encode_in_network_byte_order ( HI.RSA.n, HI.RSA.n_len ) 3902 break; 3904 case DSA: 3905 buffer := encode_in_network_byte_order ( HI.DSA.T , 1 ) 3906 buffer += encode_in_network_byte_order ( HI.DSA.Q , 20 ) 3907 buffer += encode_in_network_byte_order ( HI.DSA.P , 64 + 3908 8 * HI.DSA.T ) 3909 buffer += encode_in_network_byte_order ( HI.DSA.G , 64 + 3910 8 * HI.DSA.T ) 3911 buffer += encode_in_network_byte_order ( HI.DSA.Y , 64 + 3912 8 * HI.DSA.T ) 3913 break; 3915 } 3917 digest := SHA-1 ( buffer ) 3919 hit_128 := low_order_bits ( digest, 120 ) 3920 hit_haa := concatenate ( HAA, low_order_bits ( digest, 64 ) ) 3922 Appendix E. Example Checksums for HIP Packets 3924 The HIP checksum for HIP packets is specified in Section 6.1.2. 3925 Checksums for TCP and UDP packets running over HIP-enabled security 3926 associations are specified in Section 3.5. The examples below use IP 3927 addresses of 192.168.0.1 and 192.168.0.2 (and their respective IPv4- 3928 compatible IPv6 formats), and type 1 HITs with the first two bits 3929 "01" followed by 124 zeroes followed by a decimal 1 or 2, 3930 respectively. 3932 E.1 IPv6 HIP Example (I1) 3934 Source Address: ::c0a8:0001 3935 Destination Address: ::c0a8:0002 3936 Upper-Layer Packet Length: 40 0x28 3937 Next Header: 99 0x63 3938 Payload Protocol: 59 0x3b 3939 Header Length: 4 0x04 3940 Packet Type: 1 0x01 3941 Version: 1 0x1 3942 Reserved: 0 0x0 3943 Control: 0 0x0000 3944 Checksum: 49672 0xc208 3945 Sender's HIT: 4000::0001 3946 Receiver's HIT: 4000::0002 3948 E.2 IPv4 HIP Packet (I1) 3950 The IPv4 checksum value for the same example I1 packet is the same as 3951 the IPv6 checksum (since the checksums due to the IPv4 and IPv6 3952 pseudo-header components are the same). 3954 E.3 TCP Segment 3956 Regardless of whether IPv6 or IPv4 is used, the TCP and UDP sockets 3957 use the IPv6 pseudo-header format [8], with the HITs used in place of 3958 the IPv6 addresses. 3960 Sender's HIT: 4000::0001 3961 Receiver's HIT: 4000::0002 3962 Upper-Layer Packet Length: 20 0x14 3963 Next Header: 6 0x06 3964 Source port: 32769 0x8001 3965 Destination port: 22 0x0016 3966 Sequence number: 1 0x00000001 3967 Acknowledgment number: 0 0x00000000 3968 Header length: 20 0x14 3969 Flags: SYN 0x02 3970 Window size: 5840 0x16d0 3971 Checksum: 54519 0xd4f7 3972 Urgent pointer: 0 0x0000 3974 Appendix F. 384-bit Group 3976 This 384-bit group is defined only to be used with HIP. NOTE: The 3977 security level of this group is very low! The encryption may be 3978 broken in a very short time, even real-time. It should be used only 3979 when the host is not powerful enough (e.g. some PDAs) and when 3980 security requirements are low (e.g. during normal web surfing). 3982 This prime is: 2^384 - 2^320 - 1 + 2^64 * { [ 2^254 pi] + 5857 } 3984 Its hexadecimal value is: 3986 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 3987 29024E08 8A67CC74 020BBEA6 3B13B202 FFFFFFFF FFFFFFFF 3989 The generator is: 2. 3991 Intellectual Property Statement 3993 The IETF takes no position regarding the validity or scope of any 3994 Intellectual Property Rights or other rights that might be claimed to 3995 pertain to the implementation or use of the technology described in 3996 this document or the extent to which any license under such rights 3997 might or might not be available; nor does it represent that it has 3998 made any independent effort to identify any such rights. Information 3999 on the procedures with respect to rights in RFC documents can be 4000 found in BCP 78 and BCP 79. 4002 Copies of IPR disclosures made to the IETF Secretariat and any 4003 assurances of licenses to be made available, or the result of an 4004 attempt made to obtain a general license or permission for the use of 4005 such proprietary rights by implementers or users of this 4006 specification can be obtained from the IETF on-line IPR repository at 4007 http://www.ietf.org/ipr. 4009 The IETF invites any interested party to bring to its attention any 4010 copyrights, patents or patent applications, or other proprietary 4011 rights that may cover technology that may be required to implement 4012 this standard. Please address the information to the IETF at 4013 ietf-ipr@ietf.org. 4015 Disclaimer of Validity 4017 This document and the information contained herein are provided on an 4018 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 4019 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 4020 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 4021 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 4022 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 4023 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 4025 Copyright Statement 4027 Copyright (C) The Internet Society (2005). This document is subject 4028 to the rights, licenses and restrictions contained in BCP 78, and 4029 except as set forth therein, the authors retain all their rights. 4031 Acknowledgment 4033 Funding for the RFC Editor function is currently provided by the 4034 Internet Society.