idnits 2.17.1 draft-ietf-hip-base-00.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 3667, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 3950. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3934. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3940. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 3956), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 40. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 86 longer pages, the longest (page 46) being 75 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 98 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 32 instances of too long lines in the document, the longest one being 5 characters in excess of 72. == There are 1 instance of lines with 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 1153 has weird spacing: '...ariable publ...' == Line 1407 has weird spacing: '...c Value the ...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The UPDATE packet contains zero or one SEQ parameter. The presence of a SEQ parameter indicates that the receiver MUST ack the UPDATE. An UPDATE that does not contain a SEQ parameter is simply an ACK of a previous UPDATE and itself MUST not be acked. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: All compliant implementations MUST produce R1 packets. An R1 packet MAY be precomputed. An R1 packet MAY be reused for time Delta T, which is implementation dependent. R1 information MUST not be discarded until Delta S after T. Time S is the delay needed for the last I2 to arrive back to the responder. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 11, 2004) is 7230 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 1536 -- Looks like a reference, but probably isn't: 'RFC3110' on line 1537 == Missing Reference: '0' is mentioned on line 3772, but not defined == Unused Reference: '7' is defined on line 3520, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 3549, but no explicit reference was found in the text == Unused Reference: '24' is defined on line 3576, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1885 (ref. '4') (Obsoleted by RFC 2463) ** Obsolete normative reference: RFC 2408 (ref. '7') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2409 (ref. '8') (Obsoleted by RFC 4306) ** Downref: Normative reference to an Informational RFC: RFC 2412 (ref. '9') ** Obsolete normative reference: RFC 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 3280 (ref. '14') (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 3484 (ref. '15') (Obsoleted by RFC 6724) ** Obsolete normative reference: RFC 3513 (ref. '16') (Obsoleted by RFC 4291) == Outdated reference: A later version (-10) exists of draft-ietf-ipsec-esp-v3-05 == Outdated reference: A later version (-17) exists of draft-ietf-ipsec-ikev2-07 == Outdated reference: A later version (-06) exists of draft-moskowitz-hip-arch-03 -- Possible downref: Normative reference to a draft: ref. '20' -- Possible downref: Non-RFC (?) normative reference: ref. '21' -- No information found for draft-nikander-hip-nat - is the name correct? == Outdated reference: A later version (-09) exists of draft-nikander-esp-beet-mode-00 Summary: 17 errors (**), 0 flaws (~~), 17 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group R. Moskowitz 2 Internet-Draft ICSAlabs, a Division of TruSecure 3 Expires: December 10, 2004 Corporation 4 P. Nikander 5 P. Jokela (editor) 6 Ericsson Research NomadicLab 7 T. Henderson 8 The Boeing Company 9 June 11, 2004 11 Host Identity Protocol 12 draft-ietf-hip-base-00 14 Status of this Memo 16 By submitting this Internet-Draft, I certify that any applicable 17 patent or other IPR claims of which I am aware have been disclosed, 18 and any of which I become aware will be disclosed, in accordance with 19 RFC 3668. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at http:// 31 www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on December 10, 2004. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). All Rights Reserved. 42 Abstract 44 This memo specifies the details of the Host Identity Protocol (HIP). 45 The overall description of protocol and the underlying architectural 46 thinking is available in the separate HIP architecture specification. 47 The Host Identity Protocol is used to establish a rapid 48 authentication between two hosts and to provide continuity of 49 communications between those hosts independent of the networking 50 layer. 52 The various forms of the Host Identity, Host Identity Tag (HIT) and 53 Local Scope Identifier (LSI), are covered in detail. It is described 54 how they are used to support authentication and the establishment of 55 keying material, which is then used by IPsec Encapsulated Security 56 payload (ESP) to establish a two-way secured communication channel 57 between the hosts. The basic state machine for HIP provides a HIP 58 compliant host with the resiliency to avoid many denial-of-service 59 (DoS)attacks. The basic HIP exchange for two public hosts shows the 60 actual packet flow. Other HIP exchanges, including those that work 61 across NATs are covered elsewhere. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 66 1.1 A new name space and identifiers . . . . . . . . . . . . . 5 67 1.2 The HIP protocol . . . . . . . . . . . . . . . . . . . . . 5 68 2. Conventions used in this document . . . . . . . . . . . . . 7 69 3. Host Identifier (HI) and its representations . . . . . . . . 8 70 3.1 Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 8 71 3.1.1 Generating a HIT from a HI . . . . . . . . . . . . . . 9 72 3.2 Local Scope Identifier (LSI) . . . . . . . . . . . . . . . 10 73 3.3 Security Parameter Index (SPI) . . . . . . . . . . . . . . 10 74 4. Host Identity Protocol . . . . . . . . . . . . . . . . . . . 12 75 4.1 HIP base exchange . . . . . . . . . . . . . . . . . . . . 12 76 4.1.1 HIP Cookie Mechanism . . . . . . . . . . . . . . . . . 13 77 4.1.2 Authenticated Diffie-Hellman protocol . . . . . . . . 15 78 4.1.3 HIP replay protection . . . . . . . . . . . . . . . . 16 79 4.2 TCP and UDP pseudo-header computation . . . . . . . . . . 17 80 4.3 Updating a HIP association . . . . . . . . . . . . . . . . 17 81 4.4 Error processing . . . . . . . . . . . . . . . . . . . . . 17 82 4.5 Bootstrap support . . . . . . . . . . . . . . . . . . . . 18 83 4.6 Certificate distribution . . . . . . . . . . . . . . . . . 18 84 4.7 Sending data on HIP packets . . . . . . . . . . . . . . . 18 85 5. HIP protocol overview . . . . . . . . . . . . . . . . . . . 19 86 5.1 HIP Scenarios . . . . . . . . . . . . . . . . . . . . . . 19 87 5.2 Refusing a HIP exchange . . . . . . . . . . . . . . . . . 20 88 5.3 Reboot and SA timeout restart of HIP . . . . . . . . . . . 20 89 5.4 HIP State Machine . . . . . . . . . . . . . . . . . . . . 21 90 5.4.1 HIP States . . . . . . . . . . . . . . . . . . . . . . 21 91 5.4.2 HIP State Processes . . . . . . . . . . . . . . . . . 21 92 5.4.3 Simplified HIP State Diagram . . . . . . . . . . . . . 24 93 6. Packet formats . . . . . . . . . . . . . . . . . . . . . . . 26 94 6.1 Payload format . . . . . . . . . . . . . . . . . . . . . . 26 95 6.1.1 HIP Controls . . . . . . . . . . . . . . . . . . . . . 27 96 6.1.2 Checksum . . . . . . . . . . . . . . . . . . . . . . . 27 98 6.2 HIP parameters . . . . . . . . . . . . . . . . . . . . . . 28 99 6.2.1 TLV format . . . . . . . . . . . . . . . . . . . . . . 29 100 6.2.2 Defining new parameters . . . . . . . . . . . . . . . 30 101 6.2.3 SPI . . . . . . . . . . . . . . . . . . . . . . . . . 31 102 6.2.4 R1_COUNTER . . . . . . . . . . . . . . . . . . . . . . 32 103 6.2.5 PUZZLE . . . . . . . . . . . . . . . . . . . . . . . . 33 104 6.2.6 SOLUTION . . . . . . . . . . . . . . . . . . . . . . . 34 105 6.2.7 DIFFIE_HELLMAN . . . . . . . . . . . . . . . . . . . . 34 106 6.2.8 HIP_TRANSFORM . . . . . . . . . . . . . . . . . . . . 35 107 6.2.9 ESP_TRANSFORM . . . . . . . . . . . . . . . . . . . . 36 108 6.2.10 HOST_ID . . . . . . . . . . . . . . . . . . . . . . 37 109 6.2.11 CERT . . . . . . . . . . . . . . . . . . . . . . . . 38 110 6.2.12 HMAC . . . . . . . . . . . . . . . . . . . . . . . . 39 111 6.2.13 HIP_SIGNATURE . . . . . . . . . . . . . . . . . . . 40 112 6.2.14 HIP_SIGNATURE_2 . . . . . . . . . . . . . . . . . . 40 113 6.2.15 NES . . . . . . . . . . . . . . . . . . . . . . . . 41 114 6.2.16 SEQ . . . . . . . . . . . . . . . . . . . . . . . . 42 115 6.2.17 ACK . . . . . . . . . . . . . . . . . . . . . . . . 42 116 6.2.18 ENCRYPTED . . . . . . . . . . . . . . . . . . . . . 43 117 6.2.19 NOTIFY . . . . . . . . . . . . . . . . . . . . . . . 44 118 6.2.20 ECHO_REQUEST . . . . . . . . . . . . . . . . . . . . 47 119 6.2.21 ECHO_RESPONSE . . . . . . . . . . . . . . . . . . . 47 120 6.3 ICMP messages . . . . . . . . . . . . . . . . . . . . . . 48 121 6.3.1 Invalid Version . . . . . . . . . . . . . . . . . . . 48 122 6.3.2 Other problems with the HIP header and packet 123 structure . . . . . . . . . . . . . . . . . . . . . . 48 124 6.3.3 Unknown SPI . . . . . . . . . . . . . . . . . . . . . 48 125 6.3.4 Invalid Cookie Solution . . . . . . . . . . . . . . . 49 126 7. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . . 50 127 7.1 I1 - the HIP initiator packet . . . . . . . . . . . . . . 50 128 7.2 R1 - the HIP responder packet . . . . . . . . . . . . . . 51 129 7.3 I2 - the second HIP initiator packet . . . . . . . . . . . 52 130 7.4 R2 - the second HIP responder packet . . . . . . . . . . . 54 131 7.5 UPDATE - the HIP Update Packet . . . . . . . . . . . . . . 54 132 7.6 BOS - the HIP Bootstrap Packet . . . . . . . . . . . . . . 55 133 7.7 CER - the HIP Certificate Packet . . . . . . . . . . . . . 56 134 7.8 NOTIFY - the HIP Notify Packet . . . . . . . . . . . . . . 56 135 7.9 PAYLOAD - the HIP Payload Packet . . . . . . . . . . . . . 57 136 8. Packet processing . . . . . . . . . . . . . . . . . . . . . 58 137 8.1 Processing outgoing application data . . . . . . . . . . . 58 138 8.2 Processing incoming application data . . . . . . . . . . . 59 139 8.3 HMAC and SIGNATURE calculation and verification . . . . . 60 140 8.3.1 HMAC calculation . . . . . . . . . . . . . . . . . . . 60 141 8.3.2 Signature calculation . . . . . . . . . . . . . . . . 60 142 8.4 Initiation of a HIP exchange . . . . . . . . . . . . . . . 61 143 8.4.1 Sending multiple I1s in parallel . . . . . . . . . . . 62 144 8.4.2 Processing incoming ICMP Protocol Unreachable 145 messages . . . . . . . . . . . . . . . . . . . . . . . 62 147 8.5 Processing incoming I1 packets . . . . . . . . . . . . . . 62 148 8.5.1 R1 Management . . . . . . . . . . . . . . . . . . . . 63 149 8.5.2 Handling malformed messages . . . . . . . . . . . . . 63 150 8.6 Processing incoming R1 packets . . . . . . . . . . . . . . 64 151 8.6.1 Handling malformed messages . . . . . . . . . . . . . 65 152 8.7 Processing incoming I2 packets . . . . . . . . . . . . . . 66 153 8.7.1 Handling malformed messages . . . . . . . . . . . . . 67 154 8.8 Processing incoming R2 packets . . . . . . . . . . . . . . 67 155 8.9 Dropping HIP associations . . . . . . . . . . . . . . . . 68 156 8.10 Initiating rekeying . . . . . . . . . . . . . . . . . . 68 157 8.11 Processing UPDATE packets . . . . . . . . . . . . . . . 69 158 8.11.1 Processing an UPDATE packet in state ESTABLISHED . . 71 159 8.11.2 Processing an UPDATE packet in state REKEYING . . . 71 160 8.11.3 Leaving REKEYING state . . . . . . . . . . . . . . . 72 161 8.12 Processing BOS packets . . . . . . . . . . . . . . . . . 72 162 8.13 Processing CER packets . . . . . . . . . . . . . . . . . 72 163 8.14 Processing PAYLOAD packets . . . . . . . . . . . . . . . 72 164 8.15 Processing NOTIFY packets . . . . . . . . . . . . . . . 72 165 9. HIP KEYMAT . . . . . . . . . . . . . . . . . . . . . . . . . 73 166 10. HIP Fragmentation Support . . . . . . . . . . . . . . . . . 75 167 11. ESP with HIP . . . . . . . . . . . . . . . . . . . . . . . . 76 168 11.1 ESP Security Associations . . . . . . . . . . . . . . . 76 169 11.2 Updating ESP SAs during rekeying . . . . . . . . . . . . 76 170 11.3 Security Association Management . . . . . . . . . . . . 77 171 11.4 Security Parameter Index (SPI) . . . . . . . . . . . . . 77 172 11.5 Supported Transforms . . . . . . . . . . . . . . . . . . 77 173 11.6 Sequence Number . . . . . . . . . . . . . . . . . . . . 78 174 12. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 79 175 13. Security Considerations . . . . . . . . . . . . . . . . . . 80 176 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . 82 177 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 83 178 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 84 179 16.1 Normative references . . . . . . . . . . . . . . . . . . . 84 180 16.2 Informative references . . . . . . . . . . . . . . . . . . 85 181 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 86 182 A. API issues . . . . . . . . . . . . . . . . . . . . . . . . . 87 183 B. Probabilities of HIT collisions . . . . . . . . . . . . . . 89 184 C. Probabilities in the cookie calculation . . . . . . . . . . 90 185 D. Using responder cookies . . . . . . . . . . . . . . . . . . 91 186 E. Running HIP over IPv4 UDP . . . . . . . . . . . . . . . . . 94 187 F. Example checksums for HIP packets . . . . . . . . . . . . . 95 188 F.1 IPv6 HIP example (I1) . . . . . . . . . . . . . . . . . . 95 189 F.2 IPv4 HIP packet (I1) . . . . . . . . . . . . . . . . . . . 95 190 F.3 TCP segment . . . . . . . . . . . . . . . . . . . . . . . 95 191 G. 384-bit group . . . . . . . . . . . . . . . . . . . . . . . 97 192 Intellectual Property and Copyright Statements . . . . . . . 98 194 1. Introduction 196 The Host Identity Protocol (HIP) provides a rapid exchange of Host 197 Identities between two hosts. The exchange also establishes a pair 198 IPsec Security Associations (SA), to be used with IPsec Encapsulated 199 Security Payload (ESP) [18]. The HIP protocol is designed to be 200 resistant to Denial-of-Service (DoS) and Man-in-the-middle (MitM) 201 attacks, and when used to enable ESP, provides DoS and MitM 202 protection for upper layer protocols, such as TCP and UDP. 204 1.1 A new name space and identifiers 206 The Host Identity Protocol introduces a new namespace, the Host 207 Identity. The effects of this change are explained in the companion 208 document, the HIP architecture [20] specification. 210 There are two main representations of the Host Identity, the full 211 Host Identifier (HI) and the Host Identity Tag (HIT). The HI is a 212 public key and directly represents the Identity. Since there are 213 different public key algorithms that can be used with different key 214 lengths, the HI is not good for using as a packet identifier, or as a 215 index into the various operational tables needed to support HIP. 216 Consequently, a hash of the HI, the Host Identity Tag (HIT), becomes 217 the operational representation. It is 128 bits long and is used in 218 the HIP payloads and to index the corresponding state in the end 219 hosts. 221 1.2 The HIP protocol 223 The base HIP exchange consists of four packets. The four-packet 224 design helps to make HIP DoS resilient. The protocol exchanges 225 Diffie-Hellman keys in the 2nd and 3rd packets, and authenticates the 226 parties in the 3rd and 4th packets. Additionally, it starts the 227 cookie exchange in the 2nd packet, completing it in the 3rd packet. 229 The exchange uses the Diffie-Hellman exchange to hide the Host 230 Identity of the Initiator in packet 3. The Responder's Host Identity 231 is not protected. It should be noted, however, that both the 232 Initiator's and the Responder's HITs are transported as such (in 233 cleartext) in the packets, allowing an eavesdropper with a priori 234 knowledge about the parties to verify their identities. 236 Data packets start after the 4th packet. The 3rd and 4th HIP packets 237 may carry a data payload in the future. However, the details of this 238 are to be defined later as more implementation experience is gained. 240 Finally, HIP is designed as an end-to-end authentication and key 241 establishment protocol. It lacks much of the fine-grained policy 242 control found in Internet Key Exchange IKE RFC2409 [8] that allows 243 IKE to support complex gateway policies. Thus, HIP is not a complete 244 replacement for IKE. 246 2. Conventions used in this document 248 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 249 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 250 document are to be interpreted as described in RFC2119 [5]. 252 3. Host Identifier (HI) and its representations 254 A public key of an asymmetric key pair is used as the Host Identifier 255 (HI). Correspondingly, the host itself is the entity that holds the 256 private key from the key pair. See the HIP architecture 257 specification [20] for more details about the difference between an 258 identity and the corresponding identifier. 260 HIP implementations MUST support the Digital Signature Algorithm 261 (DSA) [13] public key algorithm; other algorithms MAY be supported. 262 DSA was chosen as the default algorithm due to its small signature 263 size. 265 A hash of the HI, the Host Identity Tag (HIT), is used in protocols 266 to represent the Host Identity. The HIT is 128 bits long and has the 267 following three key properties: i) it is the same length as an IPv6 268 address and can be used in address-sized fields in APIs and 269 protocols, ii) it is self-certifying (i.e., given a HIT, it is 270 computationally hard to find a Host Identity key that matches the 271 HIT), and iii) the probability of HIT collision between two hosts is 272 very low. 274 In many environments, 128 bits is still considered large. For 275 example, currently used IPv4 based applications are constrained with 276 32 bit address fields. Thus, a third representation, a 32 bit Local 277 Scope Identifier (LSI), may be needed. The LSI provides a 278 compression of the HIT with only a local scope so that it can be 279 carried efficiently in any application level packet and used in API 280 calls. LSIs do not have the same properties as HITs (i.e., they are 281 not self-certifying nor are they as unlikely to collide -- hence 282 their local scope), and consequently they must be used more 283 carefully. 285 Finally, HIs, HITs, and LSIs are not carried explicitly in the 286 headers of user data packets. Instead, the IPsec Security Parameter 287 Index (SPI) is used in data packets to index the right host context. 288 The SPIs are selected during the HIP exchange. For user data packets, 289 then, the combination of IPsec SPIs and IP addresses are used 290 indirectly to identify the host context, thereby avoiding an 291 additional explicit protocol header. 293 3.1 Host Identity Tag (HIT) 295 The Host Identity Tag is a 128 bit value -- a hash of the Host 296 Identifier. There are two advantages of using a hash over the actual 297 Identity in protocols. Firstly, its fixed length makes for easier 298 protocol coding and also better manages the packet size cost of this 299 technology. Secondly, it presents a consistent format to the 300 protocol whatever underlying identity technology is used. 302 There are two types of HITs. HITs of the first type, called *type 1 303 HIT*, consist of an initial 2 bit prefix of 01, followed by 126 bits 304 of the SHA-1 hash of the public key. HITs of the second type consist 305 of an initial 2 bit prefix of 10, a Host Assigning Authority (HAA) 306 field, and only the last 64 bits come from a SHA-1 hash of the Host 307 Identity. This latter format for HIT is recommended for 'well known' 308 systems. It is possible to support a resolution mechanism for these 309 names in hierarchical directories, like the DNS. Another use of HAA 310 is in policy controls, see Section 12. 312 This document fully specifies only type 1 HITs. HITs that consists 313 of the HAA field and the hash are specified in [23]. 315 Any conforming implementation MUST be able to deal with Type 1 HITs. 316 When handling other than type 1 HITs, the implementation is 317 RECOMMENDED to explicitly learn and record the binding between the 318 Host Identifier and the HIT, as it may not be able to generate such 319 HITs from the Host Identifiers. 321 3.1.1 Generating a HIT from a HI 323 The 126 or 64 hash bits in a HIT MUST be generated by taking the 324 least significant 126 or 64 bits of the SHA-1 [21] hash of the Host 325 Identifier as it is represented in the Host Identity field in a HIP 326 payload packet. 328 For Identities that are DSA public keys, the HIT is formed as 329 follows: 330 1. The DSA public key is encoded as defined in RFC2536 [13] Section 331 2, taking the fields T, Q, P, G, and Y, concatenated. Thus, the 332 data to be hashed is 1 + 20 + 3 * 64 + 3 * 8 * T octets long, 333 where T is the size parameter as defined in RFC2536 [13]. The 334 size parameter T, affecting the field lengths, MUST be selected 335 as the minimum value that is long enough to accommodate P, G, and 336 Y. The fields MUST be encoded in network byte order, as defined 337 in RFC2536 [13]. 338 2. A SHA-1 hash [21] is calculated over the encoded key. 339 3. The least significant 126 or 64 bits of the hash result are used 340 to create the HIT, as defined above. 342 The following pseudo-code illustrates the process. The symbol := 343 denotes assignment; the symbol += denotes appending. The 344 pseudo-function encode_in_network_byte_order takes two parameters, an 345 integer (bignum) and a length in bytes, and returns the integer 346 encoded into a byte string of the given length. 348 buffer := encode_in_network_byte_order ( DSA.T , 1 ) 349 buffer += encode_in_network_byte_order ( DSA.Q , 20 ) 350 buffer += encode_in_network_byte_order ( DSA.P , 64 + 8 * T ) 351 buffer += encode_in_network_byte_order ( DSA.G , 64 + 8 * T ) 352 buffer += encode_in_network_byte_order ( DSA.Y , 64 + 8 * T ) 354 digest := SHA-1 ( buffer ) 356 hit_126 := concatenate ( 01 , low_order_bits ( digest, 126 ) ) 357 hit_haa := concatenate ( 10 , HAA, low_order_bits ( digest, 64 ) ) 359 3.2 Local Scope Identifier (LSI) 361 LSIs are 32-bit localized representations of a Host Identity. The 362 purpose of an LSI is to facilitate using Host Identities in existing 363 IPv4 based protocols and APIs. The LSI can be used anywhere in system 364 processes where IP addresses have traditionally been used, such as 365 IPv4 API calls and FTP PORT commands. 367 The LSIs MUST be allocated from the TBD subnet. That makes it easier 368 to differentiate between LSIs and IPv4 addresses at the API level. 369 By default, the low order 24 bits of an LSI are equal to the low 370 order 24 bits of the corresponding HIT. 372 A host performing a HIP handshake may discover that the LSI formed 373 from the peer's HIT collides with another LSI in use locally (i.e., 374 the lower 24 bits of two different HITs are the same). In that case, 375 the host MUST handle the LSI collision locally such that application 376 calls can be disambiguated. One possible means of doing so is to 377 perform a Host NAT function to locally convert a peer's LSI into a 378 different LSI value. This would require the host to ensure that LSI 379 bits on the wire (i.e., in the application data stream) are converted 380 back to match that host's LSI. Other alternatives for resolving LSI 381 collisions may be added in the future. 383 3.3 Security Parameter Index (SPI) 385 SPIs are used in ESP to find the right security association for 386 received packets. The ESP SPIs have added significance when used 387 with HIP; they are a compressed representation of the HITs in every 388 packet. Thus, SPIs MAY be used by intermediary systems in providing 389 services like address mapping. Note that since the SPI has 390 significance at the receiver, only the < DST, SPI >, where DST is a 391 destination IP address, uniquely identifies the receiver HIT at every 392 given point of time. The same SPI value may be used by several 393 hosts. A single < DST, SPI > value may denote different hosts at 394 different points of time, depending on which host is currently 395 reachable at the DST. 397 Each host selects for itself the SPI it wants to see in packets 398 received from its peer. This allows it to select different SPIs for 399 different peers. The SPI selection SHOULD be random; the rules of 400 Section 2.1 of the ESP specification [18] must be followed. A 401 different SPI SHOULD be used for each HIP exchange with a particular 402 host; this is to avoid a replay attack. Additionally, when a host 403 rekeys, the SPI MUST be changed. Furthermore, if a host changes over 404 to use a different IP address, it MAY change the SPI. 406 One method for SPI creation that meets these criteria would be to 407 concatenate the HIT with a 32 bit random or sequential number, hash 408 this (using SHA1), and then use the high order 32 bits as the SPI. 410 The selected SPI is communicated to the peer in the third (I2) and 411 fourth (R2) packets of the base HIP exchange. Changes in SPI are 412 signaled with NES parameters. 414 4. Host Identity Protocol 416 The Host Identity Protocol is IP protocol TBD (number will be 417 assigned by IANA). The HIP payload could be carried in every 418 datagram. However, since HIP datagrams are relatively large (at 419 least 40 bytes), and ESP already has all of the functionality to 420 maintain and protect state, the HIP payload is 'compressed' into an 421 ESP payload after the HIP exchange. Thus in practice, HIP packets 422 only occur in datagrams to establish or change HIP state. 424 For testing purposes, the protocol number 99 is currently used. 426 4.1 HIP base exchange 428 The base HIP exchange serves to manage the establishment of state 429 between an Initiator and a Responder. The Initiator first sends a 430 trigger packet, I1, to the Responder. The second packet, R1, starts 431 the actual exchange. It contains a puzzle, that is, a cryptographic 432 challenge that the Initiator must solve before continuing the 433 exchange. In its reply, I2, the Initiator must display the solution. 434 Without a correct solution, the I2 message is discarded. 436 The last three packets of the exchange, R1, I2, and R2, constitute a 437 standard authenticated Diffie-Hellman key exchange. The base 438 exchange is illustrated below. 440 Initiator Responder 442 I1: trigger exchange 443 --------------------------> 444 select pre-computed R1 445 R1: puzzle, D-H, key, sig 446 <------------------------- 447 check sig remain stateless 448 solve puzzle 449 I2: solution, D-H, {key}, sig 450 --------------------------> 451 compute D-H check cookie 452 check puzzle 453 check sig 454 R2: sig 455 <-------------------------- 456 check sig compute D-H 458 In this section we cover the overall design of the base exchange. 459 The details are the subject of the rest of this memo. 461 4.1.1 HIP Cookie Mechanism 463 The purpose of the HIP cookie mechanism is to protect the Responder 464 from a number of denial-of-service threats. It allows the Responder 465 to delay state creation until receiving I2. Furthermore, the puzzle 466 included in the cookie allows the Responder to use a fairly cheap 467 calculation to check that the Initiator is "sincere" in the sense 468 that it has churned CPU cycles in solving the puzzle. 470 The Cookie mechanism has been explicitly designed to give space for 471 various implementation options. It allows a responder implementation 472 to completely delay session specific state creation until a valid I2 473 is received. In such a case a validly formatted I2 can be rejected 474 earliest only once the Responder has checked its validity by 475 computing one hash function. On the other hand, the design also 476 allows a responder implementation to keep state about received I1s, 477 and match the received I2s against the state, thereby allowing the 478 implementation to avoid the computational cost of the hash function. 479 The drawback of this latter approach is the requirement of creating 480 state. Finally, it also allows an implementation to use any 481 combination of the space-saving and computation-saving mechanisms. 483 One possible way for a Responder to remain stateless but drop most 484 spoofed I2s is to base the selection of the cookie on some function 485 over the Initiator's Host Identity. The idea is that the Responder 486 has a (perhaps varying) number of pre-calculated R1 packets, and it 487 selects one of these based on the information carried in I1. When 488 the Responder then later receives I2, it checks that the cookie in 489 the I2 matches with the cookie sent in the R1, thereby making it 490 impractical for the attacker to first exchange one I1/R1, and then 491 generate a large number of spoofed I2s that seemingly come from 492 different IP addresses or use different HITs. The method does not 493 protect from an attacker that uses fixed IP addresses and HITs, 494 though. Against such an attacker it is probably best to create a 495 piece of local state, and remember that the puzzle check has 496 previously failed. See Appendix D for one possible implementation. 497 Note, however, that the implementations MUST NOT use the exact 498 implementation given in the appendix, and SHOULD include sufficient 499 randomness to the algorithm so that algorithm complexity attacks 500 become impossible [25]. 502 The Responder can set the difficulty for Initiator, based on its 503 concern of trust of the Initiator. The Responder SHOULD use 504 heuristics to determine when it is under a denial-of-service attack, 505 and set the difficulty value K appropriately. 507 The Responder starts the cookie exchange when it receives an I1. The 508 Responder supplies a random number I, and requires the Initiator to 509 find a number J. To select a proper J, the Initiator must create the 510 concatenation of I, the HITs of the parties, and J, and take a SHA-1 511 hash over this concatenation. The lowest order K bits of the result 512 MUST be zeros. 514 To generate a proper number J, the Initiator will have to generate a 515 number of Js until one produces the hash target of zero. The 516 Initiator SHOULD give up after trying 2^(K+2) times, and start over 517 the exchange. (See Appendix C.) The Responder needs to re-create 518 the concatenation of I, the HITs, and the provided J, and compute the 519 hash once to prove that the Initiator did its assigned task. 521 To prevent pre-computation attacks, the Responder MUST select the 522 number I in such a way that the Initiator cannot guess it. 523 Furthermore, the construction MUST allow the Responder to verify that 524 the value was indeed selected by it and not by the Initiator. See 525 Appendix D for an example on how to implement this. 527 Using the Opaque data field in the ECHO_REQUEST, the Responder can 528 include some data in R1 that the Initiator must copy unmodified in 529 the corresponding I2 packet. The Responder can generate the Opaque 530 data e.g. using the sent I, some secret and possibly other related 531 data. Using this same secret, received I in I2 packet and possible 532 other data, the Receiver can verify that it has itself sent the I to 533 the Initiator. The Responder must change the secret periodically. 535 It is RECOMMENDED that the Responder generates a new cookie and a new 536 R1 once every few minutes. Furthermore, it is RECOMMENDED that the 537 Responder remembers an old cookie at least 60 seconds after it has 538 been deprecated. These time values allow a slower Initiator to solve 539 the cookie puzzle while limiting the usability that an old, solved 540 cookie has to an attacker. 542 NOTE: The protocol developers explicitly considered whether R1 should 543 include a timestamp in order to protect the Initiator from replay 544 attacks. The decision was NOT to include a timestamp. 546 In R1, the values I and K are sent in network byte order. Similarly, 547 in I2 the values I and J are sent in network byte order. The SHA-1 548 hash is created by concatenating, in network byte order, the 549 following data, in the following order: 550 64-bit random value I, in network byte order, as appearing in R1 551 and I2. 552 128-bit initiator HIT, in network byte order, as appearing in the 553 HIP Payload in R1 and I2. 554 128-bit responder HIT, in network byte order, as appearing in the 555 HIP Payload in R1 and I2. 557 64-bit random value J, in network byte order, as appearing in I2. 558 In order to be a valid response cookie, the K low-order bits of the 559 resulting SHA-1 digest must be zero. 561 Notes: 562 The length of the data to be hashed is 48 bytes. 563 All the data in the hash input MUST be in network byte order. 564 The order of the initiator and responder HITs are different in the 565 R1 and I2 packets, see Section 6.1. Care must be taken to copy 566 the values in right order to the hash input. 568 Precomputation by the Responder 570 Sets up the challenge difficulty K. 571 Creates a signed R1 and caches it. 572 Responder 574 Selects a suitable cached R1. 575 Generates a random number I. 576 Sends I and K in a HIP Cookie in the R1. 577 Saves I and K for a Delta time. 578 Initiator 580 Generates repeated attempts to solve the challenge until a 581 matching J is found: 583 Ltrunc( SHA-1( I | HIT-I | HIT-R | J ), K ) == 0 584 Sends I and J in HIP Cookie in a I2. 585 Responder 587 Verifies that the received I is a saved one. 588 Finds the right K based on I. 589 Computes V := Ltrunc( SHA-1( I | HIT-I | HIT-R | J ), K ) 590 Rejects if V != 0 591 Accept if V == 0 593 The Ltrunc (SHA-1(), K) denotes the lowest order K bits of the SHA-1 594 result. 596 4.1.2 Authenticated Diffie-Hellman protocol 598 The packets R1, I2, and R2 implement a standard authenticated 599 Diffie-Hellman exchange. The Responder sends its public 600 Diffie-Hellman key and its public authentication key, i.e., its host 601 identity, in R1. The signature in R1 allows the Initiator to verify 602 that the R1 has been once generated by the Responder. However, since 603 it is precomputed and therefore does not cover all of the packet, it 604 does not protect from replay attacks. 606 When the Initiator receives an R1, it computes the Diffie-Hellman 607 session key. It creates a HIP security association using keying 608 material from the session key (see Section 9), and uses the security 609 association to encrypt its public authentication key, i.e., host 610 identity. The resulting I2 contains the Initiator's Diffie-Hellman 611 key and its the encrypted public authentication key. The signature 612 in I2 covers all of the packet. 614 The Responder extracts the Initiator Diffie-Hellman public key from 615 the I2, computes the Diffie-Hellman session key, creates a 616 corresponding HIP security association, and decrypts the Initiator's 617 public authentication key. It can then verify the signature using 618 the authentication key. 620 The final message, R2, is needed to protect the Initiator from replay 621 attacks. 623 4.1.3 HIP replay protection 625 The HIP protocol includes the following mechanisms to protect against 626 malicious replays. Responders are protected against replays of I1 627 packets by virtue of the stateless response to I1s with presigned R1 628 messages. Initiators are protected against R1 replays by a 629 monotonically increasing "R1 generation counter" included in the R1. 630 Responders are protected against replays or false I2s by the cookie 631 mechanism (Section 4.1.1 above), and optional use of opaque data. 632 Hosts are protected against replays to R2s and UPDATEs by use of a 633 less expensive HMAC verification preceding HIP signature 634 verification. 636 The R1 generation counter is a monotonically increasing 64-bit 637 counter that may be initialized to any value. The scope of the 638 counter MAY be system-wide but SHOULD be per host identity, if there 639 is more than one local host identity. The value of this counter 640 SHOULD be kept across system reboots and invocations of the HIP 641 signaling process. This counter indicates the current generation of 642 cookie puzzles. Implementations MUST accept puzzles from the current 643 generation and MAY accept puzzles from earlier generations. A 644 system's local counter MUST be incremented at least as often as every 645 time old R1s cease to be valid, and SHOULD never be decremented, lest 646 the host expose its peers to the replay of previously generated, 647 higher numbered R1s. Also, the R1 generation counter MUST NOT roll 648 over; if the counter is about to become exhausted, the corresponding 649 HI must be abandoned and replaced with a new one. 651 A host may receive more than one R1, either due to sending multiple 652 I1s (Section 8.4.1) or due to a replay of an old R1. When sending 653 multiple I1s, an initiator SHOULD wait for a small amount of time 654 after the first R1 reception to allow possibly multiple R1s to 655 arrive, and it SHOULD respond to an R1 among the set with the largest 656 R1 generation counter. If an initiator is processing an R1 or has 657 already sent an I2 (still waiting for R2) and it receives another R1 658 with a larger R1 generation counter, it MAY elect to restart R1 659 processing with the fresher R1, as if it were the first R1 to arrive. 661 Upon conclusion of an active HIP association with another host, the 662 R1 generation counter associated with the peer host SHOULD be 663 flushed. A local policy MAY override the default flushing of R1 664 counters on a per-HIT basis. The reason for recommending the 665 flushing of this counter is that there may be hosts where the R1 666 generation counter (occasionally) decreases; e.g., due to hardware 667 failure. 669 4.2 TCP and UDP pseudo-header computation 671 When computing TCP and UDP checksums on sockets bound to HITs or 672 LSIs, the IPv6 pseudo-header format [11] MUST be used. Additionally, 673 the HITs MUST be used in the place of the IPv6 addresses in the IPv6 674 pseudo-header. Note that the pseudo-header for actual HIP payloads 675 is computed differently; see Section 6.1.2. 677 4.3 Updating a HIP association 679 A HIP association between two hosts may need to be updated over time. 680 Examples include the need to rekey expiring security associations, 681 add new security associations, or change IP addresses associated with 682 hosts. This document only specifies how UPDATE is used for rekeying; 683 other uses are deferred to other drafts. 685 HIP provides a general purpose UPDATE packet, which can carry 686 multiple HIP parameters, for updating the HIP state between two 687 peers. The UPDATE mechanism has the following properties: 688 UPDATE messages carry a monotonically increasing sequence number 689 and are explicitly acknowledged by the peer. Lost UPDATEs or 690 acknowledgments may be recovered via retransmission. Multiple 691 UPDATE messages may be outstanding. 692 UPDATE is protected by both HMAC and HIP_SIGNATURE parameters, 693 since processing UPDATE signatures alone is a potential DoS attack 694 against intermediate systems. 696 The UPDATE packet is defined in Section 7.5. 698 4.4 Error processing 700 HIP error processing behaviour depends on whether there exists an 701 active HIP association or not. In general, if an HIP security 702 association exists between the sender and receiver of a packet 703 causing an error condition, the receiver SHOULD respond with a NOTIFY 704 packet. On the other hand, if there are no existing HIP security 705 associations between the sender and receiver, or the receiver cannot 706 reasonably determine the identity of the sender, the receiver MAY 707 respond with a suitable ICMP message; see Section 6.3 for more 708 details. 710 4.5 Bootstrap support 712 This memo defines an OPTIONAL HIP based bootstrap mechanism, intended 713 for ad hoc like environments; see Section 7.6. There is little 714 operational experience of the usability of this mechanism, and it may 715 be dropped or completely revised in some future protocol version. 717 4.6 Certificate distribution 719 HIP does not define how to use certificates. However, it does define 720 a simple certificate transport mechanisms that MAY be used to 721 implement certificate based security policies. The certificate 722 payload is defined in Section 6.2.11, and the certificate packet in 723 Section 7.7. 725 4.7 Sending data on HIP packets 727 A future version of this document may define how to include ESP 728 protected data on various HIP packets. However, currently the HIP 729 header is a terminal header, and not followed by any other headers. 731 The OPTIONAL PAYLOAD packet (see Section 7.9) MAY be used to transfer 732 data. 734 5. HIP protocol overview 736 The following material is an overview of the HIP protocol operation. 737 Section 8 describes the packet processing steps in more detail. 739 A typical HIP packet flow is shown below, between an Initiator (I) 740 and a Responder (R). It illustrates the exchange of four HIP packets 741 (I1, R1, I2, and R2). 743 I --> Directory: lookup R 744 I <-- Directory: return R's addresses, and HI and/or HIT 745 I1 I --> R (Hi. Here is my I1, let's talk HIP) 746 R1 I <-- R (OK. Here is my R1, handle this HIP cookie) 747 I2 I --> R (Compute, compute, here is my counter I2) 748 R2 I <-- R (OK. Let's finish HIP with my R2) 749 I --> R (ESP protected data) 750 I <-- R (ESP protected data) 752 By definition, the system initiating a HIP exchange is the Initiator, 753 and the peer is the Responder. This distinction is forgotten once 754 the base exchange completes, and either party can become the 755 initiator in future communications. 757 5.1 HIP Scenarios 759 The HIP protocol and state machine is designed to recover from one of 760 the parties crashing and losing its state. The following scenarios 761 describe the main use cases covered by the design. 762 No prior state between the two systems. 763 The system with data to send is the Initiator. The process 764 follows the standard four packet base exchange, establishing 765 the SAs. 766 The system with data to send has no state with the receiver, but 767 the receiver has a residual SA. 768 The system with data to send is the Initiator. The Initiator 769 acts as in no prior state, sending I1 and getting R1. When the 770 Responder receives a valid I2, the old SAs are 'discovered' and 771 deleted, and the new SAs are established. 772 The system with data to send has an SA, but the receiver does not. 773 The system sends data on the outbound SA. The receiver 774 'detects' the situation when it receives an ESP packet that 775 contains an unknown SPI. The receiving host MUST discard this 776 packet, in accordance with IPsec architecture. Optionally, the 777 receiving host MAY send an ICMP packet with the Parameter 778 Problem type to inform about invalid SPI (see Section 6.3, and 779 it MAY initiate a new HIP negotiation. However, responding 780 with these optional mechanisms is implementation or policy 781 dependent. 783 A system determines that it needs to reset ESP Sequence Number, or 784 rekey. 785 The system sends a HIP UPDATE packet. The peer responds with a 786 HIP UPDATE response. The UPDATE exchanges can refresh or 787 establish new SAs for peers. 789 5.2 Refusing a HIP exchange 791 A HIP aware host may choose not to accept a HIP exchange. If the 792 host's policy is to only be an Initiator, it should begin its own HIP 793 exchange. A host MAY choose to have such a policy since only the 794 Initiator HI is protected in the exchange. There is a risk of a race 795 condition if each host's policy is to only be an Initiator, at which 796 point the HIP exchange will fail. 798 If the host's policy does not permit it to enter into a HIP exchange 799 with the Initiator, it should send an ICMP 'Destination Unreachable, 800 Administratively Prohibited' message. A more complex HIP packet is 801 not used here as it actually opens up more potential DoS attacks than 802 a simple ICMP message. 804 5.3 Reboot and SA timeout restart of HIP 806 Simulating a loss of state is a potential DoS attack. The following 807 process has been crafted to manage state recovery without presenting 808 a DoS opportunity. 810 If a host reboots or times out, it has lost its HIP state. If the 811 system that lost state has a datagram to deliver to its peer, it 812 simply restarts the HIP exchange. The peer replies with an R1 HIP 813 packet, but does not reset its state until it receives the I2 HIP 814 packet. The I2 packet MUST have a valid solution to the puzzle and, 815 if inserted in R1, a valid Opaque data as well as a valid signature. 816 Note that either the original Initiator or the Responder could end up 817 restarting the exchange, becoming the new Initiator. 819 If a system receives an ESP packet for an unknown SPI, it is possible 820 that it has lost the state and its peer has not. It MAY send an ICMP 821 packet with the Parameter Problem type, the Pointer pointing to the 822 SPI value within the ESP header. Reacting to ESP traffic with unknown 823 SPI depends on the implementation and the environment where the 824 implementation is used. 826 The initiating host cannot know, if the SA indicated by the received 827 ESP packet is either a HIP SA or and IKE SA. If the old SA was not a 828 HIP SA, the peer may not respond to the I1 packet. 830 After sending the I1, the HIP negotiation proceeds as normally and, 831 when successful, the SA is created at the initiating end. The peer 832 end removes the OLD SA and replaces it with the new one. 834 5.4 HIP State Machine 836 The HIP protocol itself has very little state. In the HIP base 837 exchange, there is an Initiator and a Responder. Once the SAs are 838 established, this distinction is lost. If the HIP state needs to be 839 re-established, the controlling parameters are which peer still has 840 state and which has a datagram to send to its peer. The following 841 state machine attempts to capture these processes. 843 The state machine is presented in a single system view, representing 844 either an Initiator or a Responder. There is not a complete overlap 845 of processing logic here and in the packet definitions. Both are 846 needed to completely implement HIP. 848 Implementors must understand that the state machine, as described 849 here, is informational. Specific implementations are free to 850 implement the actual functions differently. Section 8 describes the 851 packet processing rules in more detail. This state machine focuses 852 on the HIP I1, R1, I2, R2, and UPDATE packets only, and specifically, 853 the state induced by an UPDATE that triggers a rekeying event. Other 854 states may be introduced by mechanisms in other drafts (such as 855 mobility and multihoming). 857 5.4.1 HIP States 859 UNASSOCIATED State machine start 860 I1-SENT Initiating HIP 861 I2-SENT Waiting to finish HIP 862 R2-SENT Waiting to finish HIP 863 ESTABLISHED HIP SA established 864 REKEYING HIP SA established, but UPDATE is outstanding for rekeying 865 E-FAILED HIP exchange failed 867 5.4.2 HIP State Processes 869 +------------+ 870 |UNASSOCIATED| Start state 871 +------------+ 873 Datagram to send requiring a new SA, send I1 and go to I1-SENT 874 Receive I1, send R1 and stay at UNASSOCIATED 875 Receive I2, process 876 if successful, send R2 and go to R2-SENT 877 if fail, stay at UNASSOCIATED 879 Receive ESP for unknown SA, optionally send ICMP as defined 880 in 881 Section 6.3 882 and stay at UNASSOCIATED 883 Receive ANYOTHER, drop and stay at UNASSOCIATED 885 +---------+ 886 | I1-SENT | Initiating HIP 887 +---------+ 889 Receive I1, send R1 and stay at I1-SENT 890 Receive I2, process 891 if successful, send R2 and go to R2-SENT 892 if fail, stay at I1-SENT 893 Receive R1, process 894 if successful, send I2 and go to I2-SENT 895 if fail, go to E-FAILED 897 Receive ANYOTHER, drop and stay at I1-SENT 898 Timeout, increment timeout counter 899 If counter is less than I1_RETRIES_MAX, send I1 and stay at I1-SENT 900 If counter is greater than I1_RETRIES_MAX, go to E-FAILED 902 +---------+ 903 | I2-SENT | Waiting to finish HIP 904 +---------+ 906 Receive I1, send R1 and stay at I2-SENT 907 Receive R1, process 908 if successful, send I2 and cycle at I2-SENT 909 if fail, stay at I2-SENT 910 Receive I2, process 911 if successful, send R2 and go to R2-SENT 912 if fail, stay at I2-SENT 913 Receive R2, process 914 if successful, go to ESTABLISHED 915 if fail, go to E-FAILED 917 Receive ANYOTHER, drop and stay at I2-SENT 918 Timeout, increment timeout counter 919 If counter is less than I2_RETRIES_MAX, send I2 and stay at I2-SENT 920 If counter is greater than I2_RETRIES_MAX, go to E-FAILED 922 +---------+ 923 | R2-SENT | Waiting to finish HIP 924 +---------+ 926 Receive I1, send R1 and stay at R2-SENT 927 Receive I2, process, 928 if successful, send R2, and cycle at R2-SENT 929 if failed, stay at R2-SENT 930 Receive R1, drop and stay at R2-SENT 931 Receive R2, drop and stay at R2-SENT 933 Receive ESP for SA, process and go to ESTABLISHED 934 Receive UPDATE, go to ESTABLISHED and process from ESTABLISHED state 936 Move to ESTABLISHED after an implementation specific time. 938 +------------+ 939 |ESTABLISHED | HIP SA established 940 +------------+ 942 Receive I1, send R1 and stay at ESTABLISHED 944 Receive I2, process with cookie and possible Opaque data verification 945 if successful, send R2, drop old SAs, establish new SA, go to 946 R2-SENT 947 if fail, stay at ESTABLISHED 948 Receive R1, drop and stay at ESTABLISHED 949 Receive R2, drop and stay at ESTABLISHED 951 Receive ESP for SA, process and stay at ESTABLISHED 952 Receive UPDATE, process 953 if successful, send UPDATE in reply and go to REKEYING 954 if failed, stay at ESTABLISHED 955 Need rekey, 956 send UPDATE and go to REKEYING 958 +----------+ 959 | REKEYING | HIP SA established, rekey pending 960 +----------+ 962 Receive I1, send R1 and stay at REKEYING 964 Receive I2, process with cookie and possible Opaque data verification 965 if successful, send R2, drop old SA and go to R2-SENT 966 if fail, stay at REKEYING 967 Receive R1, drop and stay at REKEYING 968 Receive R2, drop and stay at REKEYING 970 Receive ESP for SA, process and stay at REKEYING 971 Receive UPDATE, process 972 if successful completion of rekey, go to ESTABLISHED 973 if failed, stay at REKEYING 974 Timeout, increment timeout counter 975 If counter is less than UPDATE_RETRIES_MAX, send UPDATE and stay at 976 REKEYING 977 If counter is greater than UPDATE_RETRIES_MAX, go to E-FAILED 979 +----------+ 980 | E-FAILED | HIP failed to establish association with peer 981 +----------+ 983 Move to UNASSOCIATED after an implementation specific time. Re-negotiation 984 is possible after moving to UNASSOCIATED state. 986 5.4.3 Simplified HIP State Diagram 988 The following diagram shows the major state transitions. Transitions 989 based on received packets implicitly assume that the packets are 990 successfully authenticated or processed. The diagram assumes that 991 UPDATE messages are being used for rekeying. 993 +-+ 994 | | I1 received, send R1 995 v | 996 Datagram to send +--------------+ I2 received, send R2 997 +---------------| UNASSOCIATED |---------------+ 998 | +--------------+ | 999 v | 1000 +---------+ I2 received, send R2 | 1001 | I1-SENT |---------------------------------------+ | 1002 +---------+ | | 1003 | +------------------------+ | | 1004 | R1 received, | I2 received, send R2 | | | 1005 v send I2 | v v v 1006 +---------+ | +---------+ 1007 | I2-SENT |------------+ | R2-SENT | 1008 +---------+ +---------+ 1009 | | ^ 1010 | | | 1011 | | | 1012 | timeout, | | 1013 | R2 received +--------------+ ESP | | 1014 +-------------->| ESTABLISHED |<---------+ | 1015 +--------------+ | 1016 Update received/ | ^ | I2 | 1017 Update triggered | | +---------------+ 1018 +------------------+ | 1019 | | 1020 v | 1021 +----------+ | 1022 | REKEYING |---------------+ 1023 +----------+ UPDATE acked and NES received 1025 6. Packet formats 1027 6.1 Payload format 1029 All HIP packets start with a fixed header. 1031 0 1 2 3 1032 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 1033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1034 | Next Header | Payload Len | Type | VER. | RES. | 1035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1036 | Controls | Checksum | 1037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1038 | Sender's Host Identity Tag (HIT) | 1039 | | 1040 | | 1041 | | 1042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1043 | Receiver's Host Identity Tag (HIT) | 1044 | | 1045 | | 1046 | | 1047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1048 | | 1049 / HIP Parameters / 1050 / / 1051 | | 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1054 The HIP header is logically an IPv6 extension header. However, this 1055 document does not describe processing for Next Header values other 1056 than decimal 59, IPPROTO_NONE, the IPV6 no next header value. Future 1057 documents MAY do so. However, implementations MUST ignore trailing 1058 data if a Next Header value is received that is not implemented. 1060 The Header Length field contains the length of the HIP Header and the 1061 length of HIP parameters in 8 bytes units, excluding the first 8 1062 bytes. Since all HIP headers MUST contain the sender's and 1063 receiver's HIT fields, the minimum value for this field is 4, and 1064 conversely, the maximum length of the HIP Parameters field is 1065 (255*8)-32 = 2008 bytes. Note: this sets an additional limit for 1066 sizes of TLVs included in the Parameters field, independent of the 1067 individual TLV parameter maximum lengths. 1069 The Packet Type indicates the HIP packet type. The individual packet 1070 types are defined in the relevant sections. If a HIP host receives a 1071 HIP packet that contains an unknown packet type, it MUST drop the 1072 packet. 1074 The HIP Version is four bits. The current version is 1. The version 1075 number is expected to be incremented only if there are incompatible 1076 changes to the protocol. Most extensions can be handled by defining 1077 new packet types, new parameter types, or new controls. 1079 The following four bits are reserved for future use. They MUST be 1080 zero when sent, and they SHOULD be ignored when handling a received 1081 packet. 1083 The HIT fields are always 128 bits (16 bytes) long. 1085 6.1.1 HIP Controls 1087 The HIP control section transfers information about the structure of 1088 the packet and capabilities of the host. 1090 The following fields have been defined: 1092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1093 | | | | | | | | | | | | | | |C|A| 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1096 C - Certificate One or more certificate packets (CER) follows this 1097 HIP packet (see Section 7.7). 1098 A - Anonymous If this is set, the sender's HI in this packet is 1099 anonymous, i.e., one not listed in a directory. Anonymous HIs 1100 SHOULD NOT be stored. This control is set in packets R1 and/or 1101 I2. The peer receiving an anonymous HI may choose to refuse it by 1102 silently dropping the exchange. 1103 The rest of the fields are reserved for future use and MUST be set to 1104 zero on sent packets and ignored on received packets. 1106 6.1.2 Checksum 1108 The checksum field is located at the same location within the header 1109 as the checksum field in UDP packets, enabling hardware assisted 1110 checksum generation and verification. Note that since the checksum 1111 covers the source and destination addresses in the IP header, it must 1112 be recomputed on HIP based NAT boxes. 1114 If IPv6 is used to carry the HIP packet, the pseudo-header [11] 1115 contains the source and destination IPv6 addresses, HIP packet length 1116 in the pseudo-header length field, a zero field, and the HIP protocol 1117 number (TBD, see Section 4) in the Next Header field. The length 1118 field is in bytes and can be calculated from the HIP header length 1119 field: (HIP Header Length + 1) * 8. 1121 In case of using IPv4, the IPv4 UDP pseudo header format [1] is used. 1122 In the pseudo header, the source and destination addresses are those 1123 used in the IP header, the zero field is obviously zero, the protocol 1124 is the HIP protocol number (TBD, see Section 4), and the length is 1125 calculated as in the IPv6 case. 1127 6.2 HIP parameters 1129 The HIP Parameters are used to carry the public key associated with 1130 the sender's HIT, together with other related security information. 1131 The HIP Parameters consists of ordered parameters, encoded in TLV 1132 format. 1134 The following parameter types are currently defined. 1136 TLV Type Length Data 1138 SPI 1 4 Remote's SPI. 1140 R1_COUNTER 2 12 System Boot Counter 1142 PUZZLE 5 12 K and Random #I 1144 SOLUTION 7 20 K, Random #I and puzzle solution 1146 NES 9 12 Old SPI, New SPI and other 1147 info needed for UPDATE 1149 SEQ 11 4 Update packet ID number 1151 ACK 13 variable Update packet ID number 1153 DIFFIE_HELLMAN 15 variable public key 1155 HIP_TRANSFORM 17 variable HIP Encryption and Integrity 1156 Transform 1158 ESP_TRANSFORM 19 variable ESP Encryption and 1159 Authentication Transform 1161 ENCRYPTED 21 variable Encrypted part of I2 or CER 1162 packets 1164 HOST_ID 35 variable Host Identity with Fully 1165 Qualified Domain Name 1167 CERT 64 variable HI certificate 1169 NOTIFY 256 variable Informational data 1171 ECHO_REQUEST 1022 variable Opaque data to be echoed back; 1172 under signature 1174 ECHO_RESPONSE 1024 variable Opaque data echoed back; under 1175 signature 1177 HMAC 65245 20 HMAC based message 1178 authentication code, with 1179 key material from HIP_TRANSFORM 1181 HIP_SIGNATURE_2 65277 variable Signature of the R1 packet 1183 HIP_SIGNATURE 65279 variable Signature of the packet 1185 ECHO_REQUEST 65281 variable Opaque data to be echoed back 1187 ECHO_RESPONSE 65283 variable Opaque data echoed back; after 1188 signature 1190 6.2.1 TLV format 1192 The TLV encoded parameters are described in the following 1193 subsections. The type-field value also describes the order of these 1194 fields in the packet. The parameters MUST be included into the 1195 packet so that the types form an increasing order. If the order does 1196 not follow this rule, the packet is considered to be malformed and it 1197 MUST be discarded. 1199 All the TLV parameters have a length (including Type and Length 1200 fields) which is a multiple of 8 bytes. When needed, padding MUST be 1201 added to the end of the parameter so that the total length becomes a 1202 multiple of 8 bytes. This rule ensures proper alignment of data. If 1203 padding is added, the Length field MUST NOT include the padding. Any 1204 added padding bytes MUST be set zero by the sender, but their content 1205 SHOULD NOT be checked on the receiving end. 1207 Consequently, the Length field indicates the length of the Contents 1208 field (in bytes). The total length of the TLV parameter (including 1209 Type, Length, Contents, and Padding) is related to the Length field 1210 according to the following formula: 1212 Total Length = 11 + Length - (Length + 3) % 8; 1213 0 1 2 3 1214 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 1215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1216 | Type |C| Length | 1217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1218 | | 1219 / Contents / 1220 / +-+-+-+-+-+-+-+-+ 1221 | | Padding | 1222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1224 Type Type code for the parameter 1225 C Critical. One if this parameter is critical, and 1226 MUST be recognized by the recipient, zero otherwise. 1227 The C bit is considered to be a part of the Type field. 1228 Consequently, critical parameters are always odd 1229 and non-critical ones have an even value. 1230 Length Length of the Contents, in bytes. 1231 Contents Parameter specific, defined by Type 1232 Padding Padding, 0-7 bytes, added if needed 1234 Critical parameters MUST be recognized by the recipient. If a 1235 recipient encounters a critical parameter that it does not recognize, 1236 it MUST NOT process the packet any further. 1238 Non-critical parameters MAY be safely ignored. If a recipient 1239 encounters a non-critical parameter that it does not recognize, it 1240 SHOULD proceed as if the parameter was not present in the received 1241 packet. 1243 6.2.2 Defining new parameters 1245 Future specifications may define new parameters as needed. When 1246 defining new parameters, care must be taken to ensure that the 1247 parameter type values are appropriate and leave suitable space for 1248 other future extensions. One must remember that the parameters MUST 1249 always be arranged in the increasing order by the type code, thereby 1250 limiting the order of parameters. 1252 The following rules must be followed when defining new parameters. 1253 1. The low order bit C of the Type code is used to distinguish 1254 between critical and non-critical parameters. 1255 2. A new parameter may be critical only if an old recipient ignoring 1256 it would cause security problems. In general, new parameters 1257 SHOULD be defined as non-critical, and expect a reply from the 1258 recipient. 1259 3. If a system implements a new critical parameter, it MUST provide 1260 the ability to configure the associated feature off, such that 1261 the critical parameter is not sent at all. The configuration 1262 option must be well documented. By default, sending of such a new 1263 critical parameter SHOULD be off. In other words, the management 1264 interface MUST allow vanilla standards only mode as a default 1265 configuration setting, and MAY allow new critical payloads to be 1266 configured on (and off). 1267 4. The following type codes are reserved for future base protocol 1268 extensions, and may be assigned only through an appropriate WG or 1269 RFC action. 1270 0 - 511 1271 65024 - 65535 1272 5. The following type codes are reserved for experimentation and 1273 private use. Types SHOULD be selected in a random fashion from 1274 this range, thereby reducing the probability of collisions. A 1275 method employing genuine randomness (such as flipping a coin) 1276 SHOULD be used. 1277 32768 - 49141 1278 6. All other parameter type codes MUST be registered by the IANA. 1279 See Section 14. 1281 6.2.3 SPI 1283 The SPI parameter contains the SPI that the receiving host must use 1284 when sending data to the sending host. It may be possible, in future 1285 extensions of this protocol, for multiple SPIs to exist in a 1286 host-host communications context. 1288 0 1 2 3 1289 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 1290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1291 | Type | Length | 1292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1293 | SPI | 1294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1296 Type 1 1297 Length 4 1298 SPI Security Parameter Index 1300 6.2.4 R1_COUNTER 1302 0 1 2 3 1303 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 1304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1305 | Type | Length | 1306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1307 | Reserved, 4 bytes | 1308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1309 | R1 generation counter, 8 bytes | 1310 | | 1311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1313 Type 2 1314 Length 12 1315 R1 generation 1316 counter The current generation of valid puzzles 1318 The R1_COUNTER parameter contains an 64-bit unsigned integer in 1319 network byte order, indicating the current generation of valid 1320 puzzles. The sender is supposed to increment this counter 1321 periodically. It is RECOMMENDED that the counter value is 1322 incremented at least as often as old PUZZLE values are deprecated so 1323 that SOLUTIONs to them are no longer accepted. 1325 The R1_COUNTER parameter is optional. It SHOULD be included in the 1326 R1 (in which case it is covered by the signature), and if present in 1327 the R1, it MAY be echoed (including the Reserved field) by the 1328 Initiator in the I2. 1330 6.2.5 PUZZLE 1332 0 1 2 3 1333 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 1334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1335 | Type | Length | 1336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1337 | K, 1 byte | Opaque, 3 bytes | 1338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1339 | Random # I, 8 bytes | 1340 | | 1341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1343 Type 5 1344 Length 12 1345 K K is the number of verified bits 1346 Opaque Data set by the Responder, indexing the puzzle 1347 Random #I random number 1349 Random #I is represented as 64-bit integer, K as 8-bit integer, all 1350 in network byte order. 1352 The PUZZLE parameter contains the puzzle difficulty K and an 64-bit 1353 puzzle random integer #I. A puzzle MAY be augmented by including an 1354 ECHO_REQUEST parameter to an R1. The contents of the ECHO_REQUEST 1355 are then echoed back in ECHO_RESPONSE, allowing the Responder to use 1356 the included information as a part of puzzle processing. 1358 The Opaque and Random #I field are not covered by the HIP_SIGNATURE_2 1359 parameter. 1361 6.2.6 SOLUTION 1363 0 1 2 3 1364 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 1365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1366 | Type | Length | 1367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1368 | K, 1 byte | Opaque, 3 bytes | 1369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1370 | Random #I, 8 bytes | 1371 | | 1372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1373 | Puzzle solution #J, 8 bytes | 1374 | | 1375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1377 Type 7 1378 Length 20 1379 K K is the number of verified bits 1380 Opaque Copied unmodified from the received PUZZLE TLV 1381 Random #I random number 1382 Puzzle solution 1383 #J random number 1385 Random #I, and Random #J are represented as 64-bit integers, K as 1386 8-bit integer, all in network byte order. 1388 The SOLUTION parameter contains a solution to a puzzle. It also 1389 echoes back the random difficulty K, the Opaque field, and the puzzle 1390 integer #I. 1392 6.2.7 DIFFIE_HELLMAN 1394 0 1 2 3 1395 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 1396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1397 | Type | Length | 1398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1399 | Group ID | Public Value / 1400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1401 / | padding | 1402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1404 Type 15 1405 Length length in octets, excluding Type, Length, and padding 1406 Group ID defines values for p and g 1407 Public Value the sender's public Diffie-Hellman key 1409 The following Group IDs have been defined: 1411 Group Value 1412 Reserved 0 1413 384-bit group 1 1414 OAKLEY well known group 1 2 1415 1536-bit MODP group 3 1416 3072-bit MODP group 4 1417 6144-bit MODP group 5 1418 8192-bit MODP group 6 1420 The MODP Diffie-Hellman groups are defined in [17]. The OAKLEY group 1421 is defined in [9]. The OAKLEY well known group 5 is the same as the 1422 1536-bit MODP group. 1424 A HIP implementation MUST support Group IDs 1 and 3. The 384-bit 1425 group can be used when lower security is enough (e.g. web surfing) 1426 and when the equipment is not powerful enough (e.g. some PDAs). 1427 Equipment powerful enough SHOULD implement also group ID 5. The 1428 384-bit group is defined in Appendix G. 1430 To avoid unnecessary failures during the 4-way handshake, the rest of 1431 the groups SHOULD be implemented in hosts where resources are 1432 adequate. 1434 6.2.8 HIP_TRANSFORM 1436 0 1 2 3 1437 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1439 | Type | Length | 1440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1441 | Transform-ID #1 | Transform-ID #2 | 1442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1443 | Transform-ID #n | Padding | 1444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1446 Type 17 1447 Length length in octets, excluding Type, Length, and padding 1448 Transform-ID Defines the HIP Suite to be used 1450 The Suite-IDs are identical to those defined in Section 6.2.9. 1452 There MUST NOT be more than six (6) HIP Suite-IDs in one HIP 1453 transform TLV. The limited number of transforms sets the maximum size 1454 of HIP_TRANSFORM TLV. The HIP_TRANSFORM TLV MUST contain at least one 1455 of the mandatory Suite-IDs. 1457 Mandatory implementations: ENCR-3DES-CBC with HMAC-SHA1 and ENCR-NULL 1458 with HMAC-SHA1. 1460 6.2.9 ESP_TRANSFORM 1462 0 1 2 3 1463 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 1464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1465 | Type | Length | 1466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1467 | Reserved |E| Suite-ID #1 | 1468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1469 | Suite-ID #2 | Suite-ID #3 | 1470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1471 | Suite-ID #n | Padding | 1472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1474 Type 19 1475 Length length in octets, excluding Type, Length, and padding 1476 E One if the ESP transform requires 64-bit sequence 1477 numbers 1478 (see 1479 Section 11.6 1480 ) 1481 Reserved zero when sent, ignored when received 1482 Suite-ID defines the ESP Suite to be used 1484 The following Suite-IDs are defined ([19],[22]): 1486 Suite-ID Value 1488 RESERVED 0 1489 ESP-AES-CBC with HMAC-SHA1 1 1490 ESP-3DES-CBC with HMAC-SHA1 2 1491 ESP-3DES-CBC with HMAC-MD5 3 1492 ESP-BLOWFISH-CBC with HMAC-SHA1 4 1493 ESP-NULL with HMAC-SHA1 5 1494 ESP-NULL with HMAC-MD5 6 1496 There MUST NOT be more than six (6) ESP Suite-IDs in one 1497 ESP_TRANSFORM TLV. The limited number of Suite-IDs sets the maximum 1498 size of ESP_TRANSFORM TLV. The ESP_TRANSFORM MUST contain at least 1499 one of the mandatory Suite-IDs. 1501 Mandatory implementations: ESP-3DES-CBC with HMAC-SHA1 and ESP-NULL 1502 with HMAC-SHA1. 1504 6.2.10 HOST_ID 1506 0 1 2 3 1507 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 1508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1509 | Type | Length | 1510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1511 | HI Length |DI-type| DI Length | 1512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1513 | Host Identity / 1514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1515 / | Domain Identifier / 1516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1517 / | Padding | 1518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1520 Type 35 1521 Length length in octets, excluding Type, Length, and 1522 Padding 1523 DI-type type of the following Domain Identifier field 1524 DI Length length of the FQDN or NAI in octets 1525 N if set, the following FQDN/NAI field contains a 1526 NAI 1527 Host Identity actual host identity 1528 Domain Identifier the identifier of the sender 1530 The Host Identity is represented in RFC2535 [12] format. The 1531 algorithms used in RDATA format are the following: 1533 Algorithms Values 1535 RESERVED 0 1536 DSA 3 [RFC2536] (REQUIRED) 1537 RSA 5 [RFC3110] (OPTIONAL) 1539 The following DI-types have been defined: 1541 Type Value 1542 none included 0 1543 FQDN 1 1544 NAI 2 1546 FQDN Fully Qualified Domain Name, in binary format. 1547 NAI Network Access Identifier, in binary format. The 1548 format of the NAI is login@FQDN. 1550 The format for the FQDN is defined in RFC1035 [3] Section 3.1. 1552 If there is no Domain Identifier, i.e. the DI-type field is zero, 1553 also the DI Length field is set to zero. 1555 6.2.11 CERT 1557 0 1 2 3 1558 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 1559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1560 | Type | Length | 1561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1562 | Cert count | Cert ID | Cert type | / 1563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1564 / Certificate / 1565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1566 / | Padding | 1567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1569 Type 64 1570 Length length in octets, excluding Type, Length, and padding 1571 Cert count total count of certificates that are sent, possibly 1572 in several consecutive CER packets 1573 Cert ID the order number for this certificate 1574 Cert Type describes the type of the certificate 1576 The receiver must know the total number (Cert count) of certificates 1577 that it will receive from the sender, related to the R1 or I2. The 1578 Cert ID identifies the particular certificate and its order in the 1579 certificate chain. The numbering in Cert ID MUST go from 1 to Cert 1580 count. 1582 The following certificate types are defined: 1584 Cert format Type number 1585 X.509 v3 1 1587 The encoding format for X.509v3 certificate is defined in [14]. 1589 6.2.12 HMAC 1591 0 1 2 3 1592 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 1593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1594 | Type | Length | 1595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1596 | | 1597 | HMAC | 1598 | | 1599 | | 1600 | | 1601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1603 Type 65245 1604 Length 20 1605 HMAC 160 low order bits of the HMAC computed over the HIP 1606 packet, excluding the HMAC parameter and any 1607 following HIP_SIGNATURE or HIP_SIGNATURE_2 1608 parameters. The checksum field MUST be set to zero 1609 and the HIP header length in the HIP common header 1610 MUST be calculated not to cover any excluded 1611 parameters when the HMAC is calculated. 1613 The HMAC calculation and verification process is presented in Section 1614 8.3.1 1616 6.2.13 HIP_SIGNATURE 1618 0 1 2 3 1619 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1621 | Type | Length | 1622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1623 | SIG alg | Signature / 1624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1625 / | Padding | 1626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1628 Type 65279 (2^16-2^8-1) 1629 Length length in octets, excluding Type, Length, and Padding 1630 SIG alg Signature algorithm 1631 Signature the signature is calculated over the HIP packet, 1632 excluding the HIP_SIGNATURE TLV field and any TLVs 1633 that follow the HIP_SIGNATURE TLV. The checksum field 1634 MUST be set to zero, and the HIP header length in the 1635 HIP common header MUST be calculated only to the 1636 beginning of the HIP_SIGNATURE TLV when the signature 1637 is calculated. 1639 The signature algorithms are defined in Section 6.2.10. The 1640 signature in the Signature field is encoded using the proper method 1641 depending on the signature algorithm (e.g. in case of DSA, according 1642 to [13]). 1644 The HIP_SIGNATURE calculation and verification process is presented 1645 in Section 8.3.2 1647 6.2.14 HIP_SIGNATURE_2 1649 The TLV structure is the same as in Section 6.2.13. The fields are: 1651 Type 65277 (2^16-2^8-3) 1652 Length length in octets, excluding Type, Length, and Padding 1653 SIG alg Signature algorithm 1654 Signature the signature is calculated over the HIP R1 packet, 1655 excluding the HIP_SIGNATURE_2 TLV field and any 1656 TLVs that follow the HIP_SIGNATURE_2 TLV. Initiator's 1657 HIT, checksum field, and the Opaque and Random #I 1658 fields in the PUZZLE TLV MUST be set to zero while 1659 computing the HIP_SIGNATURE_2 signature. Further, the 1660 HIP packet length in the HIP header MUST be 1661 calculated to the beginning of the HIP_SIGNATURE_2 1662 TLV when the signature is calculated. 1664 Zeroing the Initiator's HIT makes it possible to create R1 packets 1665 beforehand to minimize the effects of possible DoS attacks. Zeroing 1666 the I and Opaque fields allows these fields to be populated 1667 dynamically on precomputed R1s. 1669 Signature calculation and verification follows the process in Section 1670 8.3.2. 1672 6.2.15 NES 1674 During the life of an SA established by HIP, one of the hosts may 1675 need to reset the Sequence Number to one (to prevent wrapping) and 1676 rekey. The reason for rekeying might be an approaching sequence 1677 number wrap in ESP, or a local policy on use of a key. Rekeying ends 1678 the current SAs and starts new ones on both peers. 1680 The NES parameter is carried in the HIP UPDATE packet. It is used to 1681 reset Security Associations. It introduces a new SPI to be used when 1682 sending data to the sender of the UPDATE packet. The keys for the 1683 new Security Association will be drawn from KEYMAT. If the packet 1684 contains a Diffie-Hellman parameter, the KEYMAT is first recomputed 1685 before drawing the new keys. 1687 0 1 2 3 1688 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 1689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1690 | Type | Length | 1691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1692 | Reserved | Keymat Index | 1693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1694 | Old SPI | 1695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1696 | New SPI | 1697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1699 Type 9 1700 Length 12 1701 Keymat Index Index, in bytes, where to continue to draw ESP keys 1702 from KEYMAT. If the packet includes a new 1703 Diffie-Hellman key, the field MUST be zero. Note 1704 that the length of this field limits the amount of 1705 keying material that can be drawn from KEYMAT. If 1706 that amount is exceeded, the NES packet MUST contain 1707 a new Diffie-Hellman key. 1708 Old SPI Old SPI for data sent to the source address of 1709 this packet 1711 New SPI New SPI for data sent to the source address of 1712 this packet 1714 A host that receives an NES must reply shortly thereafter with an 1715 NES. Any middleboxes between the communicating hosts will learn the 1716 mappings from the pair of UPDATE messages. 1718 6.2.16 SEQ 1720 0 1 2 3 1721 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 1722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1723 | Type | Length | 1724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1725 | Update ID | 1726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1728 Type 11 1729 Length 4 1730 Update ID 32-bit sequence number 1732 The Update ID is an unsigned quantity, initialized by a host to zero 1733 upon moving to ESTABLISHED state. The Update ID has scope within a 1734 single HIP association, and not across multiple associations or 1735 multiple hosts. The Update ID is incremented by one before each new 1736 UPDATE that is sent by the host (i.e., the first UPDATE packet 1737 originated by a host has an Update ID of 1). 1739 6.2.17 ACK 1741 0 1 2 3 1742 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 1743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1744 | Type | Length | 1745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1746 | peer Update ID | 1747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1749 Type 13 1750 Length variable (multiple of 4) 1751 peer Update ID 32-bit sequence number corresponding to the 1752 Update ID being acked. 1754 The ACK parameter includes one or more Update IDs that have been 1755 received from the peer. The Length field identifies the number of 1756 peer Update IDs that are present in the parameter. 1758 6.2.18 ENCRYPTED 1760 0 1 2 3 1761 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 1762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1763 | Type | Length | 1764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1765 | Reserved | 1766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1767 | IV / 1768 / / 1769 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 1771 / Encrypted data / 1772 / / 1773 / +-------------------------------+ 1774 / | Padding | 1775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1777 Type 21 1778 Length length in octets, excluding Type, Length, and Padding 1779 Reserved zero when sent, ignored when received 1780 IV Initialization vector, if needed, otherwise nonexistent. 1781 The length of the IV is inferred from the HIP transform. 1782 Encrypted The data is encrypted using an encryption algorithm as 1783 data defined in HIP transform. 1784 Padding Any Padding, if necessary, to make the TLV a multiple 1785 of 8 bytes. 1787 The encrypted data is in TLV format itself. Consequently, the first 1788 fields in the contents are Type and Length, allowing the contents to 1789 be easily parsed after decryption. Each of the TLVs to be encrypted, 1790 must be padded according to rules in Section 6.2.1 before encryption. 1792 If the encryption algorithm requires the length of the data to be 1793 encrypted to be a multiple of the cipher algorithm block size, 1794 thereby necessitating padding, and if the encryption algorithm does 1795 not specify the padding contents, then an implementation MUST append 1796 the TLV parameter that is to be encrypted with an additional padding, 1797 so that the length of the resulting cleartext is a multiple of the 1798 cipher block size length. Such a padding MUST be constructed as 1799 specified in [18] Section 2.4. On the other hand, if the data to be 1800 encrypted is already a multiple of the block size, or if the 1801 encryption algorithm does specify padding as per [18] Section 2.4, 1802 then such additional padding SHOULD NOT be added. 1804 The Length field in the inside, to be encrypted TLV does not include 1805 the padding. The Length field in the outside ENCRYPTED TLV is the 1806 length of the data after encryption (including the Reserved field, 1807 the IV field, and the output from the encryption process specified 1808 for that suite, but not any additional external padding). Note that 1809 the length of the cipher suite output may be smaller or larger than 1810 the length of the data to be encrypted, since the encryption process 1811 may compress the data or add additional padding to the data. 1813 The ENCRYPTED payload may contain additional external padding, if the 1814 result of encryption, the TLV header and the IV is not a multiple of 1815 8 bytes. The contents of this external padding MUST follow the rules 1816 given in Section 6.2.1. 1818 6.2.19 NOTIFY 1820 The NOTIFY parameter is used to transmit informational data, such as 1821 error conditions and state transitions, to a HIP peer. A NOTIFY 1822 parameter may appear in the NOTIFY packet type. The use of the 1823 NOTIFY parameter in other packet types is for further study. 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 | Reserved | Notify Message Type | 1831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1832 | / 1833 / Notification data / 1834 / +---------------+ 1835 / | Padding | 1836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1838 Type 256 1839 Length length in octets, excluding Type, Length, and Padding 1840 Reserved zero when sent, ignored when received 1841 Notify Message Specifies the type of notification 1842 Type 1843 Notification Informational or error data transmitted in addition 1844 Data to the Notify Message Type. Values for this field are 1845 type specific (see below). 1846 Padding Any Padding, if necessary, to make the TLV a multiple 1847 of 8 bytes. 1849 Notification information can be error messages specifying why an SA 1850 could not be established. It can also be status data that a process 1851 managing an SA database wishes to communicate with a peer process. 1852 The table below lists the Notification messages and their 1853 corresponding values. 1855 To avoid certain types of attacks, a Responder SHOULD avoid sending a 1856 NOTIFY to any host with which it has not successfully verified a 1857 puzzle solution. 1859 Types in the range 0 - 16383 are intended for reporting errors. An 1860 implementation that receives a NOTIFY error parameter in response to 1861 a request packet (e.g., I1, I2, UPDATE), SHOULD assume that the 1862 corresponding request has failed entirely. Unrecognized error types 1863 MUST be ignored except that they SHOULD be logged. 1865 Notify payloads with status types MUST be ignored if not recognized. 1867 NOTIFY PARAMETER - ERROR TYPES Value 1868 ------------------------------ ----- 1870 UNSUPPORTED_CRITICAL_PARAMETER_TYPE 1 1872 Sent if the parameter type has the "critical" bit set and the 1873 parameter type is not recognized. Notification Data contains 1874 the two octet parameter type. 1876 INVALID_SYNTAX 7 1878 Indicates that the HIP message received was invalid because 1879 some type, length, or value was out of range or because the 1880 request was rejected for policy reasons. To avoid a denial 1881 of service attack using forged messages, this status may 1882 only be returned for and in an encrypted packet if the 1883 message ID and cryptographic checksum were valid. To avoid 1884 leaking information to someone probing a node, this status 1885 MUST be sent in response to any error not covered by one of 1886 the other status types. To aid debugging, more detailed 1887 error information SHOULD be written to a console or log. 1889 NO_DH_PROPOSAL_CHOSEN 14 1891 None of the proposed group IDs was acceptable. 1893 INVALID_DH_CHOSEN 15 1895 The D-H Group ID field does not correspond to one offered 1896 by the responder. 1898 NO_HIP_PROPOSAL_CHOSEN 16 1899 None of the proposed HIP Transform crypto suites was 1900 acceptable. 1902 INVALID_HIP_TRANSFORM_CHOSEN 17 1904 The HIP Transform crypto suite does not correspond to 1905 one offered by the responder. 1907 NO_ESP_PROPOSAL_CHOSEN 18 1909 None of the proposed ESP Transform crypto suites was 1910 acceptable. 1912 INVALID_ESP_TRANSFORM_CHOSEN 19 1914 The ESP Transform crypto suite does not correspond to 1915 one offered by the responder. 1917 AUTHENTICATION_FAILED 24 1919 Sent in response to a HIP signature failure. 1921 CHECKSUM_FAILED 26 1923 Sent in response to a HIP checksum failure. 1925 HMAC_FAILED 28 1927 Sent in response to a HIP HMAC failure. 1929 ENCRYPTION_FAILED 32 1931 The responder could not successfully decrypt the 1932 ENCRYPTED TLV. 1934 INVALID_HIT 40 1936 Sent in response to a failure to validate the peer's 1937 HIT from the corresponding HI. 1939 BLOCKED_BY_POLICY 42 1941 The resonder is unwilling to set up an association 1942 for some policy reason (e.g. received HIT is NULL 1943 and policy does not allow opportunistic mode). 1945 NOTIFY MESSAGES - STATUS TYPES Value 1946 ------------------------------ ----- 1948 (None defined at present) 1950 6.2.20 ECHO_REQUEST 1952 0 1 2 3 1953 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 1954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1955 | Type | Length | 1956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1957 | Opaque data (variable length) | 1958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1960 Type 65281 or 1022 1961 Length variable 1962 Opaque data Opaque data, supposed to be meaningful only to the 1963 node that sends ECHO_REQUEST and receives a corresponding 1964 ECHO_RESPONSE. 1966 The ECHO_REQUEST parameter contains an opaque blob of data that the 1967 sender wants to get echoed back in the corresponding reply packet. 1969 The ECHO_REQUEST and ECHO_RESPONSE parameters MAY be used for any 1970 purpose where a node wants to carry some state in a request packet 1971 and get it back in a response packet. The ECHO_REQUEST MAY be 1972 covered by the HMAC and SIGNATURE. This is dictated by the Type 1973 field selected for the parameter; Type 1022 ECHO_REQUEST is covered 1974 and Type 65281 is not. 1976 6.2.21 ECHO_RESPONSE 1978 0 1 2 3 1979 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 1980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1981 | Type | Length | 1982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1983 | Opaque data (variable length) | 1984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1986 Type 65283 or 1024 1987 Length variable 1988 Opaque data Opaque data, copied unmodified from the ECHO_REQUEST 1989 parameter that triggered this response. 1991 The ECHO_RESPONSE parameter contains an opaque blob of data that the 1992 sender of the ECHO_REQUEST wants to get echoed back. The opaque data 1993 is copied unmodified from the ECHO_REQUEST parameter. 1995 The ECHO_REQUEST and ECHO_RESPONSE parameters MAY be used for any 1996 purpose where a node wants to carry some state in a request packet 1997 and get it back in a response packet. The ECHO_RESPONSE MAY be 1998 covered by the HMAC and SIGNATURE. This is dictated by the Type field 1999 selected for the parameter; Type 1024 ECHO_RESPONSE is covered and 2000 Type 65283 is not. 2002 6.3 ICMP messages 2004 When a HIP implementation detects a problem with an incoming packet, 2005 and it either cannot determine the identity of the sender of the 2006 packet or does not have any existing HIP security association with 2007 the sender of the packet, it MAY respond with an ICMP packet. Any 2008 such replies MUST be rate limited as described in [4]. In most 2009 cases, the ICMP packet will have the Parameter Problem type (12 for 2010 ICMPv4, 4 for ICMPv6), with the Pointer field pointing to the field 2011 that caused the ICMP message to be generated. 2013 XXX: Should we say something more about rate limitation here? 2015 6.3.1 Invalid Version 2017 If a HIP implementation receives a HIP packet that has an 2018 unrecognized HIP version number, it SHOULD respond, rate limited, 2019 with an ICMP packet with type Parameter Problem, the Pointer pointing 2020 to the VER./RES. byte in the HIP header. 2022 6.3.2 Other problems with the HIP header and packet structure 2024 If a HIP implementation receives a HIP packet that has other 2025 unrecoverable problems in the header or packet format, it MAY 2026 respond, rate limited, with an ICMP packet with type Parameter 2027 Problem, the Pointer pointing to the field that failed to pass the 2028 format checks. However, an implementation MUST NOT send an ICMP 2029 message if the Checksum fails; instead, it MUST silently drop the 2030 packet. 2032 6.3.3 Unknown SPI 2034 If a HIP implementation receives an ESP packet that has an 2035 unrecognized SPI number, it MAY responder, rate limited, with an ICMP 2036 packet with type Parameter Problem, the Pointer pointing to the the 2037 beginning of SPI field in the ESP header. 2039 6.3.4 Invalid Cookie Solution 2041 If a HIP implementation receives an I2 packet that has an invalid 2042 cookie solution, the behaviour depends on the underlying version of 2043 IP. If IPv6 is used, the implementation SHOULD respond with an ICMP 2044 packet with type Parameter Problem, the Pointer pointing to the 2045 beginning of the Puzzle solution #J field in the SOLUTION payload in 2046 the HIP message. 2048 If IPv4 is used, the implementation MAY respond with an ICMP packet 2049 with the type Parameter Problem, copying enough of bytes form the I2 2050 message so that the SOLUTION parameter fits in to the ICMP message, 2051 the Pointer pointing to the beginning of the Puzzle solution #J 2052 field, as in the IPv6 case. Note, however, that the resulting ICMPv4 2053 message exceeds the typical ICMPv4 message size as defined in [2]. 2055 7. HIP Packets 2057 There are nine basic HIP packets. Four are for the base HIP 2058 exchange, one is for updating, one is a broadcast for use when there 2059 is no IP addressing (e.g., before DHCP exchange), one is used to send 2060 certificates, one for sending notifications, and one is for sending 2061 unencrypted data. 2063 Packets consist of the fixed header as described in Section 6.1, 2064 followed by the parameters. The parameter part, in turn, consists of 2065 zero or more TLV coded parameters. 2067 In addition to the base packets, other packets types will be defined 2068 later in separate specifications. For example, support for mobility 2069 and multi-homing is not included in this specification. 2071 Packet representation uses the following operations: 2073 () parameter 2074 x{y} operation x on content y 2075 i x exists i times 2076 [] optional parameter 2077 x | y x or y 2079 In the future, an OPTIONAL upper layer payload MAY follow the HIP 2080 header. The payload proto field in the header indicates if there is 2081 additional data following the HIP header. The HIP packet, however, 2082 MUST NOT be fragmented. This limits the size of the possible 2083 additional data in the packet. 2085 7.1 I1 - the HIP initiator packet 2087 The HIP header values for the I1 packet: 2089 Header: 2090 Packet Type = 1 2091 SRC HIT = Initiator's HIT 2092 DST HIT = Responder's HIT, or NULL 2094 IP ( HIP () ) 2096 The I1 packet contains only the fixed HIP header. 2098 Valid control bits: none 2100 The Initiator gets the Responder's HIT either from a DNS lookup of 2101 the Responder's FQDN, from some other repository, or from a local 2102 table. If the Initiator does not know the Responder's HIT, it may 2103 attempt opportunistic mode by using NULL (all zeros) as the 2104 Responder's HIT. 2106 Since this packet is so easy to spoof even if it were signed, no 2107 attempt is made to add to its generation or processing cost. 2109 Implementation MUST be able to handle a storm of received I1 packets, 2110 discarding those with common content that arrive within a small time 2111 delta. 2113 7.2 R1 - the HIP responder packet 2115 The HIP header values for the R1 packet: 2117 Header: 2118 Packet Type = 2 2119 SRC HIT = Responder's HIT 2120 DST HIT = Initiator's HIT 2122 IP ( HIP ( [ R1_COUNTER, ] 2123 PUZZLE, 2124 DIFFIE_HELLMAN, 2125 HIP_TRANSFORM, 2126 ESP_TRANSFORM, 2127 HOST_ID, 2128 [ ECHO_REQUEST, ] 2129 HIP_SIGNATURE_2 ) 2130 [, ECHO_REQUEST ]) 2132 Valid control bits: C, A 2134 The R1 packet may be followed by one or more CER packets. In this 2135 case, the C-bit in the control field MUST be set. 2137 If the responder HI is an anonymous one, the A control MUST be set. 2139 The initiator HIT MUST match the one received in I1. If the 2140 Responder has multiple HIs, the responder HIT used MUST match 2141 Initiator's request. If the Initiator used opportunistic mode, the 2142 Responder may select freely among its HIs. 2144 The R1 generation counter is used to determine the currently valid 2145 generation of puzzles. The value is increased periodically, and it 2146 is RECOMMENDED that it is increased at least as often as solutions to 2147 old puzzles are not accepted any longer. 2149 The Puzzle contains a random #I and the difficulty K. The difficulty 2150 K is the number of bits that the Initiator must get zero in the 2151 puzzle. The random #I is not covered by the signature and must be 2152 zeroed during the signature calculation, allowing the sender to 2153 select and set the #I into a pre-computed R1 just prior sending it to 2154 the peer. 2156 The Diffie-Hellman value is ephemeral, but can be reused over a 2157 number of connections. In fact, as a defense against I1 storms, an 2158 implementation MAY use the same Diffie-Hellman value for a period of 2159 time, for example, 15 minutes. By using a small number of different 2160 Cookies for a given Diffie-Hellman value, the R1 packets can be 2161 pre-computed and delivered as quickly as I1 packets arrive. A 2162 scavenger process should clean up unused DHs and Cookies. 2164 The HIP_TRANSFORM contains the encryption and integrity algorithms 2165 supported by the Responder to protect the HI exchange, in the order 2166 of preference. All implementations MUST support the 3DES [10] with 2167 HMAC-SHA-1-96 [6]. 2169 The ESP_TRANSFORM contains the ESP modes supported by the Responder, 2170 in the order of preference. All implementations MUST support 3DES 2171 [10] with HMAC-SHA-1-96 [6]. 2173 The ECHO_REQUEST contains data that the sender wants to receive 2174 unmodified in the corresponding response packet in the ECHO_RESPONSE 2175 parameter. The ECHO_REQUEST can be either covered by the signature, 2176 or it can be left out from it. In the first case, the ECHO_REQUEST 2177 gets Type number 1022 and in the latter case 65281. 2179 The signature is calculated over the whole HIP envelope, after 2180 setting the initiator HIT, header checksum as well as the Opaque 2181 field and the Random #I in the PUZZLE parameter temporarily to zero, 2182 and excluding any TLVs that follow the signature, as described in 2183 Section 6.2.14. This allows the Responder to use precomputed R1s. 2184 The Initiator SHOULD validate this signature. It SHOULD check that 2185 the responder HI received matches with the one expected, if any. 2187 7.3 I2 - the second HIP initiator packet 2189 The HIP header values for the I2 packet: 2191 Header: 2192 Type = 3 2193 SRC HIT = Initiator's HIT 2194 DST HIT = Responder's HIT 2196 IP ( HIP ( SPI, 2197 [R1_COUNTER,] 2198 SOLUTION, 2199 DIFFIE_HELLMAN, 2200 HIP_TRANSFORM, 2201 ESP_TRANSFORM, 2202 ENCRYPTED { HOST_ID }, 2203 [ ECHO_RESPONSE ,] 2204 HIP_SIGNATURE 2205 [, ECHO_RESPONSE] ) ) 2207 Valid control bits: C, A 2209 The HITs used MUST match the ones used previously. 2211 If the initiator HI is an anonymous one, the A control MUST be set. 2213 The Initiator MAY include an unmodified copy of the R1_COUNTER 2214 parameter received in the corresponding R1 packet into the I2 packet. 2216 The Solution contains the random # I from R1 and the computed # J. 2217 The low order K bits of the SHA-1(I | ... | J) MUST be zero. 2219 The Diffie-Hellman value is ephemeral. If precomputed, a scavenger 2220 process should clean up unused DHs. 2222 The HIP_TRANSFORM contains the encryption and integrity used to 2223 protect the HI exchange selected by the Initiator. All 2224 implementations MUST support the 3DES transform [10]. 2226 The Initiator's HI is encrypted using the HIP_TRANSFORM encryption 2227 algorithm. The keying material is derived from the Diffie-Hellman 2228 exchanged as defined in Section 9. 2230 The ESP_TRANSFORM contains the ESP mode selected by the Initiator. 2231 All implementations MUST support 3DES [10] with HMAC-SHA-1-96 [6]. 2233 The ECHO_RESPONSE contains the the unmodified Opaque data copied from 2234 the corresponding ECHO_REPLY packet. The ECHO_RESPONSE can be either 2235 covered by the signature, or it can be left out from it. In the 2236 first case, the ECHO_RESPONSE gets Type number 1024 and in the latter 2237 case 65283. 2239 The signature is calculated over whole HIP envelope, excluding any 2240 TLVs after the HIP_SIGNATURE, as described in Section 6.2.13. The 2241 Responder MUST validate this signature. It MAY use either the HI in 2242 the packet or the HI acquired by some other means. 2244 7.4 R2 - the second HIP responder packet 2246 The HIP header values for the R2 packet: 2248 Header: 2249 Packet Type = 4 2250 SRC HIT = Responder's HIT 2251 DST HIT = Initiator's HIT 2253 IP ( HIP ( SPI, HMAC, HIP_SIGNATURE ) ) 2255 Valid control bits: none 2257 The HMAC and signature are calculated over whole HIP envelope. The 2258 Initiator MUST validate both the HMAC and the signature. 2260 7.5 UPDATE - the HIP Update Packet 2262 Support for the UPDATE packet is MANDATORY. 2264 The HIP header values for the UPDATE packet: 2266 Header: 2267 Packet Type = 5 2268 SRC HIT = Sender's HIT 2269 DST HIT = Recipient's HIT 2271 IP ( HIP ( [NES, SEQ, ACK, DIFFIE_HELLMAN, ] HMAC, HIP_SIGNATURE ) ) 2273 Valid control bits: None 2275 The UPDATE packet contains mandatory HMAC and HIP_SIGNATURE 2276 parameters, and other optional parameters. 2278 The UPDATE packet contains zero or one SEQ parameter. The presence 2279 of a SEQ parameter indicates that the receiver MUST ack the UPDATE. 2280 An UPDATE that does not contain a SEQ parameter is simply an ACK of a 2281 previous UPDATE and itself MUST not be acked. 2283 An UPDATE packet contains zero or one ACK parameters. The ACK 2284 parameter echoes the SEQ sequence number of the UPDATE packet being 2285 acked. A host MAY choose to ack more than one UPDATE packet at a 2286 time; e.g., the ACK may contain the last two SEQ values received, for 2287 robustness to ack loss. ACK values are not cumulative; each received 2288 unique SEQ value requires at least one corresponding ACK value in 2289 reply. Received ACKs that are redundant are ignored. 2291 The UPDATE packet may contain both a SEQ and an ACK parameter. In 2292 this case, the ACK is being piggybacked on an outgoing UPDATE. In 2293 general, UPDATEs carrying SEQ SHOULD be acked upon completion of the 2294 processing of the UPDATE. A host MAY choose to hold the UPDATE 2295 carrying ACK for a short period of time to allow for the possibility 2296 of piggybacking the ACK parameter, in a manner similar to TCP delayed 2297 acknowledgments. 2299 A sender MAY choose to forego reliable transmission of a particular 2300 UPDATE (e.g., it becomes overcome by events). The semantics are such 2301 that the receiver MUST acknowledge the UPDATE but the sender MAY 2302 choose to not care about receiving the ACK. 2304 UPDATEs MAY be retransmitting without incrementing SEQ. If the same 2305 subset of parameters is included in multiple UPDATEs with different 2306 SEQs, the host MUST ensure that receiver processing of the parameters 2307 multiple times will not result in a protocol error. 2309 In the case of rekeying (Section 8.10), the UPDATE packet MUST carry 2310 NES and MAY carry DIFFIE_HELLMAN parameter, unless the UPDATE is a 2311 bare ack. 2313 Intermediate systems that use the SPI will have to inspect HIP 2314 packets for a UPDATE packet. The packet is signed for the benefit of 2315 the intermediate systems. Since intermediate systems may need the 2316 new SPI values, the contents of this packet cannot be encrypted. 2318 7.6 BOS - the HIP Bootstrap Packet 2320 The BOS packet is OPTIONAL. 2322 In some situations, an Initiator may not be able to learn of a 2323 Responder's information from DNS or another repository. Some examples 2324 of this are DHCP and NetBIOS servers. Thus, a packet is needed to 2325 provide information that would otherwise be gleaned from a 2326 repository. This HIP packet is either self-signed in applications 2327 like SoHo, or from a trust anchor in large private or public 2328 deployments. This packet MAY be broadcasted in IPv4 or multicasted 2329 to the all hosts multicast group in IPv6. The packet MUST NOT be 2330 sent more often than once in every second. Implementations MAY 2331 ignore received BOS packets. 2333 The HIP header values for the BOS packet: 2335 Header: 2336 Packet Type = 7 2337 SRC HIT = Announcer's HIT 2338 DST HIT = NULL 2340 IP ( HIP ( HOST_ID, HIP_SIGNATURE ) ) 2342 The BOS packet may be followed by a CER packet if the HI is signed. 2343 In this case, the C-bit in the control field MUST be set. If the BOS 2344 packet is broadcasted or multicasted, the following CER packet(s) 2345 MUST be broadcasted or multicasted to the same multicast group and 2346 scope, respectively. 2348 Valid control bits: C, A 2350 7.7 CER - the HIP Certificate Packet 2352 The CER packet is OPTIONAL. 2354 The Optional CER packets over the Announcer's HI by a higher level 2355 authority known to the Recipient is an alternative method for the 2356 Recipient to trust the Announcer's HI (over DNSSEC or PKI). 2358 The HIP header values for CER packet: 2360 Header: 2361 Packet Type = 8 2362 SRC HIT = Announcer's HIT 2363 DST HIT = Recipient's HIT 2365 IP ( HIP ( i , HIP_SIGNATURE ) ) or 2367 IP ( HIP ( ENCRYPTED { i }, HIP_SIGNATURE ) ) 2369 Valid control bits: None 2371 Certificates in the CER packet MAY be encrypted. The encryption 2372 algorithm is provided in the HIP transform of the previous (R1 or I2) 2373 packet. 2375 7.8 NOTIFY - the HIP Notify Packet 2377 The NOTIFY packet is OPTIONAL. The NOTIFY packet MAY be used to 2378 provide information to a peer. Typically, NOTIFY is used to indicate 2379 some type of protocol error or negotiation failure. 2381 The HIP header values for the NOTIFY packet: 2383 Header: 2384 Packet Type = 9 2385 SRC HIT = Sender's HIT 2386 DST HIT = Recipient's HIT, or zero if unknown 2388 IP ( HIP (i, [HOST_ID, ] HIP_SIGNATURE) ) 2390 Valid control bits: None 2392 The NOTIFY packet is used to carry one or more NOTIFY parameters. 2394 7.9 PAYLOAD - the HIP Payload Packet 2396 The PAYLOAD packet is OPTIONAL. 2398 The HIP header values for the PAYLOAD packet: 2400 Header: 2401 Packet Type = 64 2402 SRC HIT = Sender's HIT 2403 DST HIT = Recipient's HIT 2405 IP ( HIP ( ), payload ) 2407 Valid control bits: None 2409 Payload Proto field in the Header MUST be set to correspond the 2410 correct protocol number of the payload. 2412 The PAYLOAD packet is used to carry a non-ESP protected data. By 2413 using the HIP header we ensure interoperability with NAT and other 2414 middle boxes. 2416 Processing rules of the PAYLOAD packet are the following: 2417 Receiving: If there is an existing HIP security association with the 2418 given HITs, and the IP addresses match the IP addresses associated 2419 with the HITs, pass the packet to the upper layer, tagged with 2420 metadata indicating that the packet was NOT integrity or 2421 confidentiality protected. 2422 Sending: If the IPsec SPD defines BYPASS for a given destination 2423 HIT, send it with the PAYLOAD packet. Otherwise use ESP as 2424 specified in the SPD. 2426 8. Packet processing 2428 Each host is assumed to have a single HIP protocol implementation 2429 that manages the host's HIP associations and handles requests for new 2430 ones. Each HIP association is governed by a conceptual state 2431 machine, with states defined above in Section 5.4. The HIP 2432 implementation can simultaneously maintain HIP associations with more 2433 than one host. Furthermore, the HIP implementation may have more 2434 than one active HIP association with another host; in this case, HIP 2435 associations are distinguished by their respective HITs and IPsec 2436 SPIs. It is not possible to have more than one HIP associations 2437 between any given pair of HITs. Consequently, the only way for two 2438 hosts to have more than one parallel association is to use different 2439 HITs, at least at one end. 2441 The processing of packets depends on the state of the HIP 2442 association(s) with respect to the authenticated or apparent 2443 originator of the packet. A HIP implementation determines whether it 2444 has an active association with the originator of the packet based on 2445 the HITs or the SPI of the packet. 2447 8.1 Processing outgoing application data 2449 In a HIP host, an application can send application level data using 2450 HITs or LSIs as source and destination identifiers. The HITs and 2451 LSIs may be specified via a backwards compatible API (see Appendix A) 2452 or a completely new API. However, whenever there is such outgoing 2453 data, the stack has to protect the data with ESP, and send the 2454 resulting datagram using appropriate source and destination IP 2455 addresses. Here, we specify the processing rules only for the base 2456 case where both hosts have only single usable IP addresses; the 2457 multi-address multi-homing case will be specified separately. 2459 If the IPv4 backward compatible APIs and therefore LSIs are 2460 supported, it is assumed that the LSIs will be converted into proper 2461 HITs somewhere in the stack. The exact location of the conversion is 2462 an implementation specific issue and not discussed here. The 2463 following conceptual algorithm discusses only HITs, with the 2464 assumption that the LSI-to-HIT conversion takes place somewhere. 2466 The following steps define the conceptual processing rules for 2467 outgoing datagrams destined to a HIT. 2468 1. If the datagram has a specified source address, it MUST be a HIT. 2469 If it is not, the implementation MAY replace the source address 2470 with a HIT. Otherwise it MUST drop the packet. 2471 2. If the datagram has an unspecified source address, the 2472 implementation must choose a suitable source HIT for the 2473 datagram. In selecting a proper local HIT, the implementation 2474 SHOULD consult the table of currently active HIP sessions, and 2475 preferably select a HIT that already has an active session with 2476 the target HIT. 2477 3. If there no active HIP session with the given < source, 2478 destination > HIT pair, one must be created by running the base 2479 exchange. The implementation SHOULD queue at least one packet 2480 per HIP session to be formed, and it MAY queue more than one. 2481 4. Once there is an active HIP session for the given < source, 2482 destination > HIT pair, the outgoing datagram is protected using 2483 the associated ESP security association. In a typical 2484 implementation, this will result in an transport mode ESP 2485 datagram that still has HITs in the place of IP addresses. 2486 5. The HITs in the datagram are replaced with suitable IP addresses. 2487 For IPv6, the rules defined in [15] SHOULD be followed. Note 2488 that this HIT-to-IP-address conversion step MAY also be performed 2489 at some other point in the stack, e.g., before ESP processing. 2490 However, care must be taken to make sure that the right ESP SA is 2491 employed. 2493 8.2 Processing incoming application data 2495 Incoming HIP datagrams arrive as ESP protected packets. In the usual 2496 case the receiving host has a corresponding ESP security association, 2497 identified by the SPI and destination IP address in the packet. 2498 However, if the host has crashed or otherwise lost its HIP state, it 2499 may not have such an SA. 2501 The following steps define the conceptual processing rules for 2502 incoming ESP protected datagrams targeted to an ESP security 2503 association created with HIP. 2504 1. Detect the proper IPsec SA using the SPI. If the resulting SA is 2505 a non-HIP ESP SA, process the packet according to standard IPsec 2506 rules. If there are no SAs identified with the SPI, the host MAY 2507 send an ICMP packet as defined in Section 6.3.3. How to handle 2508 lost state is an implementation issue. 2509 2. If a proper HIP ESP SA is found, the packet is processed normally 2510 by ESP, as if the packet were a transport mode packet. The 2511 packet may be dropped by ESP, as usual. In a typical 2512 implementation, the result of successful ESP decryption and 2513 verification is a datagram with the original IP addresses as 2514 source and destination. 2515 3. The IP addresses in the datagram are replaced with the HITs 2516 associated with the ESP SA. Note that this IP-address-to-HIT 2517 conversion step MAY also be performed at some other point in the 2518 stack, e.g., before ESP processing. 2519 4. The datagram is delivered to the upper layer. Demultiplexing the 2520 datagram the right upper layer socket is based on the HITs (or 2521 LSIs). 2523 8.3 HMAC and SIGNATURE calculation and verification 2525 The following subsections define the actions for processing HMAC, 2526 HIP_SIGNATURE and HIP_SIGNATURE_2 TLVs. 2528 8.3.1 HMAC calculation 2530 The HMAC TLV is defined in Section 6.2.12. HMAC calculation and 2531 verification process: 2533 Packet sender: 2534 1. Create the HIP packet, without the HMAC or any possible 2535 HIP_SIGNATURE or HIP_SIGNATURE_2 TLVs. 2536 2. Calculate the Length field in the HIP header. 2537 3. Compute the HMAC. 2538 4. Add the HMAC TLV to the packet and any HIP_SIGNATURE or 2539 HIP_SIGNATURE_2 TLVs that may follow. 2540 5. Recalculate the Length field in the HIP header. 2542 Packet receiver: 2543 1. Verify the HIP header Length field. 2544 2. Remove the HMAC TLV, and if the packet contains any HIP_SIGNATURE 2545 or HIP_SIGNATURE_2 fields, remove them too, saving the contents 2546 if they will be needed later. 2547 3. Recalculate the HIP packet length in the HIP header and clear the 2548 Checksum field (set it to all zeros). 2549 4. Compute the HMAC and verify it against the received HMAC. 2551 8.3.2 Signature calculation 2553 The following process applies both to the HIP_SIGNATURE and 2554 HIP_SIGNATURE_2 TLVs. When processing HIP_SIGNATURE_2, the only 2555 difference is that instead of HIP_SIGNATURE TLV, the HIP_SIGNATURE_2 2556 TLV is used, and the Initiator's HIT and PUZZLE Opaque and Random #I 2557 fields are cleared (set to all zeros) before computing the signature. 2558 The HIP_SIGNATURE TLV is defined in Section 6.2.13 and the 2559 HIP_SIGNATURE_2 TLV in Section 6.2.14. 2561 Signature calculation and verification process: 2563 Packet sender: 2564 1. Create the HIP packet without the HIP_SIGNATURE TLV or any TLVs 2565 that follow the HIP_SIGNATURE TLV. 2566 2. Calculate the Length field in the HIP header. 2567 3. Compute the signature. 2568 4. Add the HIP_SIGNATURE TLV to the packet. 2569 5. Add any TLVs that follow the HIP_SIGNATURE TLV. 2571 6. Recalculate the Length field in the HIP header. 2573 Packet receiver: 2574 1. Verify the HIP header Length field. 2575 2. Save the contents of the HIP_SIGNATURE TLV and any TLVs following 2576 the HIP_SIGNATURE TLV and remove them from the packet. 2577 3. Recalculate the HIP packet Length in the HIP header and clear the 2578 Checksum field (set it to all zeros). 2579 4. Compute the signature and verify it against the received 2580 signature. 2582 The verification can use either the HI received from a HIP packet, 2583 the HI from a DNS query, if the FQDN has been received either in the 2584 HOST_ID or in the CER packet, or one received by some other means. 2586 8.4 Initiation of a HIP exchange 2588 An implementation may originate a HIP exchange to another host based 2589 on a local policy decision, usually triggered by an application 2590 datagram, in much the same way that an IPsec IKE key exchange can 2591 dynamically create a Security Association. Alternatively, a system 2592 may initiate a HIP exchange if it has rebooted or timed out, or 2593 otherwise lost its HIP state, as described in Section 5.3. 2595 The implementation prepares an I1 packet and sends it to the IP 2596 address that corresponds to the peer host. The IP address of the 2597 peer host may be obtained via conventional mechanisms, such as DNS 2598 lookup. The I1 contents are specified in Section 7.1. The selection 2599 of which host identity to use, if a host has more than one to choose 2600 from, is typically a policy decision. 2602 The following steps define the conceptual processing rules for 2603 initiating a HIP exchange: 2604 1. The Initiator gets the Responder's HIT and one or more addresses 2605 either from a DNS lookup of the responder's FQDN, from some other 2606 repository, or from a local table. If the initiator does not know 2607 the responder's HIT, it may attempt opportunistic mode by using 2608 NULL (all zeros) as the responder's HIT. 2609 2. The Initiator sends an I1 to one of the Responder's addresses. 2610 The selection of which address to use is a local policy decision. 2611 3. Upon sending an I1, the sender shall transition to state I1-SENT, 2612 start a timer whose timeout value should be larger than the 2613 worst-case anticipated RTT, and shall increment a timeout counter 2614 associated with the I1. 2615 4. Upon timeout, the sender SHOULD retransmit the I1 and restart the 2616 timer, up to a maximum of I1_RETRIES_MAX tries. 2618 8.4.1 Sending multiple I1s in parallel 2620 For the sake of minimizing the session establishment latency, an 2621 implementation MAY send the same I1 to more than one of the 2622 Responder's addresses. However, it MUST NOT send to more than three 2623 (3) addresses in parallel. Furthermore, upon timeout, the 2624 implementation MUST refrain from sending the same I1 packet to 2625 multiple addresses. These limitations are placed order to avoid 2626 congestion of the network, and potential DoS attacks that might 2627 happen, e.g., because someone claims to have hundreds or thousands of 2628 addresses. 2630 As the Responder is not guaranteed to distinguish the duplicate I1's 2631 it receives at several of its addresses (because it avoids to store 2632 states when it answers back an R1), the Initiator may receive several 2633 duplicate R1's. 2635 The Initiator SHOULD then select the initial preferred destination 2636 address using the source address of the selected received R1, and use 2637 the preferred address as a source address for the I2. Processing 2638 rules for received R1s are discussed in Section 8.6. 2640 8.4.2 Processing incoming ICMP Protocol Unreachable messages 2642 A host may receive an ICMP Destination Protocol Unreachable message 2643 as a response to sending an HIP I1 packet. Such a packet may be an 2644 indication that the peer does not support HIP, or it may be an 2645 attempt to launch an attack by making the Initiator believe that the 2646 Responder does not support HIP. 2648 When a system receives an ICMP Destination Protocol Unreachable 2649 message while it is waiting for an R1, it MUST NOT terminate the 2650 wait. It MAY continue as if it had not received the ICMP message, 2651 and send a few more I1s. Alternatively, it MAY take the ICMP message 2652 as a hint that the peer most probably does not support HIP, and 2653 return to state UNASSOCIATED earlier than otherwise. However, at 2654 minimum, it MUST continue waiting for an R1 for a reasonable time 2655 before returning to UNASSOCIATED. 2657 8.5 Processing incoming I1 packets 2659 An implementation SHOULD reply to an I1 with an R1 packet, unless the 2660 implementation is unable or unwilling to setup a HIP association. If 2661 the implementation is unable to setup a HIP association, the host 2662 SHOULD send an ICMP Destination Protocol Unreachable, 2663 Administratively Prohibited, message to the I1 source address. If 2664 the implementation is unwilling to setup a HIP association, the host 2665 MAY ignore the I1. This latter case may occur during a DoS attack 2666 such as an I1 flood. 2668 The implementation MUST be able to handle a storm of received I1 2669 packets, discarding those with common content that arrive within a 2670 small time delta. 2672 A spoofed I1 can result in an R1 attack on a system. An R1 sender 2673 MUST have a mechanism to rate limit R1s to an address. 2675 Under no circumstances does the HIP state machine transition upon 2676 sending an R1. 2678 The following steps define the conceptual processing rules for 2679 responding to an I1 packet: 2680 1. The responder MUST check that the responder HIT in the received 2681 I1 is either one of its own HITs, or NULL. 2682 2. If the responder is in ESTABLISHED state, the responder MAY 2683 respond to this with an R1 packet, prepare to drop existing SAs 2684 and stay at ESTABLISHED state. 2685 3. If the implementation chooses to respond to the I1 with and R1 2686 packet, it creates a new R1 or selects a precomputed R1 according 2687 to the format described in Section 7.2. 2688 4. The R1 MUST contain the received responder HIT, unless the 2689 received HIT is NULL, in which case the Responder may freely 2690 select among its HITs. 2691 5. The responder sends the R1 to the source IP address of the I1 2692 packet. 2694 8.5.1 R1 Management 2696 All compliant implementations MUST produce R1 packets. An R1 packet 2697 MAY be precomputed. An R1 packet MAY be reused for time Delta T, 2698 which is implementation dependent. R1 information MUST not be 2699 discarded until Delta S after T. Time S is the delay needed for the 2700 last I2 to arrive back to the responder. 2702 An implementation MAY keep state about received I1s and match the 2703 received I2s against the state, as discussed in Section 4.1.1. 2705 8.5.2 Handling malformed messages 2707 If an implementation receives a malformed I1 message, it SHOULD NOT 2708 respond with a NOTIFY message, as such practice could open up a 2709 potential denial-of-service danger. Instead, it MAY respond with an 2710 ICMP packet, as defined in Section 6.3. 2712 8.6 Processing incoming R1 packets 2714 A system receiving an R1 MUST first check to see if it has sent an I1 2715 to the originator of the R1 (i.e., it is in state I1-SENT). If so, 2716 it SHOULD process the R1 as described below, send an I2, and go to 2717 state I2-SENT, setting a timer to protect the I2. If the system is in 2718 state I2-SENT, it MAY respond to an R1 if the R1 has a larger R1 2719 generation counter; if so, it should drop its state due to processing 2720 the previous R1 and start over from state I1-SENT. If the system is 2721 in any other state with respect to that host, it SHOULD silently drop 2722 the R1. 2724 When sending multiple I1s, an initiator SHOULD wait for a small 2725 amount of time after the first R1 reception to allow possibly 2726 multiple R1s to arrive, and it SHOULD respond to an R1 among the set 2727 with the largest R1 generation counter. 2729 The following steps define the conceptual processing rules for 2730 responding to an R1 packet: 2731 1. A system receiving an R1 MUST first check to see if it has sent 2732 an I1 to the originator of the R1 (i.e., it has a HIP 2733 association that is in state I1-SENT and that is associated with 2734 the HITs in the R1). If so, it should process the R1 as 2735 described below. 2736 2. Otherwise, if the system is in any other state than I1-SENT or 2737 I2-SENT with respect to the HITs included in the R1, it SHOULD 2738 silently drop the R1 and remain in the current state. 2739 3. If the HIP association state is I1-SENT or I2-SENT, the received 2740 Initiator's HIT MUST correspond to the HIT used in the original, 2741 I1 and the Responder's HIT MUST correspond to the one used, 2742 unless the I1 contained a NULL HIT. 2743 4. The system SHOULD validate the R1 signature before applying 2744 further packet processing, according to Section 6.2.14. 2745 5. If the HIP association state is I1-SENT, and multiple valid R1s 2746 are present, the system SHOULD select from among the R1s with 2747 the largest R1 generation counter. 2748 6. If the HIP association state is I2-SENT, the system MAY reenter 2749 state I1-SENT and process the received R1 if it has a larger R1 2750 generation counter than the R1 responded to previously. 2751 7. The R1 packet may have the C bit set -- in this case, the system 2752 should anticipate the receipt of HIP CER packets that contain 2753 the host identity corresponding to the responder's HIT. 2754 8. The R1 packet may have the A bit set -- in this case, the system 2755 MAY choose to refuse it by dropping the R1 and returning to 2756 state UNASSOCIATED. The system SHOULD consider dropping the R1 2757 only if it used a NULL HIT in I1. If the A bit is set, the 2758 Responder's HIT is anonymous and should not be stored. 2760 9. The system SHOULD attempt to validate the HIT against the 2761 received Host Identity. 2762 10. The system MUST store the received R1 generation counter for 2763 future reference. 2764 11. The system attempts to solve the cookie puzzle in R1. The 2765 system MUST terminate the search after a number of tries, the 2766 minimum of the degree of difficulty specified by the K value or 2767 an implementation- or policy-defined maximum retry count. It is 2768 RECOMMENDED that the system does not try more than 2^(K+2) 2769 times. If the cookie puzzle is not successfully solved, the 2770 implementation may either resend I1 within the retry bounds or 2771 abandon the HIP exchange. 2772 12. The system computes standard Diffie-Hellman keying material 2773 according to the public value and Group ID provided in the 2774 DIFFIE_HELLMAN parameter. The Diffie-Hellman keying material 2775 Kij is used for key extraction as specified in Section 9. If 2776 the received Diffie-Hellman Group ID is not supported, the 2777 implementation may either resend I1 within the retry bounds or 2778 abandon the HIP exchange. 2779 13. The system selects the HIP transform and ESP transform from the 2780 choices presented in the R1 packet and uses the selected values 2781 subsequently when generating and using encryption keys, and when 2782 sending the I2. If the proposed alternatives are not acceptable 2783 to the system, it may either resend I1 within the retry bounds 2784 or abandon the HIP exchange. 2785 14. The system prepares and creates an incoming IPsec ESP security 2786 association. It may also prepare a security association for 2787 outgoing traffic, but since it does not have the correct SPI 2788 value yet, it cannot activate it. 2789 15. The system initialized the remaining variables in the associated 2790 state, including Update ID counters. 2791 16. The system prepares and sends an I2, as described in Section 2792 7.3. 2793 17. The system SHOULD start a timer whose timeout value should be 2794 larger than the worst-case anticipated RTT, and MUST increment a 2795 timeout counter associated with the I2. The sender SHOULD 2796 retransmit the I2 upon a timeout and restart the timer, up to a 2797 maximum of I2_RETRIES_MAX tries. 2798 18. If the system is in state I1-SENT, it shall transition to state 2799 I2-SENT. If the system is in any other state, it remains in the 2800 current state. 2802 8.6.1 Handling malformed messages 2804 If an implementation receives a malformed R1 message, it MUST 2805 silently drop the packet. Sending a NOTIFY or ICMP would not help, 2806 as the sender of the R1 typically doesn't have any state. An 2807 implementation SHOULD wait for some more time for a possible good R1, 2808 after which it MAY try again by sending a new I1 packet. 2810 8.7 Processing incoming I2 packets 2812 Upon receipt of an I2, the system MAY perform initial checks to 2813 determine whether the I2 corresponds to a recent R1 that has been 2814 sent out, if the Responder keeps such state. For example, the sender 2815 could check whether the I2 is from an address or HIT that has 2816 recently received an R1 from it. The R1 may have had Opaque data 2817 included that was echoed back in the I2. If the I2 is considered to 2818 be suspect, it MAY be silently discarded by the system. 2820 Otherwise, the HIP implementation SHOULD process the I2. This 2821 includes validation of the cookie puzzle solution, generating the 2822 Diffie-Hellman key, decrypting the Initiator's Host Identity, 2823 verifying the signature, creating state, and finally sending an R2. 2825 The following steps define the conceptual processing rules for 2826 responding to an I2 packet: 2827 1. The system MAY perform checks to verify that the I2 corresponds 2828 to a recently sent R1. Such checks are implementation 2829 dependent. See Appendix D for a description of an example 2830 implementation. 2831 2. The system MUST check that the Responder's HIT corresponds to 2832 one of its own HITs. 2833 3. If the system is in the R2-SENT state, it MAY check if the newly 2834 received I2 is similar to the one that triggered moving to 2835 R2-SENT. If so, it MAY retransmit a previously sent R2, reset 2836 the R2-SENT timer, and stay in R2-SENT. 2837 4. If the system is in any other state, it SHOULD check that the 2838 echoed R1 generation counter in I2 is within the acceptable 2839 range. Implementations MUST accept puzzles from the current 2840 generation and MAY accept puzzles from earlier generations. If 2841 the newly received I2 is outside the accepted range, the I2 is 2842 stale (perhaps replayed) and SHOULD be dropped. 2843 5. The system MUST validate the solution to the cookie puzzle by 2844 computing the SHA-1 hash described in Section 7.3. 2845 6. The I2 MUST have a single value in each of the HIP_TRANSFORM and 2846 ESP_TRANSFORM parameters, which MUST each match one of the 2847 values offered to the Initiator in the R1 packet. 2848 7. The system must derive Diffie-Hellman keying material Kij based 2849 on the public value and Group ID in the DIFFIE_HELLMAN 2850 parameter. This key is used to derive the HIP and ESP 2851 association keys, as described in Section 9. If the 2852 Diffie-Hellman Group ID is unsupported, the I2 packet is 2853 silently dropped. 2854 8. The encrypted HOST_ID decrypted by the Initiator encryption key 2855 defined in Section 9. If the decrypted data is not an HOST_ID 2856 parameter, the I2 packet is silently dropped. 2857 9. The implementation SHOULD also verify that the Initiator's HIT 2858 in the I2 corresponds to the Host Identity sent in the I2. 2859 10. The system MUST verify the HIP_SIGNATURE according to Section 2860 6.2.13 and Section 7.3. 2861 11. If the checks above are valid, then the system proceeds with 2862 further I2 processing; otherwise, it discards the I2 and remains 2863 in the same state. 2864 12. The I2 packet may have the C bit set -- in this case, the system 2865 should anticipate the receipt of HIP CER packets that contain 2866 the host identity corresponding to the responder's HIT. 2867 13. The I2 packet may have the A bit set -- in this case, the system 2868 MAY choose to refuse it by dropping the I2 and returning to 2869 state UNASSOCIATED. If the A bit is set, the Initiator's HIT is 2870 anonymous and should not be stored. 2871 14. The SPI field is parsed to obtain the SPI that will be used for 2872 the Security Association outbound from the Responder and inbound 2873 to the Initiator. 2874 15. The system prepares and creates both incoming and outgoing ESP 2875 security associations. 2876 16. The system initialized the remaining variables in the associated 2877 state, including Update ID counters. 2878 17. Upon successful processing of an I2 in states UNASSOCIATED, 2879 I1-SENT, I2-SENT, and R2-SENT, an R2 is sent and the state 2880 machine transitions to state ESTABLISHED. 2881 18. Upon successful processing of an I2 in state ESTABLISHED/ 2882 REKEYING, the old Security Association is dropped and a new one 2883 is installed, an R2 is sent, and the state machine transitions 2884 to R2-SENT, dropping any possibly ongoing rekeying attempt. 2885 19. Upon transitioning to R2-SENT, start a timer. Leave R2-SENT if 2886 either the timer expires (allowing for maximal retransmission of 2887 I2s), some data has been received on the incoming SA, or an 2888 UPDATE packet has been received (or some other packet that 2889 indicates that the peer has moved to ESTABLISHED). 2891 8.7.1 Handling malformed messages 2893 If an implementation receives a malformed I2 message, the behaviour 2894 SHOULD depend on how much checks the message has already passed. If 2895 the puzzle solution in the message has already been checked, the 2896 implementation SHOULD report the error by responding with a NOTIFY 2897 packet. Otherwise the implementation MAY respond with an ICMP 2898 message as defined in Section 6.3. 2900 8.8 Processing incoming R2 packets 2902 An R2 received in states UNASSOCIATED, I1-SENT, ESTABLISHED, or 2903 REKEYING results in the R2 being dropped and the state machine 2904 staying in the same state. If an R2 is received in state I2-SENT, it 2905 SHOULD be processed. 2907 The following steps define the conceptual processing rules for 2908 incoming R2 packet: 2909 1. The system MUST verify that the HITs in use correspond to the 2910 HITs that were received in R1. 2911 2. The system MUST verify the HMAC according to the procedures in 2912 Section 6.2.12. 2913 3. The system MUST verify the HIP signature according to the 2914 procedures in Section 6.2.13. 2915 4. If any of the checks above fail, there is a high probability of 2916 an ongoing man-in-the-middle or other security attack. The 2917 system SHOULD act accordingly, based on its local policy. 2918 5. If the system is in any other state than I2-SENT, the R2 is 2919 silently dropped. 2920 6. The SPI field is parsed to obtain the SPI that will be used for 2921 the ESP Security Association inbound to the Responder. The 2922 system uses this SPI to create or activate the outgoing ESP 2923 security association used to send packets to the peer. 2924 7. Upon successful processing of the R2, the state machine moves to 2925 state ESTABLISHED. 2927 8.9 Dropping HIP associations 2929 A HIP implementation is free to drop a HIP association at any time, 2930 based on its own policy. If a HIP host decides to drop an HIP 2931 association, it deletes the IPsec SAs related to that association and 2932 the corresponding HIP state, including the keying material. The 2933 implementation MUST also drop the peer's R1 generation counter value, 2934 unless a local policy explicitly defines that the value of that 2935 particular host is stored. An implementation MUST NOT store R1 2936 generation counters by default, but storing R1 generation counter 2937 values, if done, MUST be configured by explicit HITs. 2939 8.10 Initiating rekeying 2941 A system may initiate the rekey procedure at any time. It MUST 2942 initiate a rekey if its incoming ESP sequence counter is about to 2943 overflow. The system MUST NOT replace its keying material until the 2944 rekeying packet exchange successfully completes. Optionally, 2945 depending on policy, a system may include a new Diffie-Hellman key 2946 for use in new KEYMAT generation. New KEYMAT generation occurs prior 2947 to drawing the new keys. 2949 In the conceptual state machine, a system rekeys when it sends a NES 2950 parameter to the peer and receives both an ACK of the relevant UPDATE 2951 message and its peer's NES parameter. To leave REKEYING state, both 2952 parameters must be received. It may be that the ACK and the NES 2953 arrive in different UPDATE messages. This is always true if a system 2954 does not initiate rekeying but responds to a rekeying request from 2955 the peer, but may also occur if two systems initiate a rekey nearly 2956 simultaneously. In such a case, if the system is in state REKEYING, 2957 it saves the one parameter and waits for the other before leaving 2958 state REKEYING. This implies that the REKEYING state may have 2959 conceptual substates. 2961 The following steps define the processing rules for initiating a 2962 rekey: 2963 1. The system decides whether to continue to use the existing KEYMAT 2964 or to generate new KEYMAT. In the latter case, the system MUST 2965 generate a new Diffie-Hellman public key. 2966 2. The system increments its outgoing Update ID by one. 2967 3. The system creates a UPDATE packet, which contains an SEQ 2968 parameter (with the current value of Update ID), NES parameter 2969 and an optional DIFFIE_HELLMAN parameter. If the UPDATE packet 2970 contains the DIFFIE_HELLMAN parameter, the Keymat Index in the 2971 NES parameter MUST be zero. If the UPDATE does not contain 2972 DIFFIE_HELLMAN, the NES Keymat Index MUST be larger or equal to 2973 the index of the next byte to be drawn from the current KEYMAT. 2974 4. The system sends the UPDATE packet and transitions to state 2975 REKEYING. 2976 5. The system SHOULD start a timer whose timeout value should be 2977 larger than the worst-case anticipated RTT, and MUST increment a 2978 timeout counter associated with UPDATE. The sender SHOULD 2979 retransmit the UPDATE upon a timeout and restart the timer, up to 2980 a maximum of UPDATE_RETRIES_MAX tries. 2981 6. The system MUST NOT delete its existing SAs, but continue using 2982 them if its policy still allows. The UPDATE procedure SHOULD be 2983 initiated early enough to make sure that the SA replay counters 2984 do not overflow. 2985 7. In case a protocol error occurs and the peer system acknowledges 2986 the UPDATE but does not itself send a NES, the system may hang in 2987 state REKEYING. To guard against this, a system MAY re-initiate 2988 the rekeying procedure after some time waiting for the peer to 2989 respond, or it MAY decide to abort the HIP association after 2990 waiting for an implementation-dependent time. The system MUST 2991 NOT hang in state REKEYING for an indefinite time. 2993 To simplify the state machine, a host MUST NOT generate new UPDATEs 2994 (with higher Update IDs) while in state REKEYING, unless it is 2995 restarting the rekeying process. 2997 8.11 Processing UPDATE packets 2999 When a system receives an UPDATE packet, its processing depends on 3000 the state of the HIP association and the presence of and values of 3001 the SEQ and ACK parameters. An UPDATE MUST be processed if the 3002 following conditions hold (note: UPDATEs may also be processed when 3003 additional conditions hold, as specified in other drafts): 3004 1. The state of the HIP association is ESTABLISHED or REKEYING, and 3005 both the SEQ and NES parameters are present in the UPDATE. This 3006 is the case for which the peer host is in the process of 3007 rekeying. 3008 2. The state of the HIP association is REKEYING and an ACK (of 3009 outstanding Update ID) is in the UPDATE. This case usually 3010 corresponds to the peer completing the rekeying process first. 3012 If the above conditions hold, the following steps define the 3013 conceptual processing rules for handling a received UPDATE packet: 3014 1. If the SEQ parameter is present, and the Update ID in the 3015 received SEQ is smaller than the stored Update ID for the host, 3016 the packet MUST BE dropped. 3017 2. If the SEQ parameter is present, and the Update ID in the 3018 received SEQ is equal to the stored Update ID for the host, the 3019 packet is treated as a retransmission. However, the HMAC 3020 verification (next step) MUST NOT be skipped. (A byte-by-byte 3021 comparison of the received and a store packet would be OK, 3022 though.) It is recommended that a host cache the last packet 3023 that was acked to avoid the cost of generating a new ACK packet 3024 to respond to a replayed UPDATE. Systems MUST again acknowledge 3025 such apparent UPDATE message retransmissions but SHOULD also 3026 consider rate-limiting such retransmission responses to guard 3027 against replay attacks. 3028 3. The system MUST verify the HMAC in the UPDATE packet. If the 3029 verification fails, the packet MUST be dropped. 3030 4. If the received UPDATE contains a DIFFIE_HELLMAN parameter, the 3031 received Keymat Index MUST be zero. If this test fails, the 3032 packet SHOULD be dropped and the system SHOULD log an error 3033 message. 3034 5. The system MAY verify the SIGNATURE in the UPDATE packet. If the 3035 verification fails, the packet SHOULD be dropped and an error 3036 message logged. 3037 6. If a new SEQ parameter is being processed, the system MUST record 3038 the Update ID in the received SEQ parameter, for replay 3039 protection. 3040 7. If the system is in state ESTABLISHED, and the UPDATE has the NES 3041 and SEQ parameters, the packet processing continues as specified 3042 in Section 8.11.1. 3043 8. If the system is in state REKEYING, the packet processing 3044 continues as specified in Section 8.11.2. 3046 8.11.1 Processing an UPDATE packet in state ESTABLISHED 3048 The following steps define the conceptual processing rules responding 3049 handling a received initial UPDATE packet: 3050 1. The system consults its policy to see if it needs to generate a 3051 new Diffie-Hellman key, and generates a new key if needed. The 3052 system records any newly generated or received Diffie-Hellman 3053 keys, for use in KEYMAT generation upon leaving the REKEYING 3054 state. 3055 2. If the system generated new Diffie-Hellman key in the previous 3056 step, or it received a DIFFIE_HELLMAN parameter, it sets NES 3057 Keymat Index to zero. Otherwise, the NES Keymat Index MUST be 3058 larger or equal to the index of the next byte to be drawn from 3059 the current KEYMAT. In this case, it is RECOMMENDED that the 3060 host use the Keymat Index requested by the peer in the received 3061 NES. 3062 3. The system increments its outgoing Update ID by one. 3063 4. The system creates a UPDATE packet, which contains an SEQ 3064 parameter (with the current value of Update ID), NES parameter 3065 and the optional DIFFIE_HELLMAN parameter. The UPDATE packet also 3066 includes the ACK of the Update ID found in the received UPDATE 3067 SEQ parameter. 3068 5. The system sends the UPDATE packet and transitions to state 3069 REKEYING. The system stores any received NES and DIFFIE_HELLMAN 3070 parameters. At this point, it only needs to receive an ACK of 3071 its current Update ID to finish rekeying. 3073 8.11.2 Processing an UPDATE packet in state REKEYING 3075 The following steps define the conceptual processing rules responding 3076 handling a received reply UPDATE packet: 3077 1. If the packet contains a SEQ and NES parameters, then the system 3078 generates a new UPDATE packet with an ACK of the peer's Update ID 3079 as received in the SEQ parameter. Additionally, if the UPDATE 3080 packet contained an ACK of the outstanding Update ID, or if the 3081 ACK of the UPDATE packet that contained the NES has already been 3082 received, the system stores the received NES and (optional) 3083 DIFFIE_HELLMAN parameters and finishes the rekeying procedure as 3084 described in Section 8.11.3. If the ACK of the outstanding Update 3085 ID has not been received, stay in state REKEYING after storing 3086 the recived NES and (optional) DIFFIE_HELLMAN. 3087 2. If the packet contains an ACK parameter that ACKs the outstanding 3088 Update ID, and the system has previously received a NES from the 3089 peer, the system finishes the rekeying procedure as described in 3090 Section 8.11.3. If the system is still waiting for the peer's 3091 NES parameter (to arrive in subsequent UPDATE message), the 3092 system stays in state REKEYING. 3094 8.11.3 Leaving REKEYING state 3096 A system leaves REKEYING state when it has received both a NES from 3097 its peer and the ACK of the Update ID that was sent in its own NES to 3098 the peer. The following steps are taken: 3099 1. If either the received UPDATE contains a new Diffie-Hellman key, 3100 the system has a new Diffie-Hellman key from initiating rekey, or 3101 both, the system generates new KEYMAT. If there is only one new 3102 Diffie-Hellman key, the old key is used as the other key. 3103 2. If the system generated new KEYMAT in the previous step, it sets 3104 Keymat Index to zero, independent on whether the received UPDATE 3105 included a Diffie-Hellman key or not. If the system did not 3106 generate new KEYMAT, it uses the lowest Keymat Index of the two 3107 NES parameters. 3108 3. The system draws keys for new incoming and outgoing ESP SAs, 3109 starting from the Keymat Index, and prepares new incoming and 3110 outgoing ESP SAs. The SPI for the outgoing SA is the new SPI 3111 value from the UPDATE. The SPI for the incoming SA was generated 3112 when NES was sent. The order of the keys retrieved from the 3113 KEYMAT during rekeying process is similar to that described in 3114 Section 9. Note, that only IPsec ESP keys are retrieved during 3115 rekeying process, not the HIP keys. 3116 4. The system cancels any timers protecting the UPDATE and 3117 transitions to ESTABLISHED. 3118 5. The system starts to send to the new outgoing SA and prepares to 3119 start receiving data on the new incoming SA. 3121 8.12 Processing BOS packets 3123 Processing BOS packets is OPTIONAL, and currently undefined. 3125 8.13 Processing CER packets 3127 Processing CER packets is OPTIONAL, and currently undefined. 3129 8.14 Processing PAYLOAD packets 3131 Processing PAYLOAD packets is OPTIONAL, and currently undefined. 3133 8.15 Processing NOTIFY packets 3135 Processing NOTIFY packets is OPTIONAL. If processed, any errors 3136 noted by the NOTIFY parameter SHOULD be taken into account by the HIP 3137 state machine (e.g., by terminating a HIP handshake), and the error 3138 SHOULD be logged. 3140 9. HIP KEYMAT 3142 HIP keying material is derived from the Diffie-Hellman Kij produced 3143 during the base HIP exchange. The Initiator has Kij during the 3144 creation of the I2 packet, and the Responder has Kij once it receives 3145 the I2 packet. This is why I2 can already contain encrypted 3146 information. 3148 The KEYMAT is derived by feeding Kij and the HITs into the following 3149 operation; the | operation denotes concatenation. 3151 KEYMAT = K1 | K2 | K3 | ... 3152 where 3154 K1 = SHA-1( Kij | sort(HIT-I | HIT-R) | 0x01 ) 3155 K2 = SHA-1( Kij | K1 | 0x02 ) 3156 K3 = SHA-1( Kij | K2 | 0x03 ) 3157 ... 3158 K255 = SHA-1( Kij | K254 | 0xff ) 3159 K256 = SHA-1( Kij | K255 | 0x00 ) 3160 etc. 3162 Sort(HIT-I | HIT-R) is defined as the network byte order 3163 concatenation of the two HITs, with the smaller HIT preceding the 3164 larger HIT, resulting from the numeric comparison of the two HITs 3165 interpreted as positive (unsigned) 128-bit integers in network byte 3166 order. 3168 The initial keys are drawn sequentially in the order that is 3169 determined by the numeric comparison of the two HITs, with comparison 3170 method described in the previous paragraph. HOST_g denotes the host 3171 with the greater HIT value, and HOST_l the host with the lower HIT 3172 value. 3174 The drawing order for initial keys: 3175 HIP-gl encryption key for HOST_g's outgoing HIP packets 3176 HIP-gl integrity (HMAC) key for HOST_g's outgoing HIP packets 3177 HIP-lg encryption key (currently unused) for HOST_l's outgoing HIP 3178 packets 3179 HIP-lg integrity (HMAC) key for HOST_l's outgoing HIP packets 3180 SA-gl ESP encryption key for HOST_g's outgoing traffic 3181 SA-gl ESP authentication key for HOST_g's outgoing traffic 3182 SA-lg ESP encryption key for HOST_l's outgoing traffic 3183 SA-lg ESP authentication key for HOST_l's outgoing traffic 3185 The number of bits drawn for a given algorithm is the "natural" size 3186 of the keys. For the mandatory algorithms, the following sizes 3187 apply: 3189 3DES 192 bits 3190 SHA-1 160 bits 3191 NULL 0 bits 3193 The four HIP keys are only drawn from KEYMAT during a HIP I1->R2 3194 exchange. Subsequent rekeys using UPDATE will only draw the four ESP 3195 keys from KEYMAT. Section 8.11 describes the rules for reusing or 3196 regenerating KEYMAT based on the UPDATE exchange. 3198 10. HIP Fragmentation Support 3200 A HIP implementation must support IP fragmentation / reassembly. 3201 Fragment reassembly MUST be implemented in both IPv4 and IPv6, but 3202 fragment generation MUST be implemented only in IPv4 (IPv4 stacks and 3203 networks will usually do this by default) and SHOULD be implemented 3204 in IPv6. In the IPv6 world, the minimum MTU is larger, 1280 bytes, 3205 than in the IPv4 world. The larger MTU size is usually sufficient 3206 for most HIP packets, and therefore fragment generation may not be 3207 needed. If a host expects to send HIP packets that are larger than 3208 the minimum IPv6 MTU, it MUST implement fragment generation even for 3209 IPv6. 3211 In the IPv4 world, HIP packets may encounter low MTUs along their 3212 routed path. Since HIP does not provide a mechanism to use multiple 3213 IP datagrams for a single HIP packet, support of path MTU discovery 3214 does not bring any value to HIP in the IPv4 world. HIP aware NAT 3215 systems MUST perform any IPv4 reassembly/fragmentation. 3217 All HIP implementations MUST employ a reassembly algorithm that is 3218 sufficiently resistant against DoS attacks. 3220 11. ESP with HIP 3222 HIP is designed to be used in end-to-end fashion. The IPsec mode 3223 used with HIP is the BEET mode (A Bound End-to-End mode for ESP) 3224 [26]. The BEET mode provides some features from both IPsec tunnel 3225 and transport modes. The HIP uses HITs and LSIs as the "inner" 3226 addresses and IP addresses as "outer" addresses like IP addresses are 3227 used in the tunnel mode. Instead of tunneling packets between hosts, 3228 a conversion between inner and outer addresses is made at end-hosts 3229 and the inner address is never sent in the wire after the initial HIP 3230 negotiation. BEET provides IPsec transport mode syntax (no inner 3231 headers) with limited tunnel mode semantics (fixed logical inner 3232 addresses - the HITs - and changeable outer IP addresses). 3234 Since HIP does not negotiate any lifetimes, all lifetimes are local 3235 policy. The only lifetimes a HIP implementation MUST support are 3236 sequence number rollover (for replay protection), and SA timeout. An 3237 SA times out if no packets are received using that SA. The default 3238 timeout value is 15 minutes. Implementations MAY support lifetimes 3239 for the various ESP transforms. 3241 11.1 ESP Security Associations 3243 Each HIP association is linked with two ESP SAs, one incoming and one 3244 outgoing. The Initiator's incoming SA corresponds with the 3245 Responder's outgoing one. The initiator defines the SPI for this 3246 association, as defined in Section 3.3. This SA is called SA-RI, and 3247 the corresponding SPI is called SPI-RI. Respectively, the 3248 Responder's incoming SA corresponds with the Initiator's outgoing SA 3249 and is called SA-IR, with the SPI-IR. 3251 The Initiator creates SA-RI as a part of R1 processing, before 3252 sending out the I2, as explained in Section 8.6. The keys are derived 3253 from KEYMAT, as defined in Section 9. The Responder creates SA-RI as 3254 a part of I2 processing, see Section 8.7. 3256 The Responder creates SA-IR as a part of I2 processing, before 3257 sending out R2, see Step 17 in Section 8.7. The Initiator creates 3258 SA-IR when processing R2, see Step 7 in Section 8.8. 3260 11.2 Updating ESP SAs during rekeying 3262 After the initial 4-way handshake and SA establishment, both hosts 3263 are in state ESTABLISHED. There are no longer Initiator and 3264 Responder roles and the association is symmetric. In this 3265 subsection, the initiating party of the rekey procedure is denoted 3266 with I' and the peer with R'. 3268 The I' initiates the rekeying process when needed (see Section 8.10). 3269 It creates an UPDATE packet with required information and sends it to 3270 the peer node. The old SAs are still in use. 3272 The R', after receiving and processing the UPDATE (see Section 8.11), 3273 generates new SAs: SA-I'R' and SA-R'I'. It does not take the new 3274 outgoing SA into use, but uses still the old one, so there exists two 3275 SA pairs towards the same peer host. For the new outgoing SA, the 3276 SPI-R'I' value is picked from the received UPDATE packet. The R' 3277 generates the new SPI value for the incoming SA, SPI-I'R', and 3278 includes it in the response UPDATE packet. 3280 When the I' receives a response UPDATE from the R', it generates new 3281 SAs, as described in Section 8.11: SA-I'R' and SA-R'I'. It starts 3282 using the new outgoing SA immediately. 3284 The R' starts using the new outgoing SA when it receives traffic from 3285 the new incoming SA. After this, the R' can remove old SAs. 3286 Similarly, when the I' receives traffic from the new incoming SA, it 3287 can safely remove old SAs. 3289 11.3 Security Association Management 3291 An SA pair is indexed by the 2 SPIs and 2 HITs (both HITs since a 3292 system can have more than one HIT). An inactivity timer is 3293 recommended for all SAs. If the state dictates the deletion of an 3294 SA, a timer is set to allow for any late arriving packets. 3296 11.4 Security Parameter Index (SPI) 3298 The SPIs in ESP provide a simple compression of the HIP data from all 3299 packets after the HIP exchange. This does require a per HIT- pair 3300 Security Association (and SPI), and a decrease of policy granularity 3301 over other Key Management Protocols like IKE. 3303 When a host rekeys, it gets a new SPI from its partner. 3305 11.5 Supported Transforms 3307 All HIP implementations MUST support 3DES [10] and HMAC-SHA-1-96 [6]. 3308 If the Initiator does not support any of the transforms offered by 3309 the Responder in the R1 HIP packet, it MUST use 3DES and 3310 HMAC-SHA-1-96 and state so in the I2 HIP packet. 3312 In addition to 3DES, all implementations MUST implement the ESP NULL 3313 encryption and authentication algorithms. These algorithms are 3314 provided mainly for debugging purposes, and SHOULD NOT be used in 3315 production environments. The default configuration in 3316 implementations MUST be to reject NULL encryption or authentication. 3318 11.6 Sequence Number 3320 The Sequence Number field is MANDATORY in ESP. Anti-replay 3321 protection MUST be used in an ESP SA established with HIP. 3323 This means that each host MUST rekey before its sequence number 3324 reaches 2^32, or if extended sequence numbers are used, 2^64. Note 3325 that in HIP rekeying, unlike IKE rekeying, only one Diffie-Hellman 3326 key can be changed, that of the rekeying host. However, if one host 3327 rekeys, the other host SHOULD rekey as well. 3329 In some instances, a 32 bit sequence number is inadequate. In the 3330 ESP_TRANSFORM parameter, a peer MAY require that a 64 bit sequence 3331 number be used. In this case the higher 32 bits are NOT included in 3332 the ESP header, but are simply kept local to both peers. 64 bit 3333 sequence numbers must only be used for ciphers that will not be open 3334 to cryptanalysis as a result. AES is one such cipher. 3336 12. HIP Policies 3338 There are a number of variables that will influence the HIP exchanges 3339 that each host must support. All HIP implementations MUST support 3340 more than one simultaneous HIs, at least one of which SHOULD be 3341 reserved for anonymous usage. Although anonymous HIs will be rarely 3342 used as responder HIs, they will be common for Initiators. Support 3343 for more than two HIs is RECOMMENDED. 3345 Many Initiators would want to use a different HI for different 3346 Responders. The implementations SHOULD provide for an ACL of 3347 initiator HIT to responder HIT. This ACL SHOULD also include 3348 preferred transform and local lifetimes. For HITs with HAAs, 3349 wildcarding SHOULD be supported. Thus if a Community of Interest, 3350 like Banking, gets an RAA, a single ACL could be used. A global 3351 wildcard would represent the general policy to be used. Policy 3352 selection would be from most specific to most general. 3354 The value of K used in the HIP R1 packet can also vary by policy. K 3355 should never be greater than 20, but for trusted partners it could be 3356 as low as 0. 3358 Responders would need a similar ACL, representing which hosts they 3359 accept HIP exchanges, and the preferred transform and local 3360 lifetimes. Wildcarding SHOULD be supported for this ACL also. 3362 13. Security Considerations 3364 HIP is designed to provide secure authentication of hosts and to 3365 provide a fast key exchange for IPsec ESP. HIP also attempts to 3366 limit the exposure of the host to various denial-of-service and man- 3367 in-the-middle attacks. In so doing, HIP itself is subject to its own 3368 DoS and MitM attacks that potentially could be more damaging to a 3369 host's ability to conduct business as usual. 3371 HIP enabled ESP is IP address independent. This might seem to make 3372 it easier for an attacker, but ESP with replay protection is already 3373 as well protected as possible, and the removal of the IP address as a 3374 check should not increase the exposure of ESP to DoS attacks. 3375 Furthermore, this is in line with the forthcoming revision of ESP. 3377 Denial-of-service attacks take advantage of the cost of start of 3378 state for a protocol on the Responder compared to the 'cheapness' on 3379 the Initiator. HIP makes no attempt to increase the cost of the 3380 start of state on the Initiator, but makes an effort to reduce the 3381 cost to the Responder. This is done by having the Responder start 3382 the 3-way exchange instead of the Initiator, making the HIP protocol 3383 4 packets long. In doing this, packet 2 becomes a 'stock' packet 3384 that the Responder MAY use many times. The duration of use is a 3385 paranoia versus throughput concern. Using the same Diffie- Hellman 3386 values and random puzzle I has some risk. This risk needs to be 3387 balanced against a potential storm of HIP I1 packets. 3389 This shifting of the start of state cost to the Initiator in creating 3390 the I2 HIP packet, presents another DoS attack. The attacker spoofs 3391 the I1 HIP packet and the Responder sends out the R1 HIP packet. 3392 This could conceivably tie up the 'initiator' with evaluating the R1 3393 HIP packet, and creating the I2 HIP packet. The defense against this 3394 attack is to simply ignore any R1 packet where a corresponding I1 or 3395 ESP data was not sent. 3397 A second form of DoS attack arrives in the I2 HIP packet. Once the 3398 attacking Initiator has solved the cookie challenge, it can send 3399 packets with spoofed IP source addresses with either invalid 3400 encrypted HIP payload component or a bad HIP signature. This would 3401 take resources in the Responder's part to reach the point to discover 3402 that the I2 packet cannot be completely processed. The defense 3403 against this attack is after N bad I2 packets, the Responder would 3404 discard any I2s that contain the given Initiator HIT. Thus will shut 3405 down the attack. The attacker would have to request another R1 and 3406 use that to launch a new attack. The Responder could up the value of 3407 K while under attack. On the downside, valid I2s might get dropped 3408 too. 3410 A third form of DoS attack is emulating the restart of state after a 3411 reboot of one of the partners. A host restarting would send an I1 to 3412 a peer, which would respond with an R1 even if it were in state 3413 ESTABLISHED. If the I1 were spoofed, the resulting R1 would be 3414 received unexpectedly by the spoofed host and would be dropped, as in 3415 the first case above. 3417 A fourth form of DoS attack is emulating the end of state. HIP has 3418 no end of state packet. It relies on a local policy timer to end 3419 state. 3421 A fifth form of DoS attack is replaying R1s to cause the initiator to 3422 solve stale puzzles and become out of synchronization with the 3423 responder. The R1 generation counter is a monotonically increasing 3424 counter designed to protect against this attack, as described in 3425 section Section 4.1.3. 3427 Man-in-the-middle attacks are difficult to defend against, without 3428 third-party authentication. A skillful MitM could easily handle all 3429 parts of HIP; but HIP indirectly provides the following protection 3430 from a MitM attack. If the Responder's HI is retrieved from a signed 3431 DNS zone, a certificate, or through some other secure means, the 3432 Initiator can use this to validate the R1 HIP packet. 3434 Likewise, if the Initiator's HI is in a secure DNS zone, a trusted 3435 certificate, or otherwise securely available, the Responder can 3436 retrieve it after it gets the I2 HIP packet and validate that. 3437 However, since an Initiator may choose to use an anonymous HI, it 3438 knowingly risks a MitM attack. The Responder may choose not to 3439 accept a HIP exchange with an anonymous Initiator. 3441 Since not all hosts will ever support HIP, ICMP 'Destination Protocol 3442 Unreachable' are to be expected and present a DoS attack. Against an 3443 Initiator, the attack would look like the Responder does not support 3444 HIP, but shortly after receiving the ICMP message, the Initiator 3445 would receive a valid R1 HIP packet. Thus to protect from this 3446 attack, an Initiator should not react to an ICMP message until a 3447 reasonable delta time to get the real Responder's R1 HIP packet. A 3448 similar attack against the Responder is more involved. First an ICMP 3449 message is expected if the I1 was a DoS attack and the real owner of 3450 the spoofed IP address does not support HIP. The Responder SHOULD 3451 NOT act on this ICMP message to remove the minimal state from the R1 3452 HIP packet (if it has one), but wait for either a valid I2 HIP packet 3453 or the natural timeout of the R1 HIP packet. This is to allow for a 3454 sophisticated attacker that is trying to break up the HIP exchange. 3455 Likewise, the Initiator should ignore any ICMP message while waiting 3456 for an R2 HIP packet, deleting state only after a natural timeout. 3458 14. IANA Considerations 3460 IANA has assigned IP Protocol number TBD to HIP. 3462 15. Acknowledgments 3464 The drive to create HIP came to being after attending the MALLOC 3465 meeting at IETF 43. Baiju Patel and Hilarie Orman really gave the 3466 original author, Bob Moskowitz, the assist to get HIP beyond 5 3467 paragraphs of ideas. It has matured considerably since the early 3468 drafts thanks to extensive input from IETFers. Most importantly, its 3469 design goals are articulated and are different from other efforts in 3470 this direction. Particular mention goes to the members of the 3471 NameSpace Research Group of the IRTF. Noel Chiappa provided the 3472 framework for LSIs and Keith Moore the impetus to provide 3473 resolvability. Steve Deering provided encouragement to keep working, 3474 as a solid proposal can act as a proof of ideas for a research group. 3476 Many others contributed; extensive security tips were provided by 3477 Steve Bellovin. Rob Austein kept the DNS parts on track. Paul Kocher 3478 taught Bob Moskowitz how to make the cookie exchange expensive for 3479 the Initiator to respond, but easy for the Responder to validate. 3480 Bill Sommerfeld supplied the Birthday concept to simplify reboot 3481 management. Rodney Thayer and Hugh Daniels provide extensive 3482 feedback. In the early times of this draft, John Gilmore kept Bob 3483 Moskowitz challenged to provide something of value. 3485 During the later stages of this document, when the editing baton was 3486 transfered to Pekka Nikander, the input from the early implementors 3487 were invaluable. Without having actual implementations, this 3488 document would not be on the level it is now. 3490 In the usual IETF fashion, a large number of people have contributed 3491 to the actual text or ideas. The list of these people include Jeff 3492 Ahrenholz, Francis Dupont, Derek Fawcus, George Gross, Andrew 3493 McGregor, Julien Laganier, Miika Komu, Mika Kousa, Jan Melen, Henrik 3494 Petander, Michael Richardson, Tim Shepard, Jorma Wall, and Jukka 3495 Ylitalo. Our apologies to anyone who's name is missing. 3497 16. References 3499 16.1 Normative references 3501 [1] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 3502 1980. 3504 [2] Postel, J., "Internet Control Message Protocol", STD 5, RFC 3505 792, September 1981. 3507 [3] Mockapetris, P., "Domain names - implementation and 3508 specification", STD 13, RFC 1035, November 1987. 3510 [4] Conta, A. and S. Deering, "Internet Control Message Protocol 3511 (ICMPv6) for the Internet Protocol Version 6 (IPv6)", RFC 1885, 3512 December 1995. 3514 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 3515 Levels", BCP 14, RFC 2119, March 1997. 3517 [6] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP 3518 and AH", RFC 2404, November 1998. 3520 [7] Maughan, D., Schneider, M. and M. Schertler, "Internet Security 3521 Association and Key Management Protocol (ISAKMP)", RFC 2408, 3522 November 1998. 3524 [8] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 3525 RFC 2409, November 1998. 3527 [9] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, 3528 November 1998. 3530 [10] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", 3531 RFC 2451, November 1998. 3533 [11] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 3534 Specification", RFC 2460, December 1998. 3536 [12] Eastlake, D., "Domain Name System Security Extensions", RFC 3537 2535, March 1999. 3539 [13] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System 3540 (DNS)", RFC 2536, March 1999. 3542 [14] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 3543 Public Key Infrastructure Certificate and Certificate 3544 Revocation List (CRL) Profile", RFC 3280, April 2002. 3546 [15] Draves, R., "Default Address Selection for Internet Protocol 3547 version 6 (IPv6)", RFC 3484, February 2003. 3549 [16] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 3550 Addressing Architecture", RFC 3513, April 2003. 3552 [17] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 3553 Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3554 3526, May 2003. 3556 [18] Kent, S., "IP Encapsulating Security Payload (ESP)", 3557 draft-ietf-ipsec-esp-v3-05 (work in progress), April 2003. 3559 [19] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 3560 draft-ietf-ipsec-ikev2-07 (work in progress), April 2003. 3562 [20] Moskowitz, R., "Host Identity Protocol Architecture", 3563 draft-moskowitz-hip-arch-03 (work in progress), May 2003. 3565 [21] NIST, "FIPS PUB 180-1: Secure Hash Standard", April 1995. 3567 16.2 Informative references 3569 [22] Bellovin, S. and W. Aiello, "Just Fast Keying (JFK)", 3570 draft-ietf-ipsec-jfk-04 (work in progress), July 2002. 3572 [23] Moskowitz, R. and P. Nikander, "Using Domain Name System (DNS) 3573 with Host Identity Protocol (HIP)", draft-nikander-hip-dns-00 3574 (to be issued) (work in progress), June 2003. 3576 [24] Nikander, P., "SPI assisted NAT traversal (SPINAT) with Host 3577 Identity Protocol (HIP)", draft-nikander-hip-nat-00 (to be 3578 issued) (work in progress), June 2003. 3580 [25] Crosby, SA. and DS. Wallach, "Denial of Service via Algorithmic 3581 Complexity Attacks", in Proceedings of Usenix Security 3582 Symposium 2003, Washington, DC., August 2003. 3584 [26] Nikander, P., "A Bound End-to-End Tunnel (BEET) mode for ESP", 3585 draft-nikander-esp-beet-mode-00 (expired) (work in progress), 3586 Oct 2003. 3588 Authors' Addresses 3590 Robert Moskowitz 3591 ICSAlabs, a Division of TruSecure Corporation 3592 1000 Bent Creek Blvd, Suite 200 3593 Mechanicsburg, PA 3594 USA 3596 EMail: rgm@icsalabs.com 3598 Pekka Nikander 3599 Ericsson Research NomadicLab 3601 JORVAS FIN-02420 3602 FINLAND 3604 Phone: +358 9 299 1 3605 EMail: pekka.nikander@nomadiclab.com 3607 Petri Jokela 3608 Ericsson Research NomadicLab 3610 JORVAS FIN-02420 3611 FINLAND 3613 Phone: +358 9 299 1 3614 EMail: petri.jokela@nomadiclab.com 3616 Thomas R. Henderson 3617 The Boeing Company 3618 P.O. Box 3707 3619 Seattle, WA 3620 USA 3622 EMail: thomas.r.henderson@boeing.com 3624 Appendix A. API issues 3626 The following text is informational and may be expanded upon or 3627 revised in a separate Informational document. 3629 HIP may be used to support application data transfers in one of three 3630 ways: 3631 the application may be HIP-aware and may explicitly use a 3632 HIP-based API and/or resolver library; 3633 the application may not be HIP-aware but may be provided with HITs 3634 or LSIs in place of IP addresses as part of the address resolution 3635 process; and 3636 the application may or may not be HIP-aware and may present IP 3637 addresses to the system, but the system may decide to 3638 opportunistically invoke HIP or use a pre-existing HIP-based SA on 3639 its behalf. 3641 The first case is the most straightforward. The HIP-based API is 3642 outside the scope of this document. 3644 The second case is one way to provide HIP support to non-HIP-aware 3645 applications. HITs may be stored in the DNS or some other 3646 infrastructure, and the resolver library may choose to supply a 3647 querying application with a HIT or LSI in place of an IP address. 3648 Note that if the application truly needs IP addresses for a domain 3649 name for some reason (e.g., a diagnostic application, or for use in a 3650 referral scenario to a non-HIP-based host), blindly providing HITs or 3651 LSIs in place of actual IP addresses may cause some applications to 3652 break. 3654 In both of the first two cases, the means whereby a system can 3655 resolve an LSI or HIT to an IP address, when such a mapping is not 3656 locally cached in the system, is outside the scope of this document. 3658 In the third case, the system is explicitly invoking HIP to a 3659 particular destination IP address on the basis of a local policy 3660 decision. This approach resembles the way that opportunistic IPsec 3661 works. Effectively, this approach is implicitly associating IP 3662 addresses with host identities, and is prone to certain failures or 3663 ambiguity in an environment where IP addresses are dynamic (e.g., an 3664 application connects to an IP address, the peer host moves at some 3665 later time, then another host acquires the old IP address, and the 3666 system again receives a request to connect to that IP address, in 3667 which case it is ambiguous whether the application wants to connect 3668 to the host previously at that IP address or the new host at that 3669 address). 3671 If HIP is used to support an application, the application data stream 3672 may contain either IP addresses or LSIs or HITs in place of the IP 3673 addresses. 3675 Appendix B. Probabilities of HIT collisions 3677 The birthday paradox sets a bound for the expectation of collisions. 3678 It is based on the square root of the number of values. A 64-bit 3679 hash, then, would put the chances of a collision at 50-50 with 2^32 3680 hosts (4 billion). A 1% chance of collision would occur in a 3681 population of 640M and a .001% collision chance in a 20M population. 3682 A 128 bit hash will have the same .001% collision chance in a 9x10^16 3683 population. 3685 Appendix C. Probabilities in the cookie calculation 3687 A question: Is it guaranteed that the Initiator is able to solve the 3688 puzzle in this way when the K value is large? 3690 Answer: No, it is not guaranteed. But it is not guaranteed even in 3691 the old mechanism, since the Initiator may start far away from J and 3692 arrive to J after far too many steps. If we wanted to make sure that 3693 the Initiator finds a value, we would need to give some hint of a 3694 suitable J, and I don't think we want to do that. 3696 In general, if we model the hash function with a random function, the 3697 probability that one iteration gives are result with K zero bits is 3698 2^-K. Thus, the probability that one iteration does *not* give K 3699 zero bits is (1 - 2^-K). Consequently, the probability that 2^K 3700 iterations does not give K zero bits is (1 - 2^-K)^(2^K). 3702 Since my calculus starts to be rusty, I made a small experiment and 3703 found out that 3705 lim (1 - 2^-k)^(2^k) = 0.36788 3706 k->inf 3708 lim (1 - 2^-k)^(2^(k+1)) = 0.13534 3709 k->inf 3711 lim (1 - 2^-k)^(2^(k+2)) = 0.01832 3712 k->inf 3714 lim (1 - 2^-k)^(2^(k+3)) = 0.000335 3715 k->inf 3717 Thus, if hash functions were random functions, we would need about 3718 2^(K+3) iterations to make sure that the probability of a failure is 3719 less than 1% (actually less than 0.04%). Now, since my perhaps 3720 flawed understanding of hash functions is that they are "flatter" 3721 than random functions, 2^(K+3) is probably an overkill. OTOH, the 3722 currently suggested 2^K is clearly too little. The draft has been 3723 changed to read 2^(K+2). 3725 Appendix D. Using responder cookies 3727 As mentioned in Section 4.1.1, the Responder may delay state creation 3728 and still reject most spoofed I2s by using a number of pre-calculated 3729 R1s and a local selection function. This appendix defines one 3730 possible implementation in detail. The purpose of this appendix is 3731 to give the implementors an idea on how to implement the mechanism. 3732 The method described in this appendix SHOULD NOT be used in any real 3733 implementation. If the implementation is based on this appendix, it 3734 SHOULD contain some local modification that makes an attacker's task 3735 harder. 3737 The basic idea is to create a cheap, varying local mapping function 3738 f: 3740 f( IP-I, IP-R, HIT-I, HIT-R ) -> cookie-index 3742 That is, given the Initiator's and Responder's IP addresses and 3743 HITs, the function returns an index to a cookie. When processing an 3744 I1, the cookie is embedded in an pre-computed R1, and the Responder 3745 simply sends that particular R1 to the Initiator. When processing an 3746 I2, the cookie may still be embedded in the R1, or the R1 may be 3747 deprecated (and replaced with a new one), but the cookie is still 3748 there. If the received cookie does not match with the R1 or saved 3749 cookie, the I2 is simply dropped. That prevents the Initiator from 3750 generating spoofed I2s with a probability that depends on the number 3751 of pre-computed R1s. 3753 As a concrete example, let us assume that the Responder has an array 3754 of R1s. Each slot in the array contains a timestamp, an R1, and an 3755 old cookie that was sent in the previous R1 that occupied that 3756 particular slot. The Responder replaces one R1 in the array every 3757 few minutes, thereby replacing all the R1s gradually. 3759 To create a varying mapping function, the Responder generates a 3760 random number every few minutes. The octets in the IP addresses and 3761 HITs are XORed together, and finally the result is XORed with the 3762 random number. Using pseudo-code, the function looks like the 3763 following. 3765 Pre-computation: 3766 r1 := random number 3768 Index computation: 3769 index := r1 XOR hit_r[0] XOR hit_r[1] XOR ... XOR hit_r[15] 3770 index := index XOR hit_i[0] XOR hit_i[1] XOR ... XOR hit_i[15] 3771 index := index XOR ip_r[0] XOR ip_r[1] XOR ... XOR ip_r[15] 3772 index := index XOR ip_i[0] XOR ip_i[1] XOR ... XOR ip_i[15] 3774 The index gives the slot used in the array. 3776 It is possible that an Initiator receives an I1, and while it is 3777 computing I2, the Responder deprecates an R1 and/or chooses a new 3778 random number for the mapping function. Therefore the Responder must 3779 remember the cookies used in deprecated R1s and the previous random 3780 number. 3782 To check an received I2, the Responder can use a simple algorithm, 3783 expressed in pseudo-code as follows. 3785 If I2.hit_r does not match my_hits, drop the packet. 3787 index := compute_index(current_random_number, I2) 3788 If current_cookie[index] == I2.cookie, go to cookie check. 3789 If previous_cookie[index] == I2.cookie, go to cookie check. 3791 index := compute_index(previous_random_number, I2) 3792 If current_cookie[index] == I2.cookie, go to cookie check. 3793 If previous_cookie[index] == I2.cookie, go to cookie check. 3795 Drop packet. 3797 cookie_check: 3798 V := Ltrunc( SHA-1( I2.I, I2.hit_i, I2.hit_r, I2.J ), K ) 3799 if V != 0, drop the packet. 3801 Whenever the Responder receives an I2 that fails on the index check, 3802 it can simply drop the packet on the floor and forget about it. New 3803 I2s with the same or other spoofed parameters will get dropped with a 3804 reasonable probability and minimal effort. 3806 If a Responder receives an I2 that passes the index check but fails 3807 on the puzzle check, it should create a state indicating this. After 3808 two or three failures the Responder should cease checking the puzzle 3809 but drop the packets directly. This saves the Responder from the 3810 SHA-1 calculations. Such block should not last long, however, or 3811 there would be a danger that a legitimate Initiator could be blocked 3812 from getting connections. 3814 A key for the success of the defined scheme is that the mapping 3815 function must be considerably cheaper than computing SHA-1. It also 3816 must detect any changes in the IP addresses, and preferably most 3817 changes in the HITs. Checking the HITs is not that essential, 3818 though, since HITs are included in the cookie computation, too. 3820 The effectivity of the method can be varied by varying the size of 3821 the array containing pre-computed R1s. If the array is large, the 3822 probability that an I2 with a spoofed IP address or HIT happens to 3823 map to the same slot is fairly slow. However, a large array means 3824 that each R1 has a fairly long life time, thereby allowing an 3825 attacker to utilize one solved puzzle for a longer time. 3827 Appendix E. Running HIP over IPv4 UDP 3829 In the IPv4 world, with the deployed NAT devices, it may make sense 3830 to run HIP over UDP. When running HIP over UDP, the following packet 3831 structure is used. The structure is followed by the HITs, as usual. 3832 Both the Source and Destination port MUST be 272. 3834 0 1 2 3 3835 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 3836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ 3837 | Source port | Destination port | \ 3838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >UDP 3839 | Length | Checksum | / 3840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+< 3841 | HIP Controls | HIP pkt Type | Ver. | Res. | >HIP 3842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ 3844 It is currently undefined how the actual data transfer, using ESP, is 3845 handled. Plain ESP may not go through all NAT devices. 3847 It is currently FORBIDDEN to use this packet format with IPv6. 3849 Appendix F. Example checksums for HIP packets 3851 The HIP checksum for HIP packets is specified in Section 6.1.2. 3852 Checksums for TCP and UDP packets running over HIP-enabled security 3853 associations are specified in Section 3.5. The examples below use IP 3854 addresses of 192.168.0.1 and 192.168.0.2 (and their respective 3855 IPv4-compatible IPv6 formats), and type 1 HITs with the first two 3856 bits "01" followed by 124 zeroes followed by a decimal 1 or 2, 3857 respectively. 3859 F.1 IPv6 HIP example (I1) 3861 Source Address: ::c0a8:0001 3862 Destination Address: ::c0a8:0002 3863 Upper-Layer Packet Length: 40 0x28 3864 Next Header: 99 0x63 3865 Payload Protocol: 59 0x3b 3866 Header Length: 4 0x04 3867 Packet Type: 1 0x01 3868 Version: 1 0x1 3869 Reserved: 0 0x0 3870 Control: 0 0x0000 3871 Checksum: 49672 0xc208 3872 Sender's HIT: 4000::0001 3873 Receiver's HIT: 4000::0002 3875 F.2 IPv4 HIP packet (I1) 3877 The IPv4 checksum value for the same example I1 packet is the same as 3878 the IPv6 checksum (since the checksums due to the IPv4 and IPv6 3879 pseudo-header components are the same). 3881 F.3 TCP segment 3883 Regardless of whether IPv6 or IPv4 is used, the TCP and UDP sockets 3884 use the IPv6 pseudo-header format [8], with the HITs used in place of 3885 the IPv6 addresses. 3887 Sender's HIT: 4000::0001 3888 Receiver's HIT: 4000::0002 3889 Upper-Layer Packet Length: 20 0x14 3890 Next Header: 6 0x06 3891 Source port: 32769 0x8001 3892 Destination port: 22 0x0016 3893 Sequence number: 1 0x00000001 3894 Acknowledgment number: 0 0x00000000 3895 Header length: 20 0x14 3896 Flags: SYN 0x02 3897 Window size: 5840 0x16d0 3898 Checksum: 54519 0xd4f7 3899 Urgent pointer: 0 0x0000 3901 Appendix G. 384-bit group 3903 This 384-bit group is defined only to be used with HIP. NOTE: The 3904 security level of this group is very low! The encryption may be 3905 broken in a very short time, even real-time. It should be used only 3906 when the host is not powerful enough (e.g. some PDAs) and when 3907 security requirements are low (e.g. during normal web surfing). 3909 This prime is: 2^384 - 2^320 - 1 + 2^64 * { [ 2^254 pi] + 5857 } 3911 Its hexadeciaml value is: 3913 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 3914 29024E08 8A67CC74 020BBEA6 3B13B202 FFFFFFFF FFFFFFFF 3916 The generator is: 2. 3918 Intellectual Property Statement 3920 The IETF takes no position regarding the validity or scope of any 3921 Intellectual Property Rights or other rights that might be claimed to 3922 pertain to the implementation or use of the technology described in 3923 this document or the extent to which any license under such rights 3924 might or might not be available; nor does it represent that it has 3925 made any independent effort to identify any such rights. Information 3926 on the IETF's procedures with respect to rights in IETF Documents can 3927 be found in BCP 78 and BCP 79. 3929 Copies of IPR disclosures made to the IETF Secretariat and any 3930 assurances of licenses to be made available, or the result of an 3931 attempt made to obtain a general license or permission for the use of 3932 such proprietary rights by implementers or users of this 3933 specification can be obtained from the IETF on-line IPR repository at 3934 http://www.ietf.org/ipr. 3936 The IETF invites any interested party to bring to its attention any 3937 copyrights, patents or patent applications, or other proprietary 3938 rights that may cover technology that may be required to implement 3939 this standard. Please address the information to the IETF at 3940 ietf-ipr@ietf.org. 3942 Disclaimer of Validity 3944 This document and the information contained herein are provided on an 3945 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3946 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 3947 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 3948 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 3949 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3950 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3952 Copyright Statement 3954 Copyright (C) The Internet Society (2004). This document is subject 3955 to the rights, licenses and restrictions contained in BCP 78, and 3956 except as set forth therein, the authors retain all their rights. 3958 Acknowledgment 3960 Funding for the RFC Editor function is currently provided by the 3961 Internet Society.