idnits 2.17.1 draft-ietf-hip-base-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 4270. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 4281. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 4288. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 4294. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1041 has weird spacing: '...ciation has n...' == Line 1090 has weird spacing: '... failed to es...' == Line 1662 has weird spacing: '...c Value leng...' == Line 1664 has weird spacing: '...c Value the ...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 1, 2007) is 6293 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: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 1885 (Obsoleted by RFC 2463) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 2898 (Obsoleted by RFC 8018) ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) ** Obsolete normative reference: RFC 4307 (Obsoleted by RFC 8247) == Outdated reference: A later version (-07) exists of draft-laganier-ipv6-khi-05 == Outdated reference: A later version (-06) exists of draft-ietf-hip-esp-04 -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) == Outdated reference: A later version (-12) exists of draft-ietf-shim6-proto-07 == Outdated reference: A later version (-05) exists of draft-ietf-hip-mm-04 == Outdated reference: A later version (-09) exists of draft-ietf-hip-dns-08 Summary: 9 errors (**), 0 flaws (~~), 11 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Moskowitz 3 Internet-Draft ICSAlabs, a Division of TruSecure 4 Intended status: Informational Corporation 5 Expires: August 5, 2007 P. Nikander 6 P. Jokela (editor) 7 Ericsson Research NomadicLab 8 T. Henderson 9 The Boeing Company 10 February 1, 2007 12 Host Identity Protocol 13 draft-ietf-hip-base-07 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on August 5, 2007. 40 Copyright Notice 42 Copyright (C) The Internet Society (2007). 44 Abstract 46 This memo specifies the details of the Host Identity Protocol (HIP). 47 HIP allows consenting hosts to securely establish and maintain shared 48 IP-layer state, allowing separation of the identifier and locator 49 roles of IP addresses, thereby enabling continuity of communications 50 across IP address changes. HIP is based on a Sigma-compliant Diffie- 51 Hellman key exchange, using public-key identifiers from a new Host 52 Identity name space for mutual peer authentication. The protocol is 53 designed to be resistant to Denial-of-Service (DoS) and Man-in-the- 54 middle (MitM) attacks, and when used together with another suitable 55 security protocol, such as Encapsulated Security Payload (ESP), it 56 provides integrity protection and optional encryption for upper layer 57 protocols, suchs as TCP and UDP. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 62 1.1. A New Name Space and Identifiers . . . . . . . . . . . . 5 63 1.2. The HIP Base Exchange . . . . . . . . . . . . . . . . . . 6 64 1.3. Memo structure . . . . . . . . . . . . . . . . . . . . . 7 65 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 8 66 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 8 67 2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 8 68 2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 8 69 3. Host Identifier (HI) and its Representations . . . . . . . . 10 70 3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 10 71 3.2. Generating a HIT from a HI . . . . . . . . . . . . . . . 11 72 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 12 73 4.1. Creating a HIP Association . . . . . . . . . . . . . . . 12 74 4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . 13 75 4.1.2. Puzzle exchange . . . . . . . . . . . . . . . . . . . 14 76 4.1.3. Authenticated Diffie-Hellman Protocol . . . . . . . . 15 77 4.1.4. HIP Replay Protection . . . . . . . . . . . . . . . . 16 78 4.1.5. Refusing a HIP Exchange . . . . . . . . . . . . . . . 17 79 4.1.6. HIP Opportunistic Mode . . . . . . . . . . . . . . . 17 80 4.2. Updating a HIP Association . . . . . . . . . . . . . . . 18 81 4.3. Error Processing . . . . . . . . . . . . . . . . . . . . 18 82 4.4. HIP State Machine . . . . . . . . . . . . . . . . . . . . 19 83 4.4.1. HIP States . . . . . . . . . . . . . . . . . . . . . 20 84 4.4.2. HIP State Processes . . . . . . . . . . . . . . . . . 21 85 4.4.3. Simplified HIP State Diagram . . . . . . . . . . . . 28 86 4.5. User Data Considerations . . . . . . . . . . . . . . . . 30 87 4.5.1. TCP and UDP Pseudo-header Computation for User Data . 30 88 4.5.2. Sending Data on HIP Packets . . . . . . . . . . . . . 30 89 4.5.3. Transport Formats . . . . . . . . . . . . . . . . . . 30 90 4.5.4. Reboot and SA Timeout Restart of HIP . . . . . . . . 30 92 4.6. Certificate Distribution . . . . . . . . . . . . . . . . 31 93 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 32 94 5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 32 95 5.1.1. Checksum . . . . . . . . . . . . . . . . . . . . . . 33 96 5.1.2. HIP Controls . . . . . . . . . . . . . . . . . . . . 33 97 5.1.3. HIP Fragmentation Support . . . . . . . . . . . . . . 34 98 5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 35 99 5.2.1. TLV Format . . . . . . . . . . . . . . . . . . . . . 37 100 5.2.2. Defining New Parameters . . . . . . . . . . . . . . . 39 101 5.2.3. R1_COUNTER . . . . . . . . . . . . . . . . . . . . . 40 102 5.2.4. PUZZLE . . . . . . . . . . . . . . . . . . . . . . . 41 103 5.2.5. SOLUTION . . . . . . . . . . . . . . . . . . . . . . 42 104 5.2.6. DIFFIE_HELLMAN . . . . . . . . . . . . . . . . . . . 43 105 5.2.7. HIP_TRANSFORM . . . . . . . . . . . . . . . . . . . . 44 106 5.2.8. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 45 107 5.2.9. HMAC . . . . . . . . . . . . . . . . . . . . . . . . 46 108 5.2.10. HMAC_2 . . . . . . . . . . . . . . . . . . . . . . . 47 109 5.2.11. HIP_SIGNATURE . . . . . . . . . . . . . . . . . . . . 47 110 5.2.12. HIP_SIGNATURE_2 . . . . . . . . . . . . . . . . . . . 48 111 5.2.13. SEQ . . . . . . . . . . . . . . . . . . . . . . . . . 48 112 5.2.14. ACK . . . . . . . . . . . . . . . . . . . . . . . . . 49 113 5.2.15. ENCRYPTED . . . . . . . . . . . . . . . . . . . . . . 50 114 5.2.16. NOTIFICATION . . . . . . . . . . . . . . . . . . . . 51 115 5.2.17. ECHO_REQUEST_SIGNED . . . . . . . . . . . . . . . . . 54 116 5.2.18. ECHO_REQUEST_UNSIGNED . . . . . . . . . . . . . . . . 55 117 5.2.19. ECHO_RESPONSE_SIGNED . . . . . . . . . . . . . . . . 55 118 5.2.20. ECHO_RESPONSE_UNSIGNED . . . . . . . . . . . . . . . 56 119 5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 56 120 5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 57 121 5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 58 122 5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 60 123 5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 61 124 5.3.5. UPDATE - the HIP Update Packet . . . . . . . . . . . 62 125 5.3.6. NOTIFY - the HIP Notify Packet . . . . . . . . . . . 63 126 5.3.7. CLOSE - the HIP Association Closing Packet . . . . . 63 127 5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet . . 64 128 5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 64 129 5.4.1. Invalid Version . . . . . . . . . . . . . . . . . . . 65 130 5.4.2. Other Problems with the HIP Header and Packet 131 Structure . . . . . . . . . . . . . . . . . . . . . . 65 132 5.4.3. Invalid Puzzle Solution . . . . . . . . . . . . . . . 65 133 5.4.4. Non-existing HIP Association . . . . . . . . . . . . 65 134 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 66 135 6.1. Processing Outgoing Application Data . . . . . . . . . . 66 136 6.2. Processing Incoming Application Data . . . . . . . . . . 67 137 6.3. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 68 138 6.4. HMAC and SIGNATURE Calculation and Verification . . . . . 69 139 6.4.1. HMAC Calculation . . . . . . . . . . . . . . . . . . 69 140 6.4.2. Signature Calculation . . . . . . . . . . . . . . . . 70 141 6.5. HIP KEYMAT Generation . . . . . . . . . . . . . . . . . . 71 142 6.6. Initiation of a HIP Exchange . . . . . . . . . . . . . . 72 143 6.6.1. Sending Multiple I1s in Parallel . . . . . . . . . . 73 144 6.6.2. Processing Incoming ICMP Protocol Unreachable 145 Messages . . . . . . . . . . . . . . . . . . . . . . 74 146 6.7. Processing Incoming I1 Packets . . . . . . . . . . . . . 74 147 6.7.1. R1 Management . . . . . . . . . . . . . . . . . . . . 75 148 6.7.2. Handling Malformed Messages . . . . . . . . . . . . . 75 149 6.8. Processing Incoming R1 Packets . . . . . . . . . . . . . 76 150 6.8.1. Handling Malformed Messages . . . . . . . . . . . . . 78 151 6.9. Processing Incoming I2 Packets . . . . . . . . . . . . . 78 152 6.9.1. Handling Malformed Messages . . . . . . . . . . . . . 80 153 6.10. Processing Incoming R2 Packets . . . . . . . . . . . . . 80 154 6.11. Sending UPDATE Packets . . . . . . . . . . . . . . . . . 81 155 6.12. Receiving UPDATE Packets . . . . . . . . . . . . . . . . 82 156 6.12.1. Handling a SEQ parameter in a received UPDATE 157 message . . . . . . . . . . . . . . . . . . . . . . . 83 158 6.12.2. Handling an ACK Parameter in a Received UPDATE 159 Packet . . . . . . . . . . . . . . . . . . . . . . . 83 160 6.13. Processing NOTIFY Packets . . . . . . . . . . . . . . . . 84 161 6.14. Processing CLOSE Packets . . . . . . . . . . . . . . . . 84 162 6.15. Processing CLOSE_ACK Packets . . . . . . . . . . . . . . 84 163 6.16. Dropping HIP Associations . . . . . . . . . . . . . . . . 85 164 7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 86 165 8. Security Considerations . . . . . . . . . . . . . . . . . . . 87 166 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 90 167 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 92 168 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 93 169 11.1. Normative References . . . . . . . . . . . . . . . . . . 93 170 11.2. Informative References . . . . . . . . . . . . . . . . . 94 171 Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 96 172 Appendix B. Generating a Public Key Encoding from a HI . . . . . 98 173 Appendix C. Example Checksums for HIP Packets . . . . . . . . . 99 174 C.1. IPv6 HIP Example (I1) . . . . . . . . . . . . . . . . . . 99 175 C.2. IPv4 HIP Packet (I1) . . . . . . . . . . . . . . . . . . 99 176 C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . . 99 177 Appendix D. 384-bit Group . . . . . . . . . . . . . . . . . . . 101 178 Appendix E. OAKLEY Well-known group 1 . . . . . . . . . . . . . 102 179 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 103 180 Intellectual Property and Copyright Statements . . . . . . . . . 104 182 1. Introduction 184 This memo specifies the details of the Host Identity Protocol (HIP). 185 A high-level description of the protocol and the underlying 186 architectural thinking is available in the separate HIP architecture 187 description [I-D.ietf-hip-arch]. Briefly, the HIP architecture 188 proposes an alternative to the dual use of IP addresses as "locators" 189 (routing labels) and "identifiers" (endpoint, or host, identifiers). 190 In HIP, public cryptographic keys, of a public/private key pair, are 191 used as Host Identifiers, to which higher layer protocols are bound 192 instead of an IP address. By using public keys (and their 193 representations) as host identifiers, dynamic changes to IP address 194 sets can be directly authenticated between hosts and if desired, 195 strong authentication between hosts at the TCP/IP stack level can be 196 obtained. 198 This memo specifies the base HIP protocol ("base exchange") used 199 between hosts to establish an IP-layer communications context, called 200 HIP association, prior to communications. It also defines a packet 201 format and procedures for updating an active HIP association. Other 202 elements of the HIP architecture are specified in other documents, 203 such as. 205 o "Using ESP transport format with HIP" [I-D.ietf-hip-esp]: how to 206 use Encapsulating Security Payload (ESP) for integrity protection 207 and optional encryption 209 o "End-Host Mobility and Multihoming with the Host Identity 210 Protocol" [I-D.ietf-hip-mm]: how to support mobility and 211 multihoming in HIP 213 o "Host Identity Protocol (HIP) Domain Name System (DNS) Extensions" 214 [I-D.ietf-hip-dns]: how to extend DNS to contain Host Identity 215 information 217 o "Host Identity Protocol (HIP) Rendezvous Extension" 218 [I-D.ietf-hip-rvs]: using a rendezvous mechanism to contact mobile 219 HIP hosts 221 1.1. A New Name Space and Identifiers 223 The Host Identity Protocol introduces a new name space, the Host 224 Identity name space. Some ramifications of this new namespace are 225 explained in the HIP architecture description [I-D.ietf-hip-arch]. 227 There are two main representations of the Host Identity, the full 228 Host Identifier (HI) and the Host Identity Tag (HIT). The HI is a 229 public key and directly represents the Identity. Since there are 230 different public key algorithms that can be used with different key 231 lengths, the HI is not good for use as a packet identifier, or as an 232 index into the various operational tables needed to support HIP. 233 Consequently, a hash of the HI, the Host Identity Tag (HIT), becomes 234 the operational representation. It is 128 bits long and is used in 235 the HIP payloads and to index the corresponding state in the end 236 hosts. The HIT has an important security property in that it is 237 self-certifying (see Section 3). 239 1.2. The HIP Base Exchange 241 The HIP base exchange is a two-party cryptographic protocol used to 242 establish communications context between hosts. The base exchange is 243 a Sigma-compliant [KRA03] four packet exchange. The first party is 244 called the Initiator and the second party the Responder. The four- 245 packet design helps to make HIP DoS resilient. The protocol 246 exchanges Diffie-Hellman keys in the 2nd and 3rd packets, and 247 authenticates the parties in the 3rd and 4th packets. Additionally, 248 the Responder starts a puzzle exchange in the 2nd packet, with the 249 Initiator completing it in the 3rd packet before the Responder stores 250 any state from the exchange. 252 The exchange can use the Diffie-Hellman output to encrypt the Host 253 Identity of the Initiator in packet 3 (although Aura et al. [AUR03] 254 notes that such operation may interfere with packet-inspecting 255 middleboxes), or the Host Identity may instead be sent unencrypted. 256 The Responder's Host Identity is not protected. It should be noted, 257 however, that both the Initiator's and the Responder's HITs are 258 transported as such (in cleartext) in the packets, allowing an 259 eavesdropper with a priori knowledge about the parties to verify 260 their identities. 262 Data packets start to flow after the 4th packet. The 3rd and 4th HIP 263 packets may carry a data payload in the future. However, the details 264 of this are to be defined later as more implementation experience is 265 gained. 267 An existing HIP association can be updated using the update mechanism 268 defined in this document, and when the association is no longer 269 needed, it can be closed using the defined closing mechanism. 271 Finally, HIP is designed as an end-to-end authentication and key 272 establishment protocol, to be used with Encapsulated Security Payload 273 (ESP) [I-D.ietf-hip-esp] and other end-to-end security protocols. 274 The base protocol does not cover all the fine-grained policy control 275 found in Internet Key Exchange IKE RFC2409 [RFC2409] that allows IKE 276 to support complex gateway policies. Thus, HIP is not a replacement 277 for IKE. 279 1.3. Memo structure 281 The rest of this memo is structured as follows. Section 2 defines 282 the central keywords, notation, and terms used throughout the rest of 283 the document. Section 3 defines the structure of the Host Identity 284 and its various representations. Section 4 gives an overview of the 285 HIP base exchange protocol. Section 5 and Section 6 define the 286 detail packet formats and rules for packet processing. Finally, 287 Section 7, Section 8, and Section 9 discuss policy, security, and 288 IANA considerations, respectively. 290 2. Terms and Definitions 292 2.1. Requirements Terminology 294 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 295 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 296 document are to be interpreted as described in RFC2119 [RFC2119]. 298 2.2. Notation 300 [x] indicates that x is optional. 302 {x} indicates that x is encrypted. 304 X(y) indicates that y is a parameter of X. 306 i indicates that x exists i times. 308 --> signifies "Initiator to Responder" communication (requests). 310 <-- signifies "Responder to Initiator" communication (replies). 312 | signifies concatenation of information-- e.g. X | Y is the 313 concatenation of X with Y. 315 Ltrunc (SHA-1(), K) denotes the lowest order K bits of the SHA-1 316 result. 318 2.3. Definitions 320 Unused Association Lifetime (UAL): Implementation-specific time for 321 which, if no packet is sent or received for this time interval, a 322 host MAY begin to tear down an active association. 324 Maximum Segment Lifetime (MSL): Maximum time that a TCP segment is 325 expected to spend in the network. 327 Exchange Complete (EC): Time that the host spends at the R2-SENT 328 before it moves to ESTABLISHED state. The time is n * I2 329 retransmission timeout, where n is about I2_RETRIES_MAX. 331 HIT Hash Algorithm: hash algorithm used to generate a Host Identity 332 Tag (HIT) from the Host Identity public key. Currently SHA-1 333 [FIPS95] is used. 335 Responder's HIT Hash Algorithm (RHASH): hash algorithm used for 336 various hash calculations in this document. The algorithm is the 337 same as is used to generate the Responder's HIT. RHASH can be 338 determined by inspecting the Prefix of the ORCHID (HIT). The 339 Prefix value has a one-to-one mapping to a hash function. 341 Opportunistic mode: HIP base exchange where the Responder's HIT is 342 not a priori known to the Initiator. 344 3. Host Identifier (HI) and its Representations 346 In this section, the properties of the Host Identifier and Host 347 Identifier Tag are discussed, and the exact format for them is 348 defined. In HIP, public key of an asymmetric key pair is used as the 349 Host Identifier (HI). Correspondingly, the host itself is defined as 350 the entity that holds the private key from the key pair. See the HIP 351 architecture specification [I-D.ietf-hip-arch] for more details about 352 the difference between an identity and the corresponding identifier. 354 HIP implementations MUST support the Rivest Shamir Adelman (RSA/SHA1) 355 [RFC3110] public key algorithm, and SHOULD support the Digital 356 Signature Algorithm (DSA) [RFC2536] algorithm; other algorithms MAY 357 be supported. 359 A hashed encoding of the HI, the Host Identity Tag (HIT), is used in 360 protocols to represent the Host Identity. The HIT is 128 bits long 361 and has the following three key properties: i) it is the same length 362 as an IPv6 address and can be used in address-sized fields in APIs 363 and protocols, ii) it is self-certifying (i.e., given a HIT, it is 364 computationally hard to find a Host Identity key that matches the 365 HIT), and iii) the probability of HIT collision between two hosts is 366 very low. 368 Carrying HIs and HITs in the header of user data packets would 369 increase the overhead of packets. Thus, it is not expected that they 370 are carried in every packet, but other methods are used to map the 371 data packets to the corresponding HIs. In some cases, this makes it 372 possible to use HIP without any additional headers in the user data 373 packets. For example, if ESP is used to protect data traffic, the 374 Security Parameter Index (SPI) carried in the ESP header can be used 375 to map the encrypted data packet to the correct HIP association. 377 3.1. Host Identity Tag (HIT) 379 The Host Identity Tag is a 128 bits long value -- a hashed encoding 380 of the Host Identifier. There are two advantages of using a hashed 381 encoding over the actual Host Identity public key in protocols. 382 Firstly, its fixed length makes for easier protocol coding and also 383 better manages the packet size cost of this technology. Secondly, it 384 presents a consistent format to the protocol whatever underlying 385 identity technology is used. 387 "An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers 388 (ORCHID)" [I-D.laganier-ipv6-khi] has been specified to store 128-bit 389 hash based identifier called Overlay Routable Cryptographic Hash 390 Identifiers (ORCHID) under a prefix, proposed to be allocated from 391 the IPv6 address block as defined in [I-D.laganier-ipv6-khi]. The 392 Host Identity Tag is a type of ORCHID, based on a SHA-1 hash of the 393 host identity (Section 2 of [I-D.laganier-ipv6-khi]). 395 3.2. Generating a HIT from a HI 397 The HIT MUST be generated according to the ORCHID generation method 398 described in [I-D.laganier-ipv6-khi] using a context ID value of 399 0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA (this tag value has been 400 generated randomly by the editor of this specification), and an input 401 encoding the Host Identity field (see Section 5.2.8) present in a HIP 402 payload packet. The hash algorithm SHA-1 has to be used when 403 generating HITs with this context ID. If a new ORCHID hash algorithm 404 is needed in the future for HIT generation, a new version of HIP has 405 to be specified with a new ORCHID context ID associated with the new 406 hash algorithm. 408 For Identities that are either RSA or DSA public keys, this input 409 consists of the public key encoding as specified in the corresponding 410 DNSSEC document, taking the algorithm specific portion of the RDATA 411 part of the KEY RR. There is currently only two defined public key 412 algorithms: RSA/SHA1 and DSA. Hence, either of the following 413 applies: 415 The RSA public key is encoded as defined in RFC3110 [RFC3110] 416 Section 2, taking the exponent length (e_len), exponent (e) and 417 modulus (n) fields concatenated. The length (n_len) of the 418 modulus (n) can be determined from the total HI Length and the 419 preceding HI fields including the exponent (e). Thus, the data to 420 be hashed has the same length as the HI. The fields MUST be 421 encoded in network byte order, as defined in RFC3110 [RFC3110]. 423 The DSA public key is encoded as defined in RFC2536 [RFC2536] 424 Section 2, taking the fields T, Q, P, G, and Y, concatenated. 425 Thus, the data to be hashed is 1 + 20 + 3 * 64 + 3 * 8 * T octets 426 long, where T is the size parameter as defined in RFC2536 427 [RFC2536]. The size parameter T, affecting the field lengths, 428 MUST be selected as the minimum value that is long enough to 429 accommodate P, G, and Y. The fields MUST be encoded in network 430 byte order, as defined in RFC2536 [RFC2536]. 432 In Appendix B the public key encoding generation process is 433 illustrated using pseudo-code. 435 4. Protocol Overview 437 The following material is an overview of the HIP protocol operation, 438 and does not contain all details of the packet formats or the packet 439 processing steps. Section 5 and Section 6 describe in more detail 440 the packet formats and packet processing steps, respectively, and are 441 normative in case of any conflicts with this section. 443 The protocol number for Host Identity Protocol will be assigned by 444 IANA. For testing purposes, the protocol number 253 is currently 445 used. This number has been reserved by IANA for experimental use 446 (see [RFC3692]). 448 The HIP payload (Section 5.1) header could be carried in every IP 449 datagram. However, since HIP headers are relatively large (40 450 bytes), it is desirable to 'compress' the HIP header so that the HIP 451 header only occurs in control packets used to establish or change HIP 452 association state. The actual method for header 'compression' and 453 for matching data packets with existing HIP associations (if any) is 454 defined in separate documents, describing transport formats and 455 methods. All HIP implementations MUST implement, at minimum, the ESP 456 transport format for HIP [I-D.ietf-hip-esp]. 458 4.1. Creating a HIP Association 460 By definition, the system initiating a HIP exchange is the Initiator, 461 and the peer is the Responder. This distinction is forgotten once 462 the base exchange completes, and either party can become the 463 Initiator in future communications. 465 The HIP base exchange serves to manage the establishment of state 466 between an Initiator and a Responder. The first packet, I1, 467 initiates the exchange, and the last three packets, R1, I2, and R2, 468 constitute an authenticated Diffie-Hellman [DIF76] key exchange for 469 session key generation. During the Diffie-Hellman key exchange, a 470 piece of keying material is generated. The HIP association keys are 471 drawn from this keying material. If other cryptographic keys are 472 needed, e.g., to be used with ESP, they are expected to be drawn from 473 the same keying material. 475 The Initiator first sends a trigger packet, I1, to the Responder. 476 The packet contains only the HIT of the Initiator and possibly the 477 HIT of the Responder, if it is known. Note that in some cases it may 478 be possible to replace this trigger packet by some other form of a 479 trigger, in which case the protocol starts with the Responder sending 480 the R1 packet. 482 The second packet, R1, starts the actual exchange. It contains a 483 puzzle-- a cryptographic challenge that the Initiator must solve 484 before continuing the exchange. The level of difficulty of the 485 puzzle can be adjusted based on level of trust with the Initiator, 486 current load, or other factors. In addition, the R1 contains the 487 initial Diffie-Hellman parameters and a signature, covering part of 488 the message. Some fields are left outside the signature to support 489 pre-created R1s. 491 In the I2 packet, the Initiator must display the solution to the 492 received puzzle. Without a correct solution, the I2 message is 493 discarded. The I2 also contains a Diffie-Hellman parameter that 494 carries needed information for the Responder. The packet is signed 495 by the sender. 497 The R2 packet finalizes the base exchange. The packet is signed. 499 The base exchange is illustrated below. The term "key" refers to the 500 host identity public key, and "sig" represents a signature using such 501 a key. The packets contain other parameters not shown in this 502 figure. 504 Initiator Responder 506 I1: trigger exchange 507 --------------------------> 508 select pre-computed R1 509 R1: puzzle, D-H, key, sig 510 <------------------------- 511 check sig remain stateless 512 solve puzzle 513 I2: solution, D-H, {key}, sig 514 --------------------------> 515 compute D-H check puzzle 516 check sig 517 R2: sig 518 <-------------------------- 519 check sig compute D-H 521 4.1.1. HIP Puzzle Mechanism 523 The purpose of the HIP puzzle mechanism is to protect the Responder 524 from a number of denial-of-service threats. It allows the Responder 525 to delay state creation until receiving I2. Furthermore, the puzzle 526 allows the Responder to use a fairly cheap calculation to check that 527 the Initiator is "sincere" in the sense that it has churned CPU 528 cycles in solving the puzzle. 530 The Puzzle mechanism has been explicitly designed to give space for 531 various implementation options. It allows a Responder implementation 532 to completely delay session specific state creation until a valid I2 533 is received. In such a case a correctly formatted I2 can be rejected 534 only once the Responder has checked its validity by computing one 535 hash function. On the other hand, the design also allows a Responder 536 implementation to keep state about received I1s, and match the 537 received I2s against the state, thereby allowing the implementation 538 to avoid the computational cost of the hash function. The drawback 539 of this latter approach is the requirement of creating state. 540 Finally, it also allows an implementation to use other combinations 541 of the space-saving and computation-saving mechanisms. 543 One possible way for a Responder to remain stateless but drop most 544 spoofed I2s is to base the selection of the puzzle on some function 545 over the Initiator's Host Identity. The idea is that the Responder 546 has a (perhaps varying) number of pre-calculated R1 packets, and it 547 selects one of these based on the information carried in I1. When 548 the Responder then later receives I2, it checks that the puzzle in 549 the I2 matches with the puzzle sent in the R1, thereby making it 550 impractical for the attacker to first exchange one I1/R1, and then 551 generate a large number of spoofed I2s that seemingly come from 552 different IP addresses or use different HITs. The method does not 553 protect from an attacker that uses fixed IP addresses and HITs, 554 though. Against such an attacker a viable approach may be to create 555 a piece of local state, and remember that the puzzle check has 556 previously failed. See Appendix A for one possible implementation. 557 Implementations SHOULD include sufficient randomness to the algorithm 558 so that algorithmic complexity attacks become impossible [CRO03]. 560 The Responder can set the puzzle difficulty for Initiator, based on 561 its level of trust of the Initiator. Because the puzzle is not 562 included in the signature calculation, the Responder can use pre- 563 calculated R1 packets and include the puzzle just before sending the 564 R1 to the Initiator. The Responder SHOULD use heuristics to 565 determine when it is under a denial-of-service attack, and set the 566 puzzle difficulty value K appropriately; see below. 568 4.1.2. Puzzle exchange 570 The Responder starts the puzzle exchange when it receives an I1. The 571 Responder supplies a random number I, and requires the Initiator to 572 find a number J. To select a proper J, the Initiator must create the 573 concatenation of I, the HITs of the parties, and J, and take a hash 574 over this concatenation using RHASH algorithm. The lowest order K 575 bits of the result MUST be zeros. The value K sets the difficulty of 576 the puzzle. 578 To generate a proper number J, the Initiator will have to generate a 579 number of Js until one produces the hash target of zero. The 580 Initiator SHOULD give up after exceeding the puzzle lifetime in the 581 PUZZLE parameter (Section 5.2.4). The Responder needs to re-create 582 the concatenation of I, the HITs, and the provided J, and compute the 583 hash once to prove that the Initiator did its assigned task. 585 To prevent pre-computation attacks, the Responder MUST select the 586 number I in such a way that the Initiator cannot guess it. 587 Furthermore, the construction MUST allow the Responder to verify that 588 the value was indeed selected by it and not by the Initiator. See 589 Appendix A for an example on how to implement this. 591 Using the Opaque data field in an ECHO_REQUEST_SIGNED 592 (Section 5.2.17) or in an ECHO_REQUEST_UNSIGNED parameters 593 (Section 5.2.18), the Responder can include some data in R1 that the 594 Initiator must copy unmodified in the corresponding I2 packet. The 595 Responder can generate the Opaque data in various ways; e.g. using 596 the sent I, some secret, and possibly other related data. Using this 597 same secret, received I in I2 packet and possible other data, the 598 Receiver can verify that it has itself sent the I to the Initiator. 599 The Responder MUST change such a secret periodically. 601 It is RECOMMENDED that the Responder generates a new puzzle and a new 602 R1 once every few minutes. Furthermore, it is RECOMMENDED that the 603 Responder remembers an old puzzle at least 2*Lifetime seconds after 604 it has been deprecated. These time values allow a slower Initiator 605 to solve the puzzle while limiting the usability that an old, solved 606 puzzle has to an attacker. 608 NOTE: The protocol developers explicitly considered whether R1 should 609 include a timestamp in order to protect the Initiator from replay 610 attacks. The decision was to NOT include a timestamp. 612 NOTE: The protocol developers explicitly considered whether a memory 613 bound function should be used for the puzzle instead of a CPU bound 614 function. The decision was not to use memory bound functions. At 615 the time of the decision the idea of memory bound functions was 616 relatively new and their IPR status were unknown. Once there is more 617 experience about memory bound functions and once their IPR status is 618 better known, it may be reasonable to reconsider this decision. 620 4.1.3. Authenticated Diffie-Hellman Protocol 622 The packets R1, I2, and R2 implement a standard authenticated Diffie- 623 Hellman exchange. The Responder sends one or two public Diffie- 624 Hellman keys and its public authentication key, i.e., its host 625 identity, in R1. The signature in R1 allows the Initiator to verify 626 that the R1 has been once generated by the Responder. However, since 627 it is precomputed and therefore does not cover all of the packet, it 628 does not protect from replay attacks. 630 When the Initiator receives an R1, it gets one or two public Diffie- 631 Hellman values from the Responder. If there are two values, it 632 selects the value corresponding to the strongest supported Group ID 633 and computes the Diffie-Hellman session key (Kij). It creates a HIP 634 association using keying material from the session key (see 635 Section 6.5), and may use the association to encrypt its public 636 authentication key, i.e., host identity. The resulting I2 contains 637 the Initiator's Diffie-Hellman key and its (optionally encrypted) 638 public authentication key. The signature in I2 covers all of the 639 packet. 641 The Responder extracts the Initiator Diffie-Hellman public key from 642 the I2, computes the Diffie-Hellman session key, creates a 643 corresponding HIP association, and decrypts the Initiator's public 644 authentication key. It can then verify the signature using the 645 authentication key. 647 The final message, R2, is needed to protect the Initiator from replay 648 attacks. 650 4.1.4. HIP Replay Protection 652 The HIP protocol includes the following mechanisms to protect against 653 malicious replays. Responders are protected against replays of I1 654 packets by virtue of the stateless response to I1s with presigned R1 655 messages. Initiators are protected against R1 replays by a 656 monotonically increasing "R1 generation counter" included in the R1. 657 Responders are protected against replays or false I2s by the puzzle 658 mechanism (Section 4.1.1 above), and optional use of opaque data. 659 Hosts are protected against replays to R2s and UPDATEs by use of a 660 less expensive HMAC verification preceding HIP signature 661 verification. 663 The R1 generation counter is a monotonically increasing 64-bit 664 counter that may be initialized to any value. The scope of the 665 counter MAY be system-wide but SHOULD be per host identity, if there 666 is more than one local host identity. The value of this counter 667 SHOULD be kept across system reboots and invocations of the HIP base 668 exchange. This counter indicates the current generation of puzzles. 669 Implementations MUST accept puzzles from the current generation and 670 MAY accept puzzles from earlier generations. A system's local 671 counter MUST be incremented at least as often as every time old R1s 672 cease to be valid, and SHOULD never be decremented, lest the host 673 expose its peers to the replay of previously generated, higher 674 numbered R1s. The R1 counter SHOULD NOT roll over. 676 A host may receive more than one R1, either due to sending multiple 677 I1s (Section 6.6.1) or due to a replay of an old R1. When sending 678 multiple I1s, an initiator SHOULD wait for a small amount of time (a 679 reasonable time may be 2 * expected RTT) after the first R1 reception 680 to allow possibly multiple R1s to arrive, and it SHOULD respond to an 681 R1 among the set with the largest R1 generation counter. If an 682 Initiator is processing an R1 or has already sent an I2 (still 683 waiting for R2) and it receives another R1 with a larger R1 684 generation counter, it MAY elect to restart R1 processing with the 685 fresher R1, as if it were the first R1 to arrive. 687 Upon conclusion of an active HIP association with another host, the 688 R1 generation counter associated with the peer host SHOULD be 689 flushed. A local policy MAY override the default flushing of R1 690 counters on a per-HIT basis. The reason for recommending the 691 flushing of this counter is that there may be hosts where the R1 692 generation counter (occasionally) decreases; e.g., due to hardware 693 failure. 695 4.1.5. Refusing a HIP Exchange 697 A HIP aware host may choose not to accept a HIP exchange. If the 698 host's policy is to only be an Initiator, it should begin its own HIP 699 exchange. A host MAY choose to have such a policy since only the 700 Initiator HI is protected in the exchange. There is a risk of a race 701 condition if each host's policy is to only be an Initiator, at which 702 point the HIP exchange will fail. 704 If the host's policy does not permit it to enter into a HIP exchange 705 with the Initiator, it should send an ICMP 'Destination Unreachable, 706 Administratively Prohibited' message. A more complex HIP packet is 707 not used here as it actually opens up more potential DoS attacks than 708 a simple ICMP message. 710 4.1.6. HIP Opportunistic Mode 712 It is possible to initiate a HIP negotiation even if the responder's 713 HI (and HIT) is unknown. In this case the connection initializing I1 714 packet contains NULL (all zeros) as the destination HIT. This kind 715 of connection setup is called opportunistic mode. 717 There are multiple security issues involved with opportunistic mode 718 that must be carefully addressed in the implementation. Such a set 719 up is vulnerable to, e.g., man-in-the-middle attacks, because the 720 initializing node does not have any public key information about the 721 peer. 723 While this document defines the concept of the opportunistic mode, 724 and outlines the basic signalling mechanism to trigger it; i.e., send 725 an I1 with a NULL destination HIT, this document does not specify the 726 details of the opportunistic mode. Especially, its security 727 properties are not discussed beyond the warning above. It is 728 expected that a separate document will describe the opportunistic 729 mode in more detail, including its security properties. 731 4.2. Updating a HIP Association 733 A HIP association between two hosts may need to be updated over time. 734 Examples include the need to rekey expiring user data security 735 associations, add new security associations, or change IP addresses 736 associated with hosts. The UPDATE packet is used for those and other 737 similar purposes. This document only specifies the UPDATE packet 738 format and basic processing rules, with mandatory parameters. The 739 actual usage is defined in separate specifications. 741 HIP provides a general purpose UPDATE packet, which can carry 742 multiple HIP parameters, for updating the HIP state between two 743 peers. The UPDATE mechanism has the following properties: 745 UPDATE messages carry a monotonically increasing sequence number 746 and are explicitly acknowledged by the peer. Lost UPDATEs or 747 acknowledgments may be recovered via retransmission. Multiple 748 UPDATE messages may be outstanding under certain circumstances. 750 UPDATE is protected by both HMAC and HIP_SIGNATURE parameters, 751 since processing UPDATE signatures alone is a potential DoS attack 752 against intermediate systems. 754 UPDATE packets are explicitly acknowledged by the use of an 755 acknowledgment parameter that echoes an individual sequence number 756 received from the peer. A single UPDATE packet may contain both a 757 sequence number and one or more acknowledgment numbers (i.e., 758 piggybacked acknowledgment(s) for the peer's UPDATE). 760 The UPDATE packet is defined in Section 5.3.5. 762 4.3. Error Processing 764 HIP error processing behavior depends on whether there exists an 765 active HIP association or not. In general, if a HIP association 766 exists between the sender and receiver of a packet causing an error 767 condition, the receiver SHOULD respond with a NOTIFY packet. On the 768 other hand, if there are no existing HIP associations between the 769 sender and receiver, or the receiver cannot reasonably determine the 770 identity of the sender, the receiver MAY respond with a suitable ICMP 771 message; see Section 5.4 for more details. 773 The HIP protocol and state machine is designed to recover from one of 774 the parties crashing and losing its state. The following scenarios 775 describe the main use cases covered by the design. 777 No prior state between the two systems. 779 The system with data to send is the Initiator. The process 780 follows the standard four packet base exchange, establishing 781 the HIP association. 783 The system with data to send has no state with the receiver, but 784 the receiver has a residual HIP association. 786 The system with data to send is the Initiator. The Initiator 787 acts as in no prior state, sending I1 and getting R1. When the 788 Responder receives a valid I2, the old association is 789 'discovered' and deleted, and the new association is 790 established. 792 The system with data to send has a HIP association, but the 793 receiver does not. 795 The system sends data on the outbound user data security 796 association. The receiver 'detects' the situation when it 797 receives a user data packet that it cannot match to any HIP 798 association. The receiving host MUST discard this packet. 799 Optionally, the receiving host MAY send an ICMP packet with the 800 Parameter Problem type to inform about non-existing HIP 801 association (see Section 5.4), and it MAY initiate a new HIP 802 negotiation. However, responding with these optional 803 mechanisms is implementation or policy dependent. 805 4.4. HIP State Machine 807 The HIP protocol itself has little state. In the HIP base exchange, 808 there is an Initiator and a Responder. Once the SAs are established, 809 this distinction is lost. If the HIP state needs to be re- 810 established, the controlling parameters are which peer still has 811 state and which has a datagram to send to its peer. The following 812 state machine attempts to capture these processes. 814 The state machine is presented in a single system view, representing 815 either an Initiator or a Responder. There is not a complete overlap 816 of processing logic here and in the packet definitions. Both are 817 needed to completely implement HIP. 819 Implementors must understand that the state machine, as described 820 here, is informational. Specific implementations are free to 821 implement the actual functions differently. Section 6 describes the 822 packet processing rules in more detail. This state machine focuses 823 on the HIP I1, R1, I2, and R2 packets only. Other states may be 824 introduced by mechanisms in other specifications (such as mobility 825 and multihoming). 827 4.4.1. HIP States 829 +---------------------+---------------------------------------------+ 830 | State | Explanation | 831 +---------------------+---------------------------------------------+ 832 | UNASSOCIATED | State machine start | 833 | | | 834 | I1-SENT | Initiating base exchange | 835 | | | 836 | I2-SENT | Waiting to complete base exchange | 837 | | | 838 | R2-SENT | Waiting to complete base exchange | 839 | | | 840 | ESTABLISHED | HIP association established | 841 | | | 842 | CLOSING | HIP association closing, no data can be | 843 | | sent | 844 | | | 845 | CLOSED | HIP association closed, no data can be sent | 846 | | | 847 | E-FAILED | HIP exchange failed | 848 +---------------------+---------------------------------------------+ 850 4.4.2. HIP State Processes 852 System behaviour in state UNASSOCIATED, Table 2. 854 +---------------------+---------------------------------------------+ 855 | Trigger | Action | 856 +---------------------+---------------------------------------------+ 857 | User data to send, | Send I1 and go to I1-SENT | 858 | requiring a new HIP | | 859 | association | | 860 | | | 861 | Receive I1 | Send R1 and stay at UNASSOCIATED | 862 | | | 863 | Receive I2, process | If successful, send R2 and go to R2-SENT | 864 | | | 865 | | If fail, stay at UNASSOCIATED | 866 | | | 867 | Receive user data | Optionally send ICMP as defined in | 868 | for unknown HIP | Section 5.4 and stay at UNASSOCIATED | 869 | association | | 870 | | | 871 | Receive CLOSE | Optionally send ICMP Parameter Problem and | 872 | | stay at UNASSOCIATED | 873 | | | 874 | Receive ANYOTHER | Drop and stay at UNASSOCIATED | 875 +---------------------+---------------------------------------------+ 877 Table 2: UNASSOCIATED - Start state 879 System behaviour in state I1-SENT, Table 3. 881 +---------------------+---------------------------------------------+ 882 | Trigger | Action | 883 +---------------------+---------------------------------------------+ 884 | Receive I1 | If the local HIT is smaller than the peer | 885 | | HIT, drop I1 and stay at I1-SENT | 886 | | | 887 | | If the local HIT is greater than the peer | 888 | | HIT, send R1 and stay at I1_SENT | 889 | | | 890 | Receive I2, process | If successful, send R2 and go to R2-SENT | 891 | | | 892 | | If fail, stay at I1-SENT | 893 | | | 894 | Receive R1, process | If successful, send I2 and go to I2-SENT | 895 | | | 896 | | If fail, stay at I1-SENT | 897 | | | 898 | Receive ANYOTHER | Drop and stay at I1-SENT | 899 | | | 900 | Timeout, increment | If counter is less than I1_RETRIES_MAX, | 901 | timeout counter | send I1 and stay at I1-SENT | 902 | | | 903 | | If counter is greater than I1_RETRIES_MAX, | 904 | | go to E-FAILED | 905 +---------------------+---------------------------------------------+ 907 Table 3: I1-SENT - Initiating HIP 909 System behaviour in state I2-SENT, Table 4. 911 +---------------------+---------------------------------------------+ 912 | Trigger | Action | 913 +---------------------+---------------------------------------------+ 914 | Receive I1 | Send R1 and stay at I2-SENT | 915 | | | 916 | Receive R1, process | If successful, send I2 and cycle at I2-SENT | 917 | | | 918 | | If fail, stay at I2-SENT | 919 | | | 920 | Receive I2, process | If successful and local HIT is smaller than | 921 | | the peer HIT, drop I2 and stay at I2-SENT | 922 | | | 923 | | If succesful and local HIT is greater than | 924 | | the peer HIT, send R2 and go to R2-SENT | 925 | | | 926 | | If fail, stay at I2-SENT | 927 | | | 928 | Receive R2, process | If successful, go to ESTABLISHED | 929 | | | 930 | | If fail, stay at I2-SENT | 931 | | | 932 | Receive ANYOTHER | Drop and stay at I2-SENT | 933 | | | 934 | Timeout, increment | If counter is less than I2_RETRIES_MAX, | 935 | timeout counter | send I2 and stay at I2-SENT | 936 | | | 937 | | If counter is greater than I2_RETRIES_MAX, | 938 | | go to E-FAILED | 939 +---------------------+---------------------------------------------+ 941 Table 4: I2-SENT - Waiting to finish HIP 943 System behaviour in state R2-SENT, Table 5. 945 +---------------------+---------------------------------------------+ 946 | Trigger | Action | 947 +---------------------+---------------------------------------------+ 948 | Receive I1 | Send R1 and stay at R2-SENT | 949 | | | 950 | Receive I2, process | If successful, send R2 and cycle at R2-SENT | 951 | | | 952 | | If fail, stay at R2-SENT | 953 | | | 954 | Receive R1 | Drop and stay at R2-SENT | 955 | | | 956 | Receive R2 | Drop and stay at R2-SENT | 957 | | | 958 | Receive data or | Move to ESTABLISHED | 959 | UPDATE | | 960 | | | 961 | Exchange Complete | Move to ESTABLISHED | 962 | Timeout | | 963 +---------------------+---------------------------------------------+ 965 Table 5: R2-SENT - Waiting to finish HIP 967 System behaviour in state ESTABLISHED, Table 6. 969 +---------------------+---------------------------------------------+ 970 | Trigger | Action | 971 +---------------------+---------------------------------------------+ 972 | Receive I1 | Send R1 and stay at ESTABLISHED | 973 | | | 974 | Receive I2, process | If successful, send R2, drop old HIP | 975 | with puzzle and | association, establish a new HIP | 976 | possible Opaque | association, go to R2-SENT | 977 | data verification | | 978 | | | 979 | | If fail, stay at ESTABLISHED | 980 | | | 981 | Receive R1 | Drop and stay at ESTABLISHED | 982 | | | 983 | Receive R2 | Drop and stay at ESTABLISHED | 984 | | | 985 | Receive user data | Process and stay at ESTABLISHED | 986 | for HIP association | | 987 | | | 988 | No packet | Send CLOSE and go to CLOSING | 989 | sent/received | | 990 | during UAL minutes | | 991 | | | 992 | Receive CLOSE, | If successful, send CLOSE_ACK and go to | 993 | process | CLOSED | 994 | | | 995 | | If fail, stay at ESTABLISHED | 996 +---------------------+---------------------------------------------+ 998 Table 6: ESTABLISHED - HIP association established 1000 System behaviour in state CLOSING, Table 7. 1002 +---------------------+---------------------------------------------+ 1003 | Trigger | Action | 1004 +---------------------+---------------------------------------------+ 1005 | User data to send, | Send I1 and stay at CLOSING | 1006 | requires the | | 1007 | creation of another | | 1008 | incarnation of the | | 1009 | HIP association | | 1010 | | | 1011 | Receive I1 | Send R1 and stay at CLOSING | 1012 | | | 1013 | Receive I2, process | If successful, send R2 and go to R2-SENT | 1014 | | | 1015 | | If fail, stay at CLOSING | 1016 | | | 1017 | Receive R1, process | If successful, send I2 and go to I2-SENT | 1018 | | | 1019 | | If fail, stay at CLOSING | 1020 | | | 1021 | Receive CLOSE, | If successful, send CLOSE_ACK, discard | 1022 | process | state and go to CLOSED | 1023 | | | 1024 | | If fail, stay at CLOSING | 1025 | | | 1026 | Receive CLOSE_ACK, | If successful, discard state and go to | 1027 | process | UNASSOCIATED | 1028 | | | 1029 | | If fail, stay at CLOSING | 1030 | | | 1031 | Receive ANYOTHER | Drop and stay at CLOSING | 1032 | | | 1033 | Timeout, increment | If timeout sum is less than UAL+MSL | 1034 | timeout sum, reset | minutes, retransmit CLOSE and stay at | 1035 | timer | CLOSING | 1036 | | | 1037 | | If timeout sum is greater than UAL+MSL | 1038 | | minutes, go to UNASSOCIATED | 1039 +---------------------+---------------------------------------------+ 1041 Table 7: CLOSING - HIP association has not been used for UAL minutes 1042 System behaviour in state CLOSED, Table 8. 1044 +---------------------+---------------------------------------------+ 1045 | Trigger | Action | 1046 +---------------------+---------------------------------------------+ 1047 | Datagram to send, | Send I1, and stay at CLOSED | 1048 | requires the | | 1049 | creation of another | | 1050 | incarnation of the | | 1051 | HIP association | | 1052 | | | 1053 | Receive I1 | Send R1 and stay at CLOSED | 1054 | | | 1055 | Receive I2, process | If successful, send R2 and go to R2-SENT | 1056 | | | 1057 | | If fail, stay at CLOSED | 1058 | | | 1059 | Receive R1, process | If successful, send I2 and go to I2-SENT | 1060 | | | 1061 | | If fail, stay at CLOSED | 1062 | | | 1063 | Receive CLOSE, | If successful, send CLOSE_ACK, stay at | 1064 | process | CLOSED | 1065 | | | 1066 | | If fail, stay at CLOSED | 1067 | | | 1068 | Receive CLOSE_ACK, | If successful, discard state and go to | 1069 | process | UNASSOCIATED | 1070 | | | 1071 | | If fail, stay at CLOSED | 1072 | | | 1073 | Receive ANYOTHER | Drop and stay at CLOSED | 1074 | | | 1075 | Timeout (UAL+2MSL) | Discard state and go to UNASSOCIATED | 1076 +---------------------+---------------------------------------------+ 1078 Table 8: CLOSED - CLOSE_ACK sent, resending CLOSE_ACK if necessary 1080 System behaviour in state E-FAILED, Table 9. 1082 +---------------------+---------------------------------------------+ 1083 | Trigger | Action | 1084 +---------------------+---------------------------------------------+ 1085 | Wait for | Go to UNASSOCIATED. Re-negotiation is | 1086 | implementation | possible after moving to UNASSOCIATED | 1087 | specific time | state. | 1088 +---------------------+---------------------------------------------+ 1090 Table 9: E-FAILED - HIP failed to establish association with peer 1092 4.4.3. Simplified HIP State Diagram 1094 The following diagram shows the major state transitions. Transitions 1095 based on received packets implicitly assume that the packets are 1096 successfully authenticated or processed. 1098 +-+ +---------------------------+ 1099 I1 received, send R1 | | | | 1100 | v v | 1101 Datagram to send +--------------+ I2 received, send R2 | 1102 +---------------| UNASSOCIATED |---------------+ | 1103 Send I1 | +--------------+ | | 1104 v | | 1105 +---------+ I2 received, send R2 | | 1106 +---->| I1-SENT |---------------------------------------+ | | 1107 | +---------+ | | | 1108 | | +------------------------+ | | | 1109 | | R1 received, | I2 received, send R2 | | | | 1110 | v send I2 | v v v | 1111 | +---------+ | +---------+ | 1112 | +->| I2-SENT |------------+ | R2-SENT |<----+ | 1113 | | +---------+ +---------+ | | 1114 | | | | | | 1115 | | | data| | | 1116 | |receive | or| | | 1117 | |R1, send | EC timeout| receive I2,| | 1118 | |I2 |R2 received +--------------+ | send R2| | 1119 | | +----------->| ESTABLISHED |<-------+| | | 1120 | | +--------------+ | | 1121 | | | | | receive I2, send R2 | | 1122 | | recv+------------+ | +------------------------+ | 1123 | | CLOSE,| | | | 1124 | | send| No packet sent| | | 1125 | | CLOSE_ACK| /received for | timeout | | 1126 | | | UAL min, send | +---------+<-+ (UAL+MSL) | | 1127 | | | CLOSE +--->| CLOSING |--+ retransmit | | 1128 | | | +---------+ CLOSE | | 1129 +--|------------|----------------------+ | | | | | | 1130 | +------------|------------------------+ | | +----------------+ | 1131 | | | +-----------+ +------------------|--+ 1132 | | +------------+ | receive CLOSE, CLOSE_ACK | | 1133 | | | | send CLOSE_ACK received or | | 1134 | | | | timeout | | 1135 | | | | (UAL+MSL) | | 1136 | | v v | | 1137 | | +--------+ receive I2, send R2 | | 1138 | +------------------------| CLOSED |---------------------------+ | 1139 +---------------------------+--------+ /----------------------+ 1140 Datagram to send, send I1 ^ | \-------/ timeout (UAL+2MSL), 1141 +-+ move to UNASSOCIATED 1142 CLOSE received, send CLOSE_ACK 1144 4.5. User Data Considerations 1146 4.5.1. TCP and UDP Pseudo-header Computation for User Data 1148 When computing TCP and UDP checksums on user data packets that flow 1149 through sockets bound to HITs, the IPv6 pseudo-header format 1150 [RFC2460] MUST be used, even if the actual addresses on the packet 1151 are IPv4 addresses. Additionally, the HITs MUST be used in the place 1152 of the IPv6 addresses in the IPv6 pseudo-header. Note that the 1153 pseudo-header for actual HIP payloads is computed differently; see 1154 Section 5.1.1. 1156 4.5.2. Sending Data on HIP Packets 1158 A future version of this document may define how to include user data 1159 on various HIP packets. However, currently the HIP header is a 1160 terminal header, and not followed by any other headers. 1162 4.5.3. Transport Formats 1164 The actual data transmission format, used for user data after the HIP 1165 base exchange, is not defined in this document. Such transport 1166 formats and methods are described in separate specifications. All 1167 HIP implementations MUST implement, at minimum, the ESP transport 1168 format for HIP [I-D.ietf-hip-esp]. 1170 When new transport formats are defined, they get the type value from 1171 the HIP Transform type value space 2048 - 4095. The order in which 1172 the transport formats are presented in the R1 packet, is the 1173 preferred order. The last of the transport formats MUST be ESP 1174 transport format, represented by the ESP_TRANSFORM parameter. 1176 4.5.4. Reboot and SA Timeout Restart of HIP 1178 Simulating a loss of state is a potential DoS attack. The following 1179 process has been crafted to manage state recovery without presenting 1180 a DoS opportunity. 1182 If a host reboots or the HIP association times out, it has lost its 1183 HIP state. If the host that lost state has a datagram to send to the 1184 peer, it simply restarts the HIP base exchange. After the base 1185 exchange has completed, the Initiator can create a new SA and start 1186 sending data. The peer does not reset its state until it receives a 1187 valid I2 HIP packet. 1189 If a system receives a user data packet that cannot be matched to any 1190 existing HIP association, it is possible that it has lost the state 1191 and its peer has not. It MAY send an ICMP packet with the Parameter 1192 Problem type, the Pointer pointing to the referred HIP-related 1193 association information. Reacting to such traffic depends on the 1194 implementation and the environment where the implementation is used. 1196 If the host, that apparently has lost its state, decides to restart 1197 the HIP base exchange, it sends an I1 packet to the peer. After the 1198 base exchange has been completed successfully, the Initiator can 1199 create a new HIP association and the peer drops its OLD SA and 1200 creates a new one. 1202 4.6. Certificate Distribution 1204 HIP base specification does not define how to use certificates or how 1205 to transfer them between hosts. These functions are defined in a 1206 separate specification. A parameter type value, meant to be used for 1207 carrying certificates, is reserved, though: CERT, Type 768; see 1208 Section 5.2. 1210 5. Packet Formats 1212 5.1. Payload Format 1214 All HIP packets start with a fixed header. 1216 0 1 2 3 1217 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 1218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1219 | Next Header | Header Length |0| Packet Type | VER. | RES.|1| 1220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1221 | Checksum | Controls | 1222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1223 | Sender's Host Identity Tag (HIT) | 1224 | | 1225 | | 1226 | | 1227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1228 | Receiver's Host Identity Tag (HIT) | 1229 | | 1230 | | 1231 | | 1232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1233 | | 1234 / HIP Parameters / 1235 / / 1236 | | 1237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1239 The HIP header is logically an IPv6 extension header. However, this 1240 document does not describe processing for Next Header values other 1241 than decimal 59, IPPROTO_NONE, the IPv6 no next header value. Future 1242 documents MAY do so. However, current implementations MUST ignore 1243 trailing data if an unimplemented Next Header value is received. 1245 The Header Length field contains the length of the HIP Header and HIP 1246 parameters in 8 bytes units, excluding the first 8 bytes. Since all 1247 HIP headers MUST contain the sender's and receiver's HIT fields, the 1248 minimum value for this field is 4, and conversely, the maximum length 1249 of the HIP Parameters field is (255*8)-32 = 2008 bytes. Note: this 1250 sets an additional limit for sizes of parameters included in the 1251 Parameters field, independent of the individual parameter maximum 1252 lengths. 1254 The Packet Type indicates the HIP packet type. The individual packet 1255 types are defined in the relevant sections. If a HIP host receives a 1256 HIP packet that contains an unknown packet type, it MUST drop the 1257 packet. 1259 The HIP Version is four bits. The current version is 1. The version 1260 number is expected to be incremented only if there are incompatible 1261 changes to the protocol. Most extensions can be handled by defining 1262 new packet types, new parameter types, or new controls. 1264 The following three bits are reserved for future use. They MUST be 1265 zero when sent, and they SHOULD be ignored when handling a received 1266 packet. 1268 The two fixed bits in the header are reserved for potential SHIM6 1269 compatibility [I-D.ietf-shim6-proto]. For implementations adhering 1270 (only) to this specification, they MUST be set as shown when sending 1271 and MUST be ignored when receiving. This is to ensure optimal 1272 forward compatibility. Note that implementations that implement 1273 other compatible specifications in addition to this specification, 1274 the corresponding rules may well be different. For example, in the 1275 case that the forthcoming SHIM6 protocol happens to be compatible 1276 with this specification, an implementation that implements both this 1277 specification and the SHIM6 protocol may need to check these bits in 1278 order to determine how to handle the packet. 1280 The HIT fields are always 128 bits (16 bytes) long. 1282 5.1.1. Checksum 1284 Since the checksum covers the source and destination addresses in the 1285 IP header, it must be recomputed on HIP-aware NAT devies. 1287 If IPv6 is used to carry the HIP packet, the pseudo-header [RFC2460] 1288 contains the source and destination IPv6 addresses, HIP packet length 1289 in the pseudo-header length field, a zero field, and the HIP protocol 1290 number (see Section 4) in the Next Header field. The length field is 1291 in bytes and can be calculated from the HIP header length field: (HIP 1292 Header Length + 1) * 8. 1294 In case of using IPv4, the IPv4 UDP pseudo header format [RFC0768] is 1295 used. In the pseudo header, the source and destination addresses are 1296 those used in the IP header, the zero field is obviously zero, the 1297 protocol is the HIP protocol number (see Section 4), and the length 1298 is calculated as in the IPv6 case. 1300 5.1.2. HIP Controls 1302 The HIP Controls section conveys information about the structure of 1303 the packet and capabilities of the host. 1305 The following fields have been defined: 1307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1308 | | | | | | | | | | | | | | | |A| 1309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1311 A - Anonymous: If this is set, the sender's HI in this packet is 1312 anonymous, i.e., one not listed in a directory. Anonymous HIs 1313 SHOULD NOT be stored. This control is set in packets R1 and/or 1314 I2. The peer receiving an anonymous HI may choose to refuse it. 1316 The rest of the fields are reserved for future use and MUST be set to 1317 zero on sent packets and ignored on received packets. 1319 5.1.3. HIP Fragmentation Support 1321 A HIP implementation must support IP fragmentation / reassembly. 1322 Fragment reassembly MUST be implemented in both IPv4 and IPv6, but 1323 fragment generation is REQUIRED to be implemented in IPv4 (IPv4 1324 stacks and networks will usually do this by default) and RECOMMENDED 1325 to be implemented in IPv6. In IPv6 networks, the minimum MTU is 1326 larger, 1280 bytes, than in IPv4 networks. The larger MTU size is 1327 usually sufficient for most HIP packets, and therefore fragment 1328 generation may not be needed. If a host expects to send HIP packets 1329 that are larger than the minimum IPv6 MTU, it MUST implement fragment 1330 generation even for IPv6. 1332 In IPv4 networks, HIP packets may encounter low MTUs along their 1333 routed path. Since HIP does not provide a mechanism to use multiple 1334 IP datagrams for a single HIP packet, support for path MTU discovery 1335 does not bring any value to HIP in IPv4 networks. HIP-aware NAT 1336 devices MUST perform any IPv4 reassembly/fragmentation. 1338 All HIP implementations have to be careful while employing a 1339 reassembly algorithm so that the algorithm is sufficiently resistant 1340 to DoS attacks. 1342 Because certificate chains can cause the packet to be fragmented and 1343 fragmentation can open implementation to denial of service attacks 1344 [KAU03], it is strongly recommended that the separate document 1345 specifying the certificate usage in HIP Base Exchange defines the 1346 usage of "Hash and URL" formats rather than including certificates in 1347 exchanges. With this, most problems related to DoS attacks with 1348 fragmentation can be avoided. 1350 5.2. HIP Parameters 1352 The HIP Parameters are used to carry the public key associated with 1353 the sender's HIT, together with related security and other 1354 information. They consist of ordered parameters, encoded in TLV 1355 format. 1357 The following parameter types are currently defined. 1359 +------------------------+-------+----------+-----------------------+ 1360 | TLV | Type | Length | Data | 1361 +------------------------+-------+----------+-----------------------+ 1362 | R1_COUNTER | 128 | 12 | System Boot Counter | 1363 | | | | | 1364 | PUZZLE | 257 | 12 | K and Random #I | 1365 | | | | | 1366 | SOLUTION | 321 | 20 | K, Random #I and | 1367 | | | | puzzle solution J | 1368 | | | | | 1369 | SEQ | 385 | 4 | Update packet ID | 1370 | | | | number | 1371 | | | | | 1372 | ACK | 449 | variable | Update packet ID | 1373 | | | | number | 1374 | | | | | 1375 | DIFFIE_HELLMAN | 513 | variable | public key | 1376 | | | | | 1377 | HIP_TRANSFORM | 577 | variable | HIP Encryption and | 1378 | | | | Integrity Transform | 1379 | | | | | 1380 | ENCRYPTED | 641 | variable | Encrypted part of I2 | 1381 | | | | packet | 1382 | | | | | 1383 | HOST_ID | 705 | variable | Host Identity with | 1384 | | | | Fully Qualified | 1385 | | | | Domain Name or NAI | 1386 | | | | | 1387 | CERT | 768 | variable | HI Certificate; used | 1388 | | | | to transfer | 1389 | | | | certificates. Usage | 1390 | | | | defined in a separate | 1391 | | | | document. | 1392 | | | | | 1393 | NOTIFICATION | 832 | variable | Informational data | 1394 | | | | | 1395 | ECHO_REQUEST_SIGNED | 897 | variable | Opaque data to be | 1396 | | | | echoed back; under | 1397 | | | | signature | 1398 | | | | | 1399 | ECHO_RESPONSE_SIGNED | 961 | variable | Opaque data echoed | 1400 | | | | back; under signature | 1401 | | | | | 1402 | HMAC | 61505 | variable | HMAC based message | 1403 | | | | authentication code, | 1404 | | | | with key material | 1405 | | | | from HIP_TRANSFORM | 1406 | | | | | 1407 | HMAC_2 | 61569 | variable | HMAC based message | 1408 | | | | authentication code, | 1409 | | | | with key material | 1410 | | | | from HIP_TRANSFORM. | 1411 | | | | Compared to HMAC, the | 1412 | | | | HOST_ID parameter is | 1413 | | | | included in HMAC_2 | 1414 | | | | calculation. | 1415 | | | | | 1416 | HIP_SIGNATURE_2 | 61633 | variable | Signature of the R1 | 1417 | | | | packet | 1418 | | | | | 1419 | HIP_SIGNATURE | 61697 | variable | Signature of the | 1420 | | | | packet | 1421 | | | | | 1422 | ECHO_REQUEST_UNSIGNED | 63661 | variable | Opaque data to be | 1423 | | | | echoed back; after | 1424 | | | | signature | 1425 | | | | | 1426 | ECHO_RESPONSE_UNSIGNED | 63425 | variable | Opaque data echoed | 1427 | | | | back; after signature | 1428 +------------------------+-------+----------+-----------------------+ 1430 Because the ordering (from lowest to highest) of HIP parameters is 1431 strictly enforced (see Section 5.2.1), the parameter type values for 1432 existing parameters have been spaced to allow for future protocol 1433 extensions. Parameters numbered between 0-1023 are used in HIP 1434 handshake and update procedures and are covered by signatures. 1435 Parameters numbered between 1024-2047 are reserved. Parameters 1436 numbered between 2048-4095 are used for parameters related to HIP 1437 transform types. Parameters numbered between 4096 and (2^16 - 2^12) 1438 61439 are reserved. Parameters numbered between 61440-62463 are used 1439 for signatures and signed MACs. Parameters numbered between 62464- 1440 63487 are used for parameters that fall outside of the signed area of 1441 the packet. Parameters numbered between 63488-64511 are used for 1442 rendezvous and other relaying services. Parameters numbered between 1443 64512-65535 are reserved. 1445 5.2.1. TLV Format 1447 The TLV-encoded parameters are described in the following 1448 subsections. The type-field value also describes the order of these 1449 fields in the packet, except for type values from 2048 to 4095 which 1450 are reserved for new transport forms. The parameters MUST be 1451 included in the packet such that their types form an increasing 1452 order. If the parameter can exist multiple times in the packet, the 1453 type value may be the same in consecutive parameters. If the order 1454 does not follow this rule, the packet is considered to be malformed 1455 and it MUST be discarded. 1457 Parameters using type values from 2048 up to 4095 are transport 1458 formats. Currently, one transport format is defined: the ESP 1459 transport format [I-D.ietf-hip-esp]. The order of these parameters 1460 does not follow the order of their type value, but they are put in 1461 the packet in order of preference. The first of the transport 1462 formats it the most preferred, and so on. 1464 All of the TLV parameters have a length (including Type and Length 1465 fields) which is a multiple of 8 bytes. When needed, padding MUST be 1466 added to the end of the parameter so that the total length becomes a 1467 multiple of 8 bytes. This rule ensures proper alignment of data. 1468 Any added padding bytes MUST be zeroed by the sender, and their 1469 values SHOULD NOT be checked by the receiver. 1471 Consequently, the Length field indicates the length of the Contents 1472 field (in bytes). The total length of the TLV parameter (including 1473 Type, Length, Contents, and Padding) is related to the Length field 1474 according to the following formula: 1476 Total Length = 11 + Length - (Length + 3) % 8; 1478 0 1 2 3 1479 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 1480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1481 | Type |C| Length | 1482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1483 | | 1484 / Contents / 1485 / +-+-+-+-+-+-+-+-+ 1486 | | Padding | 1487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1489 Type Type code for the parameter. 16 bits long, C-bit 1490 being part of the Type code. 1491 C Critical. One if this parameter is critical, and 1492 MUST be recognized by the recipient, zero otherwise. 1493 The C bit is considered to be a part of the Type 1494 field. Consequently, critical parameters are always 1495 odd and non-critical ones have an even value. 1496 Length Length of the Contents, in bytes. 1497 Contents Parameter specific, defined by Type 1498 Padding Padding, 0-7 bytes, added if needed 1500 Critical parameters MUST be recognized by the recipient. If a 1501 recipient encounters a critical parameter that it does not recognize, 1502 it MUST NOT process the packet any further. It MAY send an ICMP or 1503 NOTIFY, as defined in Section 4.3. 1505 Non-critical parameters MAY be safely ignored. If a recipient 1506 encounters a non-critical parameter that it does not recognize, it 1507 SHOULD proceed as if the parameter was not present in the received 1508 packet. 1510 5.2.2. Defining New Parameters 1512 Future specifications may define new parameters as needed. When 1513 defining new parameters, care must be taken to ensure that the 1514 parameter type values are appropriate and leave suitable space for 1515 other future extensions. One must remember that the parameters MUST 1516 always be arranged in the increasing order by type code, thereby 1517 limiting the order of parameters (see Section 5.2.1). 1519 The following rules must be followed when defining new parameters. 1521 1. The low order bit C of the Type code is used to distinguish 1522 between critical and non-critical parameters. 1524 2. A new parameter may be critical only if an old recipient ignoring 1525 it would cause security problems. In general, new parameters 1526 SHOULD be defined as non-critical, and expect a reply from the 1527 recipient. 1529 3. If a system implements a new critical parameter, it MUST provide 1530 the ability to configure the associated feature off, such that 1531 the critical parameter is not sent at all. The configuration 1532 option must be well documented. Implementations operating in a 1533 mode adhering to this specification MUST disable the sending of 1534 new critical parameters. In other words, the management 1535 interface MUST allow vanilla standards-only mode as a default 1536 configuration setting, and MAY allow new critical payloads to be 1537 configured on (and off). 1539 4. See section Section 9 for allocation rules regarding type codes. 1541 5.2.3. R1_COUNTER 1543 0 1 2 3 1544 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 1545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1546 | Type | Length | 1547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1548 | Reserved, 4 bytes | 1549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1550 | R1 generation counter, 8 bytes | 1551 | | 1552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1554 Type 128 1555 Length 12 1556 R1 generation 1557 counter The current generation of valid puzzles 1559 The R1_COUNTER parameter contains an 64-bit unsigned integer in 1560 network byte order, indicating the current generation of valid 1561 puzzles. The sender is supposed to increment this counter 1562 periodically. It is RECOMMENDED that the counter value is 1563 incremented at least as often as old PUZZLE values are deprecated so 1564 that SOLUTIONs to them are no longer accepted. 1566 The R1_COUNTER parameter is optional. It SHOULD be included in the 1567 R1 (in which case it is covered by the signature), and if present in 1568 the R1, it MAY be echoed (including the Reserved field verbatim) by 1569 the Initiator in the I2. 1571 5.2.4. PUZZLE 1573 0 1 2 3 1574 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 1575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1576 | Type | Length | 1577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1578 | K, 1 byte | Lifetime | Opaque, 2 bytes | 1579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1580 | Random # I, 8 bytes | 1581 | | 1582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1584 Type 257 1585 Length 12 1586 K K is the number of verified bits 1587 Lifetime Puzzle lifetime 2^(value-32) seconds 1588 Opaque Data set by the Responder, indexing the puzzle 1589 Random #I random number 1591 Random #I is represented as 64-bit integer, K and Lifetime as 8-bit 1592 integer, all in network byte order. 1594 The PUZZLE parameter contains the puzzle difficulty K and a 64-bit 1595 puzzle random integer #I. The Puzzle Lifetime indicates the time 1596 during which the puzzle solution is valid, and sets a time limit 1597 which should not be exceeded by the Initiator while it attempts to 1598 solve the puzzle. The lifetime is indicated as a power of 2 using 1599 the formula 2^(Lifetime-32) seconds. A puzzle MAY be augmented with 1600 an ECHO_REQUEST_SIGNED or an ECHO_REQUEST_UNSIGNED parameter included 1601 in the R1; the contents of the echo request are then echoed back in 1602 the ECHO_RESPONSE_SIGNED or in the ECHO_RESPONSE_UNSIGNED, allowing 1603 the Responder to use the included information as a part of its puzzle 1604 processing. 1606 The Opaque and Random #I field are not covered by the HIP_SIGNATURE_2 1607 parameter. 1609 5.2.5. SOLUTION 1611 0 1 2 3 1612 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 1613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1614 | Type | Length | 1615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1616 | K, 1 byte | Reserved | Opaque, 2 bytes | 1617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1618 | Random #I, 8 bytes | 1619 | | 1620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1621 | Puzzle solution #J, 8 bytes | 1622 | | 1623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1625 Type 321 1626 Length 20 1627 K K is the number of verified bits 1628 Reserved zero when sent, ignored when received 1629 Opaque copied unmodified from the received PUZZLE 1630 parameter 1631 Random #I random number 1632 Puzzle solution 1633 #J random number 1635 Random #I, and Random #J are represented as 64-bit integers, K as an 1636 8-bit integer, all in network byte order. 1638 The SOLUTION parameter contains a solution to a puzzle. It also 1639 echoes back the random difficulty K, the Opaque field, and the puzzle 1640 integer #I. 1642 5.2.6. DIFFIE_HELLMAN 1644 0 1 2 3 1645 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 1646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1647 | Type | Length | 1648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1649 | Group ID | Public Value Length | Public Value / 1650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1651 / | 1652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1653 | Group ID | Public Value Length | Public Value / 1654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1655 / | padding | 1656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1658 Type 513 1659 Length length in octets, excluding Type, Length, and 1660 padding 1661 Group ID defines values for p and g 1662 Public Value length of the following Public Value in octets 1663 Length 1664 Public Value the sender's public Diffie-Hellman key 1666 The following Group IDs have been defined: 1668 Group Value 1669 Reserved 0 1670 384-bit group 1 1671 OAKLEY well known group 1 2 1672 1536-bit MODP group 3 1673 3072-bit MODP group 4 1674 6144-bit MODP group 5 1675 8192-bit MODP group 6 1677 The MODP Diffie-Hellman groups are defined in [RFC3526]. The OAKLEY 1678 well known group 1 is defined in Appendix E. 1680 The sender can include at most two different Diffie-Hellman public 1681 values in the DIFFIE_HELLMAN parameter. This gives the possibility 1682 e.g. for a server to provide a weaker encryption possibility for a 1683 PDA host that is not powerful enough. It is RECOMMENDED that the 1684 Initiator, receiving more than one public values selects the stronger 1685 one, if it supports it. 1687 A HIP implementation MUST implement Group IDs 1 and 3. The 384-bit 1688 group can be used when lower security is enough (e.g. web surfing) 1689 and when the equipment is not powerful enough (e.g. some PDAs). It 1690 is REQUIRED that the default configuration allows Group ID 1 usage, 1691 but it is RECOMMENDED that applications that need stronger security 1692 turn Group ID 1 support off. Equipment powerful enough SHOULD 1693 implement also group ID 5. The 384-bit group is defined in 1694 Appendix D. 1696 To avoid unnecessary failures during the base exchange, the rest of 1697 the groups SHOULD be implemented in hosts where resources are 1698 adequate. 1700 5.2.7. HIP_TRANSFORM 1702 0 1 2 3 1703 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 1704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1705 | Type | Length | 1706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1707 | Suite-ID #1 | Suite-ID #2 | 1708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1709 | Suite-ID #n | Padding | 1710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1712 Type 577 1713 Length length in octets, excluding Type, Length, and 1714 padding 1715 Suite-ID Defines the HIP Suite to be used 1717 The following Suite-IDs are defined ([RFC4307],[RFC2451]): 1719 Suite-ID Value 1721 RESERVED 0 1722 AES-CBC with HMAC-SHA1 1 1723 3DES-CBC with HMAC-SHA1 2 1724 3DES-CBC with HMAC-MD5 3 1725 BLOWFISH-CBC with HMAC-SHA1 4 1726 NULL-ENCRYPT with HMAC-SHA1 5 1727 NULL-ENCRYPT with HMAC-MD5 6 1729 The sender of a HIP transform parameter MUST make sure that there are 1730 no more than six (6) HIP Suite-IDs in one HIP transform parameter. 1731 Conversely, a recipient MUST be prepared to handle received transport 1732 parameters that contain more than six Suite-IDs by accepting the 1733 first six Suite-IDs and dropping the rest. The limited number of 1734 transforms sets the maximum size of HIP_TRANSFORM parameter. As the 1735 default configuration, the HIP_TRANSFORM parameter MUST contain at 1736 least one of the mandatory Suite-IDs. There MAY be a configuration 1737 option that allows the administrator to override this default. 1739 The Responder lists supported and desired Suite-IDs in order of 1740 preference in the R1, up to the maximum of six Suite-IDs. The 1741 Initiator MUST choose only one of the corresponding Suite-IDs. That 1742 Suite-ID will be used for generating the I2. 1744 Mandatory implementations: AES-CBC with HMAC-SHA1 and NULL-ENCRYPTION 1745 with HMAC-SHA1. 1747 5.2.8. HOST_ID 1749 0 1 2 3 1750 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 1751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1752 | Type | Length | 1753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1754 | HI Length |DI-type| DI Length | 1755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1756 | Host Identity / 1757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1758 / | Domain Identifier / 1759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1760 / | Padding | 1761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1763 Type 705 1764 Length length in octets, excluding Type, Length, and 1765 Padding 1766 HI Length Length of the Host Identity in octets 1767 DI-type type of the following Domain Identifier field 1768 DI Length length of the FQDN or NAI in octets 1769 Host Identity actual host identity 1770 Domain Identifier the identifier of the sender 1772 The Host Identity is represented in RFC2535 [RFC2535] format. The 1773 algorithms used in RDATA format are the following: 1775 Algorithms Values 1777 RESERVED 0 1778 DSA 3 [RFC2536] (RECOMMENDED) 1779 RSA/SHA1 5 [RFC3110] (REQUIRED) 1781 The following DI-types have been defined: 1783 Type Value 1784 none included 0 1785 FQDN 1 1786 NAI 2 1788 FQDN Fully Qualified Domain Name, in binary format. 1789 NAI Network Access Identifier 1791 The format for the FQDN is defined in RFC1035 [RFC1035] Section 3.1. 1792 The format for Network Access Identifier is defined in 1793 [I-D.ietf-radext-rfc2486bis] 1795 If there is no Domain Identifier, i.e. the DI-type field is zero, 1796 also the DI Length field is set to zero. 1798 5.2.9. HMAC 1800 0 1 2 3 1801 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 1802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1803 | Type | Length | 1804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1805 | | 1806 | HMAC | 1807 / / 1808 / +-------------------------------+ 1809 | | Padding | 1810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1812 Type 61505 1813 Length length in octets, excluding Type, Length, and 1814 Padding 1815 HMAC HMAC computed over the HIP packet, excluding the 1816 HMAC parameter and any following parameters, such 1817 as HIP_SIGNATURE, HIP_SIGNATURE_2, 1818 ECHO_REQUEST_UNSIGNED, or ECHO_RESPONSE_UNSIGNED. 1819 The checksum field MUST be set to zero and the HIP 1820 header length in the HIP common header MUST be 1821 calculated not to cover any excluded parameters 1822 when the HMAC is calculated. The size of the 1823 HMAC is the natural size of the hash computation 1824 output depending on the used hash function. 1826 The HMAC calculation and verification process is presented in 1827 Section 6.4.1 1829 5.2.10. HMAC_2 1831 The parameter structure is the same as in Section 5.2.9. The fields 1832 are: 1834 Type 61569 1835 Length length in octets, excluding Type, Length, and 1836 Padding 1837 HMAC HMAC computed over the HIP packet, excluding the 1838 HMAC parameter and any following parameters such 1839 as HIP_SIGNATURE, HIP_SIGNATURE_2, 1840 ECHO_REQUEST_UNSIGNED, or ECHO_RESPONSE_UNSIGNED, 1841 and including an additional sender's HOST_ID 1842 parameter during the HMAC calculation. The 1843 checksum field MUST be set to zero and the HIP 1844 header length in the HIP common header MUST be 1845 calculated not to cover any excluded parameters 1846 when the HMAC is calculated. The size of the 1847 HMAC is the natural size of the hash computation 1848 output depending on the used hash function. 1850 The HMAC calculation and verification process is presented in 1851 Section 6.4.1 1853 5.2.11. HIP_SIGNATURE 1855 0 1 2 3 1856 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 1857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1858 | Type | Length | 1859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1860 | SIG alg | Signature / 1861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1862 / | Padding | 1863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1865 Type 61697 1866 Length length in octets, excluding Type, Length, and 1867 Padding 1868 SIG alg Signature algorithm 1869 Signature the signature is calculated over the HIP packet, 1870 excluding the HIP_SIGNATURE parameter and any 1871 parameters that follow the HIP_SIGNATURE parameter. 1872 The checksum field MUST be set to zero, and the HIP 1873 header length in the HIP common header MUST be 1874 calculated only to the beginning of the 1875 HIP_SIGNATURE parameter when the signature is 1876 calculated. 1878 The signature algorithms are defined in Section 5.2.8. The signature 1879 in the Signature field is encoded using the proper method depending 1880 on the signature algorithm (e.g. according to [RFC3110] in case of 1881 RSA/SHA1, or according to [RFC2536] in case of DSA). 1883 The HIP_SIGNATURE calculation and verification process is presented 1884 in Section 6.4.2 1886 5.2.12. HIP_SIGNATURE_2 1888 The parameter structure is the same as in Section 5.2.11. The fields 1889 are: 1891 Type 61633 1892 Length length in octets, excluding Type, Length, and 1893 Padding 1894 SIG alg Signature algorithm 1895 Signature the signature is calculated over the HIP R1 packet, 1896 excluding the HIP_SIGNATURE_2 parameter and any 1897 parameters that follow. Initiator's HIT, checksum 1898 field, and the Opaque and Random #I fields in the 1899 PUZZLE parameter MUST be set to zero while 1900 computing the HIP_SIGNATURE_2 signature. Further, 1901 the HIP packet length in the HIP header MUST be 1902 calculated to the beginning of the HIP_SIGNATURE_2 1903 parameter when the signature is calculated. 1905 Zeroing the Initiator's HIT makes it possible to create R1 packets 1906 beforehand to minimize the effects of possible DoS attacks. Zeroing 1907 the I and Opaque fields allows these fields to be populated 1908 dynamically on precomputed R1s. 1910 Signature calculation and verification follows the process in 1911 Section 6.4.2. 1913 5.2.13. SEQ 1915 0 1 2 3 1916 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 1917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1918 | Type | Length | 1919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1920 | Update ID | 1921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1923 Type 385 1924 Length 4 1925 Update ID 32-bit sequence number 1927 The Update ID is an unsigned quantity, initialized by a host to zero 1928 upon moving to ESTABLISHED state. The Update ID has scope within a 1929 single HIP association, and not across multiple associations or 1930 multiple hosts. The Update ID is incremented by one before each new 1931 UPDATE that is sent by the host; the first UPDATE packet originated 1932 by a host has an Update ID of 0. 1934 5.2.14. ACK 1936 0 1 2 3 1937 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 1938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1939 | Type | Length | 1940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1941 | peer Update ID | 1942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1944 Type 449 1945 Length variable (multiple of 4) 1946 peer Update ID 32-bit sequence number corresponding to the 1947 Update ID being acked. 1949 The ACK parameter includes one or more Update IDs that have been 1950 received from the peer. The Length field identifies the number of 1951 peer Update IDs that are present in the parameter. 1953 5.2.15. ENCRYPTED 1955 0 1 2 3 1956 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 1957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1958 | Type | Length | 1959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1960 | Reserved | 1961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1962 | IV / 1963 / / 1964 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 1966 / Encrypted data / 1967 / / 1968 / +-------------------------------+ 1969 / | Padding | 1970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1972 Type 641 1973 Length length in octets, excluding Type, Length, and 1974 Padding 1975 Reserved zero when sent, ignored when received 1976 IV Initialization vector, if needed, otherwise 1977 nonexistent. The length of the IV is inferred from 1978 the HIP transform. 1979 Encrypted The data is encrypted using an encryption algorithm 1980 data as defined in HIP transform. 1981 Padding Any Padding, if necessary, to make the parameter a 1982 multiple of 8 bytes. 1984 The ENCRYPTED parameter encapsulates another parameter, the encrypted 1985 data, which is also in TLV format. Consequently, the first fields in 1986 the encapsulated parameter(s) are Type and Length, allowing the 1987 contents to be easily parsed after decryption. 1989 Both the ENCRYPTED parameter and the encapsulated parameter(s) MUST 1990 be padded. The padding needed for the ENCRYPTED parameter is 1991 referred as the "outer" padding. Correspondingly, the padding for 1992 the parameter(s) encapsulated within the ENCRYPTED parameter is 1993 referred as the "inner" padding. 1995 The inner padding follows exactly the rules of Section 5.2.1. The 1996 outer padding also follows the same rules but with an exception. 1997 Namely, some algorithms require that the data to be encrypted must be 1998 a multiple of the cipher algorithm block size. In this case, the 1999 outer padding MUST include extra padding, as specified by the 2000 encryption algorithm. The size of the extra padding is selected so 2001 that the length of the ENCRYPTED is the minimum value that is both 2002 multiple of eight and the cipher block size. The encryption 2003 algorithm may specify padding bytes other than zero; for example, AES 2004 [FIPS01] uses the PKCS5 padding scheme [RFC2898] (see section 6.1.1) 2005 where the remaining n bytes to fill the block each have the value n. 2007 Note that the length of the cipher suite output may be smaller or 2008 larger than the length of the data to be encrypted, since the 2009 encryption process may compress the data or add additional padding to 2010 the data. 2012 5.2.16. NOTIFICATION 2014 The NOTIFICATION parameter is used to transmit informational data, 2015 such as error conditions and state transitions, to a HIP peer. A 2016 NOTIFICATION parameter may appear in the NOTIFY packet type. The use 2017 of the NOTIFICATION parameter in other packet types is for further 2018 study. 2020 0 1 2 3 2021 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 2022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2023 | Type | Length | 2024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2025 | Reserved | Notify Message Type | 2026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2027 | / 2028 / Notification data / 2029 / +---------------+ 2030 / | Padding | 2031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2033 Type 832 2034 Length length in octets, excluding Type, Length, and 2035 Padding 2036 Reserved zero when sent, ignored when received 2037 Notify Message Specifies the type of notification 2038 Type 2039 Notification Informational or error data transmitted in addition 2040 Data to the Notify Message Type. Values for this field 2041 are type specific (see below). 2042 Padding Any Padding, if necessary, to make the parameter a 2043 multiple of 8 bytes. 2045 Notification information can be error messages specifying why an SA 2046 could not be established. It can also be status data that a process 2047 managing an SA database wishes to communicate with a peer process. 2048 The table below lists the Notification messages and their 2049 corresponding values. 2051 To avoid certain types of attacks, a Responder SHOULD avoid sending a 2052 NOTIFICATION to any host with which it has not successfully verified 2053 a puzzle solution. 2055 Types in the range 0 - 16383 are intended for reporting errors and in 2056 the range 16384 - 65535 for other status information. An 2057 implementation that receives a NOTIFY packet with an NOTIFICATION 2058 error parameter in response to a request packet (e.g., I1, I2, 2059 UPDATE), SHOULD assume that the corresponding request has failed 2060 entirely. Unrecognized error types MUST be ignored except that they 2061 SHOULD be logged. 2063 Notify payloads with status types MUST be ignored if not recognized. 2065 NOTIFICATION PARAMETER - ERROR TYPES Value 2066 ------------------------------------ ----- 2068 UNSUPPORTED_CRITICAL_PARAMETER_TYPE 1 2070 Sent if the parameter type has the "critical" bit set and the 2071 parameter type is not recognized. Notification Data contains 2072 the two octet parameter type. 2074 INVALID_SYNTAX 7 2076 Indicates that the HIP message received was invalid because 2077 some type, length, or value was out of range or because the 2078 request was rejected for policy reasons. To avoid a denial of 2079 service attack using forged messages, this status may only be 2080 returned for packets whose HMAC (if present) and SIGNATURE have 2081 been verified. This status MUST be sent in response to any 2082 error not covered by one of the other status types, and should 2083 not contain details to avoid leaking information to someone 2084 probing a node. To aid debugging, more detailed error 2085 information SHOULD be written to a console or log. 2087 NO_DH_PROPOSAL_CHOSEN 14 2089 None of the proposed group IDs was acceptable. 2091 INVALID_DH_CHOSEN 15 2093 The D-H Group ID field does not correspond to one offered 2094 by the Responder. 2096 NO_HIP_PROPOSAL_CHOSEN 16 2097 None of the proposed HIP Transform crypto suites was 2098 acceptable. 2100 INVALID_HIP_TRANSFORM_CHOSEN 17 2102 The HIP Transform crypto suite does not correspond to 2103 one offered by the Responder. 2105 AUTHENTICATION_FAILED 24 2107 Sent in response to a HIP signature failure, except when 2108 the signature verification fails in a NOTIFY message. 2110 CHECKSUM_FAILED 26 2112 Sent in response to a HIP checksum failure. 2114 HMAC_FAILED 28 2116 Sent in response to a HIP HMAC failure. 2118 ENCRYPTION_FAILED 32 2120 The Responder could not successfully decrypt the 2121 ENCRYPTED parameter. 2123 INVALID_HIT 40 2125 Sent in response to a failure to validate the peer's 2126 HIT from the corresponding HI. 2128 BLOCKED_BY_POLICY 42 2130 The Responder is unwilling to set up an association 2131 for some policy reason (e.g. received HIT is NULL 2132 and policy does not allow opportunistic mode). 2134 SERVER_BUSY_PLEASE_RETRY 44 2136 The Responder is unwilling to set up an association 2137 as it is suffering under some kind of overload and 2138 has chosen to shed load by rejecting your request. 2139 You may retry if you wish, however you MUST find 2140 another (different) puzzle solution for any such 2141 retries. Note that you may need to obtain a new 2142 puzzle with a new I1/R1 exchange. 2144 NOTIFY MESSAGES - STATUS TYPES Value 2145 ------------------------------ ----- 2147 I2_ACKNOWLEDGEMENT 16384 2149 The Responder has received your I2 but had to queue 2150 the I2 for processing. The puzzle was correctly solved 2151 and the Responder is willing to set up an association 2152 but has currently a number of I2s in processing queue. 2153 R2 will be sent after the I2 has been processed. 2155 5.2.17. ECHO_REQUEST_SIGNED 2157 0 1 2 3 2158 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 2159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2160 | Type | Length | 2161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2162 | Opaque data (variable length) | 2163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2165 Type 897 2166 Length variable 2167 Opaque data Opaque data, supposed to be meaningful only to the 2168 node that sends ECHO_REQUEST_SIGNED and receives a 2169 corresponding ECHO_RESPONSE_SIGNED or 2170 ECHO_RESPONSE_UNSINGED. 2172 The ECHO_REQUEST_SIGNED parameter contains an opaque blob of data 2173 that the sender wants to get echoed back in the corresponding reply 2174 packet. 2176 The ECHO_REQUEST_SIGNED and corresponding echo response parameters 2177 MAY be used for any purpose where a node wants to carry some state in 2178 a request packet and get it back in a response packet. The 2179 ECHO_REQUEST_SIGNED is covered by the HMAC and SIGNATURE. A HIP 2180 packet can contain only one ECHO_REQUEST_SIGNED or 2181 ECHO_REQUEST_UNSIGNED parameter. The ECHO_REQUEST_SIGNED parameter 2182 MUST be responded with a corresponding echo response. 2183 ECHO_RESPONSE_SIGNED SHOULD be used, but if it is not possible, e.g. 2184 due to a middle-box provided response, it MAY be responded with an 2185 ECHO_RESPONSE_UNSIGNED. 2187 5.2.18. ECHO_REQUEST_UNSIGNED 2189 0 1 2 3 2190 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 2191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2192 | Type | Length | 2193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2194 | Opaque data (variable length) | 2195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2197 Type 63661 2198 Length variable 2199 Opaque data Opaque data, supposed to be meaningful only to the 2200 node that sends ECHO_REQUEST_UNSIGNED and receives a 2201 corresponding ECHO_RESPONSE_SIGNED or 2202 ECHO_RESPONSE_UNSIGNED. 2204 The ECHO_REQUEST_UNSIGNED parameter contains an opaque blob of data 2205 that the sender wants to get echoed back in the corresponding reply 2206 packet. 2208 The ECHO_REQUEST_UNSIGNED and corresponding echo response parameters 2209 MAY be used for any purpose where a node wants to carry some state in 2210 a request packet and get it back in a response packet. The 2211 ECHO_REQUEST_UNSIGNED is not covered by the HMAC and SIGNATURE. A 2212 HIP packet can contain only one ECHO_REQUEST_SIGNED or 2213 ECHO_REQUEST_UNSIGNED parameter. The ECHO_REQUEST_UNSIGNED parameter 2214 MUST be responded with an ECHO_RESPONSE_UNSIGNED parameter. 2216 5.2.19. ECHO_RESPONSE_SIGNED 2218 0 1 2 3 2219 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 2220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2221 | Type | Length | 2222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2223 | Opaque data (variable length) | 2224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2226 Type 961 2227 Length variable 2228 Opaque data Opaque data, copied unmodified from the 2229 ECHO_REQUEST_SIGNED or ECHO_REQUEST_UNSIGNED 2230 parameter that triggered this response. 2232 The ECHO_RESPONSE_SIGNED parameter contains an opaque blob of data 2233 that the sender of the ECHO_REQUEST_SIGNED wants to get echoed back. 2234 The opaque data is copied unmodified from the ECHO_REQUEST_SIGNED 2235 parameter. 2237 The ECHO_REQUEST_SIGNED and ECHO_RESPONSE_SIGNED parameters MAY be 2238 used for any purpose where a node wants to carry some state in a 2239 request packet and get it back in a response packet. The 2240 ECHO_RESPONSE_SIGNED is covered by the HMAC and SIGNATURE. 2242 5.2.20. ECHO_RESPONSE_UNSIGNED 2244 0 1 2 3 2245 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 2246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2247 | Type | Length | 2248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2249 | Opaque data (variable length) | 2250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2252 Type 63425 2253 Length variable 2254 Opaque data Opaque data, copied unmodified from the 2255 ECHO_REQUEST_SIGNED or ECHO_REQUEST_UNSIGNED 2256 parameter that triggered this response. 2258 The ECHO_RESPONSE_UNSIGNED parameter contains an opaque blob of data 2259 that the sender of the ECHO_REQUEST_SIGNED or ECHO_REQUEST_UNSIGNED 2260 wants to get echoed back. The opaque data is copied unmodified from 2261 the corresponding echo request parameter. 2263 The echo request and ECHO_RESPONSE_UNSIGNED parameters MAY be used 2264 for any purpose where a node wants to carry some state in a request 2265 packet and get it back in a response packet. The 2266 ECHO_RESPONSE_UNSIGNED is not covered by the HMAC and SIGNATURE. 2268 5.3. HIP Packets 2270 There are eight basic HIP packets (see Table 11). Four are for the 2271 HIP base exchange, one is for updating, one is for sending 2272 notifications, and two for closing a HIP association. 2274 +------------------+------------------------------------------------+ 2275 | Packet type | Packet name | 2276 +------------------+------------------------------------------------+ 2277 | 1 | I1 - the HIP Initiator Packet | 2278 | | | 2279 | 2 | R1 - the HIP Responder Packet | 2280 | | | 2281 | 3 | I2 - the Second HIP Initiator Packet | 2282 | | | 2283 | 4 | R2 - the Second HIP Responder Packet | 2284 | | | 2285 | 16 | UPDATE - the HIP Update Packet | 2286 | | | 2287 | 17 | NOTIFY - the HIP Notify Packet | 2288 | | | 2289 | 18 | CLOSE - the HIP Association Closing Packet | 2290 | | | 2291 | 19 | CLOSE_ACK - the HIP Closing Acknowledgment | 2292 | | Packet | 2293 +------------------+------------------------------------------------+ 2295 Table 11: HIP packets and packet type numbers 2297 Packets consist of the fixed header as described in Section 5.1, 2298 followed by the parameters. The parameter part, in turn, consists of 2299 zero or more TLV coded parameters. 2301 In addition to the base packets, other packets types will be defined 2302 later in separate specifications. For example, support for mobility 2303 and multi-homing is not included in this specification. 2305 See Notation (Section 2.2) for used operations. 2307 In the future, an OPTIONAL upper layer payload MAY follow the HIP 2308 header. The Next Header field in the header indicates if there is 2309 additional data following the HIP header. The HIP packet, however, 2310 MUST NOT be fragmented. This limits the size of the possible 2311 additional data in the packet. 2313 5.3.1. I1 - the HIP Initiator Packet 2315 The HIP header values for the I1 packet: 2317 Header: 2318 Packet Type = 1 2319 SRC HIT = Initiator's HIT 2320 DST HIT = Responder's HIT, or NULL 2322 IP ( HIP () ) 2324 The I1 packet contains only the fixed HIP header. 2326 Valid control bits: none 2328 The Initiator gets the Responder's HIT either from a DNS lookup of 2329 the Responder's FQDN, from some other repository, or from a local 2330 table. If the Initiator does not know the Responder's HIT, it may 2331 attempt opportunistic mode by using NULL (all zeros) as the 2332 Responder's HIT. See also "HIP Opportunistic Mode" (Section 4.1.6)). 2334 Since this packet is so easy to spoof even if it were signed, no 2335 attempt is made to add to its generation or processing cost. 2337 Implementations MUST be able to handle a storm of received I1 2338 packets, discarding those with common content that arrive within a 2339 small time delta. 2341 5.3.2. R1 - the HIP Responder Packet 2343 The HIP header values for the R1 packet: 2345 Header: 2346 Packet Type = 2 2347 SRC HIT = Responder's HIT 2348 DST HIT = Initiator's HIT 2350 IP ( HIP ( [ R1_COUNTER, ] 2351 PUZZLE, 2352 DIFFIE_HELLMAN, 2353 HIP_TRANSFORM, 2354 HOST_ID, 2355 [ ECHO_REQUEST_SIGNED, ] 2356 HIP_SIGNATURE_2 ) 2357 [, ECHO_REQUEST_UNSIGNED ]) 2359 Valid control bits: A 2361 If the Responder HI is an anonymous one, the A control MUST be set. 2363 The Initiator HIT MUST match the one received in I1. If the 2364 Responder has multiple HIs, the Responder HIT used MUST match 2365 Initiator's request. If the Initiator used opportunistic mode, the 2366 Responder may select freely among its HIs. See also "HIP 2367 Opportunistic Mode" (Section 4.1.6)). 2369 The R1 generation counter is used to determine the currently valid 2370 generation of puzzles. The value is increased periodically, and it 2371 is RECOMMENDED that it is increased at least as often as solutions to 2372 old puzzles are no longer accepted. 2374 The Puzzle contains a random #I and the difficulty K. The difficulty 2375 K is the number of bits that the Initiator must get zero in the 2376 puzzle. The random #I is not covered by the signature and must be 2377 zeroed during the signature calculation, allowing the sender to 2378 select and set the #I into a pre-computed R1 just prior sending it to 2379 the peer. 2381 The Diffie-Hellman value is ephemeral, and one value SHOULD be used 2382 only for one connection. Once the Responder has received a valid 2383 response to an R1 packet, that Diffie-Hellman value SHOULD be 2384 deprecated. Because it is possible that the Responder has sent the 2385 same Diffie-Hellman value to different hosts simultaneously in 2386 corresponding R1 packets also those responses should be accepted. 2387 However, as a defense against I1 storms, an implementation MAY 2388 propose, and re-use if not avoidable, the same Diffie-Hellman value 2389 for a period of time, for example, 15 minutes. By using a small 2390 number of different puzzles for a given Diffie-Hellman value, the R1 2391 packets can be pre-computed and delivered as quickly as I1 packets 2392 arrive. A scavenger process should clean up unused DHs and puzzles. 2394 Re-using Diffie-Hellman public keys opens up the potential security 2395 risks of more than one Initiators ending up with the same keying 2396 material (due to faulty random number generators), and more than one 2397 Initiators using the same Responder public key half, thereby leading 2398 to potentially easier cryptographic attacks and the risk of not 2399 having perfect forward security. 2401 However, these risks involved in re-using the same key are 2402 statistical; that is, authors are not aware of any mechanism that 2403 would allow manipulation of the protocol so that the risk of the re- 2404 use of a any given Responder Diffie-Hellman public key would differ 2405 from the base probability. Consequently, it is RECOMMENDED that 2406 implementations avoid re-using the same D-H key with multiple 2407 Initiators, but because the risk is considered statistical and not 2408 known to be manipulatable, the implementations MAY re-use a key in 2409 order to ease resource constraint implementations and to increase the 2410 probability of successful communication with legitimate clients even 2411 under an I1 storm. In particular, when it is too expensive to 2412 generate enough of pre-computed R1 packets to supply each potential 2413 Initiator with a different Diffie-Hellman key, the Responder MAY send 2414 the same Diffie-Hellman key to several Initiators, thereby creating 2415 the possibility of multiple legitimate Initiators ending up using the 2416 same Responder-side public key. However, as soon as the Responder 2417 knows that it will use a particular Diffie-Hellman key, it SHOULD 2418 stop offering it. This design is aimed to allow resource-constrained 2419 Responders to offer services under I1 storms and to simultaneously 2420 make the probability of Diffie-Hellman key re-use both statistical 2421 and as low as possible. 2423 If a future version of this protocol is considered, we strongly 2424 recommend that these issues shall be studied again. Especially, the 2425 current design allows hosts to become potentially more vulnerable to 2426 a statistical, low-probability problem during I1 storm attacks than 2427 what they are if no attack is taking place; whether this is 2428 acceptable or not should be reconsidered in the light of any new 2429 experience gained. 2431 The HIP_TRANSFORM contains the encryption and integrity algorithms 2432 supported by the Responder to protect the HI exchange, in the order 2433 of preference. All implementations MUST support the AES [RFC3602] 2434 with HMAC-SHA-1-96 [RFC2404]. 2436 The ECHO_REQUEST_SIGNED and ECHO_REQUEST_UNSIGNED contains data that 2437 the sender wants to receive unmodified in the corresponding response 2438 packet in the ECHO_RESPONSE_SIGNED or ECHO_RESPONSE_UNSIGNED 2439 parameter. 2441 The signature is calculated over the whole HIP envelope, after 2442 setting the Initiator HIT, header checksum as well as the Opaque 2443 field and the Random #I in the PUZZLE parameter temporarily to zero, 2444 and excluding any parameters that follow the signature, as described 2445 in Section 5.2.12. This allows the Responder to use precomputed R1s. 2446 The Initiator SHOULD validate this signature. It SHOULD check that 2447 the Responder HI received matches with the one expected, if any. 2449 5.3.3. I2 - the Second HIP Initiator Packet 2451 The HIP header values for the I2 packet: 2453 Header: 2454 Type = 3 2455 SRC HIT = Initiator's HIT 2456 DST HIT = Responder's HIT 2458 IP ( HIP ( [R1_COUNTER,] 2459 SOLUTION, 2460 DIFFIE_HELLMAN, 2461 HIP_TRANSFORM, 2462 ENCRYPTED { HOST_ID } or HOST_ID, 2463 [ ECHO_RESPONSE_SIGNED ,] 2464 HMAC, 2465 HIP_SIGNATURE 2467 [, ECHO_RESPONSE_UNSIGNED] ) ) 2469 Valid control bits: A 2471 The HITs used MUST match the ones used previously. 2473 If the Initiator HI is an anonymous one, the A control MUST be set. 2475 The Initiator MAY include an unmodified copy of the R1_COUNTER 2476 parameter received in the corresponding R1 packet into the I2 packet. 2478 The Solution contains the random # I from R1 and the computed # J. 2479 The low order K bits of the RHASH(I | ... | J) MUST be zero. 2481 The Diffie-Hellman value is ephemeral. If precomputed, a scavenger 2482 process should clean up unused DHs. The Responder may re-use Diffie- 2483 Hellman values under some conditions as specified in Section 5.3.2. 2485 The HIP_TRANSFORM contains the single encryption and integrity 2486 transform selected by the Initiator, that will be used to protect the 2487 HI exchange. The chosen transform MUST correspond to one offered by 2488 the Responder in the R1. All implementations MUST support the AES 2489 transform [RFC3602]. 2491 The Initiator's HI MAY be encrypted using the HIP_TRANSFORM 2492 encryption algorithm. The keying material is derived from the 2493 Diffie-Hellman exchanged as defined in Section 6.5. 2495 The ECHO_RESPONSE_SIGNED and ECHO_RESPONSE_UNSIGNED contains the 2496 unmodified Opaque data copied from the corresponding echo request 2497 parameter. 2499 The HMAC is calculated over whole HIP envelope, excluding any 2500 parameters after the HMAC, as described in Section 6.4.1. The 2501 Responder MUST validate the HMAC. 2503 The signature is calculated over whole HIP envelope, excluding any 2504 parameters after the HIP_SIGNATURE, as described in Section 5.2.11. 2505 The Responder MUST validate this signature. It MAY use either the HI 2506 in the packet or the HI acquired by some other means. 2508 5.3.4. R2 - the Second HIP Responder Packet 2510 The HIP header values for the R2 packet: 2512 Header: 2513 Packet Type = 4 2514 SRC HIT = Responder's HIT 2515 DST HIT = Initiator's HIT 2517 IP ( HIP ( HMAC_2, HIP_SIGNATURE ) ) 2519 Valid control bits: none 2521 The HMAC_2 is calculated over whole HIP envelope, with Responder's 2522 HOST_ID parameter concatenated with the HIP envelope. The HOST_ID 2523 parameter is removed after the HMAC calculation. The procedure is 2524 described in 8.3.1. 2526 The signature is calculated over whole HIP envelope. 2528 The Initiator MUST validate both the HMAC and the signature. 2530 5.3.5. UPDATE - the HIP Update Packet 2532 Support for the UPDATE packet is MANDATORY. 2534 The HIP header values for the UPDATE packet: 2536 Header: 2537 Packet Type = 16 2538 SRC HIT = Sender's HIT 2539 DST HIT = Recipient's HIT 2541 IP ( HIP ( [SEQ, ACK, ] HMAC, HIP_SIGNATURE ) ) 2543 Valid control bits: None 2545 The UPDATE packet contains mandatory HMAC and HIP_SIGNATURE 2546 parameters, and other optional parameters. 2548 The UPDATE packet contains zero or one SEQ parameter. The presence 2549 of a SEQ parameter indicates that the receiver MUST ack the UPDATE. 2550 An UPDATE that does not contain a SEQ parameter is simply an ACK of a 2551 previous UPDATE and itself MUST NOT be acked. 2553 An UPDATE packet contains zero or one ACK parameters. The ACK 2554 parameter echoes the SEQ sequence number of the UPDATE packet being 2555 acked. A host MAY choose to ack more than one UPDATE packet at a 2556 time; e.g., the ACK may contain the last two SEQ values received, for 2557 robustness to ack loss. ACK values are not cumulative; each received 2558 unique SEQ value requires at least one corresponding ACK value in 2559 reply. Received ACKs that are redundant are ignored. 2561 The UPDATE packet may contain both a SEQ and an ACK parameter. In 2562 this case, the ACK is being piggybacked on an outgoing UPDATE. In 2563 general, UPDATEs carrying SEQ SHOULD be acked upon completion of the 2564 processing of the UPDATE. A host MAY choose to hold the UPDATE 2565 carrying ACK for a short period of time to allow for the possibility 2566 of piggybacking the ACK parameter, in a manner similar to TCP delayed 2567 acknowledgments. 2569 A sender MAY choose to forego reliable transmission of a particular 2570 UPDATE (e.g., it becomes overcome by events). The semantics are such 2571 that the receiver MUST acknowledge the UPDATE but the sender MAY 2572 choose to not care about receiving the ACK. 2574 UPDATEs MAY be retransmitted without incrementing SEQ. If the same 2575 subset of parameters is included in multiple UPDATEs with different 2576 SEQs, the host MUST ensure that receiver processing of the parameters 2577 multiple times will not result in a protocol error. 2579 5.3.6. NOTIFY - the HIP Notify Packet 2581 The NOTIFY packet is OPTIONAL. The NOTIFY packet MAY be used to 2582 provide information to a peer. Typically, NOTIFY is used to indicate 2583 some type of protocol error or negotiation failure. NOTIFY packets 2584 are unacknowledged. The receiver can handle the packet only as 2585 informational, and SHOULD NOT change its HIP state (Section 4.4.1) 2586 based purely on a received NOTIFY packet. 2588 The HIP header values for the NOTIFY packet: 2590 Header: 2591 Packet Type = 17 2592 SRC HIT = Sender's HIT 2593 DST HIT = Recipient's HIT, or zero if unknown 2595 IP ( HIP (i, [HOST_ID, ] HIP_SIGNATURE) ) 2597 Valid control bits: None 2599 The NOTIFY packet is used to carry one or more NOTIFICATION 2600 parameters. 2602 5.3.7. CLOSE - the HIP Association Closing Packet 2604 The HIP header values for the CLOSE packet: 2606 Header: 2607 Packet Type = 18 2608 SRC HIT = Sender's HIT 2609 DST HIT = Recipient's HIT 2611 IP ( HIP ( ECHO_REQUEST_SIGNED, HMAC, HIP_SIGNATURE ) ) 2613 Valid control bits: none 2615 The sender MUST include an ECHO_REQUEST_SIGNED used to validate 2616 CLOSE_ACK received in response, and both an HMAC and a signature 2617 (calculated over the whole HIP envelope). 2619 The receiver peer MUST validate both the HMAC and the signature if it 2620 has a HIP association state, and MUST reply with a CLOSE_ACK 2621 containing an ECHO_REPLY_SIGNED corresponding to the received 2622 ECHO_REQUEST_SIGNED. 2624 5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet 2626 The HIP header values for the CLOSE_ACK packet: 2628 Header: 2629 Packet Type = 19 2630 SRC HIT = Sender's HIT 2631 DST HIT = Recipient's HIT 2633 IP ( HIP ( ECHO_REPLY_SIGNED, HMAC, HIP_SIGNATURE ) ) 2635 Valid control bits: none 2637 The sender MUST include both an HMAC and signature (calculated over 2638 the whole HIP envelope). 2640 The receiver peer MUST validate both the HMAC and the signature. 2642 5.4. ICMP Messages 2644 When a HIP implementation detects a problem with an incoming packet, 2645 and it either cannot determine the identity of the sender of the 2646 packet or does not have any existing HIP association with the sender 2647 of the packet, it MAY respond with an ICMP packet. Any such replies 2648 MUST be rate limited as described in [RFC1885]. In most cases, the 2649 ICMP packet will have the Parameter Problem type (12 for ICMPv4, 4 2650 for ICMPv6), with the Pointer field pointing to the field that caused 2651 the ICMP message to be generated. 2653 5.4.1. Invalid Version 2655 If a HIP implementation receives a HIP packet that has an 2656 unrecognized HIP version number, it SHOULD respond, rate limited, 2657 with an ICMP packet with type Parameter Problem, the Pointer pointing 2658 to the VER./RES. byte in the HIP header. 2660 5.4.2. Other Problems with the HIP Header and Packet Structure 2662 If a HIP implementation receives a HIP packet that has other 2663 unrecoverable problems in the header or packet format, it MAY 2664 respond, rate limited, with an ICMP packet with type Parameter 2665 Problem, the Pointer pointing to the field that failed to pass the 2666 format checks. However, an implementation MUST NOT send an ICMP 2667 message if the Checksum fails; instead, it MUST silently drop the 2668 packet. 2670 5.4.3. Invalid Puzzle Solution 2672 If a HIP implementation receives an I2 packet that has an invalid 2673 puzzle solution, the behavior depends on the underlying version of 2674 IP. If IPv6 is used, the implementation SHOULD respond with an ICMP 2675 packet with type Parameter Problem, the Pointer pointing to the 2676 beginning of the Puzzle solution #J field in the SOLUTION payload in 2677 the HIP message. 2679 If IPv4 is used, the implementation MAY respond with an ICMP packet 2680 with the type Parameter Problem, copying enough of bytes from the I2 2681 message so that the SOLUTION parameter fits into the ICMP message, 2682 the Pointer pointing to the beginning of the Puzzle solution #J 2683 field, as in the IPv6 case. Note, however, that the resulting ICMPv4 2684 message exceeds the typical ICMPv4 message size as defined in 2685 [RFC0792]. 2687 5.4.4. Non-existing HIP Association 2689 If a HIP implementation receives a CLOSE, or UPDATE packet, or any 2690 other packet whose handling requires an existing association, that 2691 has either a Receiver or Sender HIT that does not match with any 2692 existing HIP association, the implementation MAY respond, rate 2693 limited, with an ICMP packet with the type Parameter Problem, the 2694 Pointer pointing to the beginning of the first HIT that does not 2695 match. 2697 A host MUST NOT reply with such an ICMP if it receives any of the 2698 following messages: I1, R2, I2, R2, and NOTIFY. When introducing new 2699 packet types, a specification SHOULD define the appropriate rules for 2700 sending or not sending this kind of ICMP replies. 2702 6. Packet Processing 2704 Each host is assumed to have a single HIP protocol implementation 2705 that manages the host's HIP associations and handles requests for new 2706 ones. Each HIP association is governed by a conceptual state 2707 machine, with states defined above in Section 4.4. The HIP 2708 implementation can simultaneously maintain HIP associations with more 2709 than one host. Furthermore, the HIP implementation may have more 2710 than one active HIP association with another host; in this case, HIP 2711 associations are distinguished by their respective HITs. It is not 2712 possible to have more than one HIP association between any given pair 2713 of HITs. Consequently, the only way for two hosts to have more than 2714 one parallel association is to use different HITs, at least at one 2715 end. 2717 The processing of packets depends on the state of the HIP 2718 association(s) with respect to the authenticated or apparent 2719 originator of the packet. A HIP implementation determines whether it 2720 has an active association with the originator of the packet based on 2721 the HITs. In the case of user data carried in a specific transport 2722 format, the transport format document specifies how the incoming 2723 packets are matched with the active associations. 2725 6.1. Processing Outgoing Application Data 2727 In a HIP host, an application can send application level data using 2728 an identifier specified via the underlying API. The API can be a 2729 backwards compatible API (see [I-D.henderson-hip-applications]), 2730 using identifiers that look similar to IP addresses, or a completely 2731 new API, providing enhanced services related to Host Identities. 2732 Depending on the HIP implementation, the identifier provided to the 2733 application may be different; it can be e.g. a HIT or an IP address. 2735 The exact format and method for transferring the data from the source 2736 HIP host to the destination HIP host is defined in the corresponding 2737 transport format document. The actual data is transferred in the 2738 network using the appropriate source and destination IP addresses. 2740 In this document, conceptual processing rules are defined only for 2741 the base case where both hosts have only single usable IP addresses; 2742 the multi-address multi-homing case will be specified separately. 2744 The following conceptual algorithm describes the steps that are 2745 required for handling outgoing datagrams destined to a HIT. 2747 1. If the datagram has a specified source address, it MUST be a HIT. 2748 If it is not, the implementation MAY replace the source address 2749 with a HIT. Otherwise it MUST drop the packet. 2751 2. If the datagram has an unspecified source address, the 2752 implementation must choose a suitable source HIT for the 2753 datagram. 2755 3. If there is no active HIP association with the given < source, 2756 destination > HIT pair, one must be created by running the base 2757 exchange. While waiting for the base exchange to complete, the 2758 implementation SHOULD queue at least one packet per HIP 2759 association to be formed, and it MAY queue more than one. 2761 4. Once there is an active HIP association for the given < source, 2762 destination > HIT pair, the outgoing datagram is passed to 2763 transport handling. The possible transport formats are defined 2764 in separate documents, of which the ESP transport format for HIP 2765 is mandatory for all HIP implementations. 2767 5. Before sending the packet, the HITs in the datagram are replaced 2768 with suitable IP addresses. For IPv6, the rules defined in 2769 [RFC3484] SHOULD be followed. Note that this HIT-to-IP-address 2770 conversion step MAY also be performed at some other point in the 2771 stack, e.g., before wrapping the packet into the output format. 2773 6.2. Processing Incoming Application Data 2775 The following conceptual algorithm describes the incoming datagram 2776 handling when HITs are used at the receiving host as application 2777 level identifiers. More detailed steps for processing packets are 2778 defined in corresponding transport format documents. 2780 1. The incoming datagram is mapped to an existing HIP association, 2781 typically using some information from the packet. For example, 2782 such mapping may be based on ESP Security Parameter Index (SPI). 2784 2. The specific transport format is unwrapped, in a way depending on 2785 the transport format, yielding a packet that looks like a 2786 standard (unencrypted) IP packet. If possible, this step SHOULD 2787 also verify that the packet was indeed (once) sent by the remote 2788 HIP host, as identified by the HIP association. 2790 3. The IP addresses in the datagram are replaced with the HITs 2791 associated with the HIP association. Note that this IP-address- 2792 to-HIT conversion step MAY also be performed at some other point 2793 in the stack. 2795 4. The datagram is delivered to the upper layer. Demultiplexing the 2796 datagram the right upper layer socket is based on the HITs. 2798 6.3. Solving the Puzzle 2800 This subsection describes the puzzle solving details. 2802 In R1, the values I and K are sent in network byte order. Similarly, 2803 in I2 the values I and J are sent in network byte order. The hash is 2804 created by concatenating, in network byte order, the following data, 2805 in the following order and using the RHASH algorithm: 2807 64-bit random value I, in network byte order, as appearing in R1 2808 and I2. 2810 128-bit Initiator HIT, in network byte order, as appearing in the 2811 HIP Payload in R1 and I2. 2813 128-bit Responder HIT, in network byte order, as appearing in the 2814 HIP Payload in R1 and I2. 2816 64-bit random value J, in network byte order, as appearing in I2. 2818 In order to be a valid response puzzle, the K low-order bits of the 2819 resulting RHASH digest must be zero. 2821 Notes: 2823 i) The length of the data to be hashed is 48 bytes. 2825 ii) All the data in the hash input MUST be in network byte order. 2827 iii) The order of the Initiator and Responder HITs are different 2828 in the R1 and I2 packets, see Section 5.1. Care must be taken to 2829 copy the values in right order to the hash input. 2831 The following procedure describes the processing steps involved, 2832 assuming that the Responder chooses to precompute the R1 packets: 2834 Precomputation by the Responder: 2835 Sets up the puzzle difficulty K. 2836 Creates a signed R1 and caches it. 2838 Responder: 2839 Selects a suitable cached R1. 2840 Generates a random number I. 2841 Sends I and K in an R1. 2842 Saves I and K for a Delta time. 2844 Initiator: 2845 Generates repeated attempts to solve the puzzle until a matching J 2846 is found: 2847 Ltrunc( RHASH( I | HIT-I | HIT-R | J ), K ) == 0 2848 Sends I and J in an I2. 2850 Responder: 2851 Verifies that the received I is a saved one. 2852 Finds the right K based on I. 2853 Computes V := Ltrunc( RHASH( I | HIT-I | HIT-R | J ), K ) 2854 Rejects if V != 0 2855 Accept if V == 0 2857 6.4. HMAC and SIGNATURE Calculation and Verification 2859 The following subsections define the actions for processing HMAC, 2860 HIP_SIGNATURE and HIP_SIGNATURE_2 parameters. 2862 6.4.1. HMAC Calculation 2864 The following process applies both to the HMAC and HMAC_2 parameters. 2865 When processing HMAC_2, the difference is that the HMAC calculation 2866 includes a pseudo HOST_ID field containing the Responder's 2867 information as sent in the R1 packet earlier. 2869 Both the Initiator and the Responder should take some care when 2870 verifying or calculating the HMAC_2. Specifically, the Responder 2871 should preserve other parameters than the HOST_ID when sending the 2872 R2. Also, the Initiator has to preserve the HOST_ID exactly as it 2873 was received in the R1 packet. 2875 The HMAC parameter is defined in Section 5.2.9 and HMAC_2 parameter 2876 in Section 5.2.10. HMAC calculation and verification process: 2878 Packet sender: 2880 1. Create the HIP packet, without the HMAC or any possible 2881 HIP_SIGNATURE or HIP_SIGNATURE_2 parameters. 2883 2. In case of HMAC_2 calculation, add a HOST_ID (Responder) 2884 parameter to the packet. 2886 3. Calculate the Length field in the HIP header. 2888 4. Compute the HMAC. 2890 5. In case of HMAC_2, remove the HOST_ID parameter from the packet. 2892 6. Add the HMAC parameter to the packet and any HIP_SIGNATURE or 2893 HIP_SIGNATURE_2 parameters that may follow. 2895 7. Recalculate the Length field in the HIP header. 2897 Packet receiver: 2899 1. Verify the HIP header Length field. 2901 2. Remove the HMAC or HMAC_2 parameter, and if the packet contains 2902 any HIP_SIGNATURE or HIP_SIGNATURE_2 fields, remove them too, 2903 saving the contents if they will be needed later. 2905 3. In case of HMAC_2, build and add a HOST_ID parameter (with 2906 Responder information) to the packet. The HOST_ID parameter 2907 should be identical to the one previously received from the 2908 Responder. 2910 4. Recalculate the HIP packet length in the HIP header and clear the 2911 Checksum field (set it to all zeros). 2913 5. Compute the HMAC and verify it against the received HMAC. 2915 6. In case of HMAC_2, remove the HOST_ID parameter from the packet 2916 before further processing. 2918 6.4.2. Signature Calculation 2920 The following process applies both to the HIP_SIGNATURE and 2921 HIP_SIGNATURE_2 parameters. When processing HIP_SIGNATURE_2, the 2922 only difference is that instead of HIP_SIGNATURE parameter, the 2923 HIP_SIGNATURE_2 parameter is used, and the Initiator's HIT and PUZZLE 2924 Opaque and Random #I fields are cleared (set to all zeros) before 2925 computing the signature. The HIP_SIGNATURE parameter is defined in 2926 Section 5.2.11 and the HIP_SIGNATURE_2 parameter in Section 5.2.12. 2928 Signature calculation and verification process: 2930 Packet sender: 2932 1. Create the HIP packet without the HIP_SIGNATURE parameter or any 2933 parameters that follow the HIP_SIGNATURE parameter. 2935 2. Calculate the Length field and zero the Checksum field in the HIP 2936 header. 2938 3. Compute the signature. 2940 4. Add the HIP_SIGNATURE parameter to the packet. 2942 5. Add any parameters that follow the HIP_SIGNATURE parameter. 2944 6. Recalculate the Length field in the HIP header, and calculate the 2945 Checksum field. 2947 Packet receiver: 2949 1. Verify the HIP header Length field. 2951 2. Save the contents of the HIP_SIGNATURE parameter and any 2952 parameters following the HIP_SIGNATURE parameter and remove them 2953 from the packet. 2955 3. Recalculate the HIP packet Length in the HIP header and clear the 2956 Checksum field (set it to all zeros). 2958 4. Compute the signature and verify it against the received 2959 signature. 2961 The verification can use either the HI received from a HIP packet, 2962 the HI from a DNS query, if the FQDN has been received in the HOST_ID 2963 packet, or one received by some other means. 2965 6.5. HIP KEYMAT Generation 2967 HIP keying material is derived from the Diffie-Hellman session key, 2968 Kij, produced during the HIP base exchange (Section 4.1.3). The 2969 Initiator has Kij during the creation of the I2 packet, and the 2970 Responder has Kij once it receives the I2 packet. This is why I2 can 2971 already contain encrypted information. 2973 The KEYMAT is derived by feeding Kij and the HITs into the following 2974 operation; the | operation denotes concatenation. 2976 KEYMAT = K1 | K2 | K3 | ... 2977 where 2979 K1 = RHASH( Kij | sort(HIT-I | HIT-R) | I | J | 0x01 ) 2980 K2 = RHASH( Kij | K1 | 0x02 ) 2981 K3 = RHASH( Kij | K2 | 0x03 ) 2982 ... 2983 K255 = RHASH( Kij | K254 | 0xff ) 2984 K256 = RHASH( Kij | K255 | 0x00 ) 2985 etc. 2987 Sort(HIT-I | HIT-R) is defined as the network byte order 2988 concatenation of the two HITs, with the smaller HIT preceding the 2989 larger HIT, resulting from the numeric comparison of the two HITs 2990 interpreted as positive (unsigned) 128-bit integers in network byte 2991 order. 2993 I and J values are from the puzzle and its solution that were 2994 exchanged in R1 and I2 messages when this HIP association was set up. 2995 Both hosts have to store I and J values for the HIP association for 2996 future use. 2998 The initial keys are drawn sequentially in the order that is 2999 determined by the numeric comparison of the two HITs, with comparison 3000 method described in the previous paragraph. HOST_g denotes the host 3001 with the greater HIT value, and HOST_l the host with the lower HIT 3002 value. 3004 The drawing order for initial keys: 3006 HIP-gl encryption key for HOST_g's outgoing HIP packets 3008 HIP-gl integrity (HMAC) key for HOST_g's outgoing HIP packets 3010 HIP-lg encryption key (currently unused) for HOST_l's outgoing HIP 3011 packets 3013 HIP-lg integrity (HMAC) key for HOST_l's outgoing HIP packets 3015 The number of bits drawn for a given algorithm is the "natural" size 3016 of the keys. For the mandatory algorithms, the following sizes 3017 apply: 3019 AES 128 bits 3021 SHA-1 160 bits 3023 NULL 0 bits 3025 If other key sizes are used, they must be treated as different 3026 encryption algorithms and defined separtely. 3028 6.6. Initiation of a HIP Exchange 3030 An implementation may originate a HIP exchange to another host based 3031 on a local policy decision, usually triggered by an application 3032 datagram, in much the same way that an IPsec IKE key exchange can 3033 dynamically create a Security Association. Alternatively, a system 3034 may initiate a HIP exchange if it has rebooted or timed out, or 3035 otherwise lost its HIP state, as described in Section 4.5.4. 3037 The implementation prepares an I1 packet and sends it to the IP 3038 address that corresponds to the peer host. The IP address of the 3039 peer host may be obtained via conventional mechanisms, such as DNS 3040 lookup. The I1 contents are specified in Section 5.3.1. The 3041 selection of which host identity to use, if a host has more than one 3042 to choose from, is typically a policy decision. 3044 The following steps define the conceptual processing rules for 3045 initiating a HIP exchange: 3047 1. The Initiator gets the Responder's HIT and one or more addresses 3048 either from a DNS lookup of the Responder's FQDN, from some other 3049 repository, or from a local table. If the Initiator does not 3050 know the Responder's HIT, it may attempt opportunistic mode by 3051 using NULL (all zeros) as the Responder's HIT. See also "HIP 3052 Opportunistic Mode" (Section 4.1.6). 3054 2. The Initiator sends an I1 to one of the Responder's addresses. 3055 The selection of which address to use is a local policy decision. 3057 3. Upon sending an I1, the sender shall transition to state I1-SENT, 3058 start a timer whose timeout value should be larger than the 3059 worst-case anticipated RTT, and shall increment a timeout counter 3060 associated with the I1. 3062 4. Upon timeout, the sender SHOULD retransmit the I1 and restart the 3063 timer, up to a maximum of I1_RETRIES_MAX tries. 3065 6.6.1. Sending Multiple I1s in Parallel 3067 For the sake of minimizing the session establishment latency, an 3068 implementation MAY send the same I1 to more than one of the 3069 Responder's addresses. However, it MUST NOT send to more than three 3070 (3) addresses in parallel. Furthermore, upon timeout, the 3071 implementation MUST refrain from sending the same I1 packet to 3072 multiple addresses. These limitations are placed order to avoid 3073 congestion of the network, and potential DoS attacks that might 3074 happen, e.g., because someone claims to have hundreds or thousands of 3075 addresses which possibly could generate a huge number of I1 messages 3076 from the Initiator. 3078 As the Responder is not guaranteed to distinguish the duplicate I1's 3079 it receives at several of its addresses (because it avoids to store 3080 states when it answers back an R1), the Initiator may receive several 3081 duplicate R1's. 3083 The Initiator SHOULD then select the initial preferred destination 3084 address using the source address of the selected received R1, and use 3085 the preferred address as a source address for the I2. Processing 3086 rules for received R1s are discussed in Section 6.8. 3088 6.6.2. Processing Incoming ICMP Protocol Unreachable Messages 3090 A host may receive an ICMP Destination Protocol Unreachable message 3091 as a response to sending a HIP I1 packet. Such a packet may be an 3092 indication that the peer does not support HIP, or it may be an 3093 attempt to launch an attack by making the Initiator believe that the 3094 Responder does not support HIP. 3096 When a system receives an ICMP Destination Protocol Unreachable 3097 message while it is waiting for an R1, it MUST NOT terminate the 3098 wait. It MAY continue as if it had not received the ICMP message, 3099 and send a few more I1s. Alternatively, it MAY take the ICMP message 3100 as a hint that the peer most probably does not support HIP, and 3101 return to state UNASSOCIATED earlier than otherwise. However, at 3102 minimum, it MUST continue waiting for an R1 for a reasonable time 3103 before returning to UNASSOCIATED. 3105 6.7. Processing Incoming I1 Packets 3107 An implementation SHOULD reply to an I1 with an R1 packet, unless the 3108 implementation is unable or unwilling to setup a HIP association. If 3109 the implementation is unable to setup a HIP association, the host 3110 SHOULD send an ICMP Destination Protocol Unreachable, 3111 Administratively Prohibited, message to the I1 source address. If 3112 the implementation is unwilling to setup a HIP association, the host 3113 MAY ignore the I1. This latter case may occur during a DoS attack 3114 such as an I1 flood. 3116 The implementation MUST be able to handle a storm of received I1 3117 packets, discarding those with common content that arrive within a 3118 small time delta. 3120 A spoofed I1 can result in an R1 attack on a system. An R1 sender 3121 MUST have a mechanism to rate limit R1s to an address. 3123 It is RECOMMENDED that the HIP state machine does not transition upon 3124 sending an R1. 3126 The following steps define the conceptual processing rules for 3127 responding to an I1 packet: 3129 1. The Responder MUST check that the Responder HIT in the received 3130 I1 is either one of its own HITs, or NULL. 3132 2. If the Responder is in ESTABLISHED state, the Responder MAY 3133 respond to this with an R1 packet, prepare to drop existing SAs 3134 and stay at ESTABLISHED state. 3136 3. If the Responder is in I1-SENT state, it must make a comparison 3137 between the sender's HIT and its own (i.e., the receiver's) HIT. 3138 If the sender's HIT is greater than its own HIT, it should drop 3139 the I1 and stay at I1-SENT. If the sender's HIT is smaller than 3140 its own HIT, it should send R1 and stay at I1-SENT. The HIT 3141 comparison goes similarly as in Section 6.5. 3143 4. If the implementation chooses to respond to the I1 with an R1 3144 packet, it creates a new R1 or selects a precomputed R1 according 3145 to the format described in Section 5.3.2. 3147 5. The R1 MUST contain the received Responder HIT, unless the 3148 received HIT is NULL, in which case the Responder SHOULD select a 3149 HIT that is constructed with the MUST algorithm in Section 3, 3150 which is currently RSA. Other than that, selecting the HIT is a 3151 local policy matter. 3153 6. The Responder sends the R1 to the source IP address of the I1 3154 packet. 3156 6.7.1. R1 Management 3158 All compliant implementations MUST produce R1 packets. An R1 packet 3159 MAY be precomputed. An R1 packet MAY be reused for time Delta T, 3160 which is implementation dependent, and SHOULD be deprecated and not 3161 used once a valid response I2 packet has been received from an 3162 Initiator. During I1 message storm, an R1 packet may be re-used 3163 beyond this limit. R1 information MUST NOT be discarded until Delta 3164 S after T. Time S is the delay needed for the last I2 to arrive back 3165 to the Responder. 3167 An implementation MAY keep state about received I1s and match the 3168 received I2s against the state, as discussed in Section 4.1.1. 3170 6.7.2. Handling Malformed Messages 3172 If an implementation receives a malformed I1 message, it SHOULD NOT 3173 respond with a NOTIFY message, as such practice could open up a 3174 potential denial-of-service danger. Instead, it MAY respond with an 3175 ICMP packet, as defined in Section 5.4. 3177 6.8. Processing Incoming R1 Packets 3179 A system receiving an R1 MUST first check to see if it has sent an I1 3180 to the originator of the R1 (i.e., it is in state I1-SENT). If so, 3181 it SHOULD process the R1 as described below, send an I2, and go to 3182 state I2-SENT, setting a timer to protect the I2. If the system is 3183 in state I2-SENT, it MAY respond to an R1 if the R1 has a larger R1 3184 generation counter; if so, it should drop its state due to processing 3185 the previous R1 and start over from state I1-SENT. If the system is 3186 in any other state with respect to that host, it SHOULD silently drop 3187 the R1. 3189 When sending multiple I1s, an Initiator SHOULD wait for a small 3190 amount of time after the first R1 reception to allow possibly 3191 multiple R1s to arrive, and it SHOULD respond to an R1 among the set 3192 with the largest R1 generation counter. 3194 The following steps define the conceptual processing rules for 3195 responding to an R1 packet: 3197 1. A system receiving an R1 MUST first check to see if it has sent 3198 an I1 to the originator of the R1 (i.e., it has a HIP 3199 association that is in state I1-SENT and that is associated with 3200 the HITs in the R1). Unless the I1 was sent in opportunistic 3201 mode (see also "HIP Opportunistic Mode" (Section 4.1.6) ), IP 3202 addresses in the received R1 packet SHOULD be ignored and the 3203 match SHOULD be based on HITs only. If a match exists, the 3204 system should process the R1 as described below. 3206 2. Otherwise, if the system is in any other state than I1-SENT or 3207 I2-SENT with respect to the HITs included in the R1, it SHOULD 3208 silently drop the R1 and remain in the current state. 3210 3. If the HIP association state is I1-SENT or I2-SENT, the received 3211 Initiator's HIT MUST correspond to the HIT used in the original, 3212 I1 and the Responder's HIT MUST correspond to the one used, 3213 unless the I1 contained a NULL HIT. 3215 4. The system SHOULD validate the R1 signature before applying 3216 further packet processing, according to Section 5.2.12. 3218 5. If the HIP association state is I1-SENT, and multiple valid R1s 3219 are present, the system SHOULD select from among the R1s with 3220 the largest R1 generation counter. 3222 6. If the HIP association state is I2-SENT, the system MAY reenter 3223 state I1-SENT and process the received R1 if it has a larger R1 3224 generation counter than the R1 responded to previously. 3226 7. The R1 packet may have the A bit set -- in this case, the system 3227 MAY choose to refuse it by dropping the R1 and returning to 3228 state UNASSOCIATED. The system SHOULD consider dropping the R1 3229 only if it used a NULL HIT in I1. If the A bit is set, the 3230 Responder's HIT is anonymous and should not be stored. 3232 8. The system SHOULD attempt to validate the HIT against the 3233 received Host Identity by using the received Host Identity to 3234 construct a HIT and verify that it matches the Sender's HIT. 3236 9. The system MUST store the received R1 generation counter for 3237 future reference. 3239 10. The system attempts to solve the puzzle in R1. The system MUST 3240 terminate the search after exceeding the remaining lifetime of 3241 the puzzle. If the puzzle is not successfully solved, the 3242 implementation may either resend I1 within the retry bounds or 3243 abandon the HIP exchange. 3245 11. The system computes standard Diffie-Hellman keying material 3246 according to the public value and Group ID provided in the 3247 DIFFIE_HELLMAN parameter. The Diffie-Hellman keying material 3248 Kij is used for key extraction as specified in Section 6.5. If 3249 the received Diffie-Hellman Group ID is not supported, the 3250 implementation may either resend I1 within the retry bounds or 3251 abandon the HIP exchange. 3253 12. The system selects the HIP transform from the choices presented 3254 in the R1 packet and uses the selected values subsequently when 3255 generating and using encryption keys, and when sending the I2. 3256 If the proposed alternatives are not acceptable to the system, 3257 it may either resend I1 within the retry bounds or abandon the 3258 HIP exchange. 3260 13. The system initializes the remaining variables in the associated 3261 state, including Update ID counters. 3263 14. The system prepares and sends an I2, as described in 3264 Section 5.3.3. 3266 15. The system SHOULD start a timer whose timeout value should be 3267 larger than the worst-case anticipated RTT, and MUST increment a 3268 timeout counter associated with the I2. The sender SHOULD 3269 retransmit the I2 upon a timeout and restart the timer, up to a 3270 maximum of I2_RETRIES_MAX tries. 3272 16. If the system is in state I1-SENT, it shall transition to state 3273 I2-SENT. If the system is in any other state, it remains in the 3274 current state. 3276 6.8.1. Handling Malformed Messages 3278 If an implementation receives a malformed R1 message, it MUST 3279 silently drop the packet. Sending a NOTIFY or ICMP would not help, 3280 as the sender of the R1 typically doesn't have any state. An 3281 implementation SHOULD wait for some more time for a possible good R1, 3282 after which it MAY try again by sending a new I1 packet. 3284 6.9. Processing Incoming I2 Packets 3286 Upon receipt of an I2, the system MAY perform initial checks to 3287 determine whether the I2 corresponds to a recent R1 that has been 3288 sent out, if the Responder keeps such state. For example, the sender 3289 could check whether the I2 is from an address or HIT that has 3290 recently received an R1 from it. The R1 may have had Opaque data 3291 included that was echoed back in the I2. If the I2 is considered to 3292 be suspect, it MAY be silently discarded by the system. 3294 Otherwise, the HIP implementation SHOULD process the I2. This 3295 includes validation of the puzzle solution, generating the Diffie- 3296 Hellman key, decrypting the Initiator's Host Identity, verifying the 3297 signature, creating state, and finally sending an R2. 3299 The following steps define the conceptual processing rules for 3300 responding to an I2 packet: 3302 1. The system MAY perform checks to verify that the I2 corresponds 3303 to a recently sent R1. Such checks are implementation 3304 dependent. See Appendix A for a description of an example 3305 implementation. 3307 2. The system MUST check that the Responder's HIT corresponds to 3308 one of its own HITs. 3310 3. If the system is in the R2-SENT state, it MAY check if the newly 3311 received I2 is similar to the one that triggered moving to R2- 3312 SENT. If so, it MAY retransmit a previously sent R2, reset the 3313 R2-SENT timer, and stay in R2-SENT. 3315 4. If the system is in the I2-SENT state, it makes a comparison 3316 between its local and sender's HITs (similarly as in 3317 Section 6.5). If the local HIT is smaller than the sender's 3318 HIT, it should drop the I2 packet, use peer Diffie-Hellman key 3319 and nonce I from the R1 packet received earlier, and get the 3320 local Diffie-Hellman key and nonce J from the I2 packet sent to 3321 the peer ealier. Otherwise, the system should process the 3322 received I2 packet and drop any previously derived Diffie- 3323 Hellman keying material Kij it might have formed upon sending 3324 the I2 previously. The peer Diffie-Hellman key and nonce J are 3325 taken from the just arrived I2 and local Diffie-Hellman key and 3326 nonce I are the ones that it sent earlier in the R1 packet. 3328 5. If the system is in the I1-SENT state, and the HITs in the I2 3329 match those used in the previously sent I1, the system uses this 3330 received I2 as the basis for the HIP assocation it was trying to 3331 form, and stops retransmitting I1 (provided that the I2 passes 3332 the below additional checks). 3334 6. If the system is in any other state than R2-SENT, it SHOULD 3335 check that the echoed R1 generation counter in I2 is within the 3336 acceptable range. Implementations MUST accept puzzles from the 3337 current generation and MAY accept puzzles from earlier 3338 generations. If the newly received I2 is outside the accepted 3339 range, the I2 is stale (perhaps replayed) and SHOULD be dropped. 3341 7. The system MUST validate the solution to the puzzle by computing 3342 the hash described in Section 5.3.3 using the same RHASH 3343 algorithm. 3345 8. The I2 MUST have a single value in the HIP_TRANSFORM parameter, 3346 which MUST match one of the values offered to the Initiator in 3347 the R1 packet. 3349 9. The system must derive Diffie-Hellman keying material Kij based 3350 on the public value and Group ID in the DIFFIE_HELLMAN 3351 parameter. This key is used to derive the HIP association keys, 3352 as described in Section 6.5. If the Diffie-Hellman Group ID is 3353 unsupported, the I2 packet is silently dropped. 3355 10. The encrypted HOST_ID decrypted by the Initiator encryption key 3356 defined in Section 6.5. If the decrypted data is not a HOST_ID 3357 parameter, the I2 packet is silently dropped. 3359 11. The implementation SHOULD also verify that the Initiator's HIT 3360 in the I2 corresponds to the Host Identity sent in the I2. 3362 12. The system MUST verify the HMAC according to the procedures in 3363 Section 5.2.9. 3365 13. The system MUST verify the HIP_SIGNATURE according to 3366 Section 5.2.11 and Section 5.3.3. 3368 14. If the checks above are valid, then the system proceeds with 3369 further I2 processing; otherwise, it discards the I2 and remains 3370 in the same state. 3372 15. The I2 packet may have the A bit set -- in this case, the system 3373 MAY choose to refuse it by dropping the I2 and returning to 3374 state UNASSOCIATED. If the A bit is set, the Initiator's HIT is 3375 anonymous and should not be stored. 3377 16. The system initializes the remaining variables in the associated 3378 state, including Update ID counters. 3380 17. Upon successful processing of an I2 in states UNASSOCIATED, I1- 3381 SENT, I2-SENT, and R2-SENT, an R2 is sent and the state machine 3382 transitions to state R2-SENT. 3384 18. Upon successful processing of an I2 in state ESTABLISHED, the 3385 old HIP association is dropped and a new one is installed, an R2 3386 is sent, and the state machine transitions to R2-SENT. 3388 19. Upon transitioning to R2-SENT, start a timer. Move to 3389 ESTABLISHED if some data has been received on the incoming HIP 3390 association, or an UPDATE packet has been received (or some 3391 other packet that indicates that the peer has moved to 3392 ESTABLISHED). If the timer expires (allowing for maximal 3393 retransmissions of I2s), move to ESTABLISHED. 3395 6.9.1. Handling Malformed Messages 3397 If an implementation receives a malformed I2 message, the behavior 3398 SHOULD depend on how much checks the message has already passed. If 3399 the puzzle solution in the message has already been checked, the 3400 implementation SHOULD report the error by responding with a NOTIFY 3401 packet. Otherwise the implementation MAY respond with an ICMP 3402 message as defined in Section 5.4. 3404 6.10. Processing Incoming R2 Packets 3406 An R2 received in states UNASSOCIATED, I1-SENT, or ESTABLISHED 3407 results in the R2 being dropped and the state machine staying in the 3408 same state. If an R2 is received in state I2-SENT, it SHOULD be 3409 processed. 3411 The following steps define the conceptual processing rules for 3412 incoming R2 packet: 3414 1. The system MUST verify that the HITs in use correspond to the 3415 HITs that were received in R1. 3417 2. The system MUST verify the HMAC_2 according to the procedures in 3418 Section 5.2.10. 3420 3. The system MUST verify the HIP signature according to the 3421 procedures in Section 5.2.11. 3423 4. If any of the checks above fail, there is a high probability of 3424 an ongoing man-in-the-middle or other security attack. The 3425 system SHOULD act accordingly, based on its local policy. 3427 5. If the system is in any other state than I2-SENT, the R2 is 3428 silently dropped. 3430 6. Upon successful processing of the R2, the state machine moves to 3431 state ESTABLISHED. 3433 6.11. Sending UPDATE Packets 3435 A host sends an UPDATE packet when it wants to update some 3436 information related to a HIP association. There are a number of 3437 likely situations, e.g. mobility management and rekeying of an 3438 existing ESP Security Association. The following paragraphs define 3439 the conceptual rules for sending an UPDATE packet to the peer. 3440 Additional steps can be defined in other documents where the UPDATE 3441 packet is used. 3443 The system first determines whether there are any outstanding UPDATE 3444 messages that may conflict with the new UPDATE message under 3445 consideration. When multiple UPDATEs are outstanding (not yet 3446 acknowledged), the sender must assume that such UPDATEs may be 3447 processed in an arbitrary order. Therefore, any new UPDATEs that 3448 depend on a previous outstanding UPDATE being successfully received 3449 and acknowledged MUST be postponed until reception of the necessary 3450 ACK(s) occurs. One way to prevent any conflicts is to only allow one 3451 outstanding UPDATE at a time, but allowing multiple UPDATEs may 3452 improve the performance of mobility and multihoming protocols. 3454 1. The first UPDATE packet is sent with Update ID of zero. 3455 Otherwise, the system increments its own Update ID value by one 3456 before continuing the below steps. 3458 2. The system creates an UPDATE packet that contains a SEQ parameter 3459 with the current value of Update ID. The UPDATE packet may also 3460 include an ACK of the peer's Update ID found in a received UPDATE 3461 SEQ parameter, if any. 3463 3. The system sends the created UPDATE packet and starts an UPDATE 3464 timer. The default value for the timer is 2 * RTT estimate. If 3465 multiple UPDATEs are outstanding, multiple timers are in effect. 3467 4. If the UPDATE timer expires, the UPDATE is resent. The UPDATE 3468 can be resent UPDATE_RETRY_MAX times. The UPDATE timer SHOULD be 3469 exponentially backed off for subsequent retransmissions. If no 3470 acknowledgment is received from the peer after UPDATE_RETRY_MAX 3471 times, the HIP association is considered to be broken and the 3472 state machine should move from state ESTABLISHED to state CLOSING 3473 as depicted in Section 4.4.3. The UPDATE timer is cancelled upon 3474 receiving an ACK from the peer that acknowledges receipt of the 3475 UPDATE. 3477 6.12. Receiving UPDATE Packets 3479 When a system receives an UPDATE packet, its processing depends on 3480 the state of the HIP association and the presence of and values of 3481 the SEQ and ACK parameters. Typically, an UPDATE message also 3482 carries optional parameters whose handling is defined in separate 3483 documents. 3485 For each association, the peer's next expected in-sequence Update ID 3486 ("peer Update ID") is stored. Initially, this value is zero. Update 3487 ID comparisons of "less than" and "greater than" are performed with 3488 respect to a circular sequence number space. 3490 The sender may send multiple outstanding UPDATE messages. These 3491 messages are processed in the order in which they are received at the 3492 receiver (i.e., no resequencing is performed). When processing 3493 UPDATEs out-of-order, the receiver MUST keep track of which UPDATEs 3494 were previously processed, so that duplicates or retransmissions are 3495 ACKed and not reprocessed. A receiver MAY choose to define a receive 3496 window of Update IDs that it is willing to process at any given time, 3497 and discard received UPDATEs falling outside of that window. 3499 1. If there is no corresponding HIP association, the implementation 3500 MAY reply with an ICMP Parameter Problem, as specified in 3501 Section 5.4.4. 3503 2. If the association is in the ESTABLISHED state and the SEQ (but 3504 not ACK) parameter is present, the UPDATE is processed and 3505 replied as described in Section 6.12.1. 3507 3. If the association is in the ESTABLISHED state and the ACK (but 3508 not SEQ) parameter is present, the UPDATE is processed as 3509 described in Section 6.12.2. 3511 4. If the association is in the ESTABLISHED state and there is both 3512 an ACK and SEQ in the UPDATE, the ACK is first processed as 3513 described in Section 6.12.2 and then the rest of the UPDATE is 3514 processed as described in Section 6.12.1. 3516 6.12.1. Handling a SEQ parameter in a received UPDATE message 3518 1. If the Update ID in the received SEQ is not the next in sequence 3519 Update ID and is greater than the receiver's window for new 3520 UPDATEs, the packet MUST be dropped. 3522 2. If the Update ID in the received SEQ corresponds to an UPDATE 3523 that has recently been processed, the packet is treated as a 3524 retransmission. The HMAC verification (next step) MUST NOT be 3525 skipped. (A byte-by-byte comparison of the received and a stored 3526 packet would be OK, though.) It is recommended that a host cache 3527 UPDATE packets sent with ACKs to avoid the cost of generating a 3528 new ACK packet to respond to a replayed UPDATE. The system MUST 3529 acknowledge, again, such (apparent) UPDATE message 3530 retransmissions but SHOULD also consider rate-limiting such 3531 retransmission responses to guard against replay attacks. 3533 3. The system MUST verify the HMAC in the UPDATE packet. If the 3534 verification fails, the packet MUST be dropped. 3536 4. The system MAY verify the SIGNATURE in the UPDATE packet. If the 3537 verification fails, the packet SHOULD be dropped and an error 3538 message logged. 3540 5. If a new SEQ parameter is being processed, the parameters in the 3541 UPDATE are then processed. The system MUST record the Update ID 3542 in the received SEQ parameter, for replay protection. 3544 6. An UPDATE acknowledgement packet with ACK parameter is prepared 3545 and sent to the peer. This ACK parameter may be included in a 3546 separate UPDATE or piggybacked in an UPDATE with SEQ parameter, 3547 as described in Section Section 5.3.5. The ACK parameter MAY 3548 acknowledge more than one of the peer's Update IDs. 3550 6.12.2. Handling an ACK Parameter in a Received UPDATE Packet 3552 1. The sequence number reported in the ACK must match with an 3553 earlier sent UPDATE packet that has not already been 3554 acknowledged. If no match is found or if the ACK does not 3555 acknowledge a new UPDATE, the packet MUST either be dropped if no 3556 SEQ parameter is present, or the processing steps in 3557 Section 6.12.1 are followed. 3559 2. The system MUST verify the HMAC in the UPDATE packet. If the 3560 verification fails, the packet MUST be dropped. 3562 3. The system MAY verify the SIGNATURE in the UPDATE packet. If the 3563 verification fails, the packet SHOULD be dropped and an error 3564 message logged. 3566 4. The corresponding UPDATE timer is stopped (see Section 6.11) so 3567 that the now acknowledged UPDATE is no longer retransmitted. If 3568 multiple UPDATEs are newly acknowledged, multiple timers are 3569 stopped. 3571 6.13. Processing NOTIFY Packets 3573 Processing NOTIFY packets is OPTIONAL. If processed, any errors in a 3574 received NOTIFICATION parameter SHOULD be logged. Received errors 3575 MUST be considered only as informational and the receiver SHOULD NOT 3576 change its HIP state Section 4.4.1 purely based on the received 3577 NOTIFY message. 3579 6.14. Processing CLOSE Packets 3581 When the host receives a CLOSE message it responds with a CLOSE_ACK 3582 message and moves to CLOSED state. (The authenticity of the CLOSE 3583 message is verified using both HMAC and SIGNATURE). This processing 3584 applies whether or not the HIP association state is CLOSING in order 3585 to handle CLOSE messages from both ends crossing in flight. 3587 The HIP association is not discarded before the host moves from the 3588 UNASSOCIATED state. 3590 Once the closing process has started, any need to send data packets 3591 will trigger creating and establishing of a new HIP association, 3592 starting with sending an I1. 3594 If there is no corresponding HIP association, the CLOSE packet is 3595 dropped. 3597 6.15. Processing CLOSE_ACK Packets 3599 When a host receives a CLOSE_ACK message it verifies that it is in 3600 CLOSING or CLOSED state and that the CLOSE_ACK was in response to the 3601 CLOSE (using the included ECHO_REPLY_SIGNED in response to the sent 3602 ECHO_REQUEST_SIGNED). 3604 The CLOSE_ACK uses HMAC and SIGNATURE for verification. The state is 3605 discarded when the state changes to UNASSOCIATED and, after that, the 3606 host MAY respond with an ICMP Parameter Problem to an incoming CLOSE 3607 message (See Section 5.4.4). 3609 6.16. Dropping HIP Associations 3611 A HIP implementation is free to drop a HIP association at any time, 3612 based on its own policy. If a HIP host decides to drop a HIP 3613 association, it deletes the corresponding HIP state, including the 3614 keying material. The implementation MUST also drop the peer's R1 3615 generation counter value, unless a local policy explicitly defines 3616 that the value of that particular host is stored. An implementation 3617 MUST NOT store R1 generation counters by default, but storing R1 3618 generation counter values, if done, MUST be configured by explicit 3619 HITs. 3621 7. HIP Policies 3623 There are a number of variables that will influence the HIP exchanges 3624 that each host must support. All HIP implementations MUST support 3625 more than one simultaneous HIs, at least one of which SHOULD be 3626 reserved for anonymous usage. Although anonymous HIs will be rarely 3627 used as Responder HIs, they will be common for Initiators. Support 3628 for more than two HIs is RECOMMENDED. 3630 Many Initiators would want to use a different HI for different 3631 Responders. The implementations SHOULD provide for an ACL of 3632 Initiator HIT to Responder HIT. This ACL SHOULD also include 3633 preferred transform and local lifetimes. 3635 The value of K used in the HIP R1 packet can also vary by policy. K 3636 should never be greater than 20, but for trusted partners it could be 3637 as low as 0. 3639 Responders would need a similar ACL, representing which hosts they 3640 accept HIP exchanges, and the preferred transform and local 3641 lifetimes. Wildcarding SHOULD be supported for this ACL also. 3643 8. Security Considerations 3645 HIP is designed to provide secure authentication of hosts. HIP also 3646 attempts to limit the exposure of the host to various denial-of- 3647 service and man-in-the-middle (MitM) attacks. In so doing, HIP 3648 itself is subject to its own DoS and MitM attacks that potentially 3649 could be more damaging to a host's ability to conduct business as 3650 usual. 3652 The 384-bit Diffie-Hellman Group is targetted to be used in hosts 3653 that either do not require or that are not powerful enough for 3654 handling strong cryptography. Although there is a risk that with 3655 suitable equipment the encryption can be broken in real time, the 3656 384-bit group can provide some protection for end-hosts that are not 3657 able to handle any stronger cryptography. When the security provided 3658 by the 384-bit group is not enough for applications on a host, the 3659 support for this group should be turned off in the configuration. 3661 Denial-of-service attacks often take advantage of the cost of start 3662 of state for a protocol on the Responder compared to the 'cheapness' 3663 on the Initiator. HIP makes no attempt to increase the cost of the 3664 start of state on the Initiator, but makes an effort to reduce the 3665 cost to the Responder. This is done by having the Responder start 3666 the 3-way exchange instead of the Initiator, making the HIP protocol 3667 4 packets long. In doing this, packet 2 becomes a 'stock' packet 3668 that the Responder MAY use many times, until some Initiator has 3669 provided a valid response to such and R1 packet. During an I1 storm 3670 the host may re-use the same D-H value also beyond that point. Using 3671 the same Diffie-Hellman values and random puzzle #I value has some 3672 risks. This risk needs to be balanced against a potential storm of 3673 HIP I1 packets. 3675 This shifting of the start of state cost to the Initiator in creating 3676 the I2 HIP packet, presents another DoS attack. The attacker spoofs 3677 the I1 HIP packet and the Responder sends out the R1 HIP packet. 3678 This could conceivably tie up the 'Initiator' with evaluating the R1 3679 HIP packet, and creating the I2 HIP packet. The defense against this 3680 attack is to simply ignore any R1 packet where a corresponding I1 was 3681 not sent. 3683 A second form of DoS attack arrives in the I2 HIP packet. Once the 3684 attacking Initiator has solved the puzzle, it can send packets with 3685 spoofed IP source addresses with either invalid encrypted HIP payload 3686 component or a bad HIP signature. This would take resources in the 3687 Responder's part to reach the point to discover that the I2 packet 3688 cannot be completely processed. The defense against this attack is 3689 after N bad I2 packets, the Responder would discard any I2s that 3690 contain the given Initiator HIT. Thus will shut down the attack. 3692 The attacker would have to request another R1 and use that to launch 3693 a new attack. The Responder could up the value of K while under 3694 attack. On the downside, valid I2s might get dropped too. 3696 A third form of DoS attack is emulating the restart of state after a 3697 reboot of one of the partners. A host restarting would send an I1 to 3698 a peer, which would respond with an R1 even if it were in the 3699 ESTABLISHED state. If the I1 were spoofed, the resulting R1 would be 3700 received unexpectedly by the spoofed host and would be dropped, as in 3701 the first case above. 3703 A fourth form of DoS attack is emulating the end of state. HIP 3704 relies on timers plus a CLOSE/CLOSE_ACK handshake to explicitly 3705 signals the end of a state. Because both CLOSE and CLOSE_ACK 3706 messages contain an HMAC, an outsider cannot close a connection. The 3707 presence of an additional SIGNATURE allows middle-boxes to inspect 3708 these messages and discard the associated state (for e.g., 3709 firewalling, SPI-based NATing, etc.). However, the optional behavior 3710 of replying to CLOSE with an ICMP Parameter Problem packet (as 3711 described in Section 5.4.4) might allow an IP spoofer sending CLOSE 3712 messages to launch reflection attacks. 3714 A fifth form of DoS attack is replaying R1s to cause the Initiator to 3715 solve stale puzzles and become out of synchronization with the 3716 Responder. The R1 generation counter is a monotonically increasing 3717 counter designed to protect against this attack, as described in 3718 section Section 4.1.4. 3720 Man-in-the-middle attacks are difficult to defend against, without 3721 third-party authentication. A skillful MitM could easily handle all 3722 parts of HIP; but HIP indirectly provides the following protection 3723 from a MitM attack. If the Responder's HI is retrieved from a signed 3724 DNS zone, a certificate, or through some other secure means, the 3725 Initiator can use this to validate the R1 HIP packet. 3727 Likewise, if the Initiator's HI is in a secure DNS zone, a trusted 3728 certificate, or otherwise securely available, the Responder can 3729 retrieve it after it gets the I2 HIP packet and validate that. 3730 However, since an Initiator may choose to use an anonymous HI, it 3731 knowingly risks a MitM attack. The Responder may choose not to 3732 accept a HIP exchange with an anonymous Initiator. 3734 The HIP Opportunistic Mode concept has been introduced in this 3735 document, but this document does not specify the details of such a 3736 connection set up (Section 4.1.6). There are certain security 3737 concerns with opportunistic mode, and they must be addressed in a 3738 separate document if such a mode will be used. 3740 NOTIFY messages are used only for informational purposes and they are 3741 unacknowledged. A HIP implementation cannot rely solely on the 3742 information received in a NOTIFY message because the packet may have 3743 been replayed. It SHOULD NOT change any state information based 3744 purely on a received NOTIFY message. 3746 Since not all hosts will ever support HIP, ICMP 'Destination Protocol 3747 Unreachable' are to be expected and present a DoS attack. Against an 3748 Initiator, the attack would look like the Responder does not support 3749 HIP, but shortly after receiving the ICMP message, the Initiator 3750 would receive a valid R1 HIP packet. Thus to protect from this 3751 attack, an Initiator should not react to an ICMP message until a 3752 reasonable delta time to get the real Responder's R1 HIP packet. A 3753 similar attack against the Responder is more involved. First an ICMP 3754 message is expected if the I1 was a DoS attack and the real owner of 3755 the spoofed IP address does not support HIP. The Responder SHOULD 3756 NOT act on this ICMP message to remove the minimal state from the R1 3757 HIP packet (if it has one), but wait for either a valid I2 HIP packet 3758 or the natural timeout of the R1 HIP packet. This is to allow for a 3759 sophisticated attacker that is trying to break up the HIP exchange. 3760 Likewise, the Initiator should ignore any ICMP message while waiting 3761 for an R2 HIP packet, deleting state only after a natural timeout. 3763 9. IANA Considerations 3765 IANA has reserved protocol number 253 to be used for experimental 3766 purposes (see [RFC3692]). In HIP, this value is used until a 3767 permanent protocol number has been assigned by IANA. 3769 This document defines a new 128-bit value under the CGA Message Type 3770 namespace [RFC3972], 0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA, to be 3771 used for HIT generation as specified in ORCHID 3772 [I-D.laganier-ipv6-khi]. 3774 This document also creates a set of new name spaces. These are 3775 described below. 3777 Packet Type 3779 The 7-bit Packet Type field in a HIP protocol packet describes the 3780 type of a HIP protocol message. It is defined in Section 5.1. 3781 The current values are defined in Section 5.3.1 through 3782 Section 5.3.8. 3784 New values are assigned through IETF Consensus [RFC2434]. 3786 HIP Version 3788 The four bit Version field in a HIP protocol packet describes the 3789 version of the HIP protocol. It is defined in Section 5.1. The 3790 only currently defined value is 1. New values are assigned 3791 through IETF Consensus. 3793 Parameter Type 3795 The 16 bit Type field in a HIP parameter describes the type of the 3796 parameter. It is defined in Section 5.2.1. The current values 3797 are defined in Section 5.2.3 through Section 5.2.20. 3799 With the exception of the assigned type codes, the type codes 0 3800 through 1023 and 61440 through 65535 are reserved for future base 3801 protocol extensions, and are assigned through IETF Consensus. 3803 The type codes 32768 through 49141 are reserved for 3804 experimentation and private use. Types SHOULD be selected in a 3805 random fashion from this range, thereby reducing the probability 3806 of collisions. A method employing genuine randomness (such as 3807 flipping a coin) SHOULD be used. 3809 All other type codes are assigned through First Come First Served, 3810 with Specification Required [RFC2434]. 3812 Group ID 3814 The eight bit Group ID values appear in the DIFFIE_HELLMAN 3815 parameter and are defined in Section 5.2.6. New values either 3816 from the reserved or unassigned space are assigned through IETF 3817 Consensus. 3819 Suite ID 3821 The 16 bit Suite ID values in a HIP_TRANSFORM parameter are 3822 defined in Section 5.2.7. New values either from the reserved or 3823 unassigned space are assigned through IETF Consensus. 3825 DI-Type 3827 The four bit DI-Type values in a HOST_ID parameter are defined in 3828 Section 5.2.8. New values are assigned through IETF Consensus. 3830 Notify Message Type 3832 The 16 bit Notify Message Type values in a NOTIFICATION parameter 3833 are defined in Section 5.2.16. New values are assigned through 3834 First Come First Served, with Specification Required. 3836 Notify Message Type values 1 through 10 are used for informing 3837 about errors in packet structures, values 11 through 20 for 3838 informing about problems in parameters containing cryptographic 3839 related material, values 21 through 30 for informing about 3840 problems in authentication or packet integrity verification. 3841 Parameter numbers above 30 can be used for informing about other 3842 types of errors or events. Values 51 - 8191 are error types 3843 reserved to be allocated by IANA. Values 8192 - 16383 are error 3844 types for private use. Values 16385 - 40959 are status types to 3845 be allocated by IANA and values 40960 - 65535 are status types for 3846 private use. 3848 10. Acknowledgments 3850 The drive to create HIP came to being after attending the MALLOC 3851 meeting at the 43rd IETF meeting. Baiju Patel and Hilarie Orman 3852 really gave the original author, Bob Moskowitz, the assist to get HIP 3853 beyond 5 paragraphs of ideas. It has matured considerably since the 3854 early drafts thanks to extensive input from IETFers. Most 3855 importantly, its design goals are articulated and are different from 3856 other efforts in this direction. Particular mention goes to the 3857 members of the NameSpace Research Group of the IRTF. Noel Chiappa 3858 provided the framework for LSIs and Keith Moore the impetus to 3859 provide resolvability. Steve Deering provided encouragement to keep 3860 working, as a solid proposal can act as a proof of ideas for a 3861 research group. 3863 Many others contributed; extensive security tips were provided by 3864 Steve Bellovin. Rob Austein kept the DNS parts on track. Paul 3865 Kocher taught Bob Moskowitz how to make the puzzle exchange expensive 3866 for the Initiator to respond, but easy for the Responder to validate. 3867 Bill Sommerfeld supplied the Birthday concept, which later evolved 3868 into the R1 generation counter, to simplify reboot management. Erik 3869 Nordmark supplied CLOSE-mechanism for closing connections. Rodney 3870 Thayer and Hugh Daniels provide extensive feedback. In the early 3871 times of this document, John Gilmore kept Bob Moskowitz challenged to 3872 provide something of value. 3874 During the later stages of this document, when the editing baton was 3875 transfered to Pekka Nikander, the input from the early implementors 3876 were invaluable. Without having actual implementations, this 3877 document would not be on the level it is now. 3879 In the usual IETF fashion, a large number of people have contributed 3880 to the actual text or ideas. The list of these people include Jeff 3881 Ahrenholz, Francis Dupont, Derek Fawcus, George Gross, Andrew 3882 McGregor, Julien Laganier, Miika Komu, Mika Kousa, Jan Melen, Henrik 3883 Petander, Michael Richardson, Tim Shepard, Jorma Wall, and Jukka 3884 Ylitalo. Our apologies to anyone whose name is missing. 3886 Once the HIP Working Group was founded in early 2004, a number of 3887 changes were introduced through the working group process. Most 3888 notably, the original draft was split in two, one containing the base 3889 exchange and the other one defining how to use ESP. Some 3890 modifications to the protocol proposed by Aura et al. [AUR03] were 3891 added at a later stage. 3893 11. References 3895 11.1. Normative References 3897 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 3898 August 1980. 3900 [RFC1035] Mockapetris, P., "Domain names - implementation and 3901 specification", STD 13, RFC 1035, November 1987. 3903 [RFC1885] Conta, A. and S. Deering, "Internet Control Message 3904 Protocol (ICMPv6) for the Internet Protocol Version 6 3905 (IPv6)", RFC 1885, December 1995. 3907 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3908 Requirement Levels", BCP 14, RFC 2119, March 1997. 3910 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within 3911 ESP and AH", RFC 2404, November 1998. 3913 [RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher 3914 Algorithms", RFC 2451, November 1998. 3916 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 3917 (IPv6) Specification", RFC 2460, December 1998. 3919 [RFC2535] Eastlake, D., "Domain Name System Security Extensions", 3920 RFC 2535, March 1999. 3922 [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System 3923 (DNS)", RFC 2536, March 1999. 3925 [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography 3926 Specification Version 2.0", RFC 2898, September 2000. 3928 [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain 3929 Name System (DNS)", RFC 3110, May 2001. 3931 [RFC3484] Draves, R., "Default Address Selection for Internet 3932 Protocol version 6 (IPv6)", RFC 3484, February 2003. 3934 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 3935 Diffie-Hellman groups for Internet Key Exchange (IKE)", 3936 RFC 3526, May 2003. 3938 [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher 3939 Algorithm and Its Use with IPsec", RFC 3602, 3940 September 2003. 3942 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 3943 RFC 3972, March 2005. 3945 [RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the 3946 Internet Key Exchange Version 2 (IKEv2)", RFC 4307, 3947 December 2005. 3949 [I-D.laganier-ipv6-khi] 3950 Nikander, P., "An IPv6 Prefix for Overlay Routable 3951 Cryptographic Hash Identifiers (ORCHID)", 3952 draft-laganier-ipv6-khi-05 (work in progress), 3953 September 2006. 3955 [I-D.ietf-radext-rfc2486bis] 3956 Aboba, B., "The Network Access Identifier", 3957 draft-ietf-radext-rfc2486bis-06 (work in progress), 3958 July 2005. 3960 [I-D.ietf-hip-esp] 3961 Jokela, P., "Using ESP transport format with HIP", 3962 draft-ietf-hip-esp-04 (work in progress), October 2006. 3964 [FIPS95] NIST, "FIPS PUB 180-1: Secure Hash Standard", April 1995. 3966 11.2. Informative References 3968 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 3969 RFC 792, September 1981. 3971 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 3972 (IKE)", RFC 2409, November 1998. 3974 [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", 3975 RFC 2412, November 1998. 3977 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3978 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 3979 October 1998. 3981 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 3982 Considered Useful", BCP 82, RFC 3692, January 2004. 3984 [I-D.ietf-hip-arch] 3985 Moskowitz, R. and P. Nikander, "Host Identity Protocol 3986 Architecture", draft-ietf-hip-arch-03 (work in progress), 3987 August 2005. 3989 [I-D.ietf-shim6-proto] 3990 Bagnulo, M. and E. Nordmark, "Level 3 multihoming shim 3991 protocol", draft-ietf-shim6-proto-07 (work in progress), 3992 December 2006. 3994 [I-D.henderson-hip-applications] 3995 Henderson, T. and P. Nikander, "Using HIP with Legacy 3996 Applications", draft-henderson-hip-applications-03 (work 3997 in progress), May 2006. 3999 [I-D.ietf-hip-mm] 4000 Nikander, P., "End-Host Mobility and Multihoming with the 4001 Host Identity Protocol", draft-ietf-hip-mm-04 (work in 4002 progress), June 2006. 4004 [I-D.ietf-hip-dns] 4005 Nikander, P. and J. Laganier, "Host Identity Protocol 4006 (HIP) Domain Name System (DNS) Extensions", 4007 draft-ietf-hip-dns-08 (work in progress), October 2006. 4009 [I-D.ietf-hip-rvs] 4010 Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 4011 Rendezvous Extension", draft-ietf-hip-rvs-05 (work in 4012 progress), June 2006. 4014 [AUR03] Aura, T., Nagarajan, A., and A. Gurtov, "Analysis of the 4015 HIP Base Exchange Protocol", in Proceedings of 10th 4016 Australasian Conference on Information Security and 4017 Privacy, July 2003. 4019 [KRA03] Krawczyk, H., "SIGMA: The 'SIGn-and-MAc' Approach to 4020 Authenticated Diffie-Hellman and Its Use in the IKE- 4021 Protocols", in Proceedings of CRYPTO 2003, pages 400-425, 4022 August 2003. 4024 [CRO03] Crosby, SA. and DS. Wallach, "Denial of Service via 4025 Algorithmic Complexity Attacks", in Proceedings of Usenix 4026 Security Symposium 2003, Washington, DC., August 2003. 4028 [FIPS01] NIST, "FIPS PUB 197: Advanced Encryption Standard", 4029 Nov 2001. 4031 [DIF76] Diffie, W. and M. Hellman, "New Directions in 4032 Cryptography", IEEE Transactions on Information 4033 Theory vol. IT-22, number 6, pages 644-654, Nov 1976. 4035 [KAU03] Kaufman, C., Perlman, R., and B. Sommerfeld, "DoS 4036 protection for UDP-based protocols", ACM Conference on 4037 Computer and Communications Security , Oct 2003. 4039 Appendix A. Using Responder Puzzles 4041 As mentioned in Section 4.1.1, the Responder may delay state creation 4042 and still reject most spoofed I2s by using a number of pre-calculated 4043 R1s and a local selection function. This appendix defines one 4044 possible implementation in detail. The purpose of this appendix is 4045 to give the implementors an idea on how to implement the mechanism. 4046 If the implementation is based on this appendix, it MAY contain some 4047 local modification that makes an attacker's task harder. 4049 The Responder creates a secret value S, that it regenerates 4050 periodically. The Responder needs to remember two latest values of 4051 S. Each time the S is regenerated, R1 generation counter value is 4052 incremented by one. 4054 The Responder generates a pre-signed R1 packet. The signature for 4055 pre-generated R1s must be recalculated when the Diffie-Hellman key is 4056 recomputed or when the R1_COUNTER value changes due to S value 4057 regeneration. 4059 When the Initiator sends the I1 packet for initializing a connection, 4060 the Responder gets the HIT and IP address from the packet, and 4061 generates an I-value for the puzzle. The I value is set to the pre- 4062 signed R1 packet. 4064 I value calculation: 4065 I = Ltrunc( RHASH ( S | HIT-I | HIT-R | IP-I | IP-R ), 64) 4067 The RHASH algorithm is the same that is used to generate the 4068 Responder's HIT value. 4070 From an incoming I2 packet, the Responder gets the required 4071 information to validate the puzzle: HITs, IP addresses, and the 4072 information of the used S value from the R1_COUNTER. Using these 4073 values, the Responder can regenerate the I, and verify it against the 4074 I received in the I2 packet. If the I values match, it can verify 4075 the solution using I, J, and difficulty K. If the I values do not 4076 match, the I2 is dropped. 4078 puzzle_check: 4079 V := Ltrunc( RHASH( I2.I | I2.hit_i | I2.hit_r | I2.J ), K ) 4080 if V != 0, drop the packet 4082 If the puzzle solution is correct, the I and J values are stored for 4083 later use. They are used as input material when keying material is 4084 generated. 4086 Keeping state about failed puzzle solutions depends on the 4087 implementation. Although it is possible that the Responder doesn't 4088 keep any state information, it still may do so to protect itself 4089 against certain attacks (see Section 4.1.1). 4091 Appendix B. Generating a Public Key Encoding from a HI 4093 The following pseudo-codes illustrate the process to generate a 4094 public key encoding from a HI for both RSA and DSA. 4096 The symbol := denotes assignment; the symbol += denotes appending. 4097 The pseudo-function encode_in_network_byte_order takes two 4098 parameters, an integer (bignum) and a length in bytes, and returns 4099 the integer encoded into a byte string of the given length. 4101 switch ( HI.algorithm ) 4102 { 4104 case RSA: 4105 buffer := encode_in_network_byte_order ( HI.RSA.e_len, 4106 ( HI.RSA.e_len > 255 ) ? 3 : 1 ) 4107 buffer += encode_in_network_byte_order ( HI.RSA.e, HI.RSA.e_len ) 4108 buffer += encode_in_network_byte_order ( HI.RSA.n, HI.RSA.n_len ) 4109 break; 4111 case DSA: 4112 buffer := encode_in_network_byte_order ( HI.DSA.T , 1 ) 4113 buffer += encode_in_network_byte_order ( HI.DSA.Q , 20 ) 4114 buffer += encode_in_network_byte_order ( HI.DSA.P , 64 + 4115 8 * HI.DSA.T ) 4116 buffer += encode_in_network_byte_order ( HI.DSA.G , 64 + 4117 8 * HI.DSA.T ) 4118 buffer += encode_in_network_byte_order ( HI.DSA.Y , 64 + 4119 8 * HI.DSA.T ) 4120 break; 4122 } 4124 Appendix C. Example Checksums for HIP Packets 4126 The HIP checksum for HIP packets is specified in Section 5.1.1. 4127 Checksums for TCP and UDP packets running over HIP-enabled security 4128 associations are specified in Section 3.5. The examples below use IP 4129 addresses of 192.168.0.1 and 192.168.0.2 (and their respective IPv4- 4130 compatible IPv6 formats), and HITs with the first two bits "01" 4131 followed by 124 zeroes followed by a decimal 1 or 2, respectively. 4133 The following example is defined only for testing a checksum 4134 calculation. The address format for IPv4-compatible IPv6 address is 4135 not a valid one, but using these IPv6 addresses when testing an IPv6 4136 implementation gives the same checksum output as an IPv4 4137 implementation with the corresponding IPv4 addresses. 4139 C.1. IPv6 HIP Example (I1) 4141 Source Address: ::192.168.0.1 4142 Destination Address: ::192.168.0.2 4143 Upper-Layer Packet Length: 40 0x28 4144 Next Header: 253 0xfd 4145 Payload Protocol: 59 0x3b 4146 Header Length: 4 0x4 4147 Packet Type: 1 0x1 4148 Version: 1 0x1 4149 Reserved: 1 0x1 4150 Control: 0 0x0 4151 Checksum: 8046 0x1f6e 4152 Sender's HIT : 1100::1 4153 Receiver's HIT: 1100::2 4155 C.2. IPv4 HIP Packet (I1) 4157 The IPv4 checksum value for the same example I1 packet is the same as 4158 the IPv6 checksum (since the checksums due to the IPv4 and IPv6 4159 pseudo-header components are the same). 4161 C.3. TCP Segment 4163 Regardless of whether IPv6 or IPv4 is used, the TCP and UDP sockets 4164 use the IPv6 pseudo-header format [RFC2460], with the HITs used in 4165 place of the IPv6 addresses. 4167 Sender's HIT: 1100::0001 4168 Receiver's HIT: 1100::0002 4169 Upper-Layer Packet Length: 20 0x14 4170 Next Header: 6 0x06 4171 Source port: 65500 0xffdc 4172 Destination port: 22 0x0016 4173 Sequence number: 1 0x00000001 4174 Acknowledgment number: 0 0x00000000 4175 Header length: 20 0x14 4176 Flags: SYN 0x02 4177 Window size: 65535 0xffff 4178 Checksum: 60301 0xeb8d 4179 Urgent pointer: 0 0x0000 4181 0x0000: 6000 0000 0014 0640 1100 0000 0000 0000 4182 0x0010: 0000 0000 0000 0002 1100 0000 0000 0000 4183 0x0020: 0000 0000 0000 0002 ffdc 0016 0000 0001 4184 0x0030: 0000 0000 5002 ffff 8deb 0000 4186 Appendix D. 384-bit Group 4188 This 384-bit group is defined only to be used with HIP. NOTE: The 4189 security level of this group is very low! The encryption may be 4190 broken in a very short time, even real-time. It should be used only 4191 when the host is not powerful enough (e.g. some PDAs) and when 4192 security requirements are low (e.g. during normal web surfing). 4194 This prime is: 2^384 - 2^320 - 1 + 2^64 * { [ 2^254 pi] + 5857 } 4196 Its hexadecimal value is: 4198 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 4199 29024E08 8A67CC74 020BBEA6 3B13B202 FFFFFFFF FFFFFFFF 4201 The generator is: 2. 4203 Appendix E. OAKLEY Well-known group 1 4205 See also [RFC2412] for definition of OAKLEY Well-known group 1. 4207 OAKLEY Well-Known Group 1: A 768 bit prime 4209 The prime is 2^768 - 2^704 - 1 + 2^64 * { [2^638 pi] + 149686 }. 4211 The hexadecimal value is: 4213 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 4214 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD 4215 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 4216 E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF 4218 This has been rigorously verified as a prime. 4220 The generator is: 22 (decimal) 4222 Authors' Addresses 4224 Robert Moskowitz 4225 ICSAlabs, a Division of TruSecure Corporation 4226 1000 Bent Creek Blvd, Suite 200 4227 Mechanicsburg, PA 4228 USA 4230 Email: rgm@icsalabs.com 4232 Pekka Nikander 4233 Ericsson Research NomadicLab 4234 JORVAS FIN-02420 4235 FINLAND 4237 Phone: +358 9 299 1 4238 Email: pekka.nikander@nomadiclab.com 4240 Petri Jokela 4241 Ericsson Research NomadicLab 4242 JORVAS FIN-02420 4243 FINLAND 4245 Phone: +358 9 299 1 4246 Email: petri.jokela@nomadiclab.com 4248 Thomas R. Henderson 4249 The Boeing Company 4250 P.O. Box 3707 4251 Seattle, WA 4252 USA 4254 Email: thomas.r.henderson@boeing.com 4256 Full Copyright Statement 4258 Copyright (C) The Internet Society (2007). 4260 This document is subject to the rights, licenses and restrictions 4261 contained in BCP 78, and except as set forth therein, the authors 4262 retain all their rights. 4264 This document and the information contained herein are provided on an 4265 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 4266 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 4267 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 4268 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 4269 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 4270 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 4272 Intellectual Property 4274 The IETF takes no position regarding the validity or scope of any 4275 Intellectual Property Rights or other rights that might be claimed to 4276 pertain to the implementation or use of the technology described in 4277 this document or the extent to which any license under such rights 4278 might or might not be available; nor does it represent that it has 4279 made any independent effort to identify any such rights. Information 4280 on the procedures with respect to rights in RFC documents can be 4281 found in BCP 78 and BCP 79. 4283 Copies of IPR disclosures made to the IETF Secretariat and any 4284 assurances of licenses to be made available, or the result of an 4285 attempt made to obtain a general license or permission for the use of 4286 such proprietary rights by implementers or users of this 4287 specification can be obtained from the IETF on-line IPR repository at 4288 http://www.ietf.org/ipr. 4290 The IETF invites any interested party to bring to its attention any 4291 copyrights, patents or patent applications, or other proprietary 4292 rights that may cover technology that may be required to implement 4293 this standard. Please address the information to the IETF at 4294 ietf-ipr@ietf.org. 4296 Acknowledgment 4298 Funding for the RFC Editor function is provided by the IETF 4299 Administrative Support Activity (IASA).