idnits 2.17.1 draft-ietf-hip-base-05.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 4111. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 4088. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 4095. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 4101. ** 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 : ---------------------------------------------------------------------------- == 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 1004 has weird spacing: '...ciation has n...' == Line 1052 has weird spacing: '... failed to es...' == Line 1596 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 (March 2, 2006) is 6629 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: 'RFC2536' on line 1696 -- Looks like a reference, but probably isn't: 'RFC3110' on line 1697 ** Obsolete normative reference: RFC 1885 (ref. '4') (Obsoleted by RFC 2463) ** Obsolete normative reference: RFC 2409 (ref. '7') (Obsoleted by RFC 4306) ** Downref: Normative reference to an Informational RFC: RFC 2412 (ref. '8') ** Obsolete normative reference: RFC 2434 (ref. '9') (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) == Outdated reference: A later version (-07) exists of draft-laganier-ipv6-khi-00 ** Downref: Normative reference to an Experimental draft: draft-laganier-ipv6-khi (ref. '22') == Outdated reference: A later version (-06) exists of draft-ietf-hip-esp-01 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-esp (ref. '24') -- Possible downref: Non-RFC (?) normative reference: ref. '25' == Outdated reference: A later version (-12) exists of draft-ietf-shim6-proto-03 == Outdated reference: A later version (-03) exists of draft-henderson-hip-applications-01 Summary: 13 errors (**), 0 flaws (~~), 12 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Moskowitz 3 Internet-Draft ICSAlabs, a Division of TruSecure 4 Expires: September 3, 2006 Corporation 5 P. Nikander 6 P. Jokela (editor) 7 Ericsson Research NomadicLab 8 T. Henderson 9 The Boeing Company 10 March 2, 2006 12 Host Identity Protocol 13 draft-ietf-hip-base-05 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 September 3, 2006. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006). 44 Abstract 46 This memo specifies the details of the Host Identity Protocol (HIP). 47 HIP allows consenting hosts to securely establish and maintain shared 48 IP-layer state, allowing separation of the identifier and locator 49 roles of IP addresses, thereby enabling continuity of communications 50 across IP address changes. HIP is based on a Sigma-compliant Diffie- 51 Hellman key exchange, using public-key identifiers from a new Host 52 Identity name space for mutual peer authentication. The protocol is 53 designed to be resistant to Denial-of-Service (DoS) and Man-in-the- 54 middle (MitM) attacks, and when used together with another suitable 55 security protocol, such as Encapsulated Security Payload (ESP), it 56 provides integrity protection and optional encryption for upper layer 57 protocols, suchs as TCP and UDP. Discussion related to this document 58 is going on at the IETF HIP Working Group mailing list. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 63 1.1. A New Name Space and Identifiers . . . . . . . . . . . . 5 64 1.2. The HIP Base Exchange . . . . . . . . . . . . . . . . . . 5 65 1.3. Memo structure . . . . . . . . . . . . . . . . . . . . . 6 66 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 7 67 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 7 68 2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 7 69 2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7 70 3. Host Identifier (HI) and its Representations . . . . . . . . 9 71 3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 9 72 3.2. Generating a HIT from a HI . . . . . . . . . . . . . . . 10 73 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 12 74 4.1. Creating a HIP Association . . . . . . . . . . . . . . . 12 75 4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . 13 76 4.1.2. Puzzle exchange . . . . . . . . . . . . . . . . . . . 14 77 4.1.3. Authenticated Diffie-Hellman Protocol . . . . . . . . 15 78 4.1.4. HIP Replay Protection . . . . . . . . . . . . . . . . 16 79 4.1.5. Refusing a HIP Exchange . . . . . . . . . . . . . . . 17 80 4.2. Updating a HIP Association . . . . . . . . . . . . . . . 17 81 4.3. Error Processing . . . . . . . . . . . . . . . . . . . . 18 82 4.4. HIP State Machine . . . . . . . . . . . . . . . . . . . . 19 83 4.4.1. HIP States . . . . . . . . . . . . . . . . . . . . . 20 84 4.4.2. HIP State Processes . . . . . . . . . . . . . . . . . 20 85 4.4.3. Simplified HIP State Diagram . . . . . . . . . . . . 27 86 4.5. User Data Considerations . . . . . . . . . . . . . . . . 29 87 4.5.1. TCP and UDP Pseudo-header Computation for User Data . 29 88 4.5.2. Sending Data on HIP Packets . . . . . . . . . . . . . 29 89 4.5.3. Transport Formats . . . . . . . . . . . . . . . . . . 29 90 4.5.4. Reboot and SA Timeout Restart of HIP . . . . . . . . 29 91 4.6. Certificate Distribution . . . . . . . . . . . . . . . . 30 92 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 31 93 5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 31 94 5.1.1. Checksum . . . . . . . . . . . . . . . . . . . . . . 32 95 5.1.2. HIP Controls . . . . . . . . . . . . . . . . . . . . 32 96 5.1.3. HIP Fragmentation Support . . . . . . . . . . . . . . 33 97 5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 33 98 5.2.1. TLV Format . . . . . . . . . . . . . . . . . . . . . 35 99 5.2.2. Defining New Parameters . . . . . . . . . . . . . . . 36 100 5.2.3. R1_COUNTER . . . . . . . . . . . . . . . . . . . . . 37 101 5.2.4. PUZZLE . . . . . . . . . . . . . . . . . . . . . . . 38 102 5.2.5. SOLUTION . . . . . . . . . . . . . . . . . . . . . . 39 103 5.2.6. DIFFIE_HELLMAN . . . . . . . . . . . . . . . . . . . 40 104 5.2.7. HIP_TRANSFORM . . . . . . . . . . . . . . . . . . . . 41 105 5.2.8. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 42 106 5.2.9. HMAC . . . . . . . . . . . . . . . . . . . . . . . . 43 107 5.2.10. HMAC_2 . . . . . . . . . . . . . . . . . . . . . . . 43 108 5.2.11. HIP_SIGNATURE . . . . . . . . . . . . . . . . . . . . 44 109 5.2.12. HIP_SIGNATURE_2 . . . . . . . . . . . . . . . . . . . 45 110 5.2.13. SEQ . . . . . . . . . . . . . . . . . . . . . . . . . 45 111 5.2.14. ACK . . . . . . . . . . . . . . . . . . . . . . . . . 46 112 5.2.15. ENCRYPTED . . . . . . . . . . . . . . . . . . . . . . 47 113 5.2.16. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . 48 114 5.2.17. ECHO_REQUEST . . . . . . . . . . . . . . . . . . . . 51 115 5.2.18. ECHO_RESPONSE . . . . . . . . . . . . . . . . . . . . 52 116 5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 52 117 5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 53 118 5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 54 119 5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 55 120 5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 57 121 5.3.5. UPDATE - the HIP Update Packet . . . . . . . . . . . 57 122 5.3.6. NOTIFY - the HIP Notify Packet . . . . . . . . . . . 58 123 5.3.7. CLOSE - the HIP Association Closing Packet . . . . . 59 124 5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet . . 59 125 5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 59 126 5.4.1. Invalid Version . . . . . . . . . . . . . . . . . . . 60 127 5.4.2. Other Problems with the HIP Header and Packet 128 Structure . . . . . . . . . . . . . . . . . . . . . . 60 129 5.4.3. Invalid Puzzle Solution . . . . . . . . . . . . . . . 60 130 5.4.4. Non-existing HIP Association . . . . . . . . . . . . 60 131 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 62 132 6.1. Processing Outgoing Application Data . . . . . . . . . . 62 133 6.2. Processing Incoming Application Data . . . . . . . . . . 63 134 6.3. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 64 135 6.4. HMAC and SIGNATURE Calculation and Verification . . . . . 65 136 6.4.1. HMAC Calculation . . . . . . . . . . . . . . . . . . 65 137 6.4.2. Signature Calculation . . . . . . . . . . . . . . . . 66 138 6.5. HIP KEYMAT Generation . . . . . . . . . . . . . . . . . . 67 139 6.6. Initiation of a HIP Exchange . . . . . . . . . . . . . . 68 140 6.6.1. Sending Multiple I1s in Parallel . . . . . . . . . . 69 141 6.6.2. Processing Incoming ICMP Protocol Unreachable 142 Messages . . . . . . . . . . . . . . . . . . . . . . 70 143 6.7. Processing Incoming I1 Packets . . . . . . . . . . . . . 70 144 6.7.1. R1 Management . . . . . . . . . . . . . . . . . . . . 71 145 6.7.2. Handling Malformed Messages . . . . . . . . . . . . . 71 146 6.8. Processing Incoming R1 Packets . . . . . . . . . . . . . 71 147 6.8.1. Handling Malformed Messages . . . . . . . . . . . . . 73 148 6.9. Processing Incoming I2 Packets . . . . . . . . . . . . . 74 149 6.9.1. Handling Malformed Messages . . . . . . . . . . . . . 76 150 6.10. Processing Incoming R2 Packets . . . . . . . . . . . . . 76 151 6.11. Sending UPDATE Packets . . . . . . . . . . . . . . . . . 77 152 6.12. Receiving UPDATE Packets . . . . . . . . . . . . . . . . 78 153 6.12.1. Handling a SEQ parameter in a received UPDATE 154 message . . . . . . . . . . . . . . . . . . . . . . . 78 155 6.12.2. Handling an ACK Parameter in a Received UPDATE 156 Packet . . . . . . . . . . . . . . . . . . . . . . . 79 157 6.13. Processing NOTIFY Packets . . . . . . . . . . . . . . . . 80 158 6.14. Processing CLOSE Packets . . . . . . . . . . . . . . . . 80 159 6.15. Processing CLOSE_ACK Packets . . . . . . . . . . . . . . 80 160 6.16. Dropping HIP Associations . . . . . . . . . . . . . . . . 80 161 7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 81 162 8. Security Considerations . . . . . . . . . . . . . . . . . . . 82 163 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 85 164 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 90 165 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 91 166 11.1. Normative References . . . . . . . . . . . . . . . . . . 91 167 11.2. Informative References . . . . . . . . . . . . . . . . . 92 168 Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 94 169 Appendix B. Generating a HIT from a HI . . . . . . . . . . . . . 95 170 Appendix C. Example Checksums for HIP Packets . . . . . . . . . 96 171 C.1. IPv6 HIP Example (I1) . . . . . . . . . . . . . . . . . . 96 172 C.2. IPv4 HIP Packet (I1) . . . . . . . . . . . . . . . . . . 96 173 C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . . 96 174 Appendix D. 384-bit Group . . . . . . . . . . . . . . . . . . . 98 175 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 99 176 Intellectual Property and Copyright Statements . . . . . . . . . 100 178 1. Introduction 180 This memo specifies the details of the Host Identity Protocol (HIP). 181 A high-level description of the protocol and the underlying 182 architectural thinking is available in the separate HIP architecture 183 description [26]. Briefly, the HIP architecture proposes an 184 alternative to the dual use of IP addresses as "locators" (routing 185 labels) and "identifiers" (endpoint, or host, identifiers). In HIP, 186 public cryptographic keys, of a public/private key pair, are used as 187 Host Identifiers, to which higher ayer protocols are bound instead of 188 an IP address. By using public keys (and their representations) as 189 host identifiers, dynamic changes to IP address sets can be directly 190 authenticated between hosts and if desired, strong authentication 191 between hosts at the TCP/IP stack level can be obtained. 193 This memo specifies the base HIP protocol ("base exchange") used 194 between hosts to establish an IP-layer communications context, called 195 HIP association, prior to communications. It also defines a packet 196 format and procedures for updating an active HIP association. Other 197 elements of the HIP architecture are specified in other documents, 198 including how HIP can be combined with a variant of the Encapsulating 199 Security Payload (ESP) for integrity protection and optional 200 encryption, mobility and multi-homing extensions to HIP, extensions 201 to the Domain Name System (DNS) for storing Host Identities there, 202 proposals on added HIP-related infrastructure into the networks, and 203 techniques for NAT traversal. 205 1.1. A New Name Space and Identifiers 207 The Host Identity Protocol introduces a new name space, the Host 208 Identity name space. Some ramifications of this new namespace are 209 explained in the HIP architecture description [26]. 211 There are two main representations of the Host Identity, the full 212 Host Identifier (HI) and the Host Identity Tag (HIT The HI is a 213 public key and directly represents the Identity. Since there are 214 different public key algorithms that can be used with different key 215 lengths, the HI is not good for use as a packet identifier, or as an 216 index into the various operational tables needed to support HIP. 217 Consequently, a hash of the HI, the Host Identity Tag (HIT), becomes 218 the operational representation. It is 128 bits long and is used in 219 the HIP payloads and to index the corresponding state in the end 220 hosts. The HIT has an important security property in that it is 221 self-certifying (see Section 3). 223 1.2. The HIP Base Exchange 225 The HIP base exchange is a two-party cryptographic protocol used to 226 establish communications context between hosts. The base exchange is 227 a Sigma-compliant [30] four packet exchange. The first party is 228 called the Initiator and the second party the Responder. The four- 229 packet design helps to make HIP DoS resilient. The protocol 230 exchanges Diffie-Hellman keys in the 2nd and 3rd packets, and 231 authenticates the parties in the 3rd and 4th packets. Additionally, 232 the Responder starts a puzzle exchange in the 2nd packet, with the 233 Initiator completing it in the 3rd packet before the Responder stores 234 any state from the exchange. 236 The exchange can use the Diffie-Hellman output to encrypt the Host 237 Identity of the Initiator in packet 3 (although Aura et al. [29] 238 notes that such operation may interfere with packet-inspecting 239 middleboxes), or the Host Identity may instead be sent unencrypted. 240 The Responder's Host Identity is not protected. It should be noted, 241 however, that both the Initiator's and the Responder's HITs are 242 transported as such (in cleartext) in the packets, allowing an 243 eavesdropper with a priori knowledge about the parties to verify 244 their identities. 246 Data packets start to flow after the 4th packet. The 3rd and 4th HIP 247 packets may carry a data payload in the future. However, the details 248 of this are to be defined later as more implementation experience is 249 gained. 251 An existing HIP association can be updated using the update mechanism 252 defined in this document, and when the association is no longer 253 needed, it can be closed using the defined closing mechanism. 255 Finally, HIP is designed as an end-to-end authentication and key 256 establishment protocol, to be used with Encapsulated Security Payload 257 (ESP) [24] and other end-to-end security protocols. The base 258 protocol lacks the details for security association management and 259 much of the fine-grained policy control found in Internet Key 260 Exchange IKE RFC2409 [7] that allows IKE to support complex gateway 261 policies. Thus, HIP is not a replacement for IKE. 263 1.3. Memo structure 265 The rest of this memo is structured as follows. Section 2 defines 266 the central keywords, notation, and terms used throughout the rest of 267 the document. Section 3 defines the structure of the Host Identity 268 and its various representations. Section 4 gives an overview of the 269 HIP base exchange protocol. Section 5 and Section 6 define the 270 detail packet formats and rules for packet processing. Finally, 271 Section 7, Section 8, and Section 9 discuss policy, security, and 272 IANA considerations, respectively. 274 2. Terms and Definitions 276 2.1. Requirements Terminology 278 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 279 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 280 document are to be interpreted as described in RFC2119 [5]. 282 2.2. Notation 284 [x] indicates that x is optional. 286 {x} indicates that x is encrypted. 288 X(y) indicates that y is a parameter of X. 290 i indicates that x exists i times. 292 --> signifies "Initiator to Responder" communication (requests). 294 <-- signifies "Responder to Initiator" communication (replies). 296 | signifies concatenation of information-- e.g. X | Y is the 297 concatenation of X with Y. 299 Ltrunc (SHA-1(), K) denotes the lowest order K bits of the SHA-1 300 result. 302 2.3. Definitions 304 Unused Association Lifetime (UAL): Implementation-specific time for 305 which, if no packet is sent or received for this time interval, a 306 host MAY begin to tear down an active association. 308 Maximum Segment Lifetime (MSL): Maximum time that a TCP segment is 309 expected to spend in the network. 311 Exchange Complete (EC): Time that the host spends at the R2-SENT 312 before it moves to ESTABLISHED state. The time is n * I2 313 retransmission timeout, where n ~ I2_RETRIES_MAX. 315 HIT Hash Algorithm: hash algorithm used to generate a Host Identity 316 Tag (HIT) from the Host Identity public key. Currently SHA-1 [25] 317 is used. 319 Puzzle Hash Algorithm (PHASH): hash algorithm used to calculate the 320 puzzle hash. The algorithm is the same as is used to generate the 321 Responder's HIT. 323 Opportunistic mode: HIP base exchange where the Responder's HIT is 324 not a priori known to the Initiator. 326 3. Host Identifier (HI) and its Representations 328 In this section, the properties of the Host Identifier and Host 329 Identifier Tag are discussed, and the exact format for them is 330 defined. In HIP, public key of an asymmetric key pair is used as the 331 Host Identifier (HI). Correspondingly, the host itself is defined as 332 the entity that holds the private key from the key pair. See the HIP 333 architecture specification [26] for more details about the difference 334 between an identity and the corresponding identifier. 336 HIP implementations MUST support the Rivest Shamir Adelman (RSA) [15] 337 public key algorithm, and SHOULD support the Digital Signature 338 Algorithm (DSA) [13] algorithm; other algorithms MAY be supported. 340 A hashed encoding of the HI, the Host Identity Tag (HIT), is used in 341 protocols to represent the Host Identity. The HIT is 128 bits long 342 and has the following three key properties: i) it is the same length 343 as an IPv6 address and can be used in address-sized fields in APIs 344 and protocols, ii) it is self-certifying (i.e., given a HIT, it is 345 computationally hard to find a Host Identity key that matches the 346 HIT), and iii) the probability of HIT collision between two hosts is 347 very low. 349 Carrying HIs and HITs in the header of user data packets would 350 increase the overhead of packets. Thus, it is not expected that they 351 are carried in every packet, but other methods are used to map the 352 data packets to the corresponding HIs. In some cases, this makes it 353 possible to use HIP without any additional headers in the user data 354 packets. For example, if ESP is used to protect data traffic, the 355 Security Parameter Index (SPI) carried in the ESP header, can be used 356 to map the encrypted data packet to the correct HIP association. 358 3.1. Host Identity Tag (HIT) 360 The Host Identity Tag is a 128 bits long value -- a hashed encoding 361 of the Host Identifier. There are two advantages of using a hashed 362 encoding over the actual Host Identity public key in protocols. 363 Firstly, its fixed length makes for easier protocol coding and also 364 better manages the packet size cost of this technology. Secondly, it 365 presents a consistent format to the protocol whatever underlying 366 identity technology is used. 368 "A Non-Routable IPv6 Prefix for Keyed Hash Identifiers" [22] has been 369 specified to store 128-bit hash based identifier called Keyed Hash 370 Identifier (KHI) under an 8-bit prefix, proposed to be allocated from 371 the IPv6 address block 1000::/4. The Host Identity Tag is a KHI 372 valid for the Context ID [22] value for HIP, 0xF0EF F02F BFF4 3D0F 373 E793 0C3C 6E61 74EA (The tag value has been generated randomly by the 374 editor of this specification.) The following figure shows, for 375 informal purposes only, the format of a HIT specified by [22], and 376 used in this document: 378 1 379 0 2 380 0 1 2 3 4 5 6 7 8 ... 7 381 +-+-+-+-+-+-+-+-+-+-//-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | Prefix | Hash | 383 +-+-+-+-+-+-+-+-+-+-//-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 Prefix (8 bits) - Fixed prefix, TBD (0x11, TO BE DISCUSSED), as 386 defined per [22]. 388 Encoding (120 bits) - Encoding of the public key and KHI context 389 identifier as defined per [22]. 391 Additional values for the prefix (including different hash 392 algorithms, or other information) may be defined in the future. A 393 host may receive a HIT for which it does not understand the prefix. 394 In such a case, it will not be able to check the mapping between HI 395 and HIT. 397 3.2. Generating a HIT from a HI 399 The HIT MUST be generated according to the KHI generation method 400 described in [22] using a context ID value of 0xF0EF F02F BFF4 3D0F 401 E793 0C3C 6E61 74EA, and an input encoding the Host Identity field 402 (see Section 5.2.8) present in a HIP payload packet. 404 For Identities that are either RSA or DSA public keys, this input 405 consists of the public key encoding as specified in the corresponding 406 DNSSEC document, taking the algorithm specific portion of the RDATA 407 part of the KEY RR. There is currently only two defined public key 408 algorithms: RSA and DSA. Hence, either of the following applies: 410 The RSA public key is encoded as defined in RFC3110 [15] Section 411 2, taking the exponent length (e_len), exponent (e) and modulus 412 (n) fields concatenated. The length (n_len) of the modulus (n) 413 can be determined from the total HI Length and the preceding HI 414 fields including the exponent (e). Thus, the data to be hashed 415 has the same length as the HI. The fields MUST be encoded in 416 network byte order, as defined in RFC3110 [15]. 418 The DSA public key is encoded as defined in RFC2536 [13] Section 419 2, taking the fields T, Q, P, G, and Y, concatenated. Thus, the 420 data to be hashed is 1 + 20 + 3 * 64 + 3 * 8 * T octets long, 421 where T is the size parameter as defined in RFC2536 [13]. The 422 size parameter T, affecting the field lengths, MUST be selected as 423 the minimum value that is long enough to accommodate P, G, and Y. 424 The fields MUST be encoded in network byte order, as defined in 425 RFC2536 [13]. 427 In Appendix B the public key encoding generation process is 428 illustrated using pseudo-code. 430 4. Protocol Overview 432 The following material is an overview of the HIP protocol operation, 433 and does not contain all details of the packet formats or the packet 434 processing steps. Section 5 and Section 6 describe in more detail 435 the packet formats and packet processing steps, respectively, and are 436 normative in case of any conflicts with this section. 438 The protocol number for Host Identity Protocol will be assigned by 439 IANA. For testing purposes, the protocol number 253 is currently 440 used. This number has been reserved by IANA for experimental use 441 (see [19]). 443 The HIP payload (Section 5.1) header could be carried in every IP 444 datagram. However, since HIP headers are relatively large (40 445 bytes), it is desirable to 'compress' the HIP header so that the HIP 446 header only occurs in control packets used to establish or change HIP 447 association state. The actual method for header 'compression' and 448 for matching data packets with existing HIP associations (if any) is 449 defined in separate documents, describing transport formats and 450 methods. All HIP implementations MUST implement, at minimum, the ESP 451 transport format for HIP [24]. 453 4.1. Creating a HIP Association 455 By definition, the system initiating a HIP exchange is the Initiator, 456 and the peer is the Responder. This distinction is forgotten once 457 the base exchange completes, and either party can become the 458 Initiator in future communications. 460 The HIP base exchange serves to manage the establishment of state 461 between an Initiator and a Responder. The first packet, I1, 462 initiates the exchange, and the last three packets, R1, I2, and R2, 463 constitute a standard authenticated Diffie-Hellman key exchange for 464 session key generation. During the Diffie-Hellman key exchange, a 465 piece of keying material is generated. The HIP association keys are 466 drawn from this keying material. If other cryptographic keys are 467 needed, e.g., to be used with ESP, they are expected to be drawn from 468 the same keying material. 470 The Initiator first sends a trigger packet, I1, to the Responder. 471 The packet contains only the HIT of the Initiator and possibly the 472 HIT of the Responder, if it is known. Note that in some cases it may 473 be possible to replace this trigger packet by some other form of a 474 trigger, in which case the protocol starts with the Responder sending 475 the R1 packet. 477 The second packet, R1, starts the actual exchange. It contains a 478 puzzle-- a cryptographic challenge that the Initiator must solve 479 before continuing the exchange. The level of difficulty of the 480 puzzle can be adjusted based on level of trust with the Initiator, 481 current load, or other factors. In addition, the R1 contains the 482 initial Diffie-Hellman parameters and a signature, covering part of 483 the message. Some fields are left outside the signature to support 484 pre-created R1s. 486 In the I2 packet, the Initiator must display the solution to the 487 received puzzle. Without a correct solution, the I2 message is 488 discarded. The I2 also contains a Diffie-Hellman parameter that 489 carries needed information for the Responder. The packet is signed 490 by the sender. 492 The R2 packet finalizes the base exchange. The packet is signed. 494 The base exchange is illustrated below. The term "key" refers to the 495 host identity public key, and "sig" represents a signature using such 496 a key. The packets contain other parameters not shown in this 497 figure. 499 Initiator Responder 501 I1: trigger exchange 502 --------------------------> 503 select pre-computed R1 504 R1: puzzle, D-H, key, sig 505 <------------------------- 506 check sig remain stateless 507 solve puzzle 508 I2: solution, D-H, {key}, sig 509 --------------------------> 510 compute D-H check puzzle 511 check sig 512 R2: sig 513 <-------------------------- 514 check sig compute D-H 516 4.1.1. HIP Puzzle Mechanism 518 The purpose of the HIP puzzle mechanism is to protect the Responder 519 from a number of denial-of-service threats. It allows the Responder 520 to delay state creation until receiving I2. Furthermore, the puzzle 521 allows the Responder to use a fairly cheap calculation to check that 522 the Initiator is "sincere" in the sense that it has churned CPU 523 cycles in solving the puzzle. 525 The Puzzle mechanism has been explicitly designed to give space for 526 various implementation options. It allows a Responder implementation 527 to completely delay session specific state creation until a valid I2 528 is received. In such a case a correctly formatted I2 can be rejected 529 only once the Responder has checked its validity by computing one 530 hash function. On the other hand, the design also allows a Responder 531 implementation to keep state about received I1s, and match the 532 received I2s against the state, thereby allowing the implementation 533 to avoid the computational cost of the hash function. The drawback 534 of this latter approach is the requirement of creating state. 535 Finally, it also allows an implementation to use other combinations 536 of the space-saving and computation-saving mechanisms. 538 One possible way for a Responder to remain stateless but drop most 539 spoofed I2s is to base the selection of the puzzle on some function 540 over the Initiator's Host Identity. The idea is that the Responder 541 has a (perhaps varying) number of pre-calculated R1 packets, and it 542 selects one of these based on the information carried in I1. When 543 the Responder then later receives I2, it checks that the puzzle in 544 the I2 matches with the puzzle sent in the R1, thereby making it 545 impractical for the attacker to first exchange one I1/R1, and then 546 generate a large number of spoofed I2s that seemingly come from 547 different IP addresses or use different HITs. The method does not 548 protect from an attacker that uses fixed IP addresses and HITs, 549 though. Against such an attacker a viable approach may be to create 550 a piece of local state, and remember that the puzzle check has 551 previously failed. See Appendix A for one possible implementation. 552 Implementations SHOULD include sufficient randomness to the algorithm 553 so that algorithm complexity attacks become impossible [31]. 555 The Responder can set the puzzle difficulty for Initiator, based on 556 its level of trust of the Initiator. The Responder SHOULD use 557 heuristics to determine when it is under a denial-of-service attack, 558 and set the puzzle difficulty value K appropriately; see below. 560 4.1.2. Puzzle exchange 562 The Responder starts the puzzle exchange when it receives an I1. The 563 Responder supplies a random number I, and requires the Initiator to 564 find a number J. To select a proper J, the Initiator must create the 565 concatenation of I, the HITs of the parties, and J, and take a SHA-1 566 hash over this concatenation. The lowest order K bits of the result 567 MUST be zeros. The value K sets the difficulty of the puzzle. 569 To generate a proper number J, the Initiator will have to generate a 570 number of Js until one produces the hash target of zero. The 571 Initiator SHOULD give up after exceeding the puzzle lifetime in the 572 PUZZLE parameter (Section 5.2.4). The Responder needs to re-create 573 the concatenation of I, the HITs, and the provided J, and compute the 574 hash once to prove that the Initiator did its assigned task. 576 To prevent pre-computation attacks, the Responder MUST select the 577 number I in such a way that the Initiator cannot guess it. 578 Furthermore, the construction MUST allow the Responder to verify that 579 the value was indeed selected by it and not by the Initiator. See 580 Appendix A for an example on how to implement this. 582 Using the Opaque data field in an ECHO_REQUEST parameter 583 (Section 5.2.17), the Responder can include some data in R1 that the 584 Initiator must copy unmodified in the corresponding I2 packet. The 585 Responder can generate the Opaque data in various ways; e.g. using 586 the sent I, some secret, and possibly other related data. Using this 587 same secret, received I in I2 packet and possible other data, the 588 Receiver can verify that it has itself sent the I to the Initiator. 589 The Responder MUST change such a secret periodically. 591 It is RECOMMENDED that the Responder generates a new puzzle and a new 592 R1 once every few minutes. Furthermore, it is RECOMMENDED that the 593 Responder remembers an old puzzle at least 2*lifetime seconds after 594 it has been deprecated. These time values allow a slower Initiator 595 to solve the puzzle while limiting the usability that an old, solved 596 puzzle has to an attacker. 598 NOTE: The protocol developers explicitly considered whether R1 should 599 include a timestamp in order to protect the Initiator from replay 600 attacks. The decision was to NOT include a timestamp. 602 NOTE: The protocol developers explicitly considered whether a memory 603 bound function should be used for the puzzle instead of a CPU bound 604 function. The decision was not to use memory bound functions. At 605 the time of the decision the idea of memory bound functions was 606 relatively new and their IPR status were unknown. Once there is more 607 experience about memory bound functions and once their IPR status is 608 better known, it may be reasonable to reconsider this decision. 610 4.1.3. Authenticated Diffie-Hellman Protocol 612 The packets R1, I2, and R2 implement a standard authenticated Diffie- 613 Hellman exchange. The Responder sends its public Diffie-Hellman key 614 and its public authentication key, i.e., its host identity, in R1. 615 The signature in R1 allows the Initiator to verify that the R1 has 616 been once generated by the Responder. However, since it is 617 precomputed and therefore does not cover all of the packet, it does 618 not protect from replay attacks. 620 When the Initiator receives an R1, it computes the Diffie-Hellman 621 session key. It creates a HIP association using keying material from 622 the session key (see Section 6.5), and may use the association to 623 encrypt its public authentication key, i.e., host identity. The 624 resulting I2 contains the Initiator's Diffie-Hellman key and its 625 (optionally encrypted) public authentication key. The signature in 626 I2 covers all of the packet. 628 The Responder extracts the Initiator Diffie-Hellman public key from 629 the I2, computes the Diffie-Hellman session key, creates a 630 corresponding HIP association, and decrypts the Initiator's public 631 authentication key. It can then verify the signature using the 632 authentication key. 634 The final message, R2, is needed to protect the Initiator from replay 635 attacks. 637 4.1.4. HIP Replay Protection 639 The HIP protocol includes the following mechanisms to protect against 640 malicious replays. Responders are protected against replays of I1 641 packets by virtue of the stateless response to I1s with presigned R1 642 messages. Initiators are protected against R1 replays by a 643 monotonically increasing "R1 generation counter" included in the R1. 644 Responders are protected against replays or false I2s by the puzzle 645 mechanism (Section 4.1.1 above), and optional use of opaque data. 646 Hosts are protected against replays to R2s and UPDATEs by use of a 647 less expensive HMAC verification preceding HIP signature 648 verification. 650 The R1 generation counter is a monotonically increasing 64-bit 651 counter that may be initialized to any value. The scope of the 652 counter MAY be system-wide but SHOULD be per host identity, if there 653 is more than one local host identity. The value of this counter 654 SHOULD be kept across system reboots and invocations of the HIP base 655 exchange. This counter indicates the current generation of puzzles. 656 Implementations MUST accept puzzles from the current generation and 657 MAY accept puzzles from earlier generations. A system's local 658 counter MUST be incremented at least as often as every time old R1s 659 cease to be valid, and SHOULD never be decremented, lest the host 660 expose its peers to the replay of previously generated, higher 661 numbered R1s. Also, the R1 generation counter MUST NOT roll over; if 662 the counter is about to become exhausted, the corresponding HI must 663 be abandoned and replaced with a new one. 665 A host may receive more than one R1, either due to sending multiple 666 I1s (Section 6.6.1) or due to a replay of an old R1. When sending 667 multiple I1s, an initiator SHOULD wait for a small amount of time 668 after the first R1 reception to allow possibly multiple R1s to 669 arrive, and it SHOULD respond to an R1 among the set with the largest 670 R1 generation counter. If an Initiator is processing an R1 or has 671 already sent an I2 (still waiting for R2) and it receives another R1 672 with a larger R1 generation counter, it MAY elect to restart R1 673 processing with the fresher R1, as if it were the first R1 to arrive. 675 Upon conclusion of an active HIP association with another host, the 676 R1 generation counter associated with the peer host SHOULD be 677 flushed. A local policy MAY override the default flushing of R1 678 counters on a per-HIT basis. The reason for recommending the 679 flushing of this counter is that there may be hosts where the R1 680 generation counter (occasionally) decreases; e.g., due to hardware 681 failure. 683 4.1.5. Refusing a HIP Exchange 685 A HIP aware host may choose not to accept a HIP exchange. If the 686 host's policy is to only be an Initiator, it should begin its own HIP 687 exchange. A host MAY choose to have such a policy since only the 688 Initiator HI is protected in the exchange. There is a risk of a race 689 condition if each host's policy is to only be an Initiator, at which 690 point the HIP exchange will fail. 692 If the host's policy does not permit it to enter into a HIP exchange 693 with the Initiator, it should send an ICMP 'Destination Unreachable, 694 Administratively Prohibited' message. A more complex HIP packet is 695 not used here as it actually opens up more potential DoS attacks than 696 a simple ICMP message. 698 4.2. Updating a HIP Association 700 A HIP association between two hosts may need to be updated over time. 701 Examples include the need to rekey expiring user data security 702 associations, add new security associations, or change IP addresses 703 associated with hosts. The UPDATE packet is used for those and other 704 similar purposes. This document only specifies the UPDATE packet 705 format and basic processing rules, with mandatory parameters. The 706 actual usage is defined in separate specifications. 708 HIP provides a general purpose UPDATE packet, which can carry 709 multiple HIP parameters, for updating the HIP state between two 710 peers. The UPDATE mechanism has the following properties: 712 UPDATE messages carry a monotonically increasing sequence number 713 and are explicitly acknowledged by the peer. Lost UPDATEs or 714 acknowledgments may be recovered via retransmission. Multiple 715 UPDATE messages may be outstanding under certain circumstances. 717 UPDATE is protected by both HMAC and HIP_SIGNATURE parameters, 718 since processing UPDATE signatures alone is a potential DoS attack 719 against intermediate systems. 721 UPDATE packets are explicitly acknowledged by the use of an 722 acknowledgment parameter that echoes an individual sequence number 723 received from the peer. A single UPDATE packet may contain both a 724 sequence number and one or more acknowledgment numbers (i.e., 725 piggybacked acknowledgment(s) for the peer's UPDATE). 727 The UPDATE packet is defined in Section 5.3.5. 729 4.3. Error Processing 731 HIP error processing behavior depends on whether there exists an 732 active HIP association or not. In general, if an HIP association 733 exists between the sender and receiver of a packet causing an error 734 condition, the receiver SHOULD respond with a NOTIFY packet. On the 735 other hand, if there are no existing HIP associations between the 736 sender and receiver, or the receiver cannot reasonably determine the 737 identity of the sender, the receiver MAY respond with a suitable ICMP 738 message; see Section 5.4 for more details. 740 The HIP protocol and state machine is designed to recover from one of 741 the parties crashing and losing its state. The following scenarios 742 describe the main use cases covered by the design. 744 No prior state between the two systems. 746 The system with data to send is the Initiator. The process 747 follows the standard four packet base exchange, establishing 748 the HIP association. 750 The system with data to send has no state with the receiver, but 751 the receiver has a residual HIP association. 753 The system with data to send is the Initiator. The Initiator 754 acts as in no prior state, sending I1 and getting R1. When the 755 Responder receives a valid I2, the old association is 756 'discovered' and deleted, and the new association is 757 established. 759 The system with data to send has an HIP association, but the 760 receiver does not. 762 The system sends data on the outbound user data security 763 association. The receiver 'detects' the situation when it 764 receives a user data packet that it cannot match to any HIP 765 association. The receiving host MUST discard this packet. 766 Optionally, the receiving host MAY send an ICMP packet with the 767 Parameter Problem type to inform about non-existing HIP 768 association (see Section 5.4), and it MAY initiate a new HIP 769 negotiation. However, responding with these optional 770 mechanisms is implementation or policy dependent. 772 4.4. HIP State Machine 774 The HIP protocol itself has little state. In the HIP base exchange, 775 there is an Initiator and a Responder. Once the SAs are established, 776 this distinction is lost. If the HIP state needs to be re- 777 established, the controlling parameters are which peer still has 778 state and which has a datagram to send to its peer. The following 779 state machine attempts to capture these processes. 781 The state machine is presented in a single system view, representing 782 either an Initiator or a Responder. There is not a complete overlap 783 of processing logic here and in the packet definitions. Both are 784 needed to completely implement HIP. 786 Implementors must understand that the state machine, as described 787 here, is informational. Specific implementations are free to 788 implement the actual functions differently. Section 6 describes the 789 packet processing rules in more detail. This state machine focuses 790 on the HIP I1, R1, I2, and R2 packets only. Other states may be 791 introduced by mechanisms in other specifications (such as mobility 792 and multihoming). 794 4.4.1. HIP States 796 +---------------------+---------------------------------------------+ 797 | State | Explanation | 798 +---------------------+---------------------------------------------+ 799 | UNASSOCIATED | State machine start | 800 | | | 801 | I1-SENT | Initiating base exchange | 802 | | | 803 | I2-SENT | Waiting to complete base exchange | 804 | | | 805 | R2-SENT | Waiting to complete base exchange | 806 | | | 807 | ESTABLISHED | HIP association established | 808 | | | 809 | CLOSING | HIP association closing, no data can be | 810 | | sent | 811 | | | 812 | CLOSED | HIP association closed, no data can be sent | 813 | | | 814 | E-FAILED | HIP exchange failed | 815 +---------------------+---------------------------------------------+ 817 4.4.2. HIP State Processes 819 System behaviour in state UNASSOCIATED, Table 2. 821 +---------------------+---------------------------------------------+ 822 | Trigger | Action | 823 +---------------------+---------------------------------------------+ 824 | User data to send, | Send I1 and go to I1-SENT | 825 | requiring a new HIP | | 826 | association | | 827 | | | 828 | Receive I1 | Send R1 and stay at UNASSOCIATED | 829 | | | 830 | Receive I2, process | If successful, send R2 and go to R2-SENT | 831 | | | 832 | | If fail, stay at UNASSOCIATED | 833 | | | 834 | Receive user data | Optionally send ICMP as defined in | 835 | for unknown HIP | Section 5.4 and stay at UNASSOCIATED | 836 | association | | 837 | | | 838 | Receive CLOSE | Optionally send ICMP Parameter Problem and | 839 | | stay at UNASSOCIATED | 840 | | | 841 | Receive ANYOTHER | Drop and stay at UNASSOCIATED | 842 +---------------------+---------------------------------------------+ 844 Table 2: UNASSOCIATED - Start state 846 System behaviour in state I1-SENT, Table 3. 848 +---------------------+---------------------------------------------+ 849 | Trigger | Action | 850 +---------------------+---------------------------------------------+ 851 | Receive I1 | If the local HIT is smaller than the peer | 852 | | HIT, drop I1 and stay at I1-SENT | 853 | | | 854 | | If the local HIT is greater than the peer | 855 | | HIT, send R1 and stay at I1_SENT | 856 | | | 857 | Receive I2, process | If successful, send R2 and go to R2-SENT | 858 | | | 859 | | If fail, stay at I1-SENT | 860 | | | 861 | Receive R1, process | If successful, send I2 and go to I2-SENT | 862 | | | 863 | | If fail, go to E-FAILED | 864 | | | 865 | Receive ANYOTHER | Drop and stay at I1-SENT | 866 | | | 867 | Timeout, increment | If counter is less than I1_RETRIES_MAX, | 868 | timeout counter | send I1 and stay at I1-SENT | 869 | | | 870 | | If counter is greater than I1_RETRIES_MAX, | 871 | | go to E-FAILED | 872 +---------------------+---------------------------------------------+ 874 Table 3: I1-SENT - Initiating HIP 875 System behaviour in state I2-SENT, Table 4. 877 +---------------------+---------------------------------------------+ 878 | Trigger | Action | 879 +---------------------+---------------------------------------------+ 880 | Receive I1 | Send R1 and stay at I2-SENT | 881 | | | 882 | Receive R1, process | If successful, send I2 and cycle at I2-SENT | 883 | | | 884 | | If fail, stay at I2-SENT | 885 | | | 886 | Receive I2, process | If successful and local HIT is smaller than | 887 | | the peer HIT, drop I2 and stay at I2-SENT | 888 | | | 889 | | If succesful and local HIT is greater than | 890 | | the peer HIT, send R2 and go to R2-SENT | 891 | | | 892 | | If fail, stay at I2-SENT | 893 | | | 894 | Receive R2, process | If successful, go to ESTABLISHED | 895 | | | 896 | | If fail, go to E-FAILED | 897 | | | 898 | Receive ANYOTHER | Drop and stay at I2-SENT | 899 | | | 900 | Timeout, increment | If counter is less than I2_RETRIES_MAX, | 901 | timeout counter | send I2 and stay at I2-SENT | 902 | | | 903 | | If counter is greater than I2_RETRIES_MAX, | 904 | | go to E-FAILED | 905 +---------------------+---------------------------------------------+ 907 Table 4: I2-SENT - Waiting to finish HIP 908 System behaviour in state R2-SENT, Table 5. 910 +---------------------+---------------------------------------------+ 911 | Trigger | Action | 912 +---------------------+---------------------------------------------+ 913 | Receive I1 | Send R1 and stay at R2-SENT | 914 | | | 915 | Receive I2, process | If successful, send R2 and cycle at R2-SENT | 916 | | | 917 | | If fail, stay at R2-SENT | 918 | | | 919 | Receive R1 | Drop and stay at R2-SENT | 920 | | | 921 | Receive R2 | Drop and stay at R2-SENT | 922 | | | 923 | Receive data or | Move to ESTABLISHED | 924 | UPDATE | | 925 | | | 926 | Exchange Complete | Move to ESTABLISHED | 927 | Timeout | | 928 +---------------------+---------------------------------------------+ 930 Table 5: R2-SENT - Waiting to finish HIP 931 System behaviour in state ESTABLISHED, Table 6. 933 +---------------------+---------------------------------------------+ 934 | Trigger | Action | 935 +---------------------+---------------------------------------------+ 936 | Receive I1 | Send R1 and stay at ESTABLISHED | 937 | | | 938 | Receive I2, process | If successful, send R2, drop old HIP | 939 | with puzzle and | association, establish a new HIP | 940 | possible Opaque | association, go to R2-SENT | 941 | data verification | | 942 | | | 943 | | If fail, stay at ESTABLISHED | 944 | | | 945 | Receive R1 | Drop and stay at ESTABLISHED | 946 | | | 947 | Receive R2 | Drop and stay at ESTABLISHED | 948 | | | 949 | Receive user data | Process and stay at ESTABLISHED | 950 | for HIP association | | 951 | | | 952 | No packet | Send CLOSE and go to CLOSING | 953 | sent/received | | 954 | during UAL minutes | | 955 | | | 956 | Receive CLOSE, | If successful, send CLOSE_ACK and go to | 957 | process | CLOSED | 958 | | | 959 | | If fail, stay at ESTABLISHED | 960 +---------------------+---------------------------------------------+ 962 Table 6: ESTABLISHED - HIP association established 963 System behaviour in state CLOSING, Table 7. 965 +---------------------+---------------------------------------------+ 966 | Trigger | Action | 967 +---------------------+---------------------------------------------+ 968 | User data to send, | Send I1 and stay at CLOSING | 969 | requires the | | 970 | creation of another | | 971 | incarnation of the | | 972 | HIP association | | 973 | | | 974 | Receive I1 | Send R1 and stay at CLOSING | 975 | | | 976 | Receive I2, process | If successful, send R2 and go to R2-SENT | 977 | | | 978 | | If fail, stay at CLOSING | 979 | | | 980 | Receive R1, process | If successful, send I2 and go to I2-SENT | 981 | | | 982 | | If fail, stay at CLOSING | 983 | | | 984 | Receive CLOSE, | If successful, send CLOSE_ACK, discard | 985 | process | state and go to CLOSED | 986 | | | 987 | | If fail, stay at CLOSING | 988 | | | 989 | Receive CLOSE_ACK, | If successful, discard state and go to | 990 | process | UNASSOCIATED | 991 | | | 992 | | If fail, stay at CLOSING | 993 | | | 994 | Receive ANYOTHER | Drop and stay at CLOSING | 995 | | | 996 | Timeout, increment | If timeout sum is less than UAL+MSL | 997 | timeout sum, reset | minutes, retransmit CLOSE and stay at | 998 | timer | CLOSING | 999 | | | 1000 | | If timeout sum is greater than UAL+MSL | 1001 | | minutes, go to UNASSOCIATED | 1002 +---------------------+---------------------------------------------+ 1004 Table 7: CLOSING - HIP association has not been used for UAL minutes 1005 System behaviour in state CLOSED, Table 8. 1007 +---------------------+---------------------------------------------+ 1008 | Trigger | Action | 1009 +---------------------+---------------------------------------------+ 1010 | Datagram to send, | Send I1, and stay at CLOSED | 1011 | requires the | | 1012 | creation of another | | 1013 | incarnation of the | | 1014 | HIP association | | 1015 | | | 1016 | Receive I1 | Send R1 and stay at CLOSED | 1017 | | | 1018 | Receive I2, process | If successful, send R2 and go to R2-SENT | 1019 | | | 1020 | | If fail, stay at CLOSED | 1021 | | | 1022 | Receive R1, process | If successful, send I2 and go to I2-SENT | 1023 | | | 1024 | | If fail, stay at CLOSED | 1025 | | | 1026 | Receive CLOSE, | If successful, send CLOSE_ACK, stay at | 1027 | process | CLOSED | 1028 | | | 1029 | | If fail, stay at CLOSED | 1030 | | | 1031 | Receive CLOSE_ACK, | If successful, discard state and go to | 1032 | process | UNASSOCIATED | 1033 | | | 1034 | | If fail, stay at CLOSED | 1035 | | | 1036 | Receive ANYOTHER | Drop and stay at CLOSED | 1037 | | | 1038 | Timeout (UAL+2MSL) | Discard state and go to UNASSOCIATED | 1039 +---------------------+---------------------------------------------+ 1041 Table 8: CLOSED - CLOSE_ACK sent, resending CLOSE_ACK if necessary 1042 System behaviour in state E-FAILED, Table 9. 1044 +---------------------+---------------------------------------------+ 1045 | Trigger | Action | 1046 +---------------------+---------------------------------------------+ 1047 | Wait for | Go to UNASSOCIATED. Re-negotiation is | 1048 | implementation | possible after moving to UNASSOCIATED | 1049 | specific time | state. | 1050 +---------------------+---------------------------------------------+ 1052 Table 9: E-FAILED - HIP failed to establish association with peer 1054 4.4.3. Simplified HIP State Diagram 1056 The following diagram shows the major state transitions. Transitions 1057 based on received packets implicitly assume that the packets are 1058 successfully authenticated or processed. 1060 +-+ +---------------------------+ 1061 I1 received, send R1 | | | | 1062 | v v | 1063 Datagram to send +--------------+ I2 received, send R2 | 1064 +---------------| UNASSOCIATED |---------------+ | 1065 | +--------------+ | | 1066 v | | 1067 +---------+ I2 received, send R2 | | 1068 +---->| I1-SENT |---------------------------------------+ | | 1069 | +---------+ | | | 1070 | | +------------------------+ | | | 1071 | | R1 received, | I2 received, send R2 | | | | 1072 | v send I2 | v v v | 1073 | +---------+ | +---------+ | 1074 | +->| I2-SENT |------------+ | R2-SENT |<----+ | 1075 | | +---------+ +---------+ | | 1076 | | | | | | 1077 | | | data| | | 1078 | |receive | or| | | 1079 | |R1, send | EC timeout| receive I2,| | 1080 | |I2 |R2 received +--------------+ | send R2| | 1081 | | +----------->| ESTABLISHED |<-------+| | | 1082 | | +--------------+ | | 1083 | | | | | | | 1084 | | +------------+ | +------------------------+ | 1085 | | recv| | | | 1086 | | CLOSE,| No packet sent| | | 1087 | | send| /received for | | | 1088 | | CLOSE_ACK| UAL min, send | | | 1089 | | | CLOSE | +---------+<-+ timeout | | 1090 | | | +--->| CLOSING |--+ (UAL+MSL) | | 1091 | | | +---------+ retransmit | | 1092 +--|------------|----------------------+ | | | | CLOSE | | 1093 | +------------|------------------------+ | | +----------------+ | 1094 | | | +-----------+ +------------------|--+ 1095 | | +------------+ | receive CLOSE, CLOSE_ACK | | 1096 | | | | send CLOSE_ACK received or | | 1097 | | v v timeout | | 1098 | | +--------+ (UAL+MSL) | | 1099 | +------------------------| CLOSED |---------------------------+ | 1100 +---------------------------+--------+------------------------------+ 1101 Datagram to send ^ | timeout (UAL+2MSL), 1102 +-+ move to UNASSOCIATED 1103 CLOSE received, 1104 send CLOSE_ACK 1106 4.5. User Data Considerations 1108 4.5.1. TCP and UDP Pseudo-header Computation for User Data 1110 When computing TCP and UDP checksums on user data packets that flow 1111 through sockets bound to HITs, the IPv6 pseudo-header format [11] 1112 MUST be used, even if the actual addresses on the packet are IPv4 1113 addresses. Additionally, the HITs MUST be used in the place of the 1114 IPv6 addresses in the IPv6 pseudo-header. Note that the pseudo- 1115 header for actual HIP payloads is computed differently; see 1116 Section 5.1.1. 1118 4.5.2. Sending Data on HIP Packets 1120 A future version of this document may define how to include user data 1121 on various HIP packets. However, currently the HIP header is a 1122 terminal header, and not followed by any other headers. 1124 4.5.3. Transport Formats 1126 The actual data transmission format, used for user data after the HIP 1127 base exchange, is not defined in this document. Such transport 1128 formats and methods are described in separate specifications. All 1129 HIP implementations MUST implement, at minimum, the ESP transport 1130 format for HIP [24]. 1132 When new transport formats are defined, they get the type value from 1133 the HIP Transform type value space 2048 - 4095. The order in which 1134 the transport formats are presented in the R1 packet, is the 1135 preferred order. The last of the transport formats MUST be ESP 1136 transport format, represented by the ESP_TRANSFORM parameter. 1138 4.5.4. Reboot and SA Timeout Restart of HIP 1140 Simulating a loss of state is a potential DoS attack. The following 1141 process has been crafted to manage state recovery without presenting 1142 a DoS opportunity. 1144 If a host reboots or the HIP association times out, it has lost its 1145 HIP state. If the host that lost state has a datagram to send to the 1146 peer, it simply restarts the HIP base exchange. After the base 1147 exchange has completed, the Initiator can create a new SA and start 1148 sending data. The peer does not reset its state until it receives a 1149 valid I2 HIP packet. 1151 If a system receives a user data packet that cannot be matched to any 1152 existing HIP association, it is possible that it has lost the state 1153 and its peer has not. It MAY send an ICMP packet with the Parameter 1154 Problem type, the Pointer pointing to the referred HIP-related 1155 association information. Reacting to such traffic depends on the 1156 implementation and the environment where the implementation is used. 1158 If the host, that apparently has lost its state, decides to restart 1159 the HIP base exchange, it sends an I1 packet to the peer. After the 1160 base exchange has been completed successfully, the Initiator can 1161 create a new HIP association and the peer drops its OLD SA and 1162 creates a new one. 1164 4.6. Certificate Distribution 1166 HIP base specification does not define how to use certificates or how 1167 to transfer them between hosts. These functions are defined in a 1168 separate specification. A parameter type value, meant to be used for 1169 carrying certificates, is reserved, though: CERT, Type 768; see 1170 Section 5.2. 1172 5. Packet Formats 1174 5.1. Payload Format 1176 All HIP packets start with a fixed header. 1178 0 1 2 3 1179 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 1180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1181 | Next Header | Header Length |0| Packet Type | VER. | RES.|1| 1182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1183 | Checksum | Controls | 1184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1185 | Sender's Host Identity Tag (HIT) | 1186 | | 1187 | | 1188 | | 1189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1190 | Receiver's Host Identity Tag (HIT) | 1191 | | 1192 | | 1193 | | 1194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1195 | | 1196 / HIP Parameters / 1197 / / 1198 | | 1199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1201 The HIP header is logically an IPv6 extension header. However, this 1202 document does not describe processing for Next Header values other 1203 than decimal 59, IPPROTO_NONE, the IPv6 no next header value. Future 1204 documents MAY do so. However, current implementations MUST ignore 1205 trailing data if an unimplemented Next Header value is received. 1207 The Header Length field contains the length of the HIP Header and HIP 1208 parameters in 8 bytes units, excluding the first 8 bytes. Since all 1209 HIP headers MUST contain the sender's and receiver's HIT fields, the 1210 minimum value for this field is 4, and conversely, the maximum length 1211 of the HIP Parameters field is (255*8)-32 = 2008 bytes. Note: this 1212 sets an additional limit for sizes of parameters included in the 1213 Parameters field, independent of the individual parameter maximum 1214 lengths. 1216 The Packet Type indicates the HIP packet type. The individual packet 1217 types are defined in the relevant sections. If a HIP host receives a 1218 HIP packet that contains an unknown packet type, it MUST drop the 1219 packet. 1221 The HIP Version is four bits. The current version is 1. The version 1222 number is expected to be incremented only if there are incompatible 1223 changes to the protocol. Most extensions can be handled by defining 1224 new packet types, new parameter types, or new controls. 1226 The following three bits are reserved for future use. They MUST be 1227 zero when sent, and they SHOULD be ignored when handling a received 1228 packet. 1230 The two fixed bits in the header are reserved for potential SHIM6 1231 compatibility [27]. For implementations adhering (only) to this 1232 specification, they MUST be set as shown when sending and MUST be 1233 ignored when receiving. This is to ensure optimal forward 1234 compatibility. Note that implementations that implement other 1235 compatible specifications in addition to this specification, the 1236 corresponding rules may well be different. For example, in the case 1237 that the forthcoming SHIM6 protocol happens to be compatible with 1238 this specification, an implementation that implements both this 1239 specification and the SHIM6 protocol may need to check these bits in 1240 order to determine how to handle the packet. 1242 The HIT fields are always 128 bits (16 bytes) long. 1244 5.1.1. Checksum 1246 Since the checksum covers the source and destination addresses in the 1247 IP header, it must be recomputed on HIP-aware NAT devies. 1249 If IPv6 is used to carry the HIP packet, the pseudo-header [11] 1250 contains the source and destination IPv6 addresses, HIP packet length 1251 in the pseudo-header length field, a zero field, and the HIP protocol 1252 number (see Section 4) in the Next Header field. The length field is 1253 in bytes and can be calculated from the HIP header length field: (HIP 1254 Header Length + 1) * 8. 1256 In case of using IPv4, the IPv4 UDP pseudo header format [1] is used. 1257 In the pseudo header, the source and destination addresses are those 1258 used in the IP header, the zero field is obviously zero, the protocol 1259 is the HIP protocol number (see Section 4), and the length is 1260 calculated as in the IPv6 case. 1262 5.1.2. HIP Controls 1264 The HIP Controls section conveys information about the structure of 1265 the packet and capabilities of the host. 1267 The following fields have been defined: 1269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1270 | | | | | | | | | | | | | | | |A| 1271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1273 A - Anonymous: If this is set, the sender's HI in this packet is 1274 anonymous, i.e., one not listed in a directory. Anonymous HIs 1275 SHOULD NOT be stored. This control is set in packets R1 and/or 1276 I2. The peer receiving an anonymous HI may choose to refuse it. 1278 The rest of the fields are reserved for future use and MUST be set to 1279 zero on sent packets and ignored on received packets. 1281 5.1.3. HIP Fragmentation Support 1283 A HIP implementation must support IP fragmentation / reassembly. 1284 Fragment reassembly MUST be implemented in both IPv4 and IPv6, but 1285 fragment generation is REQUIRED to be implemented in IPv4 (IPv4 1286 stacks and networks will usually do this by default) and RECOMMENDED 1287 to be implemented in IPv6. In IPv6 networks, the minimum MTU is 1288 larger, 1280 bytes, than in IPv4 networks. The larger MTU size is 1289 usually sufficient for most HIP packets, and therefore fragment 1290 generation may not be needed. If a host expects to send HIP packets 1291 that are larger than the minimum IPv6 MTU, it MUST implement fragment 1292 generation even for IPv6. 1294 In IPv4 networks, HIP packets may encounter low MTUs along their 1295 routed path. Since HIP does not provide a mechanism to use multiple 1296 IP datagrams for a single HIP packet, support for path MTU discovery 1297 does not bring any value to HIP in IPv4 networks. HIP-aware NAT 1298 devices MUST perform any IPv4 reassembly/fragmentation. 1300 All HIP implementations MUST employ a reassembly algorithm that is 1301 sufficiently resistant to DoS attacks. 1303 5.2. HIP Parameters 1305 The HIP Parameters are used to carry the public key associated with 1306 the sender's HIT, together with related security and other 1307 information. They consist of ordered parameters, encoded in TLV 1308 format. 1310 The following parameter types are currently defined. 1312 +------------------+-------+----------+-----------------------------+ 1313 | TLV | Type | Length | Data | 1314 +------------------+-------+----------+-----------------------------+ 1315 | R1_COUNTER | 128 | 12 | System Boot Counter | 1316 | | | | | 1317 | PUZZLE | 257 | 12 | K and Random #I | 1318 | | | | | 1319 | SOLUTION | 321 | 20 | K, Random #I and puzzle | 1320 | | | | solution J | 1321 | | | | | 1322 | SEQ | 385 | 4 | Update packet ID number | 1323 | | | | | 1324 | ACK | 449 | variable | Update packet ID number | 1325 | | | | | 1326 | DIFFIE_HELLMAN | 513 | variable | public key | 1327 | | | | | 1328 | HIP_TRANSFORM | 577 | variable | HIP Encryption and | 1329 | | | | Integrity Transform | 1330 | | | | | 1331 | ENCRYPTED | 641 | variable | Encrypted part of I2 packet | 1332 | | | | | 1333 | HOST_ID | 705 | variable | Host Identity with Fully | 1334 | | | | Qualified Domain Name or | 1335 | | | | NAI | 1336 | | | | | 1337 | CERT | 768 | variable | HI Certificate; used to | 1338 | | | | transfer certificates. | 1339 | | | | Usage defined in a separate | 1340 | | | | document. | 1341 | | | | | 1342 | NOTIFY | 832 | variable | Informational data | 1343 | | | | | 1344 | ECHO_REQUEST | 897 | variable | Opaque data to be echoed | 1345 | | | | back; under signature | 1346 | | | | | 1347 | ECHO_RESPONSE | 961 | variable | Opaque data echoed back; | 1348 | | | | under signature | 1349 | | | | | 1350 | HMAC | 61505 | 20 | HMAC based message | 1351 | | | | authentication code, with | 1352 | | | | key material from | 1353 | | | | HIP_TRANSFORM | 1354 | | | | | 1355 | HMAC_2 | 61569 | 20 | HMAC based message | 1356 | | | | authentication code, with | 1357 | | | | key material from | 1358 | | | | HIP_TRANSFORM | 1359 | | | | | 1360 | HIP_SIGNATURE_2 | 61633 | variable | Signature of the R1 packet | 1361 | | | | | 1362 | HIP_SIGNATURE | 61697 | variable | Signature of the packet | 1363 | | | | | 1364 | ECHO_REQUEST | 63661 | variable | Opaque data to be echoed | 1365 | | | | back; after signature | 1366 | | | | | 1367 | ECHO_RESPONSE | 63425 | variable | Opaque data echoed back; | 1368 | | | | after signature | 1369 +------------------+-------+----------+-----------------------------+ 1371 Because the ordering (from lowest to highest) of HIP parameters is 1372 strictly enforced (see Section 5.2.1), the parameter type values for 1373 existing parameters have been spaced to allow for future protocol 1374 extensions. Parameters numbered between 0-1023 are used in HIP 1375 handshake and update procedures and are covered by signatures. 1376 Parameters numbered between 1024-2047 are reserved. Parameters 1377 numbered between 2048-4095 are used for parameters related to HIP 1378 transform types. Parameters numbered between 4096 and (2^16 - 2^12) 1379 61439 are reserved. Parameters numbered between 61440-62463 are used 1380 for signatures and signed MACs. Parameters numbered between 62464- 1381 63487 are used for parameters that fall outside of the signed area of 1382 the packet. Parameters numbered between 63488-64511 are used for 1383 rendezvous and other relaying services. Parameters numbered between 1384 64512-65535 are reserved. 1386 5.2.1. TLV Format 1388 The TLV-encoded parameters are described in the following 1389 subsections. The type-field value also describes the order of these 1390 fields in the packet, except for type values from 2048 to 4095 which 1391 are reserved for new transport forms. The parameters MUST be 1392 included in the packet such that their types form an increasing 1393 order. If the order does not follow this rule, the packet is 1394 considered to be malformed and it MUST be discarded. 1396 Parameters using type values from 2048 up to 4095 are transport 1397 formats. Currently, one transport format is defined: the ESP 1398 transport format [24]. The order of these parameters does not follow 1399 the order of their type value, but they are put in the packet in 1400 order of preference. The first of the transport formats it the most 1401 preferred, and so on. 1403 All of the TLV parameters have a length (including Type and Length 1404 fields) which is a multiple of 8 bytes. When needed, padding MUST be 1405 added to the end of the parameter so that the total length becomes a 1406 multiple of 8 bytes. This rule ensures proper alignment of data. If 1407 padding is added, the Length field MUST NOT include the padding. Any 1408 added padding bytes MUST be zeroed by the sender, and their values 1409 SHOULD NOT be checked by the receiver. 1411 Consequently, the Length field indicates the length of the Contents 1412 field (in bytes). The total length of the TLV parameter (including 1413 Type, Length, Contents, and Padding) is related to the Length field 1414 according to the following formula: 1416 Total Length = 11 + Length - (Length + 3) % 8; 1418 0 1 2 3 1419 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 1420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1421 | Type |C| Length | 1422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1423 | | 1424 / Contents / 1425 / +-+-+-+-+-+-+-+-+ 1426 | | Padding | 1427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1429 Type Type code for the parameter. 16 bits long, C-bit 1430 being part of the Type code. 1431 C Critical. One if this parameter is critical, and 1432 MUST be recognized by the recipient, zero otherwise. 1433 The C bit is considered to be a part of the Type 1434 field. Consequently, critical parameters are always 1435 odd and non-critical ones have an even value. 1436 Length Length of the Contents, in bytes. 1437 Contents Parameter specific, defined by Type 1438 Padding Padding, 0-7 bytes, added if needed 1440 Critical parameters MUST be recognized by the recipient. If a 1441 recipient encounters a critical parameter that it does not recognize, 1442 it MUST NOT process the packet any further. It MAY send an ICMP or 1443 NOTIFY, as defined in Section 4.3. 1445 Non-critical parameters MAY be safely ignored. If a recipient 1446 encounters a non-critical parameter that it does not recognize, it 1447 SHOULD proceed as if the parameter was not present in the received 1448 packet. 1450 5.2.2. Defining New Parameters 1452 Future specifications may define new parameters as needed. When 1453 defining new parameters, care must be taken to ensure that the 1454 parameter type values are appropriate and leave suitable space for 1455 other future extensions. One must remember that the parameters MUST 1456 always be arranged in the increasing order by type code, thereby 1457 limiting the order of parameters (see Section 5.2.1). 1459 The following rules must be followed when defining new parameters. 1461 1. The low order bit C of the Type code is used to distinguish 1462 between critical and non-critical parameters. 1464 2. A new parameter may be critical only if an old recipient ignoring 1465 it would cause security problems. In general, new parameters 1466 SHOULD be defined as non-critical, and expect a reply from the 1467 recipient. 1469 3. If a system implements a new critical parameter, it MUST provide 1470 the ability to configure the associated feature off, such that 1471 the critical parameter is not sent at all. The configuration 1472 option must be well documented. By default, sending of such a 1473 new critical parameter SHOULD be off. In other words, the 1474 management interface MUST allow vanilla standards-only mode as a 1475 default configuration setting, and MAY allow new critical 1476 payloads to be configured on (and off). 1478 4. See section Section 9 for allocation rules regarding type codes. 1480 5.2.3. R1_COUNTER 1482 0 1 2 3 1483 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 1484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1485 | Type | Length | 1486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1487 | Reserved, 4 bytes | 1488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1489 | R1 generation counter, 8 bytes | 1490 | | 1491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1493 Type 128 1494 Length 12 1495 R1 generation 1496 counter The current generation of valid puzzles 1498 The R1_COUNTER parameter contains an 64-bit unsigned integer in 1499 network byte order, indicating the current generation of valid 1500 puzzles. The sender is supposed to increment this counter 1501 periodically. It is RECOMMENDED that the counter value is 1502 incremented at least as often as old PUZZLE values are deprecated so 1503 that SOLUTIONs to them are no longer accepted. 1505 The R1_COUNTER parameter is optional. It SHOULD be included in the 1506 R1 (in which case it is covered by the signature), and if present in 1507 the R1, it MAY be echoed (including the Reserved field verbatim) by 1508 the Initiator in the I2. 1510 5.2.4. PUZZLE 1512 0 1 2 3 1513 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 1514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1515 | Type | Length | 1516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1517 | K, 1 byte | Lifetime | Opaque, 2 bytes | 1518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1519 | Random # I, 8 bytes | 1520 | | 1521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1523 Type 257 1524 Length 12 1525 K K is the number of verified bits 1526 Lifetime Puzzle lifetime 2^(value-32) seconds 1527 Opaque Data set by the Responder, indexing the puzzle 1528 Random #I random number 1530 Random #I is represented as 64-bit integer, K and Lifetime as 8-bit 1531 integer, all in network byte order. 1533 The PUZZLE parameter contains the puzzle difficulty K and a 64-bit 1534 puzzle random integer #I. The Puzzle Lifetime indicates the time 1535 during which the puzzle solution is valid, and sets a time limit 1536 which should not be exceeded by the Initiator while it attempts to 1537 solve the puzzle. The lifetime is indicated as a power of 2 using 1538 the formula 2^(Lifetime-32) seconds. A puzzle MAY be augmented with 1539 an ECHO_REQUEST parameter included in the R1; the contents of the 1540 ECHO_REQUEST are then echoed back in the ECHO_RESPONSE, allowing the 1541 Responder to use the included information as a part of its puzzle 1542 processing. 1544 The Opaque and Random #I field are not covered by the HIP_SIGNATURE_2 1545 parameter. 1547 5.2.5. SOLUTION 1549 0 1 2 3 1550 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 1551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1552 | Type | Length | 1553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1554 | K, 1 byte | Reserved | Opaque, 2 bytes | 1555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1556 | Random #I, 8 bytes | 1557 | | 1558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1559 | Puzzle solution #J, 8 bytes | 1560 | | 1561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1563 Type 321 1564 Length 20 1565 K K is the number of verified bits 1566 Reserved zero when sent, ignored when received 1567 Opaque copied unmodified from the received PUZZLE 1568 parameter 1569 Random #I random number 1570 Puzzle solution 1571 #J random number 1573 Random #I, and Random #J are represented as 64-bit integers, K as an 1574 8-bit integer, all in network byte order. 1576 The SOLUTION parameter contains a solution to a puzzle. It also 1577 echoes back the random difficulty K, the Opaque field, and the puzzle 1578 integer #I. 1580 5.2.6. DIFFIE_HELLMAN 1582 0 1 2 3 1583 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 1584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1585 | Type | Length | 1586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1587 | Group ID | Public Value / 1588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1589 / | padding | 1590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1592 Type 513 1593 Length length in octets, excluding Type, Length, and 1594 padding 1595 Group ID defines values for p and g 1596 Public Value the sender's public Diffie-Hellman key 1598 The following Group IDs have been defined: 1600 Group Value 1601 Reserved 0 1602 384-bit group 1 1603 OAKLEY well known group 1 2 1604 1536-bit MODP group 3 1605 3072-bit MODP group 4 1606 6144-bit MODP group 5 1607 8192-bit MODP group 6 1609 The MODP Diffie-Hellman groups are defined in [17]. The OAKLEY group 1610 is defined in [8]. The OAKLEY well known group 5 is the same as the 1611 1536-bit MODP group. 1613 A HIP implementation MUST support Group IDs 1 and 3. The 384-bit 1614 group can be used when lower security is enough (e.g. web surfing) 1615 and when the equipment is not powerful enough (e.g. some PDAs). 1616 Equipment powerful enough SHOULD implement also group ID 5. The 384- 1617 bit group is defined in Appendix D. 1619 To avoid unnecessary failures during the base exchange, the rest of 1620 the groups SHOULD be implemented in hosts where resources are 1621 adequate. 1623 5.2.7. HIP_TRANSFORM 1625 0 1 2 3 1626 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 1627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1628 | Type | Length | 1629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1630 | Transform-ID #1 | Transform-ID #2 | 1631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1632 | Transform-ID #n | Padding | 1633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1635 Type 577 1636 Length length in octets, excluding Type, Length, and 1637 padding 1638 Transform-ID Defines the HIP Suite to be used 1640 The following Suite-IDs are defined ([21],[10]): 1642 Suite-ID Value 1644 RESERVED 0 1645 AES-CBC with HMAC-SHA1 1 1646 3DES-CBC with HMAC-SHA1 2 1647 3DES-CBC with HMAC-MD5 3 1648 BLOWFISH-CBC with HMAC-SHA1 4 1649 NULL-ENCRYPT with HMAC-SHA1 5 1650 NULL-ENCRYPT with HMAC-MD5 6 1652 There MUST NOT be more than six (6) HIP Suite-IDs in one HIP 1653 transform parameter. The limited number of transforms sets the 1654 maximum size of HIP_TRANSFORM parameter. The HIP_TRANSFORM parameter 1655 MUST contain at least one of the mandatory Suite-IDs. 1657 The Responder lists supported and desired Suite-IDs in order of 1658 preference in the R1, up to the maximum of six Suite-IDs. In the I2, 1659 the Initiator MUST choose and insert only one of the corresponding 1660 Suite-IDs that will be used for generating the I2. 1662 Mandatory implementations: AES-CBC with HMAC-SHA1 and NULL-ENCRYPTION 1663 with HMAC-SHA1. 1665 5.2.8. HOST_ID 1667 0 1 2 3 1668 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 1669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1670 | Type | Length | 1671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1672 | HI Length |DI-type| DI Length | 1673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1674 | Host Identity / 1675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1676 / | Domain Identifier / 1677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1678 / | Padding | 1679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1681 Type 705 1682 Length length in octets, excluding Type, Length, and 1683 Padding 1684 HI Length Length of the Host Identity in octets 1685 DI-type type of the following Domain Identifier field 1686 DI Length length of the FQDN or NAI in octets 1687 Host Identity actual host identity 1688 Domain Identifier the identifier of the sender 1690 The Host Identity is represented in RFC2535 [12] format. The 1691 algorithms used in RDATA format are the following: 1693 Algorithms Values 1695 RESERVED 0 1696 DSA 3 [RFC2536] (RECOMMENDED) 1697 RSA 5 [RFC3110] (REQUIRED) 1699 The following DI-types have been defined: 1701 Type Value 1702 none included 0 1703 FQDN 1 1704 NAI 2 1706 FQDN Fully Qualified Domain Name, in binary format. 1707 NAI Network Access Identifier 1708 [23] 1709 The format for the FQDN is defined in RFC1035 [3] Section 3.1. 1711 If there is no Domain Identifier, i.e. the DI-type field is zero, 1712 also the DI Length field is set to zero. 1714 5.2.9. HMAC 1716 0 1 2 3 1717 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 1718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1719 | Type | Length | 1720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1721 | | 1722 | HMAC | 1723 | | 1724 | | 1725 | | 1726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1728 Type 61505 1729 Length 20 1730 HMAC 160 low order bits of the HMAC computed over the 1731 HIP packet, excluding the HMAC parameter and any 1732 following parameters, such as HIP_SIGNATURE, 1733 HIP_SIGNATURE_2, ECHO_REQUEST, or ECHO_RESPONSE. 1734 The checksum field MUST be set to zero 1735 and the HIP header length in the HIP common header 1736 MUST be calculated not to cover any excluded 1737 parameters when the HMAC is calculated. 1739 The HMAC calculation and verification process is presented in 1740 Section 6.4.1 1742 5.2.10. HMAC_2 1744 The parameter structure is the same as in Section 5.2.9. The fields 1745 are: 1747 Type 61569 1748 Length 20 1749 HMAC 160 low order bits of the HMAC computed over the 1750 HIP packet, excluding the HMAC parameter and any 1751 following parameters such as HIP_SIGNATURE, 1752 HIP_SIGNATURE_2, ECHO_REQUEST, or ECHO_RESPONSE, 1753 and including an additional sender's 1754 HOST_ID parameter during the HMAC calculation. The 1755 checksum field MUST be set to zero and the HIP 1756 header length in the HIP common header MUST be 1757 calculated not to cover any excluded parameters 1758 when the HMAC is calculated. 1760 The HMAC calculation and verification process is presented in 1761 Section 6.4.1 1763 5.2.11. HIP_SIGNATURE 1765 0 1 2 3 1766 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 1767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1768 | Type | Length | 1769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1770 | SIG alg | Signature / 1771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1772 / | Padding | 1773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1775 Type 61697 1776 Length length in octets, excluding Type, Length, and 1777 Padding 1778 SIG alg Signature algorithm 1779 Signature the signature is calculated over the HIP packet, 1780 excluding the HIP_SIGNATURE parameter and any 1781 parameters that follow the HIP_SIGNATURE parameter. 1782 The checksum field MUST be set to zero, and the HIP 1783 header length in the HIP common header MUST be 1784 calculated only to the beginning of the 1785 HIP_SIGNATURE parameter when the signature is 1786 calculated. 1788 The signature algorithms are defined in Section 5.2.8. The signature 1789 in the Signature field is encoded using the proper method depending 1790 on the signature algorithm (e.g. according to [15] in case of RSA, or 1791 according to [13] in case of DSA). 1793 The HIP_SIGNATURE calculation and verification process is presented 1794 in Section 6.4.2 1796 5.2.12. HIP_SIGNATURE_2 1798 The parameter structure is the same as in Section 5.2.11. The fields 1799 are: 1801 Type 61633 1802 Length length in octets, excluding Type, Length, and 1803 Padding 1804 SIG alg Signature algorithm 1805 Signature the signature is calculated over the HIP R1 packet, 1806 excluding the HIP_SIGNATURE_2 parameter and any 1807 parameters that follow. Initiator's HIT, checksum 1808 field, and the Opaque and Random #I fields in the 1809 PUZZLE parameter MUST be set to zero while 1810 computing the HIP_SIGNATURE_2 signature. Further, 1811 the HIP packet length in the HIP header MUST be 1812 calculated to the beginning of the HIP_SIGNATURE_2 1813 parameter when the signature is calculated. 1815 Zeroing the Initiator's HIT makes it possible to create R1 packets 1816 beforehand to minimize the effects of possible DoS attacks. Zeroing 1817 the I and Opaque fields allows these fields to be populated 1818 dynamically on precomputed R1s. 1820 Signature calculation and verification follows the process in 1821 Section 6.4.2. 1823 5.2.13. SEQ 1825 0 1 2 3 1826 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 1827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1828 | Type | Length | 1829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1830 | Update ID | 1831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1833 Type 385 1834 Length 4 1835 Update ID 32-bit sequence number 1837 The Update ID is an unsigned quantity, initialized by a host to zero 1838 upon moving to ESTABLISHED state. The Update ID has scope within a 1839 single HIP association, and not across multiple associations or 1840 multiple hosts. The Update ID is incremented by one before each new 1841 UPDATE that is sent by the host; the first UPDATE packet originated 1842 by a host has an Update ID of 0. 1844 5.2.14. ACK 1846 0 1 2 3 1847 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 1848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1849 | Type | Length | 1850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1851 | peer Update ID | 1852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1854 Type 449 1855 Length variable (multiple of 4) 1856 peer Update ID 32-bit sequence number corresponding to the 1857 Update ID being acked. 1859 The ACK parameter includes one or more Update IDs that have been 1860 received from the peer. The Length field identifies the number of 1861 peer Update IDs that are present in the parameter. 1863 5.2.15. ENCRYPTED 1865 0 1 2 3 1866 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 1867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1868 | Type | Length | 1869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1870 | Reserved | 1871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1872 | IV / 1873 / / 1874 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 1876 / Encrypted data / 1877 / / 1878 / +-------------------------------+ 1879 / | Padding | 1880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1882 Type 641 1883 Length length in octets, excluding Type, Length, and 1884 Padding 1885 Reserved zero when sent, ignored when received 1886 IV Initialization vector, if needed, otherwise 1887 nonexistent. The length of the IV is inferred from 1888 the HIP transform. 1889 Encrypted The data is encrypted using an encryption algorithm 1890 data as defined in HIP transform. 1891 Padding Any Padding, if necessary, to make the parameter a 1892 multiple of 8 bytes. 1894 The ENCRYPTED parameter encapsulates another parameter, the encrypted 1895 data, which is also in TLV format. Consequently, the first fields in 1896 the encapsulated parameter(s) are Type and Length, allowing the 1897 contents to be easily parsed after decryption. 1899 Both the ENCRYPTED parameter and the encapsulated parameter(s) MUST 1900 be padded. The padding needed for the ENCRYPTED parameter is 1901 referred as the "outer" padding. Correspondingly, the padding for 1902 the parameter(s) encapsulated within the ENCRYPTED parameter is 1903 referred as the "inner" padding. 1905 The inner padding follows exactly the rules of Section 5.2.1. The 1906 outer padding also follows the same rules but with an exception. 1907 Namely, some algorithms require that the data to be encrypted must be 1908 a multiple of the cipher algorithm block size. In this case, the 1909 outer padding MUST include extra padding, as specified by the 1910 encryption algorithm. The size of the extra padding is selected so 1911 that the length of the ENCRYPTED is the minimum value that is both 1912 multiple of eight and the cipher block size. The encryption 1913 algorithm may specify padding bytes other than zero; for example, AES 1914 [32] uses the PKCS5 padding scheme [14] (see section 6.1.1) where the 1915 remaining n bytes to fill the block each have the value n. 1917 Note that the length of the cipher suite output may be smaller or 1918 larger than the length of the data to be encrypted, since the 1919 encryption process may compress the data or add additional padding to 1920 the data. 1922 5.2.16. NOTIFY 1924 The NOTIFY parameter is used to transmit informational data, such as 1925 error conditions and state transitions, to a HIP peer. A NOTIFY 1926 parameter may appear in the NOTIFY packet type. The use of the 1927 NOTIFY parameter in other packet types is for further study. 1929 0 1 2 3 1930 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 1931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1932 | Type | Length | 1933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1934 | Reserved | Notify Message Type | 1935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1936 | / 1937 / Notification data / 1938 / +---------------+ 1939 / | Padding | 1940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1942 Type 832 1943 Length length in octets, excluding Type, Length, and 1944 Padding 1945 Reserved zero when sent, ignored when received 1946 Notify Message Specifies the type of notification 1947 Type 1948 Notification Informational or error data transmitted in addition 1949 Data to the Notify Message Type. Values for this field 1950 are type specific (see below). 1951 Padding Any Padding, if necessary, to make the parameter a 1952 multiple of 8 bytes. 1954 Notification information can be error messages specifying why an SA 1955 could not be established. It can also be status data that a process 1956 managing an SA database wishes to communicate with a peer process. 1957 The table below lists the Notification messages and their 1958 corresponding values. 1960 To avoid certain types of attacks, a Responder SHOULD avoid sending a 1961 NOTIFY to any host with which it has not successfully verified a 1962 puzzle solution. 1964 Types in the range 0 - 16383 are intended for reporting errors. An 1965 implementation that receives a NOTIFY error parameter in response to 1966 a request packet (e.g., I1, I2, UPDATE), SHOULD assume that the 1967 corresponding request has failed entirely. Unrecognized error types 1968 MUST be ignored except that they SHOULD be logged. 1970 Notify payloads with status types MUST be ignored if not recognized. 1972 NOTIFY PARAMETER - ERROR TYPES Value 1973 ------------------------------ ----- 1975 UNSUPPORTED_CRITICAL_PARAMETER_TYPE 1 1977 Sent if the parameter type has the "critical" bit set and the 1978 parameter type is not recognized. Notification Data contains 1979 the two octet parameter type. 1981 INVALID_SYNTAX 7 1983 Indicates that the HIP message received was invalid because 1984 some type, length, or value was out of range or because the 1985 request was rejected for policy reasons. To avoid a denial of 1986 service attack using forged messages, this status may only be 1987 returned for packets whose HMAC (if present) and SIGNATURE have 1988 been verified. This status MUST be sent in response to any 1989 error not covered by one of the other status types, and should 1990 not contain details to avoid leaking information to someone 1991 probing a node. To aid debugging, more detailed error 1992 information SHOULD be written to a console or log. 1994 NO_DH_PROPOSAL_CHOSEN 14 1996 None of the proposed group IDs was acceptable. 1998 INVALID_DH_CHOSEN 15 2000 The D-H Group ID field does not correspond to one offered 2001 by the Responder. 2003 NO_HIP_PROPOSAL_CHOSEN 16 2005 None of the proposed HIP Transform crypto suites was 2006 acceptable. 2008 INVALID_HIP_TRANSFORM_CHOSEN 17 2010 The HIP Transform crypto suite does not correspond to 2011 one offered by the Responder. 2013 AUTHENTICATION_FAILED 24 2015 Sent in response to a HIP signature failure, except when 2016 the signature verification fails in a NOTIFY message. 2018 CHECKSUM_FAILED 26 2020 Sent in response to a HIP checksum failure. 2022 HMAC_FAILED 28 2024 Sent in response to a HIP HMAC failure. 2026 ENCRYPTION_FAILED 32 2028 The Responder could not successfully decrypt the 2029 ENCRYPTED parameter. 2031 INVALID_HIT 40 2033 Sent in response to a failure to validate the peer's 2034 HIT from the corresponding HI. 2036 BLOCKED_BY_POLICY 42 2038 The Responder is unwilling to set up an association 2039 for some policy reason (e.g. received HIT is NULL 2040 and policy does not allow opportunistic mode). 2042 SERVER_BUSY_PLEASE_RETRY 44 2044 The Responder is unwilling to set up an association 2045 as it is suffering under some kind of overload and 2046 has chosen to shed load by rejecting your request. 2047 You may retry if you wish, however you MUST find 2048 another (different) puzzle solution for any such 2049 retries. Note that you may need to obtain a new 2050 puzzle with a new I1/R1 exchange. 2052 I2_ACKNOWLEDGEMENT 46 2054 The Responder has received your I2 but had to queue 2055 the I2 for processing. The puzzle was correctly solved 2056 and the Responder is willing to set up an association 2057 but has currently a number of I2s in processing queue. 2058 R2 will be sent after the I2 has been processed. 2060 NOTIFY MESSAGES - STATUS TYPES Value 2061 ------------------------------ ----- 2063 (None defined at present) 2065 5.2.17. ECHO_REQUEST 2067 0 1 2 3 2068 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 2069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2070 | Type | Length | 2071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2072 | Opaque data (variable length) | 2073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2075 Type 63661 or 897 2076 Length variable 2077 Opaque data Opaque data, supposed to be meaningful only to the 2078 node that sends ECHO_REQUEST and receives a 2079 corresponding ECHO_RESPONSE. 2081 The ECHO_REQUEST parameter contains an opaque blob of data that the 2082 sender wants to get echoed back in the corresponding reply packet. 2084 The ECHO_REQUEST and ECHO_RESPONSE parameters MAY be used for any 2085 purpose where a node wants to carry some state in a request packet 2086 and get it back in a response packet. The ECHO_REQUEST MAY be 2087 covered by the HMAC and SIGNATURE. This is dictated by the Type 2088 field selected for the parameter; Type 897 ECHO_REQUEST is covered 2089 and Type 63661 is not covered. A HIP packet can contain only one 2090 ECHO_REQUEST parameter. 2092 5.2.18. ECHO_RESPONSE 2094 0 1 2 3 2095 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 2096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2097 | Type | Length | 2098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2099 | Opaque data (variable length) | 2100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2102 Type 63425 or 961 2103 Length variable 2104 Opaque data Opaque data, copied unmodified from the ECHO_REQUEST 2105 parameter that triggered this response. 2107 The ECHO_RESPONSE parameter contains an opaque blob of data that the 2108 sender of the ECHO_REQUEST wants to get echoed back. The opaque data 2109 is copied unmodified from the ECHO_REQUEST parameter. 2111 The ECHO_REQUEST and ECHO_RESPONSE parameters MAY be used for any 2112 purpose where a node wants to carry some state in a request packet 2113 and get it back in a response packet. The ECHO_RESPONSE MAY be 2114 covered by the HMAC and SIGNATURE. This is dictated by the Type 2115 field selected for the parameter; Type 961 ECHO_RESPONSE is covered 2116 and Type 63425 is not. 2118 5.3. HIP Packets 2120 There are eight basic HIP packets (see Table 11). Four are for the 2121 HIP base exchange, one is for updating, one is for sending 2122 notifications, and two for closing a HIP association. 2124 +-------------+---------------------------------------------------+ 2125 | Packet type | Packet name | 2126 +-------------+---------------------------------------------------+ 2127 | 1 | I1 - the HIP Initiator Packet | 2128 | | | 2129 | 2 | R1 - the HIP Responder Packet | 2130 | | | 2131 | 3 | I2 - the Second HIP Initiator Packet | 2132 | | | 2133 | 4 | R2 - the Second HIP Responder Packet | 2134 | | | 2135 | 16 | UPDATE - the HIP Update Packet | 2136 | | | 2137 | 17 | NOTIFY - the HIP Notify Packet | 2138 | | | 2139 | 18 | CLOSE - the HIP Association Closing Packet | 2140 | | | 2141 | 19 | CLOSE_ACK - the HIP Closing Acknowledgment Packet | 2142 +-------------+---------------------------------------------------+ 2144 Table 11: HIP packets and packet type numbers 2146 Packets consist of the fixed header as described in Section 5.1, 2147 followed by the parameters. The parameter part, in turn, consists of 2148 zero or more parameter coded parameters. 2150 In addition to the base packets, other packets types will be defined 2151 later in separate specifications. For example, support for mobility 2152 and multi-homing is not included in this specification. 2154 See Notation (Section 2.2) for used operations. 2156 In the future, an OPTIONAL upper layer payload MAY follow the HIP 2157 header. The Next Header field in the header indicates if there is 2158 additional data following the HIP header. The HIP packet, however, 2159 MUST NOT be fragmented. This limits the size of the possible 2160 additional data in the packet. 2162 5.3.1. I1 - the HIP Initiator Packet 2164 The HIP header values for the I1 packet: 2166 Header: 2167 Packet Type = 1 2168 SRC HIT = Initiator's HIT 2169 DST HIT = Responder's HIT, or NULL 2171 IP ( HIP () ) 2173 The I1 packet contains only the fixed HIP header. 2175 Valid control bits: none 2177 The Initiator gets the Responder's HIT either from a DNS lookup of 2178 the Responder's FQDN, from some other repository, or from a local 2179 table. If the Initiator does not know the Responder's HIT, it may 2180 attempt opportunistic mode by using NULL (all zeros) as the 2181 Responder's HIT. If the Initiator sends a NULL as the Responder's 2182 HIT, it MUST be able to handle all MUST and SHOULD algorithms from 2183 Section 3, which are currently RSA and DSA. 2185 Since this packet is so easy to spoof even if it were signed, no 2186 attempt is made to add to its generation or processing cost. 2188 Implementations MUST be able to handle a storm of received I1 2189 packets, discarding those with common content that arrive within a 2190 small time delta. 2192 5.3.2. R1 - the HIP Responder Packet 2194 The HIP header values for the R1 packet: 2196 Header: 2197 Packet Type = 2 2198 SRC HIT = Responder's HIT 2199 DST HIT = Initiator's HIT 2201 IP ( HIP ( [ R1_COUNTER, ] 2202 PUZZLE, 2203 DIFFIE_HELLMAN, 2204 HIP_TRANSFORM, 2205 HOST_ID, 2206 [ ECHO_REQUEST, ] 2207 HIP_SIGNATURE_2 ) 2208 [, ECHO_REQUEST ]) 2210 Valid control bits: A 2212 If the Responder HI is an anonymous one, the A control MUST be set. 2214 The Initiator HIT MUST match the one received in I1. If the 2215 Responder has multiple HIs, the Responder HIT used MUST match 2216 Initiator's request. If the Initiator used opportunistic mode, the 2217 Responder may select freely among its HIs. 2219 The R1 generation counter is used to determine the currently valid 2220 generation of puzzles. The value is increased periodically, and it 2221 is RECOMMENDED that it is increased at least as often as solutions to 2222 old puzzles are no longer accepted. 2224 The Puzzle contains a random #I and the difficulty K. The difficulty 2225 K is the number of bits that the Initiator must get zero in the 2226 puzzle. The random #I is not covered by the signature and must be 2227 zeroed during the signature calculation, allowing the sender to 2228 select and set the #I into a pre-computed R1 just prior sending it to 2229 the peer. 2231 The Diffie-Hellman value is ephemeral, but can be reused over a 2232 number of connections. In fact, as a defense against I1 storms, an 2233 implementation MAY use the same Diffie-Hellman value for a period of 2234 time, for example, 15 minutes. By using a small number of different 2235 puzzles for a given Diffie-Hellman value, the R1 packets can be pre- 2236 computed and delivered as quickly as I1 packets arrive. A scavenger 2237 process should clean up unused DHs and puzzles. 2239 The HIP_TRANSFORM contains the encryption and integrity algorithms 2240 supported by the Responder to protect the HI exchange, in the order 2241 of preference. All implementations MUST support the AES [18] with 2242 HMAC-SHA-1-96 [6]. 2244 The ECHO_REQUEST contains data that the sender wants to receive 2245 unmodified in the corresponding response packet in the ECHO_RESPONSE 2246 parameter. The ECHO_REQUEST can be either covered by the signature, 2247 or it can be left out from it. In the first case, the ECHO_REQUEST 2248 gets Type number 897 and in the latter case 63661. 2250 The signature is calculated over the whole HIP envelope, after 2251 setting the Initiator HIT, header checksum as well as the Opaque 2252 field and the Random #I in the PUZZLE parameter temporarily to zero, 2253 and excluding any parameters that follow the signature, as described 2254 in Section 5.2.12. This allows the Responder to use precomputed R1s. 2255 The Initiator SHOULD validate this signature. It SHOULD check that 2256 the Responder HI received matches with the one expected, if any. 2258 5.3.3. I2 - the Second HIP Initiator Packet 2260 The HIP header values for the I2 packet: 2262 Header: 2263 Type = 3 2264 SRC HIT = Initiator's HIT 2265 DST HIT = Responder's HIT 2267 IP ( HIP ( [R1_COUNTER,] 2268 SOLUTION, 2269 DIFFIE_HELLMAN, 2270 HIP_TRANSFORM, 2271 ENCRYPTED { HOST_ID } or HOST_ID, 2272 [ ECHO_RESPONSE ,] 2273 HMAC, 2274 HIP_SIGNATURE 2275 [, ECHO_RESPONSE] ) ) 2277 Valid control bits: A 2279 The HITs used MUST match the ones used previously. 2281 If the Initiator HI is an anonymous one, the A control MUST be set. 2283 The Initiator MAY include an unmodified copy of the R1_COUNTER 2284 parameter received in the corresponding R1 packet into the I2 packet. 2286 The Solution contains the random # I from R1 and the computed # J. 2287 The low order K bits of the PHASH(I | ... | J) MUST be zero. 2289 The Diffie-Hellman value is ephemeral. If precomputed, a scavenger 2290 process should clean up unused DHs. 2292 The HIP_TRANSFORM contains the single encryption and integrity 2293 transform selected by the Initiator, that will be used to protect the 2294 HI exchange. The chosen transform MUST correspond to one offered by 2295 the Responder in the R1. All implementations MUST support the AES 2296 transform [18]. 2298 The Initiator's HI MAY be encrypted using the HIP_TRANSFORM 2299 encryption algorithm. The keying material is derived from the 2300 Diffie-Hellman exchanged as defined in Section 6.5. 2302 The ECHO_RESPONSE contains the unmodified Opaque data copied from the 2303 corresponding ECHO_REQUEST parameter. The ECHO_RESPONSE can be 2304 either covered by the HMAC and SIGNATURE or not covered. In the 2305 former case, the ECHO_RESPONSE gets Type number 961, in the latter it 2306 is 63425. 2308 The HMAC is calculated over whole HIP envelope, excluding any 2309 parameters after the HMAC, as described in Section 6.4.1. The 2310 Responder MUST validate the HMAC. 2312 The signature is calculated over whole HIP envelope, excluding any 2313 parameters after the HIP_SIGNATURE, as described in Section 5.2.11. 2314 The Responder MUST validate this signature. It MAY use either the HI 2315 in the packet or the HI acquired by some other means. 2317 5.3.4. R2 - the Second HIP Responder Packet 2319 The HIP header values for the R2 packet: 2321 Header: 2322 Packet Type = 4 2323 SRC HIT = Responder's HIT 2324 DST HIT = Initiator's HIT 2326 IP ( HIP ( HMAC_2, HIP_SIGNATURE ) ) 2328 Valid control bits: none 2330 The HMAC_2 is calculated over whole HIP envelope, with Responder's 2331 HOST_ID parameter concatenated with the HIP envelope. The HOST_ID 2332 parameter is removed after the HMAC calculation. The procedure is 2333 described in 8.3.1. 2335 The signature is calculated over whole HIP envelope. 2337 The Initiator MUST validate both the HMAC and the signature. 2339 5.3.5. UPDATE - the HIP Update Packet 2341 Support for the UPDATE packet is MANDATORY. 2343 The HIP header values for the UPDATE packet: 2345 Header: 2346 Packet Type = 16 2347 SRC HIT = Sender's HIT 2348 DST HIT = Recipient's HIT 2350 IP ( HIP ( [SEQ, ACK, ] HMAC, HIP_SIGNATURE ) ) 2352 Valid control bits: None 2354 The UPDATE packet contains mandatory HMAC and HIP_SIGNATURE 2355 parameters, and other optional parameters. 2357 The UPDATE packet contains zero or one SEQ parameter. The presence 2358 of a SEQ parameter indicates that the receiver MUST ack the UPDATE. 2359 An UPDATE that does not contain a SEQ parameter is simply an ACK of a 2360 previous UPDATE and itself MUST not be acked. 2362 An UPDATE packet contains zero or one ACK parameters. The ACK 2363 parameter echoes the SEQ sequence number of the UPDATE packet being 2364 acked. A host MAY choose to ack more than one UPDATE packet at a 2365 time; e.g., the ACK may contain the last two SEQ values received, for 2366 robustness to ack loss. ACK values are not cumulative; each received 2367 unique SEQ value requires at least one corresponding ACK value in 2368 reply. Received ACKs that are redundant are ignored. 2370 The UPDATE packet may contain both a SEQ and an ACK parameter. In 2371 this case, the ACK is being piggybacked on an outgoing UPDATE. In 2372 general, UPDATEs carrying SEQ SHOULD be acked upon completion of the 2373 processing of the UPDATE. A host MAY choose to hold the UPDATE 2374 carrying ACK for a short period of time to allow for the possibility 2375 of piggybacking the ACK parameter, in a manner similar to TCP delayed 2376 acknowledgments. 2378 A sender MAY choose to forego reliable transmission of a particular 2379 UPDATE (e.g., it becomes overcome by events). The semantics are such 2380 that the receiver MUST acknowledge the UPDATE but the sender MAY 2381 choose to not care about receiving the ACK. 2383 UPDATEs MAY be retransmitted without incrementing SEQ. If the same 2384 subset of parameters is included in multiple UPDATEs with different 2385 SEQs, the host MUST ensure that receiver processing of the parameters 2386 multiple times will not result in a protocol error. 2388 5.3.6. NOTIFY - the HIP Notify Packet 2390 The NOTIFY packet is OPTIONAL. The NOTIFY packet MAY be used to 2391 provide information to a peer. Typically, NOTIFY is used to indicate 2392 some type of protocol error or negotiation failure. NOTIFY packets 2393 are unacknowledged. 2395 The HIP header values for the NOTIFY packet: 2397 Header: 2398 Packet Type = 17 2399 SRC HIT = Sender's HIT 2400 DST HIT = Recipient's HIT, or zero if unknown 2402 IP ( HIP (i, [HOST_ID, ] HIP_SIGNATURE) ) 2404 Valid control bits: None 2405 The NOTIFY packet is used to carry one or more NOTIFY parameters. 2407 5.3.7. CLOSE - the HIP Association Closing Packet 2409 The HIP header values for the CLOSE packet: 2411 Header: 2412 Packet Type = 18 2413 SRC HIT = Sender's HIT 2414 DST HIT = Recipient's HIT 2416 IP ( HIP ( ECHO_REQUEST, HMAC, HIP_SIGNATURE ) ) 2418 Valid control bits: none 2420 The sender MUST include an ECHO_REQUEST used to validate CLOSE_ACK 2421 received in response, and both an HMAC and a signature (calculated 2422 over the whole HIP envelope). 2424 The receiver peer MUST validate both the HMAC and the signature if it 2425 has a HIP association state, and MUST reply with a CLOSE_ACK 2426 containing an ECHO_REPLY corresponding to the received ECHO_REQUEST. 2428 5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet 2430 The HIP header values for the CLOSE_ACK packet: 2432 Header: 2433 Packet Type = 19 2434 SRC HIT = Sender's HIT 2435 DST HIT = Recipient's HIT 2437 IP ( HIP ( ECHO_REPLY, HMAC, HIP_SIGNATURE ) ) 2439 Valid control bits: none 2441 The sender MUST include both an HMAC and signature (calculated over 2442 the whole HIP envelope). 2444 The receiver peer MUST validate both the HMAC and the signature. 2446 5.4. ICMP Messages 2448 When a HIP implementation detects a problem with an incoming packet, 2449 and it either cannot determine the identity of the sender of the 2450 packet or does not have any existing HIP association with the sender 2451 of the packet, it MAY respond with an ICMP packet. Any such replies 2452 MUST be rate limited as described in [4]. In most cases, the ICMP 2453 packet will have the Parameter Problem type (12 for ICMPv4, 4 for 2454 ICMPv6), with the Pointer field pointing to the field that caused the 2455 ICMP message to be generated. 2457 5.4.1. Invalid Version 2459 If a HIP implementation receives a HIP packet that has an 2460 unrecognized HIP version number, it SHOULD respond, rate limited, 2461 with an ICMP packet with type Parameter Problem, the Pointer pointing 2462 to the VER./RES. byte in the HIP header. 2464 5.4.2. Other Problems with the HIP Header and Packet Structure 2466 If a HIP implementation receives a HIP packet that has other 2467 unrecoverable problems in the header or packet format, it MAY 2468 respond, rate limited, with an ICMP packet with type Parameter 2469 Problem, the Pointer pointing to the field that failed to pass the 2470 format checks. However, an implementation MUST NOT send an ICMP 2471 message if the Checksum fails; instead, it MUST silently drop the 2472 packet. 2474 5.4.3. Invalid Puzzle Solution 2476 If a HIP implementation receives an I2 packet that has an invalid 2477 puzzle solution, the behavior depends on the underlying version of 2478 IP. If IPv6 is used, the implementation SHOULD respond with an ICMP 2479 packet with type Parameter Problem, the Pointer pointing to the 2480 beginning of the Puzzle solution #J field in the SOLUTION payload in 2481 the HIP message. 2483 If IPv4 is used, the implementation MAY respond with an ICMP packet 2484 with the type Parameter Problem, copying enough of bytes from the I2 2485 message so that the SOLUTION parameter fits into the ICMP message, 2486 the Pointer pointing to the beginning of the Puzzle solution #J 2487 field, as in the IPv6 case. Note, however, that the resulting ICMPv4 2488 message exceeds the typical ICMPv4 message size as defined in [2]. 2490 5.4.4. Non-existing HIP Association 2492 If a HIP implementation receives a CLOSE, or UPDATE packet, or any 2493 other packet whose handling requires an existing association, that 2494 has either a Receiver or Sender HIT that does not match with any 2495 existing HIP association, the implementation MAY respond, rate 2496 limited, with an ICMP packet with the type Parameter Problem, the 2497 Pointer pointing to the beginning of the first HIT that does not 2498 match. 2500 A host MUST NOT reply with such an ICMP if it receives any of the 2501 following messages: I1, R2, I2, R2, and NOTIFY. When introducing new 2502 packet types, a specification SHOULD define the appropriate rules for 2503 sending or not sending this kind of ICMP replies. 2505 6. Packet Processing 2507 Each host is assumed to have a single HIP protocol implementation 2508 that manages the host's HIP associations and handles requests for new 2509 ones. Each HIP association is governed by a conceptual state 2510 machine, with states defined above in Section 4.4. The HIP 2511 implementation can simultaneously maintain HIP associations with more 2512 than one host. Furthermore, the HIP implementation may have more 2513 than one active HIP association with another host; in this case, HIP 2514 associations are distinguished by their respective HITs. It is not 2515 possible to have more than one HIP association between any given pair 2516 of HITs. Consequently, the only way for two hosts to have more than 2517 one parallel association is to use different HITs, at least at one 2518 end. 2520 The processing of packets depends on the state of the HIP 2521 association(s) with respect to the authenticated or apparent 2522 originator of the packet. A HIP implementation determines whether it 2523 has an active association with the originator of the packet based on 2524 the HITs. In the case of user data carried in a specific transport 2525 format, the transport format document specifies how the incoming 2526 packets are matched with the active associations. 2528 6.1. Processing Outgoing Application Data 2530 In a HIP host, an application can send application level data using 2531 an identifier specified via the underlying API. The API can be a 2532 backwards compatible API (see [28]), using identifiers that look 2533 similar to IP addresses, or a completely new API, providing enhanced 2534 services related to Host Identities. Depending on the HIP 2535 implementation, the identifier provided to the application may be 2536 different; it can be e.g. a HIT or an IP address. 2538 The exact format and method for transferring the data from the source 2539 HIP host to the destination HIP host is defined in the corresponding 2540 transport format document. The actual data is transferred in the 2541 network using the appropriate source and destination IP addresses. 2543 In this document, conceptual processing rules are defined only for 2544 the base case where both hosts have only single usable IP addresses; 2545 the multi-address multi-homing case will be specified separately. 2547 The following conceptual algorithm describes the steps that are 2548 required for handling outgoing datagrams destined to a HIT. 2550 1. If the datagram has a specified source address, it MUST be a HIT. 2551 If it is not, the implementation MAY replace the source address 2552 with a HIT. Otherwise it MUST drop the packet. 2554 2. If the datagram has an unspecified source address, the 2555 implementation must choose a suitable source HIT for the 2556 datagram. 2558 3. If there is no active HIP association with the given < source, 2559 destination > HIT pair, one must be created by running the base 2560 exchange. While waiting for the base exchange to complete, the 2561 implementation SHOULD queue at least one packet per HIP 2562 association to be formed, and it MAY queue more than one. 2564 4. Once there is an active HIP association for the given < source, 2565 destination > HIT pair, the outgoing datagram is passed to 2566 transport handling. The possible transport formats are defined 2567 in separate documents, of which the ESP transport format for HIP 2568 is mandatory for all HIP implementations. 2570 5. Before sending the packet, the HITs in the datagram are replaced 2571 with suitable IP addresses. For IPv6, the rules defined in [16] 2572 SHOULD be followed. Note that this HIT-to-IP-address conversion 2573 step MAY also be performed at some other point in the stack, 2574 e.g., before wrapping the packet into the output format. 2576 6.2. Processing Incoming Application Data 2578 The following conceptual algorithm describes the incoming datagram 2579 handling when HITs are used at the receiving host as application 2580 level identifiers. More detailed steps for processing packets are 2581 defined in corresponding transport format documents. 2583 1. The incoming datagram is mapped to an existing HIP association, 2584 typically using some information from the packet. For example, 2585 such mapping may be based on ESP Security Parameter Index (SPI). 2587 2. The specific transport format is unwrapped, in a way depending on 2588 the transport format, yielding a packet that looks like a 2589 standard (unencrypted) IP packet. If possible, this step SHOULD 2590 also verify that the packet was indeed (once) sent by the remote 2591 HIP host, as identified by the HIP association. 2593 3. The IP addresses in the datagram are replaced with the HITs 2594 associated with the HIP association. Note that this IP-address- 2595 to-HIT conversion step MAY also be performed at some other point 2596 in the stack. 2598 4. The datagram is delivered to the upper layer. Demultiplexing the 2599 datagram the right upper layer socket is based on the HITs. 2601 6.3. Solving the Puzzle 2603 This subsection describes the puzzle solving details. 2605 In R1, the values I and K are sent in network byte order. Similarly, 2606 in I2 the values I and J are sent in network byte order. The SHA-1 2607 hash is created by concatenating, in network byte order, the 2608 following data, in the following order: 2610 64-bit random value I, in network byte order, as appearing in R1 2611 and I2. 2613 128-bit Initiator HIT, in network byte order, as appearing in the 2614 HIP Payload in R1 and I2. 2616 128-bit Responder HIT, in network byte order, as appearing in the 2617 HIP Payload in R1 and I2. 2619 64-bit random value J, in network byte order, as appearing in I2. 2621 In order to be a valid response puzzle, the K low-order bits of the 2622 resulting PHASH digest must be zero. 2624 Notes: 2626 i) The length of the data to be hashed is 48 bytes. 2628 ii) All the data in the hash input MUST be in network byte order. 2630 iii) The order of the Initiator and Responder HITs are different 2631 in the R1 and I2 packets, see Section 5.1. Care must be taken to 2632 copy the values in right order to the hash input. 2634 The following procedure describes the processing steps involved, 2635 assuming that the Responder chooses to precompute the R1 packets: 2637 Precomputation by the Responder: 2638 Sets up the puzzle difficulty K. 2639 Creates a signed R1 and caches it. 2641 Responder: 2642 Selects a suitable cached R1. 2643 Generates a random number I. 2644 Sends I and K in an R1. 2645 Saves I and K for a Delta time. 2647 Initiator: 2648 Generates repeated attempts to solve the puzzle until a matching J 2649 is found: 2650 Ltrunc( PHASH( I | HIT-I | HIT-R | J ), K ) == 0 2651 Sends I and J in an I2. 2653 Responder: 2654 Verifies that the received I is a saved one. 2655 Finds the right K based on I. 2656 Computes V := Ltrunc( PHASH( I | HIT-I | HIT-R | J ), K ) 2657 Rejects if V != 0 2658 Accept if V == 0 2660 6.4. HMAC and SIGNATURE Calculation and Verification 2662 The following subsections define the actions for processing HMAC, 2663 HIP_SIGNATURE and HIP_SIGNATURE_2 parameters. 2665 6.4.1. HMAC Calculation 2667 The following process applies both to the HMAC and HMAC_2 parameters. 2668 When processing HMAC_2, the difference is that the HMAC calculation 2669 includes a pseudo HOST_ID field containing the Responder's 2670 information as sent in the R1 packet earlier. 2672 Both the Initiator and the Responder should take some care when 2673 verifying or calculating the HMAC_2. Specifically, the Responder 2674 should preserve other parameters than the HOST_ID when sending the 2675 R2. Also, the Initiator has to preserve the HOST_ID exactly as it 2676 was received in the R1 packet. 2678 The HMAC parameter is defined in Section 5.2.9 and HMAC_2 parameter 2679 in Section 5.2.10. HMAC calculation and verification process: 2681 Packet sender: 2683 1. Create the HIP packet, without the HMAC or any possible 2684 HIP_SIGNATURE or HIP_SIGNATURE_2 parameters. 2686 2. In case of HMAC_2 calculation, add a HOST_ID (Responder) 2687 parameter to the packet. 2689 3. Calculate the Length field in the HIP header. 2691 4. Compute the HMAC. 2693 5. In case of HMAC_2, remove the HOST_ID parameter from the packet. 2695 6. Add the HMAC parameter to the packet and any HIP_SIGNATURE or 2696 HIP_SIGNATURE_2 parameters that may follow. 2698 7. Recalculate the Length field in the HIP header. 2700 Packet receiver: 2702 1. Verify the HIP header Length field. 2704 2. Remove the HMAC or HMAC_2 parameter, and if the packet contains 2705 any HIP_SIGNATURE or HIP_SIGNATURE_2 fields, remove them too, 2706 saving the contents if they will be needed later. 2708 3. In case of HMAC_2, build and add a HOST_ID parameter (with 2709 Responder information) to the packet. The HOST_ID parameter 2710 should be identical to the one previously received from the 2711 Responder. 2713 4. Recalculate the HIP packet length in the HIP header and clear the 2714 Checksum field (set it to all zeros). 2716 5. Compute the HMAC and verify it against the received HMAC. 2718 6. In case of HMAC_2, remove the HOST_ID parameter from the packet 2719 before further processing. 2721 6.4.2. Signature Calculation 2723 The following process applies both to the HIP_SIGNATURE and 2724 HIP_SIGNATURE_2 parameters. When processing HIP_SIGNATURE_2, the 2725 only difference is that instead of HIP_SIGNATURE parameter, the 2726 HIP_SIGNATURE_2 parameter is used, and the Initiator's HIT and PUZZLE 2727 Opaque and Random #I fields are cleared (set to all zeros) before 2728 computing the signature. The HIP_SIGNATURE parameter is defined in 2729 Section 5.2.11 and the HIP_SIGNATURE_2 parameter in Section 5.2.12. 2731 Signature calculation and verification process: 2733 Packet sender: 2735 1. Create the HIP packet without the HIP_SIGNATURE parameter or any 2736 parameters that follow the HIP_SIGNATURE parameter. 2738 2. Calculate the Length field and zero the Checksum field in the HIP 2739 header. 2741 3. Compute the signature. 2743 4. Add the HIP_SIGNATURE parameter to the packet. 2745 5. Add any parameters that follow the HIP_SIGNATURE parameter. 2747 6. Recalculate the Length field in the HIP header, and calculate the 2748 Checksum field. 2750 Packet receiver: 2752 1. Verify the HIP header Length field. 2754 2. Save the contents of the HIP_SIGNATURE parameter and any 2755 parameters following the HIP_SIGNATURE parameter and remove them 2756 from the packet. 2758 3. Recalculate the HIP packet Length in the HIP header and clear the 2759 Checksum field (set it to all zeros). 2761 4. Compute the signature and verify it against the received 2762 signature. 2764 The verification can use either the HI received from a HIP packet, 2765 the HI from a DNS query, if the FQDN has been received in the HOST_ID 2766 packet, or one received by some other means. 2768 6.5. HIP KEYMAT Generation 2770 HIP keying material is derived from the Diffie-Hellman Kij produced 2771 during the HIP base exchange. The Initiator has Kij during the 2772 creation of the I2 packet, and the Responder has Kij once it receives 2773 the I2 packet. This is why I2 can already contain encrypted 2774 information. 2776 The KEYMAT is derived by feeding Kij and the HITs into the following 2777 operation; the | operation denotes concatenation. 2779 KEYMAT = K1 | K2 | K3 | ... 2780 where 2782 K1 = SHA-1( Kij | sort(HIT-I | HIT-R) | I | J | 0x01 ) 2783 K2 = SHA-1( Kij | K1 | 0x02 ) 2784 K3 = SHA-1( Kij | K2 | 0x03 ) 2785 ... 2786 K255 = SHA-1( Kij | K254 | 0xff ) 2787 K256 = SHA-1( Kij | K255 | 0x00 ) 2788 etc. 2790 Sort(HIT-I | HIT-R) is defined as the network byte order 2791 concatenation of the two HITs, with the smaller HIT preceding the 2792 larger HIT, resulting from the numeric comparison of the two HITs 2793 interpreted as positive (unsigned) 128-bit integers in network byte 2794 order. 2796 I and J values are from the puzzle and its solution that were 2797 exchanged in R1 and I2 messages when this HIP association was set up. 2798 Both hosts have to store I and J values for the HIP association for 2799 future use. 2801 The initial keys are drawn sequentially in the order that is 2802 determined by the numeric comparison of the two HITs, with comparison 2803 method described in the previous paragraph. HOST_g denotes the host 2804 with the greater HIT value, and HOST_l the host with the lower HIT 2805 value. 2807 The drawing order for initial keys: 2809 HIP-gl encryption key for HOST_g's outgoing HIP packets 2811 HIP-gl integrity (HMAC) key for HOST_g's outgoing HIP packets 2813 HIP-lg encryption key (currently unused) for HOST_l's outgoing HIP 2814 packets 2816 HIP-lg integrity (HMAC) key for HOST_l's outgoing HIP packets 2818 The number of bits drawn for a given algorithm is the "natural" size 2819 of the keys. For the mandatory algorithms, the following sizes 2820 apply: 2822 AES 128 bits 2824 SHA-1 160 bits 2826 NULL 0 bits 2828 6.6. Initiation of a HIP Exchange 2830 An implementation may originate a HIP exchange to another host based 2831 on a local policy decision, usually triggered by an application 2832 datagram, in much the same way that an IPsec IKE key exchange can 2833 dynamically create a Security Association. Alternatively, a system 2834 may initiate a HIP exchange if it has rebooted or timed out, or 2835 otherwise lost its HIP state, as described in Section 4.5.4. 2837 The implementation prepares an I1 packet and sends it to the IP 2838 address that corresponds to the peer host. The IP address of the 2839 peer host may be obtained via conventional mechanisms, such as DNS 2840 lookup. The I1 contents are specified in Section 5.3.1. The 2841 selection of which host identity to use, if a host has more than one 2842 to choose from, is typically a policy decision. 2844 The following steps define the conceptual processing rules for 2845 initiating a HIP exchange: 2847 1. The Initiator gets the Responder's HIT and one or more addresses 2848 either from a DNS lookup of the Responder's FQDN, from some other 2849 repository, or from a local table. If the Initiator does not 2850 know the Responder's HIT, it may attempt opportunistic mode by 2851 using NULL (all zeros) as the Responder's HIT. 2853 2. The Initiator sends an I1 to one of the Responder's addresses. 2854 The selection of which address to use is a local policy decision. 2856 3. Upon sending an I1, the sender shall transition to state I1-SENT, 2857 start a timer whose timeout value should be larger than the 2858 worst-case anticipated RTT, and shall increment a timeout counter 2859 associated with the I1. 2861 4. Upon timeout, the sender SHOULD retransmit the I1 and restart the 2862 timer, up to a maximum of I1_RETRIES_MAX tries. 2864 6.6.1. Sending Multiple I1s in Parallel 2866 For the sake of minimizing the session establishment latency, an 2867 implementation MAY send the same I1 to more than one of the 2868 Responder's addresses. However, it MUST NOT send to more than three 2869 (3) addresses in parallel. Furthermore, upon timeout, the 2870 implementation MUST refrain from sending the same I1 packet to 2871 multiple addresses. These limitations are placed order to avoid 2872 congestion of the network, and potential DoS attacks that might 2873 happen, e.g., because someone claims to have hundreds or thousands of 2874 addresses. 2876 As the Responder is not guaranteed to distinguish the duplicate I1's 2877 it receives at several of its addresses (because it avoids to store 2878 states when it answers back an R1), the Initiator may receive several 2879 duplicate R1's. 2881 The Initiator SHOULD then select the initial preferred destination 2882 address using the source address of the selected received R1, and use 2883 the preferred address as a source address for the I2. Processing 2884 rules for received R1s are discussed in Section 6.8. 2886 6.6.2. Processing Incoming ICMP Protocol Unreachable Messages 2888 A host may receive an ICMP Destination Protocol Unreachable message 2889 as a response to sending an HIP I1 packet. Such a packet may be an 2890 indication that the peer does not support HIP, or it may be an 2891 attempt to launch an attack by making the Initiator believe that the 2892 Responder does not support HIP. 2894 When a system receives an ICMP Destination Protocol Unreachable 2895 message while it is waiting for an R1, it MUST NOT terminate the 2896 wait. It MAY continue as if it had not received the ICMP message, 2897 and send a few more I1s. Alternatively, it MAY take the ICMP message 2898 as a hint that the peer most probably does not support HIP, and 2899 return to state UNASSOCIATED earlier than otherwise. However, at 2900 minimum, it MUST continue waiting for an R1 for a reasonable time 2901 before returning to UNASSOCIATED. 2903 6.7. Processing Incoming I1 Packets 2905 An implementation SHOULD reply to an I1 with an R1 packet, unless the 2906 implementation is unable or unwilling to setup a HIP association. If 2907 the implementation is unable to setup a HIP association, the host 2908 SHOULD send an ICMP Destination Protocol Unreachable, 2909 Administratively Prohibited, message to the I1 source address. If 2910 the implementation is unwilling to setup a HIP association, the host 2911 MAY ignore the I1. This latter case may occur during a DoS attack 2912 such as an I1 flood. 2914 The implementation MUST be able to handle a storm of received I1 2915 packets, discarding those with common content that arrive within a 2916 small time delta. 2918 A spoofed I1 can result in an R1 attack on a system. An R1 sender 2919 MUST have a mechanism to rate limit R1s to an address. 2921 It is RECOMMENDED that the HIP state machine does not transition upon 2922 sending an R1. 2924 The following steps define the conceptual processing rules for 2925 responding to an I1 packet: 2927 1. The Responder MUST check that the Responder HIT in the received 2928 I1 is either one of its own HITs, or NULL. 2930 2. If the Responder is in ESTABLISHED state, the Responder MAY 2931 respond to this with an R1 packet, prepare to drop existing SAs 2932 and stay at ESTABLISHED state. 2934 3. If the Responder is in I1-SENT state, it must make a comparison 2935 between the sender's HIT and its own HIT. If the sender's HIT is 2936 greater than its own HIT, it should drop the I1 and stay at I1- 2937 SENT. If the sender's HIT is smaller than its own HIT, it should 2938 send R1 and stay at I1-SENT. The HIT comparison goes similarly 2939 as in Section 6.5. 2941 4. If the implementation chooses to respond to the I1 with an R1 2942 packet, it creates a new R1 or selects a precomputed R1 according 2943 to the format described in Section 5.3.2. 2945 5. The R1 MUST contain the received Responder HIT, unless the 2946 received HIT is NULL, in which case the Responder SHOULD select a 2947 HIT that is constructed with the MUST algorithm in Section 3, 2948 which is currently RSA. Other than that, selecting the HIT is a 2949 local policy matter. 2951 6. The Responder sends the R1 to the source IP address of the I1 2952 packet. 2954 6.7.1. R1 Management 2956 All compliant implementations MUST produce R1 packets. An R1 packet 2957 MAY be precomputed. An R1 packet MAY be reused for time Delta T, 2958 which is implementation dependent. R1 information MUST not be 2959 discarded until Delta S after T. Time S is the delay needed for the 2960 last I2 to arrive back to the Responder. 2962 An implementation MAY keep state about received I1s and match the 2963 received I2s against the state, as discussed in Section 4.1.1. 2965 6.7.2. Handling Malformed Messages 2967 If an implementation receives a malformed I1 message, it SHOULD NOT 2968 respond with a NOTIFY message, as such practice could open up a 2969 potential denial-of-service danger. Instead, it MAY respond with an 2970 ICMP packet, as defined in Section 5.4. 2972 6.8. Processing Incoming R1 Packets 2974 A system receiving an R1 MUST first check to see if it has sent an I1 2975 to the originator of the R1 (i.e., it is in state I1-SENT). If so, 2976 it SHOULD process the R1 as described below, send an I2, and go to 2977 state I2-SENT, setting a timer to protect the I2. If the system is 2978 in state I2-SENT, it MAY respond to an R1 if the R1 has a larger R1 2979 generation counter; if so, it should drop its state due to processing 2980 the previous R1 and start over from state I1-SENT. If the system is 2981 in any other state with respect to that host, it SHOULD silently drop 2982 the R1. 2984 When sending multiple I1s, an Initiator SHOULD wait for a small 2985 amount of time after the first R1 reception to allow possibly 2986 multiple R1s to arrive, and it SHOULD respond to an R1 among the set 2987 with the largest R1 generation counter. 2989 The following steps define the conceptual processing rules for 2990 responding to an R1 packet: 2992 1. A system receiving an R1 MUST first check to see if it has sent 2993 an I1 to the originator of the R1 (i.e., it has a HIP 2994 association that is in state I1-SENT and that is associated with 2995 the HITs in the R1. IP addresses in the received R1 packet 2996 SHOULD be ignored and the match SHOULD be based on HITs only). 2997 If so, it should process the R1 as described below. Note that 2998 when the connection was initialized in opportunistic mode, HITs 2999 cannot be used, but the Initiator must rely on the Responder's 3000 IP address in the received R1 packet. 3002 2. Otherwise, if the system is in any other state than I1-SENT or 3003 I2-SENT with respect to the HITs included in the R1, it SHOULD 3004 silently drop the R1 and remain in the current state. 3006 3. If the HIP association state is I1-SENT or I2-SENT, the received 3007 Initiator's HIT MUST correspond to the HIT used in the original, 3008 I1 and the Responder's HIT MUST correspond to the one used, 3009 unless the I1 contained a NULL HIT. 3011 4. The system SHOULD validate the R1 signature before applying 3012 further packet processing, according to Section 5.2.12. 3014 5. If the HIP association state is I1-SENT, and multiple valid R1s 3015 are present, the system SHOULD select from among the R1s with 3016 the largest R1 generation counter. 3018 6. If the HIP association state is I2-SENT, the system MAY reenter 3019 state I1-SENT and process the received R1 if it has a larger R1 3020 generation counter than the R1 responded to previously. 3022 7. The R1 packet may have the A bit set -- in this case, the system 3023 MAY choose to refuse it by dropping the R1 and returning to 3024 state UNASSOCIATED. The system SHOULD consider dropping the R1 3025 only if it used a NULL HIT in I1. If the A bit is set, the 3026 Responder's HIT is anonymous and should not be stored. 3028 8. The system SHOULD attempt to validate the HIT against the 3029 received Host Identity. 3031 9. The system MUST store the received R1 generation counter for 3032 future reference. 3034 10. The system attempts to solve the puzzle in R1. The system MUST 3035 terminate the search after exceeding the remaining lifetime of 3036 the puzzle. If the puzzle is not successfully solved, the 3037 implementation may either resend I1 within the retry bounds or 3038 abandon the HIP exchange. 3040 11. The system computes standard Diffie-Hellman keying material 3041 according to the public value and Group ID provided in the 3042 DIFFIE_HELLMAN parameter. The Diffie-Hellman keying material 3043 Kij is used for key extraction as specified in Section 6.5. If 3044 the received Diffie-Hellman Group ID is not supported, the 3045 implementation may either resend I1 within the retry bounds or 3046 abandon the HIP exchange. 3048 12. The system selects the HIP transform from the choices presented 3049 in the R1 packet and uses the selected values subsequently when 3050 generating and using encryption keys, and when sending the I2. 3051 If the proposed alternatives are not acceptable to the system, 3052 it may either resend I1 within the retry bounds or abandon the 3053 HIP exchange. 3055 13. The system initializes the remaining variables in the associated 3056 state, including Update ID counters. 3058 14. The system prepares and sends an I2, as described in 3059 Section 5.3.3. 3061 15. The system SHOULD start a timer whose timeout value should be 3062 larger than the worst-case anticipated RTT, and MUST increment a 3063 timeout counter associated with the I2. The sender SHOULD 3064 retransmit the I2 upon a timeout and restart the timer, up to a 3065 maximum of I2_RETRIES_MAX tries. 3067 16. If the system is in state I1-SENT, it shall transition to state 3068 I2-SENT. If the system is in any other state, it remains in the 3069 current state. 3071 6.8.1. Handling Malformed Messages 3073 If an implementation receives a malformed R1 message, it MUST 3074 silently drop the packet. Sending a NOTIFY or ICMP would not help, 3075 as the sender of the R1 typically doesn't have any state. An 3076 implementation SHOULD wait for some more time for a possible good R1, 3077 after which it MAY try again by sending a new I1 packet. 3079 6.9. Processing Incoming I2 Packets 3081 Upon receipt of an I2, the system MAY perform initial checks to 3082 determine whether the I2 corresponds to a recent R1 that has been 3083 sent out, if the Responder keeps such state. For example, the sender 3084 could check whether the I2 is from an address or HIT that has 3085 recently received an R1 from it. The R1 may have had Opaque data 3086 included that was echoed back in the I2. If the I2 is considered to 3087 be suspect, it MAY be silently discarded by the system. 3089 Otherwise, the HIP implementation SHOULD process the I2. This 3090 includes validation of the puzzle solution, generating the Diffie- 3091 Hellman key, decrypting the Initiator's Host Identity, verifying the 3092 signature, creating state, and finally sending an R2. 3094 The following steps define the conceptual processing rules for 3095 responding to an I2 packet: 3097 1. The system MAY perform checks to verify that the I2 corresponds 3098 to a recently sent R1. Such checks are implementation 3099 dependent. See Appendix A for a description of an example 3100 implementation. 3102 2. The system MUST check that the Responder's HIT corresponds to 3103 one of its own HITs. 3105 3. If the system is in the R2-SENT state, it MAY check if the newly 3106 received I2 is similar to the one that triggered moving to R2- 3107 SENT. If so, it MAY retransmit a previously sent R2, reset the 3108 R2-SENT timer, and stay in R2-SENT. 3110 4. If the system is in the I2-SENT state, it makes a comparison 3111 between its local and sender's HITs (similarly as in 3112 Section 6.5). If the local HIT is smaller than the sender's 3113 HIT, it should drop the I2 packet. Otherwise, the system should 3114 process the received I2 packet. 3116 5. To avoid the possibility to end up with different session keys 3117 due to symmetric operation of the peer nodes, the Diffie-Hellman 3118 key, I, and J selection is also based on the HIT comparison. If 3119 the local HIT is smaller than the peer HIT, the system uses peer 3120 Diffie-Hellman key and nonce I from the R1 packet received 3121 earlier. The local Diffie-Hellman key and nonce J are taken 3122 from the I2 packet sent to the peer earlier. Otherwise, it uses 3123 peer Diffie-Hellman key and nonce J from the just arrived I2. 3124 The local Diffie-Hellman key and nonce I are the ones that it 3125 sent ealier in the R1 packet. 3127 6. If the system is in any other state than R2-SENT, it SHOULD 3128 check that the echoed R1 generation counter in I2 is within the 3129 acceptable range. Implementations MUST accept puzzles from the 3130 current generation and MAY accept puzzles from earlier 3131 generations. If the newly received I2 is outside the accepted 3132 range, the I2 is stale (perhaps replayed) and SHOULD be dropped. 3134 7. The system MUST validate the solution to the puzzle by computing 3135 the hash described in Section 5.3.3 using the same hash 3136 algorithm used to generate the Responder's HIT. 3138 8. The I2 MUST have a single value in the HIP_TRANSFORM parameter, 3139 which MUST match one of the values offered to the Initiator in 3140 the R1 packet. 3142 9. The system must derive Diffie-Hellman keying material Kij based 3143 on the public value and Group ID in the DIFFIE_HELLMAN 3144 parameter. This key is used to derive the HIP association keys, 3145 as described in Section 6.5. If the Diffie-Hellman Group ID is 3146 unsupported, the I2 packet is silently dropped. 3148 10. The encrypted HOST_ID decrypted by the Initiator encryption key 3149 defined in Section 6.5. If the decrypted data is not a HOST_ID 3150 parameter, the I2 packet is silently dropped. 3152 11. The implementation SHOULD also verify that the Initiator's HIT 3153 in the I2 corresponds to the Host Identity sent in the I2. 3155 12. The system MUST verify the HMAC according to the procedures in 3156 Section 5.2.9. 3158 13. The system MUST verify the HIP_SIGNATURE according to 3159 Section 5.2.11 and Section 5.3.3. 3161 14. If the checks above are valid, then the system proceeds with 3162 further I2 processing; otherwise, it discards the I2 and remains 3163 in the same state. 3165 15. The I2 packet may have the A bit set -- in this case, the system 3166 MAY choose to refuse it by dropping the I2 and returning to 3167 state UNASSOCIATED. If the A bit is set, the Initiator's HIT is 3168 anonymous and should not be stored. 3170 16. The system initializes the remaining variables in the associated 3171 state, including Update ID counters. 3173 17. Upon successful processing of an I2 in states UNASSOCIATED, I1- 3174 SENT, I2-SENT, and R2-SENT, an R2 is sent and the state machine 3175 transitions to state R2-SENT. 3177 18. Upon successful processing of an I2 in state ESTABLISHED, the 3178 old HIP association is dropped and a new one is installed, an R2 3179 is sent, and the state machine transitions to R2-SENT. 3181 19. Upon transitioning to R2-SENT, start a timer. Move to 3182 ESTABLISHED if some data has been received on the incoming HIP 3183 association, or an UPDATE packet has been received (or some 3184 other packet that indicates that the peer has moved to 3185 ESTABLISHED). If the timer expires (allowing for maximal 3186 retransmissions of I2s), move to UNASSOCIATED. 3188 6.9.1. Handling Malformed Messages 3190 If an implementation receives a malformed I2 message, the behavior 3191 SHOULD depend on how much checks the message has already passed. If 3192 the puzzle solution in the message has already been checked, the 3193 implementation SHOULD report the error by responding with a NOTIFY 3194 packet. Otherwise the implementation MAY respond with an ICMP 3195 message as defined in Section 5.4. 3197 6.10. Processing Incoming R2 Packets 3199 An R2 received in states UNASSOCIATED, I1-SENT, or ESTABLISHED 3200 results in the R2 being dropped and the state machine staying in the 3201 same state. If an R2 is received in state I2-SENT, it SHOULD be 3202 processed. 3204 The following steps define the conceptual processing rules for 3205 incoming R2 packet: 3207 1. The system MUST verify that the HITs in use correspond to the 3208 HITs that were received in R1. 3210 2. The system MUST verify the HMAC_2 according to the procedures in 3211 Section 5.2.10. 3213 3. The system MUST verify the HIP signature according to the 3214 procedures in Section 5.2.11. 3216 4. If any of the checks above fail, there is a high probability of 3217 an ongoing man-in-the-middle or other security attack. The 3218 system SHOULD act accordingly, based on its local policy. 3220 5. If the system is in any other state than I2-SENT, the R2 is 3221 silently dropped. 3223 6. Upon successful processing of the R2, the state machine moves to 3224 state ESTABLISHED. 3226 6.11. Sending UPDATE Packets 3228 A host sends an UPDATE packet when it wants to update some 3229 information related to a HIP association. There are a number of 3230 likely situations, e.g. mobility management and rekeying of an 3231 existing ESP Security Association. The following paragraphs define 3232 the conceptual rules for sending an UPDATE packet to the peer. 3233 Additional steps can be defined in other documents where the UPDATE 3234 packet is used. 3236 The system first determines whether there are any outstanding UPDATE 3237 messages that may conflict with the new UPDATE message under 3238 consideration. When multiple UPDATEs are outstanding (not yet 3239 acknowledged), the sender must assume that such UPDATEs may be 3240 processed in an arbitrary order. Therefore, any new UPDATEs that 3241 depend on a previous outstanding UPDATE being successfully received 3242 and acknowledged MUST be postponed until reception of the necessary 3243 ACK(s) occurs. One way to prevent any conflicts is to only allow one 3244 outstanding UPDATE at a time, but allowing multiple UPDATEs may 3245 improve the performance of mobility and multihoming protocols. 3247 1. The first UPDATE packet is sent with Update ID of zero. 3248 Otherwise, the system increments its own Update ID value by one 3249 before continuing the below steps. 3251 2. The system creates an UPDATE packet that contains a SEQ parameter 3252 with the current value of Update ID. The UPDATE packet may also 3253 include an ACK of the peer's Update ID found in a received UPDATE 3254 SEQ parameter, if any. 3256 3. The system sends the created UPDATE packet and starts an UPDATE 3257 timer. The default value for the timer is 2 * RTT estimate. If 3258 multiple UPDATEs are outstanding, multiple timers are in effect. 3260 4. If the UPDATE timer expires, the UPDATE is resent. The UPDATE 3261 can be resent UPDATE_RETRY_MAX times. The UPDATE timer SHOULD be 3262 exponentially backed off for subsequent retransmissions. If no 3263 acknowledgment is received from the peer after UPDATE_RETRY_MAX 3264 times, the HIP association is considered to be broken and the 3265 state machine should move from state ESTABLISHED to state CLOSING 3266 as depicted in Section 4.4.3. The UPDATE timer is cancelled upon 3267 receiving an ACK from the peer that acknowledges receipt of the 3268 UPDATE. 3270 6.12. Receiving UPDATE Packets 3272 When a system receives an UPDATE packet, its processing depends on 3273 the state of the HIP association and the presence of and values of 3274 the SEQ and ACK parameters. Typically, an UPDATE message also 3275 carries optional parameters whose handling is defined in separate 3276 documents. 3278 For each association, the peer's next expected in-sequence Update ID 3279 ("peer Update ID") is stored. Initially, this value is zero. Update 3280 ID comparisons of "less than" and "greater than" are performed with 3281 respect to a circular sequence number space. 3283 The sender may send multiple outstanding UPDATE messages. These 3284 messages are processed in the order in which they are received at the 3285 receiver (i.e., no resequencing is performed). When processing 3286 UPDATEs out-of-order, the receiver MUST keep track of which UPDATEs 3287 were previously processed, so that duplicates or retransmissions are 3288 ACKed and not reprocessed. A receiver MAY choose to define a receive 3289 window of Update IDs that it is willing to process at any given time, 3290 and discard received UPDATEs falling outside of that window. 3292 1. If there is no corresponding HIP association, the implementation 3293 MAY reply with an ICMP Parameter Problem, as specified in 3294 Section 5.4.4. 3296 2. If the association is in the ESTABLISHED state and the SEQ (but 3297 not ACK) parameter is present, the UPDATE is processed and 3298 replied as described in Section 6.12.1. 3300 3. If the association is in the ESTABLISHED state and the ACK (but 3301 not SEQ) parameter is present, the UPDATE is processed as 3302 described in Section 6.12.2. 3304 4. If the association is in the ESTABLISHED state and there is both 3305 an ACK and SEQ in the UPDATE, the ACK is first processed as 3306 described in Section 6.12.2 and then the rest of the UPDATE is 3307 processed as described in Section 6.12.1. 3309 6.12.1. Handling a SEQ parameter in a received UPDATE message 3311 1. If the Update ID in the received SEQ is not the next in sequence 3312 Update ID and is greater than the receiver's window for new 3313 UPDATEs, the packet MUST be dropped. 3315 2. If the Update ID in the received SEQ corresponds to an UPDATE 3316 that has recently been processed, the packet is treated as a 3317 retransmission. The HMAC verification (next step) MUST NOT be 3318 skipped. (A byte-by-byte comparison of the received and a stored 3319 packet would be OK, though.) It is recommended that a host cache 3320 UPDATE packets sent with ACKs to avoid the cost of generating a 3321 new ACK packet to respond to a replayed UPDATE. The system MUST 3322 acknowledge, again, such (apparent) UPDATE message 3323 retransmissions but SHOULD also consider rate-limiting such 3324 retransmission responses to guard against replay attacks. 3326 3. The system MUST verify the HMAC in the UPDATE packet. If the 3327 verification fails, the packet MUST be dropped. 3329 4. The system MAY verify the SIGNATURE in the UPDATE packet. If the 3330 verification fails, the packet SHOULD be dropped and an error 3331 message logged. 3333 5. If a new SEQ parameter is being processed, the parameters in the 3334 UPDATE are then processed. The system MUST record the Update ID 3335 in the received SEQ parameter, for replay protection. 3337 6. An UPDATE acknowledgement packet with ACK parameter is prepared 3338 and sent to the peer. This ACK parameter may be included in a 3339 separate UPDATE or piggybacked in an UPDATE with SEQ parameter, 3340 as described in Section Section 5.3.5. The ACK parameter MAY 3341 acknowledge more than one of the peer's Update IDs. 3343 6.12.2. Handling an ACK Parameter in a Received UPDATE Packet 3345 1. The sequence number reported in the ACK must match with an 3346 earlier sent UPDATE packet that has not already been 3347 acknowledged. If no match is found or if the ACK does not 3348 acknowledge a new UPDATE, the packet MUST either be dropped if no 3349 SEQ parameter is present, or the processing steps in 3350 Section 6.12.1 are followed. 3352 2. The system MUST verify the HMAC in the UPDATE packet. If the 3353 verification fails, the packet MUST be dropped. 3355 3. The system MAY verify the SIGNATURE in the UPDATE packet. If the 3356 verification fails, the packet SHOULD be dropped and an error 3357 message logged. 3359 4. The corresponding UPDATE timer is stopped (see Section 6.11) so 3360 that the now acknowledged UPDATE is no longer retransmitted. If 3361 multiple UPDATEs are newly acknowledged, multiple timers are 3362 stopped. 3364 6.13. Processing NOTIFY Packets 3366 Processing NOTIFY packets is OPTIONAL. If processed, any errors 3367 noted by the NOTIFY parameter SHOULD be taken into account by the HIP 3368 state machine (e.g., by terminating a HIP handshake), and the error 3369 SHOULD be logged. 3371 6.14. Processing CLOSE Packets 3373 When the host receives a CLOSE message it responds with a CLOSE_ACK 3374 message and moves to CLOSED state. (The authenticity of the CLOSE 3375 message is verified using both HMAC and SIGNATURE). This processing 3376 applies whether or not the HIP association state is CLOSING in order 3377 to handle CLOSE messages from both ends crossing in flight. 3379 The HIP association is not discarded before the host moves from the 3380 UNASSOCIATED state. 3382 Once the closing process has started, any need to send data packets 3383 will trigger creating and establishing of a new HIP association, 3384 starting with sending an I1. 3386 If there is no corresponding HIP association, the CLOSE packet is 3387 dropped. 3389 6.15. Processing CLOSE_ACK Packets 3391 When a host receives a CLOSE_ACK message it verifies that it is in 3392 CLOSING or CLOSED state and that the CLOSE_ACK was in response to the 3393 CLOSE (using the included ECHO_REPLY in response to the sent 3394 ECHO_REQUEST). 3396 The CLOSE_ACK uses HMAC and SIGNATURE for verification. The state is 3397 discarded when the state changes to UNASSOCIATED and, after that, the 3398 host MAY respond with an ICMP Parameter Problem to an incoming CLOSE 3399 message (See Section 5.4.4). 3401 6.16. Dropping HIP Associations 3403 A HIP implementation is free to drop a HIP association at any time, 3404 based on its own policy. If a HIP host decides to drop a HIP 3405 association, it deletes the corresponding HIP state, including the 3406 keying material. The implementation MUST also drop the peer's R1 3407 generation counter value, unless a local policy explicitly defines 3408 that the value of that particular host is stored. An implementation 3409 MUST NOT store R1 generation counters by default, but storing R1 3410 generation counter values, if done, MUST be configured by explicit 3411 HITs. 3413 7. HIP Policies 3415 There are a number of variables that will influence the HIP exchanges 3416 that each host must support. All HIP implementations MUST support 3417 more than one simultaneous HIs, at least one of which SHOULD be 3418 reserved for anonymous usage. Although anonymous HIs will be rarely 3419 used as Responder HIs, they will be common for Initiators. Support 3420 for more than two HIs is RECOMMENDED. 3422 Many Initiators would want to use a different HI for different 3423 Responders. The implementations SHOULD provide for an ACL of 3424 Initiator HIT to Responder HIT. This ACL SHOULD also include 3425 preferred transform and local lifetimes. 3427 The value of K used in the HIP R1 packet can also vary by policy. K 3428 should never be greater than 20, but for trusted partners it could be 3429 as low as 0. 3431 Responders would need a similar ACL, representing which hosts they 3432 accept HIP exchanges, and the preferred transform and local 3433 lifetimes. Wildcarding SHOULD be supported for this ACL also. 3435 8. Security Considerations 3437 HIP is designed to provide secure authentication of hosts. HIP also 3438 attempts to limit the exposure of the host to various denial-of- 3439 service and man-in-the-middle (MitM) attacks. In so doing, HIP 3440 itself is subject to its own DoS and MitM attacks that potentially 3441 could be more damaging to a host's ability to conduct business as 3442 usual. 3444 Denial-of-service attacks take advantage of the cost of start of 3445 state for a protocol on the Responder compared to the 'cheapness' on 3446 the Initiator. HIP makes no attempt to increase the cost of the 3447 start of state on the Initiator, but makes an effort to reduce the 3448 cost to the Responder. This is done by having the Responder start 3449 the 3-way exchange instead of the Initiator, making the HIP protocol 3450 4 packets long. In doing this, packet 2 becomes a 'stock' packet 3451 that the Responder MAY use many times. The duration of use is a 3452 paranoia versus throughput concern. Using the same Diffie-Hellman 3453 values and random puzzle #I has some risk. This risk needs to be 3454 balanced against a potential storm of HIP I1 packets. 3456 This shifting of the start of state cost to the Initiator in creating 3457 the I2 HIP packet, presents another DoS attack. The attacker spoofs 3458 the I1 HIP packet and the Responder sends out the R1 HIP packet. 3459 This could conceivably tie up the 'Initiator' with evaluating the R1 3460 HIP packet, and creating the I2 HIP packet. The defense against this 3461 attack is to simply ignore any R1 packet where a corresponding I1 was 3462 not sent. 3464 A second form of DoS attack arrives in the I2 HIP packet. Once the 3465 attacking Initiator has solved the puzzle, it can send packets with 3466 spoofed IP source addresses with either invalid encrypted HIP payload 3467 component or a bad HIP signature. This would take resources in the 3468 Responder's part to reach the point to discover that the I2 packet 3469 cannot be completely processed. The defense against this attack is 3470 after N bad I2 packets, the Responder would discard any I2s that 3471 contain the given Initiator HIT. Thus will shut down the attack. 3472 The attacker would have to request another R1 and use that to launch 3473 a new attack. The Responder could up the value of K while under 3474 attack. On the downside, valid I2s might get dropped too. 3476 A third form of DoS attack is emulating the restart of state after a 3477 reboot of one of the partners. A host restarting would send an I1 to 3478 a peer, which would respond with an R1 even if it were in the 3479 ESTABLISHED state. If the I1 were spoofed, the resulting R1 would be 3480 received unexpectedly by the spoofed host and would be dropped, as in 3481 the first case above. 3483 A fourth form of DoS attack is emulating the end of state. HIP 3484 relies on timers plus a CLOSE/CLOSE_ACK handshake to explicitly 3485 signals the end of a state. Because both CLOSE and CLOSE_ACK 3486 messages contain an HMAC, an outsider cannot close a connection. The 3487 presence of an additional SIGNATURE allows middle-boxes to inspect 3488 these messages and discard the associated state (for e.g., 3489 firewalling, SPI-based NATing, etc.). However, the optional behavior 3490 of replying to CLOSE with an ICMP Parameter Problem packet (as 3491 described in Section 5.4.4) might allow an IP spoofer sending CLOSE 3492 messages to launch reflection attacks. 3494 A fifth form of DoS attack is replaying R1s to cause the Initiator to 3495 solve stale puzzles and become out of synchronization with the 3496 Responder. The R1 generation counter is a monotonically increasing 3497 counter designed to protect against this attack, as described in 3498 section Section 4.1.4. 3500 Man-in-the-middle attacks are difficult to defend against, without 3501 third-party authentication. A skillful MitM could easily handle all 3502 parts of HIP; but HIP indirectly provides the following protection 3503 from a MitM attack. If the Responder's HI is retrieved from a signed 3504 DNS zone, a certificate, or through some other secure means, the 3505 Initiator can use this to validate the R1 HIP packet. 3507 Likewise, if the Initiator's HI is in a secure DNS zone, a trusted 3508 certificate, or otherwise securely available, the Responder can 3509 retrieve it after it gets the I2 HIP packet and validate that. 3510 However, since an Initiator may choose to use an anonymous HI, it 3511 knowingly risks a MitM attack. The Responder may choose not to 3512 accept a HIP exchange with an anonymous Initiator. 3514 If an Initiator wants to use opportunistic mode, it is vulnerable to 3515 man-in-the-middle attacks. Furthermore, the available HI types are 3516 limited to the MUST implement algorithms, as per Section 3. Hence, 3517 if a future specification deprecates the current MUST implement 3518 algorithm(s) and replaces it (them) with some new one(s), backward 3519 compatibility cannot be preserved. 3521 Since not all hosts will ever support HIP, ICMP 'Destination Protocol 3522 Unreachable' are to be expected and present a DoS attack. Against an 3523 Initiator, the attack would look like the Responder does not support 3524 HIP, but shortly after receiving the ICMP message, the Initiator 3525 would receive a valid R1 HIP packet. Thus to protect from this 3526 attack, an Initiator should not react to an ICMP message until a 3527 reasonable delta time to get the real Responder's R1 HIP packet. A 3528 similar attack against the Responder is more involved. First an ICMP 3529 message is expected if the I1 was a DoS attack and the real owner of 3530 the spoofed IP address does not support HIP. The Responder SHOULD 3531 NOT act on this ICMP message to remove the minimal state from the R1 3532 HIP packet (if it has one), but wait for either a valid I2 HIP packet 3533 or the natural timeout of the R1 HIP packet. This is to allow for a 3534 sophisticated attacker that is trying to break up the HIP exchange. 3535 Likewise, the Initiator should ignore any ICMP message while waiting 3536 for an R2 HIP packet, deleting state only after a natural timeout. 3538 9. IANA Considerations 3540 This document specifies the IP protocol number 253 to be used with 3541 Host Identity Protocol during the experimental phase. This number 3542 has been reserved by IANA for experimental use (see [19]. 3544 This document defines a new 128-bit value under the CGA Message Type 3545 namespace [20], 0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA. 3547 This document also creates a set of new name spaces. These are 3548 described below. 3550 Packet Type 3552 The 7-bit Packet Type field in a HIP protocol packet describes the 3553 type of a HIP protocol message. It is defined in Section 5.1. 3554 The current values are defined in Section 5.3.1 through 3555 Section 5.3.8 and are listed below: 3557 * I1 is 1. 3559 * R1 is 2. 3561 * I2 is 3. 3563 * R2 is 4. 3565 * UPDATE is 16. 3567 * NOTIFY is 17. 3569 * CLOSE is 18. 3571 * CLOSE_ACK is 19. 3573 New values are assigned through IETF Consensus [9]. 3575 HIP Version 3577 The four bit Version field in a HIP protocol packet describes the 3578 version of the HIP protocol. It is defined in Section 5.1. The 3579 only currently defined value is 1. New values are assigned 3580 through IETF Consensus. 3582 Parameter Type 3584 The 16 bit Type field in a HIP parameters describes the type of 3585 the parameter. It is defined in Section 5.2.1. The current 3586 values are defined in Section 5.2.3 through Section 5.2.18 and are 3587 listed below: 3589 * R1_COUNTER is 128. 3591 * PUZZLE is 257. 3593 * SOLUTION is 321. 3595 * SEQ is 385. 3597 * ACK is 449. 3599 * DIFFIE_HELLMAN is 513. 3601 * HIP_TRANSFORM is 577. 3603 * ENCRYPTED is 641. 3605 * HOST_ID is 705. 3607 * CERT is 768. 3609 * NOTIFY is 832. 3611 * ECHO_REQUEST is 897. 3613 * ECHO_RESPONSE is 961. 3615 * HMAC is 61505. 3617 * HMAC_2 is 61569. 3619 * HIP_SIGNATURE_2 is 61633. 3621 * HIP_SIGNATURE is 61697. 3623 * ECHO_REQUEST is 63661. 3625 * ECHO_RESPONSE is 63425. 3627 The type codes 0 through 1023 and 61440 through 65535 are reserved 3628 for future base protocol extensions, and are assigned through IETF 3629 Consensus. 3631 The type codes 32768 through 49141 are reserved for 3632 experimentation and private use. Types SHOULD be selected in a 3633 random fashion from this range, thereby reducing the probability 3634 of collisions. A method employing genuine randomness (such as 3635 flipping a coin) SHOULD be used. 3637 All other type codes are assigned through First Come First Served, 3638 with Specification Required [9]. 3640 Group ID 3642 The eight bit Group ID values appear in the DIFFIE_HELLMAN 3643 parameter, defined in Section 5.2.6. The currently defined values 3644 are listed below: 3646 * 384-bit group is 1. 3648 * OAKLEY well known group 1 is 2. 3650 * 1536-bit MODP group is 3. 3652 * 3072-bit MODP group is 4. 3654 * 6144-bit MODP group is 5. 3656 * 8192-bit MODP group is 6. 3658 * Value 0 is reserved. 3660 New values either from the reserved or unassigned space are 3661 assigned through IETF Consensus. 3663 Suite ID 3665 The 16 bit Suite ID values in a HIP_TRANSFORM parameter are 3666 defined in Section 5.2.7. The currently defined values are listed 3667 below: 3669 * AES-CBC with HMAC-SHA1 is 1. 3671 * 3DES-CBC with HMAC-SHA1 is 2. 3673 * 3DES-CBC with HMAC-MD5 is 3. 3675 * BLOWFISH-CBC with HMAC-SHA1 is 4. 3677 * NULL-ENCRYPT with HMAC-SHA1 is 5. 3679 * NULL-ENCRYPT with HMAC-MD5 is 6. 3681 * Value 0 is reserved. 3683 New values either from the reserved or unassigned space are 3684 assigned through IETF Consensus. 3686 DI-Type 3688 The four bit DI-Type values in a HOST_ID parameter are defined in 3689 Section 5.2.8. The currently defined values are listed below: 3691 * None included is 0. 3693 * FQDN is 1. 3695 * NAI is 2. 3697 New values are assigned through IETF Consensus. 3699 Notify Message Type 3701 The 16 bit Notify Message Type field in a NOTIFY parameter is 3702 defined in Section 5.2.16. The currently defined values are 3703 listed below: 3705 * UNSUPPORTED_CRITICAL_PARAMETER_TYPE is 1. 3707 * INVALID_SYNTAX is 7. 3709 * NO_DH_PROPOSAL_CHOSEN is 14. 3711 * INVALID_DH_CHOSEN is 15. 3713 * NO_HIP_PROPOSAL_CHOSEN is 16. 3715 * INVALID_HIP_TRANSFORM_CHOSEN is 17. 3717 * AUTHENTICATION_FAILED is 24. 3719 * CHECKSUM_FAILED is 26. 3721 * HMAC_FAILED is 28. 3723 * ENCRYPTION_FAILED is 32. 3725 * INVALID_HIT is 40. 3727 * BLOCKED_BY_POLICY is 42. 3729 * SERVER_BUSY_PLEASE_RETRY is 44. 3731 New values are assigned through First Come First Served, with 3732 Specification Required. 3734 10. Acknowledgments 3736 The drive to create HIP came to being after attending the MALLOC 3737 meeting at the 43rd IETF meeting. Baiju Patel and Hilarie Orman 3738 really gave the original author, Bob Moskowitz, the assist to get HIP 3739 beyond 5 paragraphs of ideas. It has matured considerably since the 3740 early drafts thanks to extensive input from IETFers. Most 3741 importantly, its design goals are articulated and are different from 3742 other efforts in this direction. Particular mention goes to the 3743 members of the NameSpace Research Group of the IRTF. Noel Chiappa 3744 provided the framework for LSIs and Keith Moore the impetus to 3745 provide resolvability. Steve Deering provided encouragement to keep 3746 working, as a solid proposal can act as a proof of ideas for a 3747 research group. 3749 Many others contributed; extensive security tips were provided by 3750 Steve Bellovin. Rob Austein kept the DNS parts on track. Paul 3751 Kocher taught Bob Moskowitz how to make the puzzle exchange expensive 3752 for the Initiator to respond, but easy for the Responder to validate. 3753 Bill Sommerfeld supplied the Birthday concept, which later evolved 3754 into the R1 generation counter, to simplify reboot management. Erik 3755 Nordmark supplied CLOSE-mechanism for closing connections. Rodney 3756 Thayer and Hugh Daniels provide extensive feedback. In the early 3757 times of this draft, John Gilmore kept Bob Moskowitz challenged to 3758 provide something of value. 3760 During the later stages of this document, when the editing baton was 3761 transfered to Pekka Nikander, the input from the early implementors 3762 were invaluable. Without having actual implementations, this 3763 document would not be on the level it is now. 3765 In the usual IETF fashion, a large number of people have contributed 3766 to the actual text or ideas. The list of these people include Jeff 3767 Ahrenholz, Francis Dupont, Derek Fawcus, George Gross, Andrew 3768 McGregor, Julien Laganier, Miika Komu, Mika Kousa, Jan Melen, Henrik 3769 Petander, Michael Richardson, Tim Shepard, Jorma Wall, and Jukka 3770 Ylitalo. Our apologies to anyone whose name is missing. 3772 Once the HIP Working Group was founded in early 2004, a number of 3773 changes were introduced through the working group process. Most 3774 notably, the original draft was split in two, one containing the base 3775 exchange and the other one defining how to use ESP. Some 3776 modifications to the protocol proposed by Aura et al. [29] were added 3777 at a later stage. 3779 11. References 3781 11.1. Normative References 3783 [1] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 3784 August 1980. 3786 [2] Postel, J., "Internet Control Message Protocol", STD 5, 3787 RFC 792, September 1981. 3789 [3] Mockapetris, P., "Domain names - implementation and 3790 specification", STD 13, RFC 1035, November 1987. 3792 [4] Conta, A. and S. Deering, "Internet Control Message Protocol 3793 (ICMPv6) for the Internet Protocol Version 6 (IPv6)", RFC 1885, 3794 December 1995. 3796 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 3797 Levels", BCP 14, RFC 2119, March 1997. 3799 [6] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP 3800 and AH", RFC 2404, November 1998. 3802 [7] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 3803 RFC 2409, November 1998. 3805 [8] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, 3806 November 1998. 3808 [9] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 3809 Considerations Section in RFCs", BCP 26, RFC 2434, 3810 October 1998. 3812 [10] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", 3813 RFC 2451, November 1998. 3815 [11] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 3816 Specification", RFC 2460, December 1998. 3818 [12] Eastlake, D., "Domain Name System Security Extensions", 3819 RFC 2535, March 1999. 3821 [13] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System 3822 (DNS)", RFC 2536, March 1999. 3824 [14] Kaliski, B., "PKCS #5: Password-Based Cryptography 3825 Specification Version 2.0", RFC 2898, September 2000. 3827 [15] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name 3828 System (DNS)", RFC 3110, May 2001. 3830 [16] Draves, R., "Default Address Selection for Internet Protocol 3831 version 6 (IPv6)", RFC 3484, February 2003. 3833 [17] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 3834 Diffie-Hellman groups for Internet Key Exchange (IKE)", 3835 RFC 3526, May 2003. 3837 [18] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher 3838 Algorithm and Its Use with IPsec", RFC 3602, September 2003. 3840 [19] Narten, T., "Assigning Experimental and Testing Numbers 3841 Considered Useful", BCP 82, RFC 3692, January 2004. 3843 [20] Aura, T., "Cryptographically Generated Addresses (CGA)", 3844 RFC 3972, March 2005. 3846 [21] Schiller, J., "Cryptographic Algorithms for use in the Internet 3847 Key Exchange Version 2", draft-ietf-ipsec-ikev2-algorithms-05 3848 (work in progress), April 2004. 3850 [22] Nikander, P., "A Non-Routable IPv6 Prefix for Keyed Hash 3851 Identifiers (KHI)", draft-laganier-ipv6-khi-00 (work in 3852 progress), September 2005. 3854 [23] Aboba, B., "The Network Access Identifier", 3855 draft-ietf-radext-rfc2486bis-06 (work in progress), July 2005. 3857 [24] Jokela, P., "Using ESP transport format with HIP", 3858 draft-ietf-hip-esp-01 (work in progress), October 2005. 3860 [25] NIST, "FIPS PUB 180-1: Secure Hash Standard", April 1995. 3862 11.2. Informative References 3864 [26] Moskowitz, R. and P. Nikander, "Host Identity Protocol 3865 Architecture", draft-ietf-hip-arch-03 (work in progress), 3866 August 2005. 3868 [27] Bagnulo, M. and E. Nordmark, "Level 3 multihoming shim 3869 protocol", draft-ietf-shim6-proto-03 (work in progress), 3870 December 2005. 3872 [28] Henderson, T. and P. Nikander, "Using HIP with Legacy 3873 Applications", draft-henderson-hip-applications-01 (work in 3874 progress), July 2005. 3876 [29] Aura, T., Nagarajan, A., and A. Gurtov, "Analysis of the HIP 3877 Base Exchange Protocol", in Proceedings of 10th Australasian 3878 Conference on Information Security and Privacy, July 2003. 3880 [30] Krawczyk, H., "SIGMA: The 'SIGn-and-MAc' Approach to 3881 Authenticated Diffie-Hellman and Its Use in the IKE-Protocols", 3882 in Proceedings of CRYPTO 2003, pages 400-425, August 2003. 3884 [31] Crosby, SA. and DS. Wallach, "Denial of Service via Algorithmic 3885 Complexity Attacks", in Proceedings of Usenix Security 3886 Symposium 2003, Washington, DC., August 2003. 3888 [32] NIST, "FIPS PUB 197: Advanced Encryption Standard", Nov 2001. 3890 Appendix A. Using Responder Puzzles 3892 As mentioned in Section 4.1.1, the Responder may delay state creation 3893 and still reject most spoofed I2s by using a number of pre-calculated 3894 R1s and a local selection function. This appendix defines one 3895 possible implementation in detail. The purpose of this appendix is 3896 to give the implementors an idea on how to implement the mechanism. 3897 If the implementation is based on this appendix, it MAY contain some 3898 local modification that makes an attacker's task harder. 3900 The Responder creates a secret value S, that it regenerates 3901 periodically. The Responder needs to remember two latest values of 3902 S. Each time the S is regenerated, R1 generation counter value is 3903 incremented by one. 3905 The Responder generates a pre-signed R1 packet. The signature for 3906 pre-generated R1s must be recalculated when the Diffie-Hellman key is 3907 recomputed or when the R1_COUNTER value changes due to S value 3908 regeneration. 3910 When the Initiator sends the I1 packet for initializing a connection, 3911 the Responder gets the HIT and IP address from the packet, and 3912 generates an I-value for the puzzle. The I value is set to the pre- 3913 signed R1 packet. 3915 I value calculation: 3916 I = Ltrunc( PHASH ( S | HIT-I | HIT-R | IP-I | IP-R ), 64) 3918 The PHASH algorithm is the same that is used to generate the 3919 Responder's HIT value. 3921 From an incoming I2 packet, the Responder gets the required 3922 information to validate the puzzle: HITs, IP addresses, and the 3923 information of the used S value from the R1_COUNTER. Using these 3924 values, the Responder can regenerate the I, and verify it against the 3925 I received in the I2 packet. If the I values match, it can verify 3926 the solution using I, J, and difficulty K. If the I values do not 3927 match, the I2 is dropped. 3929 puzzle_check: 3930 V := Ltrunc( PHASH( I2.I | I2.hit_i | I2.hit_r | I2.J ), K ) 3931 if V != 0, drop the packet 3933 If the puzzle solution is correct, the I and J values are stored for 3934 later use. They are used as input material when keying material is 3935 generated. 3937 The Responder SHOULD NOT keep state about failed puzzle solutions. 3939 Appendix B. Generating a HIT from a HI 3941 The following pseudo-codes illustrate the process to generate a 3942 public key encoding from a HI for both RSA and DSA. 3944 The symbol := denotes assignment; the symbol += denotes appending. 3945 The pseudo-function encode_in_network_byte_order takes two 3946 parameters, an integer (bignum) and a length in bytes, and returns 3947 the integer encoded into a byte string of the given length. 3949 switch ( HI.algorithm ) 3950 { 3952 case RSA: 3953 buffer := encode_in_network_byte_order ( HI.RSA.e_len, 3954 ( HI.RSA.e_len > 255 ) ? 3 : 1 ) 3955 buffer += encode_in_network_byte_order ( HI.RSA.e, HI.RSA.e_len ) 3956 buffer += encode_in_network_byte_order ( HI.RSA.n, HI.RSA.n_len ) 3957 break; 3959 case DSA: 3960 buffer := encode_in_network_byte_order ( HI.DSA.T , 1 ) 3961 buffer += encode_in_network_byte_order ( HI.DSA.Q , 20 ) 3962 buffer += encode_in_network_byte_order ( HI.DSA.P , 64 + 3963 8 * HI.DSA.T ) 3964 buffer += encode_in_network_byte_order ( HI.DSA.G , 64 + 3965 8 * HI.DSA.T ) 3966 buffer += encode_in_network_byte_order ( HI.DSA.Y , 64 + 3967 8 * HI.DSA.T ) 3968 break; 3970 } 3972 Appendix C. Example Checksums for HIP Packets 3974 The HIP checksum for HIP packets is specified in Section 6.1.2. 3975 Checksums for TCP and UDP packets running over HIP-enabled security 3976 associations are specified in Section 3.5. The examples below use IP 3977 addresses of 192.168.0.1 and 192.168.0.2 (and their respective IPv4- 3978 compatible IPv6 formats), and HITs with the first two bits "01" 3979 followed by 124 zeroes followed by a decimal 1 or 2, respectively. 3981 C.1. IPv6 HIP Example (I1) 3983 Source Address: ::192.168.0.1 3984 Destination Address: ::192.168.0.2 3985 Upper-Layer Packet Length: 40 0x28 3986 Next Header: 253 0xfd 3987 Payload Protocol: 59 0x3b 3988 Header Length: 4 0x4 3989 Packet Type: 1 0x1 3990 Version: 1 0x1 3991 Reserved: 1 0x1 3992 Control: 0 0x0 3993 Checksum: 8046 0x1f6e 3994 Sender's HIT : 1100::1 3995 Receiver's HIT: 1100::2 3997 C.2. IPv4 HIP Packet (I1) 3999 The IPv4 checksum value for the same example I1 packet is the same as 4000 the IPv6 checksum (since the checksums due to the IPv4 and IPv6 4001 pseudo-header components are the same). 4003 C.3. TCP Segment 4005 Regardless of whether IPv6 or IPv4 is used, the TCP and UDP sockets 4006 use the IPv6 pseudo-header format [11], with the HITs used in place 4007 of the IPv6 addresses. 4009 Sender's HIT: 1100::0001 4010 Receiver's HIT: 1100::0002 4011 Upper-Layer Packet Length: 20 0x14 4012 Next Header: 6 0x06 4013 Source port: 65500 0xffdc 4014 Destination port: 22 0x0016 4015 Sequence number: 1 0x00000001 4016 Acknowledgment number: 0 0x00000000 4017 Header length: 20 0x14 4018 Flags: SYN 0x02 4019 Window size: 65535 0xffff 4020 Checksum: 60301 0xeb8d 4021 Urgent pointer: 0 0x0000 4023 0x0000: 6000 0000 0014 0640 1100 0000 0000 0000 4024 0x0010: 0000 0000 0000 0002 1100 0000 0000 0000 4025 0x0020: 0000 0000 0000 0002 ffdc 0016 0000 0001 4026 0x0030: 0000 0000 5002 ffff 8deb 0000 4028 Appendix D. 384-bit Group 4030 This 384-bit group is defined only to be used with HIP. NOTE: The 4031 security level of this group is very low! The encryption may be 4032 broken in a very short time, even real-time. It should be used only 4033 when the host is not powerful enough (e.g. some PDAs) and when 4034 security requirements are low (e.g. during normal web surfing). 4036 This prime is: 2^384 - 2^320 - 1 + 2^64 * { [ 2^254 pi] + 5857 } 4038 Its hexadecimal value is: 4040 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 4041 29024E08 8A67CC74 020BBEA6 3B13B202 FFFFFFFF FFFFFFFF 4043 The generator is: 2. 4045 Authors' Addresses 4047 Robert Moskowitz 4048 ICSAlabs, a Division of TruSecure Corporation 4049 1000 Bent Creek Blvd, Suite 200 4050 Mechanicsburg, PA 4051 USA 4053 Email: rgm@icsalabs.com 4055 Pekka Nikander 4056 Ericsson Research NomadicLab 4057 JORVAS FIN-02420 4058 FINLAND 4060 Phone: +358 9 299 1 4061 Email: pekka.nikander@nomadiclab.com 4063 Petri Jokela 4064 Ericsson Research NomadicLab 4065 JORVAS FIN-02420 4066 FINLAND 4068 Phone: +358 9 299 1 4069 Email: petri.jokela@nomadiclab.com 4071 Thomas R. Henderson 4072 The Boeing Company 4073 P.O. Box 3707 4074 Seattle, WA 4075 USA 4077 Email: thomas.r.henderson@boeing.com 4079 Intellectual Property Statement 4081 The IETF takes no position regarding the validity or scope of any 4082 Intellectual Property Rights or other rights that might be claimed to 4083 pertain to the implementation or use of the technology described in 4084 this document or the extent to which any license under such rights 4085 might or might not be available; nor does it represent that it has 4086 made any independent effort to identify any such rights. Information 4087 on the procedures with respect to rights in RFC documents can be 4088 found in BCP 78 and BCP 79. 4090 Copies of IPR disclosures made to the IETF Secretariat and any 4091 assurances of licenses to be made available, or the result of an 4092 attempt made to obtain a general license or permission for the use of 4093 such proprietary rights by implementers or users of this 4094 specification can be obtained from the IETF on-line IPR repository at 4095 http://www.ietf.org/ipr. 4097 The IETF invites any interested party to bring to its attention any 4098 copyrights, patents or patent applications, or other proprietary 4099 rights that may cover technology that may be required to implement 4100 this standard. Please address the information to the IETF at 4101 ietf-ipr@ietf.org. 4103 Disclaimer of Validity 4105 This document and the information contained herein are provided on an 4106 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 4107 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 4108 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 4109 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 4110 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 4111 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 4113 Copyright Statement 4115 Copyright (C) The Internet Society (2006). This document is subject 4116 to the rights, licenses and restrictions contained in BCP 78, and 4117 except as set forth therein, the authors retain all their rights. 4119 Acknowledgment 4121 Funding for the RFC Editor function is currently provided by the 4122 Internet Society.