idnits 2.17.1 draft-ietf-hip-rfc5201-bis-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 2 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 2129 has weird spacing: '...c Value leng...' == Line 2131 has weird spacing: '...c Value the ...' == Line 2648 has weird spacing: '...ication info...' == Line 2787 has weird spacing: '...ue data opaqu...' == Line 2817 has weird spacing: '...ue data opaqu...' == (2 more instances...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: o Replaced occurrences of SHOULD not with SHOULD NOT. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 14, 2011) is 4785 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-08) exists of draft-ietf-hip-rfc4843-bis-00 == Outdated reference: A later version (-07) exists of draft-ietf-hip-rfc5202-bis-00 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2898 (Obsoleted by RFC 8018) ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) ** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542) ** Obsolete normative reference: RFC 5201 (Obsoleted by RFC 7401) ** Downref: Normative reference to an Informational RFC: RFC 5869 ** Downref: Normative reference to an Informational RFC: RFC 5903 ** Downref: Normative reference to an Informational RFC: RFC 6090 == Outdated reference: A later version (-12) exists of draft-ietf-hip-cert-09 == Outdated reference: A later version (-20) exists of draft-ietf-hip-rfc4423-bis-02 == Outdated reference: A later version (-08) exists of draft-ietf-hip-rfc5204-bis-00 == Outdated reference: A later version (-10) exists of draft-ietf-hip-rfc5205-bis-00 == Outdated reference: A later version (-14) exists of draft-ietf-hip-rfc5206-bis-01 -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 9 errors (**), 0 flaws (~~), 17 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Moskowitz, Ed. 3 Internet-Draft Verizon 4 Obsoletes: 5201 (if approved) T. Heer 5 Intended status: Standards Track RWTH Aachen University, 6 Expires: September 15, 2011 Communication and Distributed 7 Systems Group 8 P. Jokela 9 Ericsson Research NomadicLab 10 T. Henderson 11 The Boeing Company 12 March 14, 2011 14 Host Identity Protocol Version 2 (HIPv2) 15 draft-ietf-hip-rfc5201-bis-05 17 Abstract 19 This document specifies the details of the Host Identity Protocol 20 (HIP). HIP allows consenting hosts to securely establish and 21 maintain shared IP-layer state, allowing separation of the identifier 22 and locator roles of IP addresses, thereby enabling continuity of 23 communications across IP address changes. HIP is based on a SIGMA- 24 compliant Diffie-Hellman key exchange, using public key identifiers 25 from a new Host Identity namespace for mutual peer authentication. 26 The protocol is designed to be resistant to denial-of-service (DoS) 27 and man-in-the-middle (MitM) attacks. When used together with 28 another suitable security protocol, such as the Encapsulated Security 29 Payload (ESP), it provides integrity protection and optional 30 encryption for upper-layer protocols, such as TCP and UDP. 32 This document obsoletes RFC 5201 and addresses the concerns raised by 33 the IESG, particularly that of crypto agility. It also incorporates 34 lessons learned from the implementations of RFC 5201. 36 Status of This Memo 38 This Internet-Draft is submitted to IETF in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF), its areas, and its working groups. Note that 43 other groups may also distribute working documents as Internet- 44 Drafts. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 The list of current Internet-Drafts can be accessed at 52 http://www.ietf.org/ietf/1id-abstracts.txt. 54 The list of Internet-Draft Shadow Directories can be accessed at 55 http://www.ietf.org/shadow.html. 57 This Internet-Draft will expire on September 15, 2011. 59 Copyright Notice 61 Copyright (c) 2011 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (http://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the BSD License. 74 This document may contain material from IETF Documents or IETF 75 Contributions published or made publicly available before November 76 10, 2008. The person(s) controlling the copyright in some of this 77 material may not have granted the IETF Trust the right to allow 78 modifications of such material outside the IETF Standards Process. 79 Without obtaining an adequate license from the person(s) controlling 80 the copyright in such materials, this document may not be modified 81 outside the IETF Standards Process, and derivative works of it may 82 not be created outside the IETF Standards Process, except to format 83 it for publication as an RFC or to translate it into languages other 84 than English. 86 Table of Contents 88 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 89 1.1. A New Namespace and Identifiers . . . . . . . . . . . . . 7 90 1.2. The HIP Base Exchange (BEX) . . . . . . . . . . . . . . . 7 91 1.3. Memo Structure . . . . . . . . . . . . . . . . . . . . . 8 92 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 8 93 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 8 94 2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 8 95 2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 9 96 3. Host Identity (HI) and its Structure . . . . . . . . . . . . 10 97 3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 11 98 3.2. Generating a HIT from an HI . . . . . . . . . . . . . . . 11 99 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 12 100 4.1. Creating a HIP Association . . . . . . . . . . . . . . . 13 101 4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . 14 102 4.1.2. Puzzle Exchange . . . . . . . . . . . . . . . . . . . 15 103 4.1.3. Authenticated Diffie-Hellman Protocol with DH 104 Group Negotiation . . . . . . . . . . . . . . . . . . 17 105 4.1.4. HIP Replay Protection . . . . . . . . . . . . . . . . 18 106 4.1.5. Refusing a HIP Base Exchange . . . . . . . . . . . . 19 107 4.1.6. Aborting a HIP Base Exchange . . . . . . . . . . . . 20 108 4.1.7. HIP Downgrade Protection . . . . . . . . . . . . . . 20 109 4.1.8. HIP Opportunistic Mode . . . . . . . . . . . . . . . 21 110 4.2. Updating a HIP Association . . . . . . . . . . . . . . . 24 111 4.3. Error Processing . . . . . . . . . . . . . . . . . . . . 24 112 4.4. HIP State Machine . . . . . . . . . . . . . . . . . . . . 25 113 4.4.1. State Machine Terminology . . . . . . . . . . . . . . 26 114 4.4.2. HIP States . . . . . . . . . . . . . . . . . . . . . 27 115 4.4.3. HIP State Processes . . . . . . . . . . . . . . . . . 27 116 4.4.4. Simplified HIP State Diagram . . . . . . . . . . . . 34 117 4.5. User Data Considerations . . . . . . . . . . . . . . . . 36 118 4.5.1. TCP and UDP Pseudo-Header Computation for User Data . 36 119 4.5.2. Sending Data on HIP Packets . . . . . . . . . . . . . 36 120 4.5.3. Transport Formats . . . . . . . . . . . . . . . . . . 36 121 4.5.4. Reboot, Timeout, and Restart of HIP . . . . . . . . . 36 122 4.6. Certificate Distribution . . . . . . . . . . . . . . . . 37 123 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 37 124 5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 37 125 5.1.1. Checksum . . . . . . . . . . . . . . . . . . . . . . 38 126 5.1.2. HIP Controls . . . . . . . . . . . . . . . . . . . . 39 127 5.1.3. HIP Fragmentation Support . . . . . . . . . . . . . . 39 128 5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 40 129 5.2.1. TLV Format . . . . . . . . . . . . . . . . . . . . . 43 130 5.2.2. Defining New Parameters . . . . . . . . . . . . . . . 45 131 5.2.3. R1_COUNTER . . . . . . . . . . . . . . . . . . . . . 46 132 5.2.4. PUZZLE . . . . . . . . . . . . . . . . . . . . . . . 47 133 5.2.5. SOLUTION . . . . . . . . . . . . . . . . . . . . . . 48 134 5.2.6. DIFFIE_HELLMAN . . . . . . . . . . . . . . . . . . . 49 135 5.2.7. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . 50 136 5.2.8. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 51 137 5.2.9. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 53 138 5.2.10. DH_GROUP_LIST . . . . . . . . . . . . . . . . . . . . 54 139 5.2.11. HIP_MAC . . . . . . . . . . . . . . . . . . . . . . . 55 140 5.2.12. HIP_MAC_2 . . . . . . . . . . . . . . . . . . . . . . 55 141 5.2.13. HIP_SIGNATURE . . . . . . . . . . . . . . . . . . . . 56 142 5.2.14. HIP_SIGNATURE_2 . . . . . . . . . . . . . . . . . . . 57 143 5.2.15. SEQ . . . . . . . . . . . . . . . . . . . . . . . . . 57 144 5.2.16. ACK . . . . . . . . . . . . . . . . . . . . . . . . . 58 145 5.2.17. ENCRYPTED . . . . . . . . . . . . . . . . . . . . . . 59 146 5.2.18. NOTIFICATION . . . . . . . . . . . . . . . . . . . . 60 147 5.2.19. ECHO_REQUEST_SIGNED . . . . . . . . . . . . . . . . . 64 148 5.2.20. ECHO_REQUEST_UNSIGNED . . . . . . . . . . . . . . . . 64 149 5.2.21. ECHO_RESPONSE_SIGNED . . . . . . . . . . . . . . . . 65 150 5.2.22. ECHO_RESPONSE_UNSIGNED . . . . . . . . . . . . . . . 66 151 5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 66 152 5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 67 153 5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 68 154 5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 71 155 5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 72 156 5.3.5. UPDATE - the HIP Update Packet . . . . . . . . . . . 72 157 5.3.6. NOTIFY - the HIP Notify Packet . . . . . . . . . . . 73 158 5.3.7. CLOSE - the HIP Association Closing Packet . . . . . 74 159 5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet . . 74 160 5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 75 161 5.4.1. Invalid Version . . . . . . . . . . . . . . . . . . . 75 162 5.4.2. Other Problems with the HIP Header and Packet 163 Structure . . . . . . . . . . . . . . . . . . . . . . 75 164 5.4.3. Invalid Puzzle Solution . . . . . . . . . . . . . . . 75 165 5.4.4. Non-Existing HIP Association . . . . . . . . . . . . 76 166 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 76 167 6.1. Processing Outgoing Application Data . . . . . . . . . . 77 168 6.2. Processing Incoming Application Data . . . . . . . . . . 78 169 6.3. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 78 170 6.4. HIP_MAC and SIGNATURE Calculation and Verification . . . 80 171 6.4.1. HMAC Calculation . . . . . . . . . . . . . . . . . . 80 172 6.4.2. Signature Calculation . . . . . . . . . . . . . . . . 82 173 6.5. HIP KEYMAT Generation . . . . . . . . . . . . . . . . . . 84 174 6.6. Initiation of a HIP Base Exchange . . . . . . . . . . . . 86 175 6.6.1. Sending Multiple I1 Packets in Parallel . . . . . . . 87 176 6.6.2. Processing Incoming ICMP Protocol Unreachable 177 Messages . . . . . . . . . . . . . . . . . . . . . . 87 178 6.7. Processing Incoming I1 Packets . . . . . . . . . . . . . 88 179 6.7.1. R1 Management . . . . . . . . . . . . . . . . . . . . 89 180 6.7.2. Handling Malformed Messages . . . . . . . . . . . . . 89 181 6.8. Processing Incoming R1 Packets . . . . . . . . . . . . . 89 182 6.8.1. Handling of Malformed Messages . . . . . . . . . . . 92 183 6.9. Processing Incoming I2 Packets . . . . . . . . . . . . . 92 184 6.9.1. Handling of Malformed Messages . . . . . . . . . . . 95 185 6.10. Processing of Incoming R2 Packets . . . . . . . . . . . . 95 186 6.11. Sending UPDATE Packets . . . . . . . . . . . . . . . . . 96 187 6.12. Receiving UPDATE Packets . . . . . . . . . . . . . . . . 97 188 6.12.1. Handling a SEQ Parameter in a Received UPDATE 189 Message . . . . . . . . . . . . . . . . . . . . . . . 98 190 6.12.2. Handling an ACK Parameter in a Received UPDATE 191 Packet . . . . . . . . . . . . . . . . . . . . . . . 98 192 6.13. Processing of NOTIFY Packets . . . . . . . . . . . . . . 99 193 6.14. Processing CLOSE Packets . . . . . . . . . . . . . . . . 99 194 6.15. Processing CLOSE_ACK Packets . . . . . . . . . . . . . . 99 195 6.16. Handling State Loss . . . . . . . . . . . . . . . . . . . 100 196 7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 100 197 8. Security Considerations . . . . . . . . . . . . . . . . . . . 100 198 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 103 199 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 105 200 11. Changes from RFC 5201 . . . . . . . . . . . . . . . . . . . . 106 201 11.1. Changes from draft-ietf-hip-rfc5201-bis-04 . . . . . . . 106 202 11.2. Changes from draft-ietf-hip-rfc5201-bis-03 . . . . . . . 108 203 11.3. Changes from draft-ietf-hip-rfc5201-bis-02 . . . . . . . 108 204 11.4. Changes from draft-ietf-hip-rfc5201-bis-01 . . . . . . . 109 205 11.5. Changes from draft-ietf-hip-rfc5201-bis-00 . . . . . . . 111 206 11.6. Contents of draft-ietf-hip-rfc5201-bis-00 . . . . . . . . 111 207 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 111 208 12.1. Normative References . . . . . . . . . . . . . . . . . . 111 209 12.2. Informative References . . . . . . . . . . . . . . . . . 113 210 Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 115 211 Appendix B. Generating a Public Key Encoding from an HI . . . . 116 212 Appendix C. Example Checksums for HIP Packets . . . . . . . . . 117 213 C.1. IPv6 HIP Example (I1 packet) . . . . . . . . . . . . . . 118 214 C.2. IPv4 HIP Packet (I1 packet) . . . . . . . . . . . . . . . 118 215 C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . . 118 216 Appendix D. ECDH and ECDSA 160 Bit Groups . . . . . . . . . . . 119 217 Appendix E. HIT Suites and HIT Generation . . . . . . . . . . . 119 219 1. Introduction 221 This document specifies the details of the Host Identity Protocol 222 (HIP). A high-level description of the protocol and the underlying 223 architectural thinking is available in the separate HIP architecture 224 description [I-D.ietf-hip-rfc4423-bis]. Briefly, the HIP 225 architecture proposes an alternative to the dual use of IP addresses 226 as "locators" (routing labels) and "identifiers" (endpoint, or host, 227 identifiers). In HIP, public cryptographic keys, of a public/private 228 key pair, are used as Host Identifiers, to which higher layer 229 protocols are bound instead of an IP address. By using public keys 230 (and their representations) as host identifiers, dynamic changes to 231 IP address sets can be directly authenticated between hosts, and if 232 desired, strong authentication between hosts at the TCP/IP stack 233 level can be obtained. 235 This memo specifies the base HIP protocol ("base exchange") used 236 between hosts to establish an IP-layer communications context, called 237 a HIP association, prior to communications. It also defines a packet 238 format and procedures for updating an active HIP association. Other 239 elements of the HIP architecture are specified in other documents, 240 such as: 242 o "Using the Encapsulating Security Payload (ESP) Transport Format 243 with the Host Identity Protocol (HIP)" [I-D.ietf-hip-rfc5202-bis]: 244 how to use the Encapsulating Security Payload (ESP) for integrity 245 protection and optional encryption 247 o "Host Mobility with the Host Identity Protocol" 248 [I-D.ietf-hip-rfc5206-bis]: how to support host mobility in HIP 250 o "Host Identity Protocol (HIP) Domain Name System (DNS) Extensions" 251 [I-D.ietf-hip-rfc5205-bis]: how to extend DNS to contain Host 252 Identity information 254 o "Host Identity Protocol (HIP) Rendezvous Extension" 255 [I-D.ietf-hip-rfc5204-bis]: using a rendezvous mechanism to 256 contact mobile HIP hosts 258 Since the HIP Base Exchange was first developed, there have been a 259 few advances in cryptography and attacks against cryptographic 260 systems. As a result, all cryptographic protocols need to be agile. 261 That is, it should be a part of the protocol to be able to switch 262 from one cryptographic primitive to another. It is important to 263 support a reasonable set of mainstream algorithms to cater for 264 different use cases and allow moving away from algorithms that are 265 later discovered to be vulnerable This update to the Base Exchange 266 includes this needed cryptographic agility while addressing the 267 downgrade attacks that such flexibility introduces. In particular, 268 Elliptic Curve support by Elliptic Curve DSA (ECDSA) and Elliptic 269 Curve Diffie-Hellman (ECDH) and alternative hash functions have been 270 added. 272 1.1. A New Namespace and Identifiers 274 The Host Identity Protocol introduces a new namespace, the Host 275 Identity namespace. Some ramifications of this new namespace are 276 explained in the HIP architecture description 277 [I-D.ietf-hip-rfc4423-bis]. 279 There are two main representations of the Host Identity, the full 280 Host Identity (HI) and the Host Identity Tag (HIT). The HI is a 281 public key and directly represents the Identity of a host. Since 282 there are different public key algorithms that can be used with 283 different key lengths, the HI, as such, is unsuitable for use as a 284 packet identifier, or as an index into the various state-related 285 implementation structures needed to support HIP. Consequently, a 286 hash of the HI, the Host Identity Tag (HIT), is used as the 287 operational representation. The HIT is 128 bits long and is used in 288 the HIP headers and to index the corresponding state in the end 289 hosts. The HIT has an important security property in that it is 290 self-certifying (see Section 3). 292 1.2. The HIP Base Exchange (BEX) 294 The HIP base exchange is a two-party cryptographic protocol used to 295 establish communications context between hosts. The base exchange is 296 a SIGMA-compliant [KRA03] four-packet exchange. The first party is 297 called the Initiator and the second party the Responder. The 298 protocol exchanges Diffie-Hellman [DIF76] keys in the 2nd and 3rd 299 packets, and authenticates the parties in the 3rd and 4th packets. 300 The four-packet design helps to make HIP DoS resilient. It allows 301 the Responder to stay stateless until the IP address and the 302 cryptographic puzzle is verified. The Responder starts the puzzle 303 exchange in the 2nd packet, with the Initiator completing it in the 304 3rd packet before the Responder stores any state from the exchange. 306 The exchange can use the Diffie-Hellman output to encrypt the Host 307 Identity of the Initiator in the 3rd packet (although Aura, et al., 308 [AUR03] notes that such operation may interfere with packet- 309 inspecting middleboxes), or the Host Identity may instead be sent 310 unencrypted. The Responder's Host Identity is not protected. It 311 should be noted, however, that both the Initiator's and the 312 Responder's HITs are transported as such (in cleartext) in the 313 packets, allowing an eavesdropper with a priori knowledge about the 314 parties to identify them by their HITs. Hence, encrypting the HI of 315 any party does not provide privacy against such attacker. 317 Data packets start to flow after the 4th packet. The 3rd and 4th HIP 318 packets may carry a data payload in the future. However, the details 319 of this may be defined later. 321 An existing HIP association can be updated using the update mechanism 322 defined in this document, and when the association is no longer 323 needed, it can be closed using the defined closing mechanism. 325 Finally, HIP is designed as an end-to-end authentication and key 326 establishment protocol, to be used with Encapsulated Security Payload 327 (ESP) [I-D.ietf-hip-rfc5202-bis] and other end-to-end security 328 protocols. The base protocol does not cover all the fine-grained 329 policy control found in Internet Key Exchange (IKE) [RFC4306] that 330 allows IKE to support complex gateway policies. Thus, HIP is not a 331 complete replacement for IKE. 333 1.3. Memo Structure 335 The rest of this memo is structured as follows. Section 2 defines 336 the central keywords, notation, and terms used throughout the rest of 337 the document. Section 3 defines the structure of the Host Identity 338 and its various representations. Section 4 gives an overview of the 339 HIP base exchange protocol. Sections 5 and 6 define the detailed 340 packet formats and rules for packet processing. Finally, Sections 7, 341 8, and 9 discuss policy, security, and IANA considerations, 342 respectively. 344 2. Terms and Definitions 346 2.1. Requirements Terminology 348 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 349 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 350 document are to be interpreted as described in RFC 2119 [RFC2119]. 352 2.2. Notation 354 [x] indicates that x is optional. 356 {x} indicates that x is encrypted. 358 X(y) indicates that y is a parameter of X. 360 i indicates that x exists i times. 362 --> signifies "Initiator to Responder" communication (requests). 364 <-- signifies "Responder to Initiator" communication (replies). 366 | signifies concatenation of information (e.g., X | Y is the 367 concatenation of X with Y). 369 Ltrunc (H(x), K) denotes the lowest order #K bits of the result of 370 the hash function H on the input x. 372 2.3. Definitions 374 HIP Base Exchange (BEX): the handshake for establishing a new HIP 375 association. 377 Host Identity (HI): The public key of the signature algorithm that 378 represents the identity of the host. In HIP, a host proves its 379 identity by creating a signature with the private key belonging to 380 its HI (c.f. Section 3). 382 Host Identity Tag (HIT): A shorthand for the HI in IPv6 format. It 383 is generated by hashing the HI (c.f. Section 3.1). 385 HIT Suite: A HIT Suite groups all cryptographic algorithms that are 386 required to generate and use an HI and its HIT. In particular, 387 these algorithms are: 1) the public key signature algorithm and 2) 388 the hash function, 3) the truncation (c.f. Appendix E). 390 HIP association: The shared state between two peers after 391 completion of the BEX. 393 Initiator: The host that initiates the BEX. This role is typically 394 forgotten once the BEX is completed. 396 Responder: The host that responds to the Initiator in the BEX. 397 This role is typically forgotten once the BEX is completed. 399 Responder's HIT Hash Algorithm (RHASH): The Hash algorithm used for 400 various hash calculations in this document. The algorithm is the 401 same as is used to generate the Responder's HIT. The RHASH is the 402 hash function defined by the HIT Suite of the Responder's HIT 403 (c.f. Appendix E). 405 Length of the Responder's HIT Hash Algorithm (RHASH_len): The 406 natural output length of RHASH in bits. 408 Signed data: Data that is signed is protected by a digital 409 signature that was created by the sender of the data by using the 410 private key of its HI. 412 KEYMAT: The keying material derived from the Diffie-Hellman key 413 exchange. Symmetric keys for encryption and integrity protection 414 of HIP control and payload packets are drawn from this keying 415 material. 417 3. Host Identity (HI) and its Structure 419 In this section, the properties of the Host Identity and Host 420 Identity Tag are discussed, and the exact format for them is defined. 421 In HIP, the public key of an asymmetric key pair is used as the Host 422 Identity (HI). Correspondingly, the host itself is defined as the 423 entity that holds the private key of the key pair. See the HIP 424 architecture specification [I-D.ietf-hip-rfc4423-bis] for more 425 details on the difference between an identity and the corresponding 426 identifier. 428 HIP implementations MUST support the Rivest Shamir Adelman (RSA) 429 [RFC3110] public key algorithm, and SHOULD support the Digital 430 Signature Algorithm (DSA) [RFC2536] algorithms, and Elliptic Curve 431 Digital Signature Algorithm (ECDSA) for generating the HI as defined 432 in Section 5.2.8. Additional algorithms MAY be supported. 434 A hashed encoding of the HI, the Host Identity Tag (HIT), is used in 435 protocols to represent the Host Identity. The HIT is 128 bits long 436 and has the following three key properties: i) it is the same length 437 as an IPv6 address and can be used in fixed address-sized fields in 438 APIs and protocols, ii) it is self-certifying (i.e., given a HIT, it 439 is computationally hard to find a Host Identity key that matches the 440 HIT), and iii) the probability of a HIT collision between two hosts 441 is very low, hence, it is infeasible for an attacker to find a 442 collision with a HIT that is in use. For details on the security 443 properties of the HIT see [I-D.ietf-hip-rfc4423-bis]. 445 The structure of the HIT is defined in [I-D.ietf-hip-rfc4843-bis]. 446 The HIT is an Overlay Routable Cryptographic Hash Identifier (ORCHID) 447 and consists of three parts: first, an IANA assigned prefix to 448 distinguish it from other IPv6 addresses. Second, a four-bit 449 encoding of the algorithms that were used for generating the HI and 450 the hashed representation of HI. Third, a 96-bit hashed 451 representation of the Host Identity. The encoding of the ORCHID 452 generation algorithm and the exact algorithm for generating the 453 hashed representation is specified in Appendix E. 455 Carrying HIs and HITs in the header of user data packets would 456 increase the overhead of packets. Thus, it is not expected that they 457 are carried in every packet, but other methods are used to map the 458 data packets to the corresponding HIs. In some cases, this makes it 459 possible to use HIP without any additional headers in the user data 460 packets. For example, if ESP is used to protect data traffic, the 461 Security Parameter Index (SPI) carried in the ESP header can be used 462 to map the encrypted data packet to the correct HIP association. 464 3.1. Host Identity Tag (HIT) 466 The Host Identity Tag is a 128-bit value -- a hashed encoding of the 467 Host Identifier. There are two advantages of using a hashed encoding 468 over the actual variable-sized Host Identity public key in protocols. 469 First, the fixed length of the HIT keeps packet sizes manageable and 470 eases protocol coding. Second, it presents a consistent format for 471 the protocol, independent of the underlying identity technology in 472 use. 474 RFC 4843-bis [I-D.ietf-hip-rfc4843-bis] specifies 128-bit hash-based 475 identifiers, called Overlay Routable Cryptographic Hash Identifiers, 476 ORCHIDs. Their prefix, allocated from the IPv6 address block, is 477 defined in [I-D.ietf-hip-rfc4843-bis]. The Host Identity Tag is one 478 type of an ORCHID. 480 This document extends the original, experimental HIP specification 481 [RFC5201] with measures to support crypto agility. One of these 482 measures is to allow different hash functions for creating a HIT. 483 HIT Suites group the sets of algorithms that are required to generate 484 and use a particular HIT. The Suites are encoded in HIT Suite IDs. 485 These HIT Suite IDs are transmitted in the ORCHID Generation 486 Algorithm (OGA) field in the ORCHID. With the HIT Suite ID in the 487 OGA field, a hosts can tell from another host's HIT, whether it 488 supports the necessary hash and signature algorithms to establish a 489 HIP association with that host. 491 3.2. Generating a HIT from an HI 493 The HIT MUST be generated according to the ORCHID generation method 494 described in [I-D.ietf-hip-rfc4843-bis] using a context ID value of 495 0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA (this tag value has been 496 generated randomly by the editor of this specification), and an input 497 that encodes the Host Identity field (see Section 5.2.8) present in a 498 HIP payload packet. The set of hash function, signature algorithm, 499 and the algorithm used for generating the HIT from the HI depends on 500 the HIT Suite (see Appendix E) and is indicated by the four bits of 501 the ORCHID Generation Algorithm (OGA) field in the ORCHID. 502 Currently, truncated SHA-1 and truncated SHA-256 [FIPS.180-2.2002] 503 are defined as hashes for generating a HIT. 505 For identities that are either RSA, Digital Signature Algorithm 506 (DSA), or Elliptic Curve DSA (ECDSA) public keys, the ORCHID input 507 consists of the public key encoding as specified in Section 5.2.8. 508 This document defines four algorithm profiles: RSA, DSA, ECDSA, and 509 ECDSA_LOW. The ECDSA_LOW profile is meant for devices with low 510 computational capabilities. There are currently only three defined 511 public key algorithm classes: RSA/SHA-1, DSA, and ECDSA. Hence, 512 either of the following applies: 514 The RSA public key is encoded as defined in [RFC3110] Section 2, 515 taking the exponent length (e_len), exponent (e), and modulus (n) 516 fields concatenated. The length (n_len) of the modulus (n) can be 517 determined from the total HI Length and the preceding HI fields 518 including the exponent (e). Thus, the data that serves as input 519 for the HIT generation has the same length as the HI. The fields 520 MUST be encoded in network byte order, as defined in [RFC3110]. 522 The DSA public key is encoded as defined in [RFC2536] Section 2, 523 taking the fields T, Q, P, G, and Y, concatenated as input. Thus, 524 the data to be hashed is 1 + 20 + 3 * 64 + 3 * 8 * T octets long, 525 where T is the size parameter as defined in [RFC2536]. The size 526 parameter T, affecting the field lengths, MUST be selected as the 527 minimum value that is long enough to accommodate P, G, and Y. The 528 fields MUST be encoded in network byte order, as defined in 529 [RFC2536]. 531 The ECDSA public keys are encoded as defined in [RFC6090] Section 532 4.2 and 6. 534 In Appendix B, the public key encoding process is illustrated using 535 pseudo-code. 537 4. Protocol Overview 539 This section is a simplified overview of the HIP protocol operation, 540 and does not contain all the details of the packet formats or the 541 packet processing steps. Sections 5 and 6 describe in more detail 542 the packet formats and packet processing steps, respectively, and are 543 normative in case of any conflicts with this section. 545 The protocol number 139 has been assigned by IANA to the Host 546 Identity Protocol. 548 The HIP payload (Section 5.1) header could be carried in every IP 549 datagram. However, since HIP headers are relatively large (40 550 bytes), it is desirable to 'compress' the HIP header so that the HIP 551 header only occurs in control packets used to establish or change HIP 552 association state. The actual method for header 'compression' and 553 for matching data packets with existing HIP associations (if any) is 554 defined in separate documents, describing transport formats and 555 methods. All HIP implementations MUST implement, at minimum, the ESP 556 transport format for HIP [I-D.ietf-hip-rfc5202-bis]. 558 4.1. Creating a HIP Association 560 By definition, the system initiating a HIP base exchange is the 561 Initiator, and the peer is the Responder. This distinction is 562 typically forgotten once the base exchange completes, and either 563 party can become the Initiator in future communications. 565 The HIP base exchange serves to manage the establishment of state 566 between an Initiator and a Responder. The first packet, I1, 567 initiates the exchange, and the last three packets, R1, I2, and R2, 568 constitute an authenticated Diffie-Hellman [DIF76] key exchange for 569 session-key generation. In the first two packets, the hosts agree on 570 a set of cryptographic identifiers and algorithms that are then used 571 in and after the exchange. During the Diffie-Hellman key exchange, a 572 piece of keying material is generated. The HIP association keys are 573 drawn from this keying material. If other cryptographic keys are 574 needed, e.g., to be used with ESP, they are expected to be drawn from 575 the same keying material. 577 The Initiator first sends a trigger packet, I1, to the Responder. 578 The packet contains the HIT of the Initiator and possibly the HIT of 579 the Responder, if it is known. Moreover, the I1 packet initializes 580 the negotiation of the Diffie-Hellman group that is used for 581 generating the keying material. Therefore, the I1 packet contains a 582 list of Diffie Hellman Group IDs supported by the Initiator. Note 583 that in some cases it may be possible to replace this trigger packet 584 by some other form of a trigger, in which case the protocol starts 585 with the Responder sending the R1 packet. In such cases, another 586 mechanism to convey the Initiator's supported DH Groups (e.g., by 587 using a default group) must be specified. 589 The second packet, R1, starts the actual authenticated Diffie-Hellman 590 exchange. It contains a puzzle -- a cryptographic challenge that the 591 Initiator must solve before continuing the exchange. The level of 592 difficulty of the puzzle can be adjusted based on level of trust with 593 the Initiator, current load, or other factors. In addition, the R1 594 contains the Responder's Diffie-Hellman parameter and lists of 595 cryptographic algorithms supported by the Responder. Based on these 596 lists, the Initiator can continue, abort, or restart the base 597 exchange with a different selection of cryptographic algorithms. 598 Also, the R1 packet contains a signature that covers selected parts 599 of the message. Some fields are left outside the signature to 600 support pre-created R1s. 602 In the I2 packet, the Initiator MUST display the solution to the 603 received puzzle. Without a correct solution, the I2 message is 604 discarded. The I2 packet also contains a Diffie-Hellman parameter 605 that carries needed information for the Responder. The I2 packet is 606 signed by the Initiator. 608 The R2 packet acknowledges the receipt of the I2 packet and completes 609 the base exchange. The packet is signed by the Responder. 611 The base exchange is illustrated below in Figure 1. The term "key" 612 refers to the Host Identity public key, and "sig" represents a 613 signature using such a key. The packets contain other parameters not 614 shown in this figure. 616 Initiator Responder 618 I1: DH list 619 --------------------------> 620 select precomputed R1 621 R1: puzzle, DH, key, sig 622 <------------------------- 623 check sig remain stateless 624 solve puzzle 625 I2: solution, DH, {key}, sig 626 --------------------------> 627 compute DH check puzzle 628 check sig 629 R2: sig 630 <-------------------------- 631 check sig compute DH 633 Figure 1 635 4.1.1. HIP Puzzle Mechanism 637 The purpose of the HIP puzzle mechanism is to protect the Responder 638 from a number of denial-of-service threats. It allows the Responder 639 to delay state creation until receiving the I2 packet. Furthermore, 640 the puzzle allows the Responder to use a fairly cheap calculation to 641 check that the Initiator is "sincere" in the sense that it has 642 churned enough CPU cycles in solving the puzzle. 644 The puzzle allows a Responder implementation to completely delay 645 session-specific state creation until a valid I2 packet is received. 646 An I2 packet without valid puzzle solution can be rejected 647 immediately once the Responder has checked the solution by computing 648 only one hash function before state is created and CPU-intensive 649 public-key signature verification and Diffie-Hellman key generation 650 are performed. By varying the difficulty of the puzzle, the 651 Responder can frustrate CPU or memory targeted DoS attacks. 653 The Responder can remain stateless and drop most spoofed I2 packets 654 because puzzle calculation is based on the Initiator's Host Identity 655 Tag. The idea is that the Responder has a (perhaps varying) number of 656 pre-calculated R1 packets, and it selects one of these based on the 657 information carried in the I1 packet. When the Responder then later 658 receives the I2 packet, it can verify that the puzzle has been solved 659 using the Initiator's HIT. This makes it impractical for the 660 attacker to first exchange one I1/R1 packet, and then generate a 661 large number of spoofed I2 packets that seemingly come from different 662 HITs. This method does not protect the Responder from an attacker 663 that uses fixed HITs, though. Against such an attacker, a viable 664 approach may be to create a piece of local state, and remember that 665 the puzzle check has previously failed. See Appendix A for one 666 possible implementation. Responder implementations SHOULD include 667 sufficient randomness in the puzzle values so that algorithmic 668 complexity attacks become impossible [CRO03]. 670 The Responder can set the puzzle difficulty for the Initiator, based 671 on its level of trust of the Initiator. Because the puzzle is not 672 included in the signature calculation, the Responder can use pre- 673 calculated R1 packets and include the puzzle just before sending the 674 R1 to the Initiator. The Responder SHOULD use heuristics to 675 determine when it is under a denial-of-service attack, and set the 676 puzzle difficulty value #K appropriately as explained later. 678 4.1.2. Puzzle Exchange 680 The Responder starts the puzzle exchange when it receives an I1 681 packet. The Responder supplies a random number #I, and requires the 682 Initiator to find a number J. To select a proper #J, the Initiator 683 must create the concatenation of #I, the HITs of the parties, and #J, 684 and calculate a hash over this concatenation using the RHASH 685 algorithm. The lowest order #K bits of the result MUST be zeros. 686 The value #K sets the difficulty of the puzzle. 688 To generate a proper number #J, the Initiator will have to generate a 689 number of Js until one produces the hash target of zeros. The 690 Initiator SHOULD give up after exceeding the puzzle Lifetime in the 691 PUZZLE parameter (as described in Section 5.2.4). The Responder 692 needs to re-create the concatenation of #I, the HITs, and the 693 provided #J, and compute the hash once to prove that the Initiator 694 completed its assigned task. 696 To prevent precomputation attacks, the Responder MUST select the 697 number #I in such a way that the Initiator cannot guess it. 698 Furthermore, the construction MUST allow the Responder to verify that 699 the value #I was indeed selected by it and not by the Initiator. See 700 Appendix A for an example on how to implement this. 702 Using the Opaque data field in the PUZZLE (see Section 5.2.4), in an 703 ECHO_REQUEST_SIGNED (see Section 5.2.19) or in an 704 ECHO_REQUEST_UNSIGNED parameter (see Section 5.2.20), the Responder 705 can include some data in R1 that the Initiator MUST copy unmodified 706 in the corresponding I2 packet. The Responder can use the opaque 707 data to transfer a piece of local state information to the Initiator 708 and back, for example to recognize that the I2 is a response to a 709 previously sent R1. The Responder can generate the Opaque data in 710 various ways; e.g., using encryption or hashing with some secret, the 711 sent #I, and possibly using other related data. With the same 712 secret, the received #I (from the I2 packet), and the other related 713 data (if any), the Responder can verify that it has itself sent the 714 #I to the Initiator. The Responder MUST periodically change such a 715 secret. 717 It is RECOMMENDED that the Responder generates new secrets for the 718 puzzle and new R1s once every few minutes. Furthermore, it is 719 RECOMMENDED that the Responder is able to verify valid puzzle 720 solution at least Lifetime seconds after the puzzle secret has been 721 deprecated. This time value guarantees that the puzzle is valid for 722 at least Lifetime and at most 2 * Lifetime seconds. This limits the 723 usability that an old, solved puzzle has to an attacker. Moreover, 724 it avoids problems with the validity of puzzles if the lifetime is 725 relatively short compared to the network delay and the time for 726 solving the puzzle. 728 The puzzle value #I and the solution #J are inputs for deriving the 729 keying material from the Diffie-Hellman key exchange (see 730 Section 6.5). Therefore, a Responder SHOULD NOT use the same puzzle 731 #I with the same DH keys for the same Initiator twice to ensure that 732 the derived keying material differs. Such uniqueness can be 733 achieved, for example, by using a counter as an additional input for 734 generating #I. This counter can be increased for each processed I1 735 packet. The state of the counter can be transmitted in the Opaque 736 data field in the PUZZLE (see Section 5.2.4), in an 737 ECHO_REQUEST_SIGNED (see Section 5.2.19) or in an 738 ECHO_REQUEST_UNSIGNED parameter (see Section 5.2.20) without the need 739 to establish state. 741 NOTE: The protocol developers explicitly considered whether R1 should 742 include a timestamp in order to protect the Initiator from replay 743 attacks. The decision was to NOT include a timestamp to avoid 744 problems with global time synchronization. 746 NOTE: The protocol developers explicitly considered whether a memory 747 bound function should be used for the puzzle instead of a CPU-bound 748 function. The decision was not to use memory-bound functions. 750 4.1.3. Authenticated Diffie-Hellman Protocol with DH Group Negotiation 752 The packets R1, I2, and R2 implement a standard authenticated Diffie- 753 Hellman exchange. The Responder sends one of its public Diffie- 754 Hellman keys and its public authentication key, i.e., its Host 755 Identity, in R1. The signature in the R1 packet allows the Initiator 756 to verify that the R1 has been once generated by the Responder. 757 However, since the R1 is precomputed and therefore does not cover 758 association-specific information in the I1 packet, it does not 759 protect from replay attacks. 761 Before the actual authenticated Diffie-Hellman exchange, the 762 Initiator expresses its preference regarding its choice of the DH 763 groups in the I1 packet. The preference is expressed as a sorted 764 list of DH Group IDs. The I1 packet is not protected by a signature. 765 Therefore, this list is sent in an unauthenticated way to avoid 766 costly computations for processing the I1 packet at the Responder 767 side. Based on the preferences of the Initiator, the Responder sends 768 an R1 packet containing its most suitable public DH value. The 769 Responder also attaches a list of its own preferences to the R1 to 770 convey the basis for the DH group selection to the Initiator. This 771 list is carried in the signed part of the R1 packet. If the choice 772 of the DH group value in the R1 does not match the preferences of the 773 Initiator and the Responder, the Initiator can detect that the list 774 of DH Group IDs in the I1 was manipulated (see below for details). 776 If none of the DH Group IDs in the I1 packet is supported by the 777 Responder, the Responder selects the DH Group most suitable for it 778 regardless of the Initiator's preference. It then sends the R1 779 containing this DH Group and its list of supported DH Group IDs to 780 the Initiator. 782 When the Initiator receives an R1, it receives one of the Responder's 783 public Diffie-Hellman values and the list of DH Group IDs supported 784 by the Responder. This list is covered by the signature in the R1 785 packet to avoid forgery. The Initiator compares the Group ID of the 786 public DH value in the R1 packet to the list of supported DH Group 787 IDs in the R1 packets and to its own preferences expressed in the 788 list of supported DH Group IDs. The Initiator continues the BEX only 789 if the Group ID of the public DH value of the Responder is the most 790 preferred of the IDs supported by both the Initiator and Responder. 791 Otherwise, the communication is subject of a downgrade attack and the 792 Initiator MUST either restart the base exchange with a new I1 packet 793 or abort the base exchange. If the Responder's choice of the DH 794 Group is not supported by the Initiator, the Initiator MAY abort the 795 handshake or send a new I1 packet with a different list of supported 796 DH Groups. However, the Initiator MUST verify the signature of the 797 R1 packet before restarting or aborting the handshake. It MUST 798 silently ignore the R1 packet if the signature is not valid. 800 If the preferences regarding the DH Group ID match, the Initiator 801 computes the Diffie-Hellman session key (Kij). The Initiator creates 802 a HIP association using keying material from the session key (see 803 Section 6.5), and may use the HIP association to encrypt its public 804 authentication key, i.e., the Host Identity. The resulting I2 packet 805 contains the Initiator's Diffie-Hellman key and its (optionally 806 encrypted) public authentication key. The signature of the I2 807 message covers all parameters of the signed parameter ranges (see 808 Section 5.2) in the packet without exceptions as in the R1. 810 The Responder extracts the Initiator's Diffie-Hellman public key from 811 the I2 packet, computes the Diffie-Hellman session key, creates a 812 corresponding HIP association, and decrypts the Initiator's public 813 authentication key. It can then verify the signature using the 814 authentication key. 816 The final message, R2, completes the BEX and protects the Initiator 817 against replay attacks because the Responder uses the shared key from 818 the Diffie-Hellman exchange to create an HMAC as well as uses the 819 private key of its Host Identity to sign the packet contents. 821 4.1.4. HIP Replay Protection 823 The HIP protocol includes the following mechanisms to protect against 824 malicious packet replays. Responders are protected against replays 825 of I1 packets by virtue of the stateless response to I1 packets with 826 pre-signed R1 messages. Initiators are protected against R1 replays 827 by a monotonically increasing "R1 generation counter" included in the 828 R1. Responders are protected against replays of forged I2 packets by 829 the puzzle mechanism (see Section 4.1.1 above), and optional use of 830 opaque data. Hosts are protected against replays of R2 packets and 831 UPDATEs by use of a less expensive HMAC verification preceding the 832 HIP signature verification. 834 The R1 generation counter is a monotonically increasing 64-bit 835 counter that may be initialized to any value. The scope of the 836 counter MAY be system-wide but there SHOULD be a separate counter for 837 each Host Identity, if there is more than one local host identity. 838 The value of this counter SHOULD be preserved across system reboots 839 and invocations of the HIP base exchange. This counter indicates the 840 current generation of puzzles. Implementations MUST accept puzzles 841 from the current generation and MAY accept puzzles from earlier 842 generations. A system's local counter MUST be incremented at least 843 as often as every time old R1s cease to be valid. The local counter 844 SHOULD never be decremented, otherwise the host exposes its peers to 845 the replay of previously generated, higher numbered R1s. The R1 846 counter SHOULD NOT roll over. 848 A host may receive more than one R1, either due to sending multiple 849 I1 packets (see Section 6.6.1) or due to a replay of an old R1. When 850 sending multiple I1 packets to the same host, an Initiator SHOULD 851 wait for a small amount of time (a reasonable time may be 2 * 852 expected RTT) after the first R1 reception to allow possibly multiple 853 R1s to arrive, and it SHOULD respond to an R1 among the set with the 854 largest R1 generation counter. If an Initiator is processing an R1 855 or has already sent an I2 packet (still waiting for the R2 packet) 856 and it receives another R1 with a larger R1 generation counter, it 857 MAY elect to restart R1 processing with the fresher R1, as if it were 858 the first R1 to arrive. 860 Upon conclusion of an active HIP association with another host, the 861 R1 generation counter associated with the peer host SHOULD be 862 flushed. A local policy MAY override the default flushing of R1 863 counters on a per-HIT basis. The reason for recommending the 864 flushing of this counter is that there may be hosts where the R1 865 generation counter (occasionally) decreases; e.g., due to hardware 866 failure. 868 4.1.5. Refusing a HIP Base Exchange 870 A HIP-aware host may choose not to accept a HIP base exchange. If 871 the host's policy is to only be an Initiator, it should begin its own 872 HIP base exchange. A host MAY choose to have such a policy since 873 only the privacy of the Initiator's HI is protected in the exchange. 874 It should be noted that such behavior can introduce the risk of a 875 race condition if each host's policy is to only be an Initiator, at 876 which point the HIP base exchange will fail. 878 If the host's policy does not permit it to enter into a HIP exchange 879 with the Initiator, it should send an ICMP 'Destination Unreachable, 880 Administratively Prohibited' message. A more complex HIP packet is 881 not used here as it actually opens up more potential DoS attacks than 882 a simple ICMP message. A HIP NOTIFY message is not used because no 883 HIP session exists between the two hosts at that time. 885 4.1.6. Aborting a HIP Base Exchange 887 Two HIP hosts may encounter situations in which they cannot complete 888 a HIP base exchange because of insufficient support for cryptographic 889 algorithms, in particular the HIT Suites and DH Groups. After 890 receiving the R1 packet, the Initiator can determine whether the 891 Responder supports the required cryptographic operations to 892 successfully establish a HIP association. The Initiator can abort 893 the BEX silently after receiving an R1 packet that indicates an 894 unsupported set of algorithms. The specific conditions are described 895 below. 897 The R1 packet contains a signed list of HIT Suite IDs as supported by 898 the Responder. Therefore, the Initiator can determine whether its 899 source HIT is supported by the Responder. If the HIT Suite ID of the 900 Initiator's HIT is not contained in the list of HIT Suites in the R1, 901 the Initiator MAY abort the handshake silently or MAY restart the 902 handshake with a new I1 packet that contains a source HIT supported 903 by the Responder. 905 During the Handshake, the Initiator and the Responder agree on a 906 single DH Group. The Responder selects the DH Group and its DH 907 public value in the R1 based on the list of DH Suite IDs in the I1 908 packet. If the responder supports none of the DH Groups requested by 909 the Initiator, the Responder selects an arbitrary DH and replies with 910 an R1 containing its list of supported DH Group IDs. In such case, 911 the Initiator receives an R1 packet containing the DH public value 912 for an unrequested DH Group and also the Responder's DH Group list in 913 the signed part of the R1 packet. At this point, the Initiator MAY 914 abort the handshake or MAY restart the handshake by sending a new I1 915 packet containing a selection of DH Group IDs that is supported by 916 the Responder. 918 4.1.7. HIP Downgrade Protection 920 In a downgrade attack, an attacker attempts to unnoticeably 921 manipulate the packets of an Initiator and/or a Responder to 922 influence the result of the cryptographic negotiations in the BEX to 923 its favor. As a result, the victims select weaker cryptographic 924 algorithms than they would otherwise have selected without the 925 attacker's interference. Downgrade attacks can only be successful if 926 they remain un-detected by the victims and the victims falsely assume 927 a secure communication channel. 929 In HIP, almost all packet parameters related to cryptographic 930 negotiations are covered by signatures. These parameters cannot be 931 directly manipulated in a downgrade attack without invalidating the 932 signature. However, signed packets can be subject to replay attacks. 934 In such a replay attack, the attacker could use an old BEX packet 935 with an outdated and weak selection of cryptographic algorithms and 936 replay it instead of a more recent packet with a collection of 937 stronger cryptographic algorithms. Signed packets that could be 938 subject to this replay attack are the R1 and I2 packet. However, 939 replayed R1 and I2 packets cannot be used to successfully establish a 940 HIP BEX because these packets also contain the public DH values of 941 the Initiator and the Responder. Old DH values from replayed packets 942 lead to invalid keying material and mismatching shared secrets 943 because the attacker is unable to derive valid keying material from 944 the DH public keys in the R1 and cannot generate a valid HMAC and 945 signature for a replayed I2. 947 In contrast to the first version of HIP [RFC5201],the version 2 of 948 HIP defined in this document begins the negotiation of the DH Groups 949 already in the first BEX packet, the I1. The I1 packet is, by 950 intention, not protected by a signature to avoid CPU-intensive 951 cryptographic operations for processing floods of I1 packets targeted 952 at the Responder. Hence, the list of DH Group IDs in the I1 packet 953 is vulnerable to forgery and manipulation. To thwart an unnoticed 954 manipulation of the I1 packet, the Responder chooses the DH Group 955 deterministically and includes its own list of DH Group IDs in the 956 signed part of the R1 packet. The Initiator can detect an attempted 957 downgrade attack by comparing the list of DH Group IDs in the R1 958 packet to its own preferences in the I1 packet. If the choice of the 959 DH Group in the R1 packet does not equal to the best match of the two 960 lists (the highest priority DH ID of the Responder that is present in 961 the Initiator's DH list), the Initiator can conclude that its list in 962 the I1 packet was altered by an attacker. In this case, the 963 Initiator can restart or abort the BEX. As mentioned before, the 964 detection of the downgrade attack is sufficient to prevent it. 966 4.1.8. HIP Opportunistic Mode 968 It is possible to initiate a HIP BEX even if the Responder's HI (and 969 HIT) is unknown. In this case, the initial I1 packet contains all 970 zeros as the destination HIT. This kind of connection setup is 971 called opportunistic mode. 973 The Responder may have multiple HITs due to multiple supported HIT 974 Suites. Since the Responder's HIT Suite in the opportunistic mode is 975 not determined by the destination HIT of the I1 packet, the Responder 976 can freely select a HIT of any HIT Suite. The complete set of HIT 977 Suites supported by the Initiator is not known to the Responder. 978 Therefore, the Responder SHOULD should select its HIT from the same 979 HIT Suite as the Initiator's HIT (indicated by the HIT suite 980 information in the OGA field of the Initiator's HIT) because this HIT 981 Suite is obviously supported by the Initiator. If the Responder 982 selects a different HIT that is not supported by the Initiator, the 983 Initiator MAY restart the BEX with an I1 packet with a source HIT 984 that is contained in the list of the Responder's HIT Suites in the R1 985 packet. 987 Note that the Initiator cannot verify the signature of the R1 packet 988 if the Responder's HIT Suite is not supported. Therefore, the 989 Initiator MUST treat R1 packets with unsupported Responder HITs as 990 potentially forged and MUST NOT use any parameters from the 991 unverified R1 besides the HIT Suite List. Moreover, an Initiator 992 that uses an unverified HIT Suite List from an R1 packet to determine 993 a possible source HIT MUST verify that the HIT_SUITE_LIST in the 994 first unverified R1 packet matches the HIT_SUITE_LIST in the second 995 R1 packet for which the Initiator supports the signature algorithm. 996 The Initiator MUST restart the BEX with a new I1 packet for which the 997 algorithm was mentioned in the verifiable R1 if the two lists do not 998 match. This procedure is necessary to mitigate downgrade attacks. 1000 There are both security and API issues involved with the 1001 opportunistic mode. These issues are described in the reminder of 1002 this section. 1004 Given that the Responder's HI is not known by the Initiator, there 1005 must be suitable API calls that allow the Initiator to request, 1006 directly or indirectly, that the underlying system initiates the HIP 1007 base exchange solely based on locators. The Responder's HI will be 1008 tentatively available in the R1 packet, and in an authenticated form 1009 once the R2 packet has been received and verified. Hence, the 1010 Responder's HIT could be communicated to the application via new API 1011 mechanisms. However, with a backwards-compatible API the application 1012 sees only the locators used for the initial contact. Depending on 1013 the desired semantics of the API, this can raise the following 1014 issues: 1016 o The actual locators may later change if an UPDATE message is used, 1017 even if from the API perspective the session still appears to be 1018 between two specific locators. However, the locator update is 1019 still secure and the session is still between the same nodes. 1021 o Different sessions between the same two locators may result in 1022 connections to different nodes, if the implementation no longer 1023 remembers which identifier the peer had in an earlier session. 1024 This is possible when the peer's locator has changed for 1025 legitimate reasons or when an attacker pretends to be a node that 1026 has the peer's locator. Therefore, when using opportunistic mode, 1027 HIP implementations MUST NOT place any expectation that the peer's 1028 HI returned in the R1 message matches any HI previously seen from 1029 that address. 1031 If the HIP implementation and application do not have the same 1032 understanding of what constitutes a session, this may even happen 1033 within the same session. For instance, an implementation may not 1034 know when HIP state can be purged for UDP-based applications. 1036 o As with all HIP base exchanges, the handling of locator-based or 1037 interface-based policy is unclear for HIP in opportunistic mode. 1038 An application may create a connection to a specific locator 1039 because the application has knowledge of the security properties 1040 along the network to that locator. If one of the nodes moves and 1041 the locators are updated, these security properties may not be 1042 maintained. Depending on the security policy of the application, 1043 this may be a problem. This is an area of ongoing study. As an 1044 example, there is work to create an API that applications can use 1045 to specify their security requirements in a similar context 1046 [I-D.ietf-btns-c-api]. 1048 In addition, the following security considerations apply. The 1049 generation counter mechanism will be less efficient in protecting 1050 against replays of the R1 packet, given that the Responder can choose 1051 a replay that uses an arbitrary HI, not just the one given in the I1 1052 packet. 1054 More importantly, the opportunistic exchange is vulnerable to man-in- 1055 the-middle attacks, because the Initiator does not have any public 1056 key information about the peer. To assess the impacts of this 1057 vulnerability, we compare it to vulnerabilities in current, non-HIP- 1058 capable communications. 1060 An attacker on the path between the two peers can insert itself as a 1061 man-in-the-middle by providing its own identifier to the Initiator 1062 and then initiating another HIP session towards the Responder. For 1063 this to be possible, the Initiator must employ opportunistic mode, 1064 and the Responder must be configured to accept a connection from any 1065 HIP-enabled node. 1067 An attacker outside the path will be unable to do so, given that it 1068 cannot respond to the messages in the base exchange. 1070 These security properties are characteristic also of communications 1071 in the current Internet. A client contacting a server without 1072 employing end-to-end security may find itself talking to the server 1073 via a man-in-the-middle, assuming again that the server is willing to 1074 talk to anyone. 1076 If end-to-end security is in place, then the worst that can happen in 1077 both the opportunistic HIP and non-HIP (normal IP) cases is denial- 1078 of-service; an entity on the path can disrupt communications, but 1079 will be unable to successfully insert itself as a man-in-the-middle. 1081 However, once the opportunistic exchange has successfully completed, 1082 HIP provides confidentiality and integrity protection for the 1083 communications, and can securely change the locators of the 1084 endpoints. 1086 As a result, it is believed that the HIP opportunistic mode is at 1087 least as secure as current IP. 1089 4.2. Updating a HIP Association 1091 A HIP association between two hosts may need to be updated over time. 1092 Examples include the need to rekey expiring security associations, 1093 add new security associations, or change IP addresses associated with 1094 hosts. The UPDATE packet is used for those and other similar 1095 purposes. This document only specifies the UPDATE packet format and 1096 basic processing rules, with mandatory parameters. The actual usage 1097 is defined in separate specifications. 1099 HIP provides a general purpose UPDATE packet, which can carry 1100 multiple HIP parameters, for updating the HIP state between two 1101 peers. The UPDATE mechanism has the following properties: 1103 UPDATE messages carry a monotonically increasing sequence number 1104 and are explicitly acknowledged by the peer. Lost UPDATEs or 1105 acknowledgments may be recovered via retransmission. Multiple 1106 UPDATE messages may be outstanding under certain circumstances. 1108 UPDATE is protected by both HIP_MAC and HIP_SIGNATURE parameters, 1109 since processing UPDATE signatures alone is a potential DoS attack 1110 against intermediate systems. 1112 UPDATE packets are explicitly acknowledged by the use of an 1113 acknowledgment parameter that echoes an individual sequence number 1114 received from the peer. A single UPDATE packet may contain both a 1115 sequence number and one or more acknowledgment numbers (i.e., 1116 piggybacked acknowledgment(s) for the peer's UPDATE). 1118 The UPDATE packet is defined in Section 5.3.5. 1120 4.3. Error Processing 1122 HIP error processing behavior depends on whether or not there exists 1123 an active HIP association. In general, if a HIP association exists 1124 between the sender and receiver of a packet causing an error 1125 condition, the receiver SHOULD respond with a NOTIFY packet. On the 1126 other hand, if there are no existing HIP associations between the 1127 sender and receiver, or the receiver cannot reasonably determine the 1128 identity of the sender, the receiver MAY respond with a suitable ICMP 1129 message; see Section 5.4 for more details. 1131 The HIP protocol and state machine are designed to recover from one 1132 of the parties crashing and losing its state. The following 1133 scenarios describe the main use cases covered by the design. 1135 No prior state between the two systems. 1137 The system with data to send is the Initiator. The process 1138 follows the standard four-packet base exchange, establishing 1139 the HIP association. 1141 The system with data to send has no state with the receiver, but 1142 the receiver has a residual HIP association. 1144 The system with data to send is the Initiator. The Initiator 1145 acts as in no prior state, sending an I1 packet and receiving 1146 an R1 packet. When the Responder receives a valid I2 packet, 1147 the old association is 'discovered' and deleted, and the new 1148 association is established. 1150 The system with data to send has a HIP association, but the 1151 receiver does not. 1153 The system sends data on the outbound user data security 1154 association. The receiver 'detects' the situation when it 1155 receives a user data packet that it cannot match to any HIP 1156 association. The receiving host MUST discard this packet. 1158 Optionally, the receiving host MAY send an ICMP packet, with 1159 the type Parameter Problem, to inform the sender that the HIP 1160 association does not exist (see Section 5.4), and it MAY 1161 initiate a new HIP BEX. However, responding with these 1162 optional mechanisms is implementation or policy dependent. 1164 4.4. HIP State Machine 1166 The HIP protocol itself has little state. In the HIP base exchange, 1167 there is an Initiator and a Responder. Once the security 1168 associations (SAs) are established, this distinction is lost. If the 1169 HIP state needs to be re-established, the controlling parameters are 1170 which peer still has state and which has a datagram to send to its 1171 peer. The following state machine attempts to capture these 1172 processes. 1174 The state machine is symmetric and is presented in a single system 1175 view, representing either an Initiator or a Responder. The state 1176 machine is not a full representation of the processing logic. 1177 Additional processing rules are presented in the packet definitions. 1178 Hence, both are needed to completely implement HIP. 1180 This document extends the state machine as defined in [RFC5201] and 1181 introduces a restart option to allow for the negotiation of 1182 cryptographic algorithms. The extension to the previous state 1183 machine in [RFC5201] is a transition from state I1-SENT to I1-SENT - 1184 the restart option. An Initiator is required to restart the HIP base 1185 exchange if the Responder does not support the HIT Suite of the 1186 Initiator. In this case, the Initiator restarts the HIP base 1187 exchange by sending a new I1 packet with a source HIT supported by 1188 the Responder. 1190 Implementors must understand that the state machine, as described 1191 here, is informational. Specific implementations are free to 1192 implement the actual processing logic differently. Section 6 1193 describes the packet processing rules in more detail. This state 1194 machine focuses on the HIP I1, R1, I2, and R2 packets only. New 1195 states and state transitions may be introduced by mechanisms in other 1196 specifications (such as mobility and multihoming). 1198 4.4.1. State Machine Terminology 1200 Unused Association Lifetime (UAL): Implementation-specific time for 1201 which, if no packet is sent or received for this time interval, a 1202 host MAY begin to tear down an active HIP association. 1204 Maximum Segment Lifetime (MSL): Maximum time that a TCP segment is 1205 expected to spend in the network. 1207 Exchange Complete (EC): Time that the host spends at the R2-SENT 1208 state before it moves to the ESTABLISHED state. The time is n * 1209 I2 retransmission timeout, where n is about I2_RETRIES_MAX. 1211 Receive ANYOTHER: Any received packet for which no state 1212 transitions or processing rules are defined for a given state. 1214 4.4.2. HIP States 1216 +---------------------+---------------------------------------------+ 1217 | State | Explanation | 1218 +---------------------+---------------------------------------------+ 1219 | UNASSOCIATED | State machine start | 1220 | | | 1221 | I1-SENT | Initiating base exchange | 1222 | | | 1223 | I2-SENT | Waiting to complete base exchange | 1224 | | | 1225 | R2-SENT | Waiting to complete base exchange | 1226 | | | 1227 | ESTABLISHED | HIP association established | 1228 | | | 1229 | CLOSING | HIP association closing, no data can be | 1230 | | sent | 1231 | | | 1232 | CLOSED | HIP association closed, no data can be sent | 1233 | | | 1234 | E-FAILED | HIP base exchange failed | 1235 +---------------------+---------------------------------------------+ 1237 Table 1: HIP States 1239 4.4.3. HIP State Processes 1241 System behavior in state UNASSOCIATED, Table 2. 1243 +---------------------+---------------------------------------------+ 1244 | Trigger | Action | 1245 +---------------------+---------------------------------------------+ 1246 | User data to send, | Send I1 and go to I1-SENT | 1247 | requiring a new HIP | | 1248 | association | | 1249 | | | 1250 | Receive I1 | Send R1 and stay at UNASSOCIATED | 1251 | | | 1252 | Receive I2, process | If successful, send R2 and go to R2-SENT | 1253 | | | 1254 | | If fail, stay at UNASSOCIATED | 1255 | | | 1256 | Receive user data | Optionally send ICMP as defined in | 1257 | for an unknown HIP | Section 5.4 and stay at UNASSOCIATED | 1258 | association | | 1259 | | | 1260 | Receive CLOSE | Optionally send ICMP Parameter Problem and | 1261 | | stay at UNASSOCIATED | 1262 | Receive ANYOTHER | Drop and stay at UNASSOCIATED | 1263 +---------------------+---------------------------------------------+ 1265 Table 2: UNASSOCIATED - Start state 1267 System behavior in state I1-SENT, Table 3. 1269 +---------------------+---------------------------------------------+ 1270 | Trigger | Action | 1271 +---------------------+---------------------------------------------+ 1272 | Receive I1 from | If the local HIT is smaller than the peer | 1273 | Responder | HIT, drop I1 and stay at I1-SENT (see | 1274 | | Section 6.5 for HIT comparison) | 1275 | | | 1276 | | If the local HIT is greater than the peer | 1277 | | HIT, send R1 and stay at I1-SENT | 1278 | | | 1279 | Receive I2, process | If successful, send R2 and go to R2-SENT | 1280 | | | 1281 | | If fail, stay at I1-SENT | 1282 | | | 1283 | Receive R1, process | If the HIT Suite of the local HIT is not | 1284 | | supported by the peer, select supported | 1285 | | local HIT, send I1 and stay at I1-SENT | 1286 | | | 1287 | | If successful, send I2 and go to I2-SENT | 1288 | | | 1289 | | If fail, stay at I1-SENT | 1290 | | | 1291 | Receive ANYOTHER | Drop and stay at I1-SENT | 1292 | | | 1293 | Timeout | Increment timeout counter | 1294 | | | 1295 | | If counter is less than I1_RETRIES_MAX, | 1296 | | send I1 and stay at I1-SENT | 1297 | | | 1298 | | If counter is greater than I1_RETRIES_MAX, | 1299 | | go to E-FAILED | 1300 +---------------------+---------------------------------------------+ 1302 Table 3: I1-SENT - Initiating the HIP Base Exchange 1304 System behavior in state I2-SENT, Table 4. 1306 +---------------------+---------------------------------------------+ 1307 | Trigger | Action | 1308 +---------------------+---------------------------------------------+ 1309 | Receive I1 | Send R1 and stay at I2-SENT | 1310 | | | 1311 | Receive R1, process | If successful, send I2 and stay at I2-SENT | 1312 | | | 1313 | | If fail, stay at I2-SENT | 1314 | | | 1315 | Receive I2, process | If successful and local HIT is smaller than | 1316 | | the peer HIT, drop I2 and stay at I2-SENT | 1317 | | | 1318 | | If successful and local HIT is greater than | 1319 | | the peer HIT, send R2 and go to R2-SENT | 1320 | | | 1321 | | If fail, stay at I2-SENT | 1322 | | | 1323 | Receive R2, process | If successful, go to ESTABLISHED | 1324 | | | 1325 | | If fail, stay at I2-SENT | 1326 | | | 1327 | Receive CLOSE, | If successful, send CLOSE_ACK and go to | 1328 | process | CLOSED | 1329 | | | 1330 | | If fail, stay at I2-SENT | 1331 | | | 1332 | Receive ANYOTHER | Drop and stay at I2-SENT | 1333 | | | 1334 | Timeout | Increment timeout counter | 1335 | | | 1336 | | If counter is less than I2_RETRIES_MAX, | 1337 | | send I2 and stay at I2-SENT | 1338 | | | 1339 | | If counter is greater than I2_RETRIES_MAX, | 1340 | | go to E-FAILED | 1341 +---------------------+---------------------------------------------+ 1343 Table 4: I2-SENT - Waiting to finish the HIP Base Exchange 1345 System behavior in state R2-SENT, Table 5. 1347 +---------------------+---------------------------------------------+ 1348 | Trigger | Action | 1349 +---------------------+---------------------------------------------+ 1350 | Receive I1 | Send R1 and stay at R2-SENT | 1351 | | | 1352 | Receive I2, process | If successful, send R2 and stay at R2-SENT | 1353 | | | 1354 | | If fail, stay at R2-SENT | 1355 | | | 1356 | Receive R1 | Drop and stay at R2-SENT | 1357 | | | 1358 | Receive R2 | Drop and stay at R2-SENT | 1359 | | | 1360 | Receive data or | Move to ESTABLISHED | 1361 | UPDATE | | 1362 | | | 1363 | Exchange Complete | Move to ESTABLISHED | 1364 | Timeout | | 1365 | | | 1366 | Receive CLOSE, | If successful, send CLOSE_ACK and go to | 1367 | process | CLOSED | 1368 | | | 1369 | | If fail, stay at ESTABLISHED | 1370 | | | 1371 | Receive CLOSE_ACK | Drop and stay at R2-SENT | 1372 | | | 1373 | Receive NOTIFY | Process and stay at R2-SENT | 1374 +---------------------+---------------------------------------------+ 1376 Table 5: R2-SENT - Waiting to finish HIP 1378 System behavior in state ESTABLISHED, Table 6. 1380 +---------------------+---------------------------------------------+ 1381 | Trigger | Action | 1382 +---------------------+---------------------------------------------+ 1383 | Receive I1 | Send R1 and stay at ESTABLISHED | 1384 | | | 1385 | Receive I2 | Process with puzzle and possible Opaque | 1386 | | data verification | 1387 | | | 1388 | | If successful, send R2, drop old HIP | 1389 | | association, establish a new HIP | 1390 | | association and go to R2-SENT | 1391 | | | 1392 | | If fail, stay at ESTABLISHED | 1393 | | | 1394 | Receive R1 | Drop and stay at ESTABLISHED | 1395 | | | 1396 | Receive R2 | Drop and stay at ESTABLISHED | 1397 | | | 1398 | Receive user data | Process and stay at ESTABLISHED | 1399 | for HIP association | | 1400 | | | 1401 | No packet | Send CLOSE and go to CLOSING | 1402 | sent/received | | 1403 | during UAL minutes | | 1404 | | | 1405 | Receive UPDATE | Process and stay at ESTABLISHED | 1406 | | | 1407 | Receive CLOSE, | If successful, send CLOSE_ACK and go to | 1408 | process | CLOSED | 1409 | | | 1410 | | If fail, stay at ESTABLISHED | 1411 | | | 1412 | Receive CLOSE_ACK | Drop and stay at ESTABLISHED | 1413 | | | 1414 | Receive NOTIFY | Process and stay at ESTABLISHED | 1415 +---------------------+---------------------------------------------+ 1417 Table 6: ESTABLISHED - HIP association established 1419 System behavior in state CLOSING, Table 7. 1421 +---------------------+---------------------------------------------+ 1422 | Trigger | Action | 1423 +---------------------+---------------------------------------------+ 1424 | User data to send, | Send I1 and stay at CLOSING | 1425 | requires the | | 1426 | creation of another | | 1427 | incarnation of the | | 1428 | HIP association | | 1429 | | | 1430 | Receive I1 | Send R1 and stay at CLOSING | 1431 | | | 1432 | Receive I2, process | If successful, send R2 and go to R2-SENT | 1433 | | | 1434 | | If fail, stay at CLOSING | 1435 | | | 1436 | Receive R1, process | If successful, send I2 and go to I2-SENT | 1437 | | | 1438 | | If fail, stay at CLOSING | 1439 | | | 1440 | Receive CLOSE, | If successful, send CLOSE_ACK, discard | 1441 | process | state and go to CLOSED | 1442 | | | 1443 | | If fail, stay at CLOSING | 1444 | | | 1445 | Receive CLOSE_ACK, | If successful, discard state and go to | 1446 | process | UNASSOCIATED | 1447 | | | 1448 | | If fail, stay at CLOSING | 1449 | | | 1450 | Receive ANYOTHER | Drop and stay at CLOSING | 1451 | | | 1452 | Timeout | Increment timeout sum and reset timer. If | 1453 | | timeout sum is less than UAL+MSL minutes, | 1454 | | retransmit CLOSE and stay at CLOSING | 1455 | | | 1456 | | If timeout sum is greater than UAL+MSL | 1457 | | minutes, go to UNASSOCIATED | 1458 +---------------------+---------------------------------------------+ 1460 Table 7: CLOSING - HIP association has not been used for UAL minutes 1461 System behavior in state CLOSED, Table 8. 1463 +---------------------+---------------------------------------------+ 1464 | Trigger | Action | 1465 +---------------------+---------------------------------------------+ 1466 | Datagram to send, | Send I1, and stay at CLOSED | 1467 | requires the | | 1468 | creation of another | | 1469 | incarnation of the | | 1470 | HIP association | | 1471 | | | 1472 | Receive I1 | Send R1 and stay at CLOSED | 1473 | | | 1474 | Receive I2, process | If successful, send R2 and go to R2-SENT | 1475 | | | 1476 | | If fail, stay at CLOSED | 1477 | | | 1478 | Receive R1, process | If successful, send I2 and go to I2-SENT | 1479 | | | 1480 | | If fail, stay at CLOSED | 1481 | | | 1482 | Receive CLOSE, | If successful, send CLOSE_ACK, stay at | 1483 | process | CLOSED | 1484 | | | 1485 | | If fail, stay at CLOSED | 1486 | | | 1487 | Receive CLOSE_ACK, | If successful, discard state and go to | 1488 | process | UNASSOCIATED | 1489 | | | 1490 | | If fail, stay at CLOSED | 1491 | | | 1492 | Receive ANYOTHER | Drop and stay at CLOSED | 1493 | | | 1494 | Timeout (UAL+2MSL) | Discard state, and go to UNASSOCIATED | 1495 +---------------------+---------------------------------------------+ 1497 Table 8: CLOSED - CLOSE_ACK sent, resending CLOSE_ACK if necessary 1499 System behavior in state E-FAILED, Table 9. 1501 +-------------------------+-----------------------------------------+ 1502 | Trigger | Action | 1503 +-------------------------+-----------------------------------------+ 1504 | Wait for | Go to UNASSOCIATED. Re-negotiation is | 1505 | implementation-specific | possible after moving to UNASSOCIATED | 1506 | time | state. | 1507 +-------------------------+-----------------------------------------+ 1508 Table 9: E-FAILED - HIP failed to establish association with peer 1510 4.4.4. Simplified HIP State Diagram 1512 The following diagram (Figure 2) shows the major state transitions. 1513 Transitions based on received packets implicitly assume that the 1514 packets are successfully authenticated or processed. 1516 +--+ +----------------------------+ 1517 recv I1, send R1 | | | | 1518 | v v | 1519 +--------------+ recv I2, send R2 | 1520 +----------------| UNASSOCIATED |----------------+ | 1521 datagram| +--+ +--------------+ | | 1522 to send,| | | Alg. not supported, | | 1523 send I1| | | send I1 | | 1524 v | v | | 1525 +---------+ recv I2, send R2 | | 1526 +---->| I1-SENT |--------------------------------------+ | | 1527 | +---------+ +----------------------+ | | | 1528 | | recv R2, | recv I2, send R2 | | | | 1529 | v send I2 | v v v | 1530 | +---------+ | +---------+ | 1531 | +--->| I2-SENT |----------+ +--------------| R2-SENT |<---+ | 1532 | | +---------+ | +---------+ | | 1533 | | | |recv R2 | data or| | | 1534 | |recv R1, | | | EC timeout| | | 1535 | |send I2 +--|-----------------+ | receive I2,| | 1536 | | | | +-------------+ | send R2| | 1537 | | | +------>| ESTABLISHED |<----------+ | | 1538 | | | +-------------+ | | 1539 | | | | | | receive I2, send R2 | | 1540 | | +------------+ | +-------------------------------+ | 1541 | | | +-----------+ | | 1542 | | | no packet sent/received| +---+ | | 1543 | | | for UAL min, send CLOSE| | |timeout | | 1544 | | | v v |(UAL+MSL) | | 1545 | | | +---------+ |retransmit | | 1546 +--|----------|------------------------| CLOSING |-+CLOSE | | 1547 | | +---------+ | | 1548 | | | | | | | | 1549 +----------|-------------------------+ | | +----------------+ | 1550 | | +-----------+ +------------------|--+ 1551 | | |recv CLOSE, recv CLOSE_ACK | | 1552 | +-------------+ |send CLOSE_ACK or timeout | | 1553 | recv CLOSE, | | (UAL+MSL) | | 1554 | send CLOSE_ACK v v | | 1555 | +--------+ receive I2, send R2 | | 1556 +---------------------| CLOSED |------------------------------+ | 1557 +--------+ | 1558 ^ | | | 1559 recv CLOSE, send CLOSE_ACK| | | timeout (UAL+2MSL) | 1560 +-+ +------------------------------------+ 1562 Figure 2 1564 4.5. User Data Considerations 1566 4.5.1. TCP and UDP Pseudo-Header Computation for User Data 1568 When computing TCP and UDP checksums on user data packets that flow 1569 through sockets bound to HITs, the IPv6 pseudo-header format 1570 [RFC2460] MUST be used, even if the actual addresses in the header of 1571 the packet are IPv4 addresses. Additionally, the HITs MUST be used 1572 in place of the IPv6 addresses in the IPv6 pseudo-header. Note that 1573 the pseudo-header for actual HIP payloads is computed differently; 1574 see Section 5.1.1. 1576 4.5.2. Sending Data on HIP Packets 1578 Other documents may define how to include user data in various HIP 1579 packets. However, currently the HIP header is a terminal header, and 1580 not followed by any other headers. 1582 4.5.3. Transport Formats 1584 The actual data transmission format, used for user data after the HIP 1585 base exchange, is not defined in this document. Such transport 1586 formats and methods are described in separate specifications. All 1587 HIP implementations MUST implement, at minimum, the ESP transport 1588 format for HIP [I-D.ietf-hip-rfc5202-bis]. 1590 4.5.4. Reboot, Timeout, and Restart of HIP 1592 Simulating a loss of state is a potential DoS attack. The following 1593 process has been crafted to manage state recovery without presenting 1594 a DoS opportunity. 1596 If a host reboots or the HIP association times out, it has lost its 1597 HIP state. If the host that lost state has a datagram to send to the 1598 peer, it simply restarts the HIP base exchange. After the base 1599 exchange has completed, the Initiator can create a new payload 1600 association and start sending data. The peer does not reset its 1601 state until it receives a valid I2 packet. 1603 If a system receives a user data packet that cannot be matched to any 1604 existing HIP association, it is possible that it has lost the state 1605 and its peer has not. It MAY send an ICMP packet with the Parameter 1606 Problem type, and with the pointer pointing to the referred HIP- 1607 related association information. Reacting to such traffic depends on 1608 the implementation and the environment where the implementation is 1609 used. 1611 If the host, that apparently has lost its state, decides to restart 1612 the HIP base exchange, it sends an I1 packet to the peer. After the 1613 base exchange has been completed successfully, the Initiator can 1614 create a new HIP association and the peer drops its old payload 1615 associations and creates a new one. 1617 4.6. Certificate Distribution 1619 This document does not define how to use certificates or how to 1620 transfer them between hosts. These functions are expected to be 1621 defined in a future specification as for HIP Version 1 1622 [I-D.ietf-hip-cert]. A parameter type value, meant to be used for 1623 carrying certificates, is reserved, though: CERT, Type 768; see 1624 Section 5.2. 1626 5. Packet Formats 1628 5.1. Payload Format 1630 All HIP packets start with a fixed header. 1632 0 1 2 3 1633 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 1634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1635 | Next Header | Header Length |0| Packet Type |Version| RES.|1| 1636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1637 | Checksum | Controls | 1638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1639 | Sender's Host Identity Tag (HIT) | 1640 | | 1641 | | 1642 | | 1643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1644 | Receiver's Host Identity Tag (HIT) | 1645 | | 1646 | | 1647 | | 1648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1649 | | 1650 / HIP Parameters / 1651 / / 1652 | | 1653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1655 The HIP header is logically an IPv6 extension header. However, this 1656 document does not describe processing for Next Header values other 1657 than decimal 59, IPPROTO_NONE, the IPv6 'no next header' value. 1659 Future documents MAY define behavior for also other values. However, 1660 current implementations MUST ignore trailing data if an unimplemented 1661 Next Header value is received. 1663 The Header Length field contains the combined length of the HIP 1664 Header and HIP parameters in 8-byte units, excluding the first 8 1665 bytes. Since all HIP headers MUST contain the sender's and 1666 receiver's HIT fields, the minimum value for this field is 4, and 1667 conversely, the maximum length of the HIP Parameters field is 1668 (255*8)-32 = 2008 bytes. Note: this sets an additional limit for 1669 sizes of parameters included in the Parameters field, independent of 1670 the individual parameter maximum lengths. 1672 The Packet Type indicates the HIP packet type. The individual packet 1673 types are defined in the relevant sections. If a HIP host receives a 1674 HIP packet that contains an unrecognized packet type, it MUST drop 1675 the packet. 1677 The HIP Version field is four bits. The version defined in this 1678 document is 2. The version number is expected to be incremented only 1679 if there are incompatible changes to the protocol. Most extensions 1680 can be handled by defining new packet types, new parameter types, or 1681 new Controls (see Section 5.1.2) . 1683 The following three bits are reserved for future use. They MUST be 1684 zero when sent, and they SHOULD be ignored when handling a received 1685 packet. 1687 The two fixed bits in the header are reserved for SHIM6 compatibility 1688 [RFC5533], Section 5.3. For implementations adhering (only) to this 1689 specification, they MUST be set as shown when sending and MUST be 1690 ignored when receiving. This is to ensure optimal forward 1691 compatibility. Note that for implementations that implement other 1692 compatible specifications in addition to this specification, the 1693 corresponding rules may well be different. For example, an 1694 implementation that implements both this specification and the SHIM6 1695 protocol may need to check these bits in order to determine how to 1696 handle the packet. 1698 The HIT fields are always 128 bits (16 bytes) long. 1700 5.1.1. Checksum 1702 Since the checksum covers the source and destination addresses in the 1703 IP header, it MUST be recomputed on HIP-aware NAT devices. 1705 If IPv6 is used to carry the HIP packet, the pseudo-header [RFC2460] 1706 contains the source and destination IPv6 addresses, HIP packet length 1707 in the pseudo-header length field, a zero field, and the HIP protocol 1708 number (see Section 4) in the Next Header field. The length field is 1709 in bytes and can be calculated from the HIP header length field: (HIP 1710 Header Length + 1) * 8. 1712 In case of using IPv4, the IPv4 UDP pseudo-header format [RFC0768] is 1713 used. In the pseudo-header, the source and destination addresses are 1714 those used in the IP header, the zero field is obviously zero, the 1715 protocol is the HIP protocol number (see Section 4), and the length 1716 is calculated as in the IPv6 case. 1718 5.1.2. HIP Controls 1720 The HIP Controls field conveys information about the structure of the 1721 packet and capabilities of the host. 1723 The following fields have been defined: 1725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1726 | | | | | | | | | | | | | | | |A| 1727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1729 A - Anonymous: If this is set, the sender's HI in this packet is 1730 anonymous, i.e., one not listed in a directory. Anonymous HIs 1731 SHOULD NOT be stored. This control is set in packets R1 and/or 1732 I2. The peer receiving an anonymous HI may choose to refuse it. 1734 The rest of the fields are reserved for future use and MUST be set to 1735 zero in sent packets and ignored in received packets. 1737 5.1.3. HIP Fragmentation Support 1739 A HIP implementation MUST support IP fragmentation/reassembly. 1740 Fragment reassembly MUST be implemented in both IPv4 and IPv6, but 1741 fragment generation is REQUIRED to be implemented in IPv4 (IPv4 1742 stacks and networks will usually do this by default) and RECOMMENDED 1743 to be implemented in IPv6. In IPv6 networks, the minimum MTU is 1744 larger, 1280 bytes, than in IPv4 networks. The larger MTU size is 1745 usually sufficient for most HIP packets, and therefore fragment 1746 generation may not be needed. If a host expects to send HIP packets 1747 that are larger than the minimum IPv6 MTU, it MUST implement fragment 1748 generation even for IPv6. 1750 In IPv4 networks, HIP packets may encounter low MTUs along their 1751 routed path. Since basic HIP, as defined in this document, does not 1752 provide a mechanism to use multiple IP datagrams for a single HIP 1753 packet, support for path MTU discovery does not bring any value to 1754 HIP in IPv4 networks. HIP-aware NAT devices SHOULD perform IPv4 1755 reassembly/fragmentation for HIP control packets. 1757 All HIP implementations have to be careful while employing a 1758 reassembly algorithm so that the algorithm is sufficiently resistant 1759 to DoS attacks. 1761 Certificate chains can cause the packet to be fragmented and 1762 fragmentation can open implementations to denial-of-service attacks 1763 [KAU03]. "Hash and URL" schemes as defined in [I-D.ietf-hip-cert] 1764 for HIP version 1 may be used to avoid fragmentation and mitigate 1765 resulting DoS attacks. 1767 5.2. HIP Parameters 1769 The HIP parameters carry information that is necessary for 1770 establishing and maintaining a HIP association. For example, the 1771 peer's public keys as well as the signaling for negotiating ciphers 1772 and payload handling are encapsulated in HIP parameters. Additional 1773 information, meaningful for end-hosts or middleboxes, may also be 1774 included in HIP parameters. The specification of the HIP parameters 1775 and their mapping to HIP packets and packet types is flexible to 1776 allow HIP extensions to define new parameters and new protocol 1777 behavior. 1779 In HIP packets, HIP parameters are ordered according to their numeric 1780 type number and encoded in TLV format. 1782 The following parameter types are currently defined. 1784 +------------------------+-------+----------+-----------------------+ 1785 | TLV | Type | Length | Data | 1786 +------------------------+-------+----------+-----------------------+ 1787 | R1_COUNTER | 128 | 12 | Puzzle generation | 1788 | | | | counter | 1789 | | | | | 1790 | PUZZLE | 257 | 12 | K and Random #I | 1791 | | | | | 1792 | SOLUTION | 321 | 20 | K, Random #I and | 1793 | | | | puzzle solution J | 1794 | | | | | 1795 | SEQ | 385 | 4 | UPDATE packet ID | 1796 | | | | number | 1797 | | | | | 1798 | ACK | 449 | variable | UPDATE packet ID | 1799 | | | | number | 1800 | | | | | 1801 | DIFFIE_HELLMAN | 513 | variable | public key | 1802 | | | | | 1803 | HIP_CIPHER | 579 | variable | List of HIP | 1804 | | | | encryption algorithms | 1805 | | | | | 1806 | ENCRYPTED | 641 | variable | Encrypted part of a | 1807 | | | | HIP packet | 1808 | | | | | 1809 | HOST_ID | 705 | variable | Host Identity with | 1810 | | | | Fully-Qualified | 1811 | | | | Domain FQDN (Name) or | 1812 | | | | Network Access | 1813 | | | | Identifier (NAI) | 1814 | | | | | 1815 | HIT_SUITE_LIST | 715 | variable | Ordered list of the | 1816 | | | | HIT suites supported | 1817 | | | | by the Responder | 1818 | | | | | 1819 | CERT | 768 | variable | HI Certificate; used | 1820 | | | | to transfer | 1821 | | | | certificates. | 1822 | | | | Specified in a | 1823 | | | | separate docment. | 1824 | | | | | 1825 | NOTIFICATION | 832 | variable | Informational data | 1826 | | | | | 1827 | ECHO_REQUEST_SIGNED | 897 | variable | Opaque data to be | 1828 | | | | echoed back; signed | 1829 | | | | | 1830 | ECHO_RESPONSE_SIGNED | 961 | variable | Opaque data echoed | 1831 | | | | back; signed | 1832 | DH_GROUP_LIST | 2151 | variable | Ordered list of DH | 1833 | | | | Group IDs supported | 1834 | | | | by a host | 1835 | | | | | 1836 | HIP_MAC | 61505 | variable | HMAC-based message | 1837 | | | | authentication code, | 1838 | | | | with key material | 1839 | | | | from KEYMAT | 1840 | | | | | 1841 | HIP_MAC_2 | 61569 | variable | HMAC based message | 1842 | | | | authentication code, | 1843 | | | | with key material | 1844 | | | | from KEYMAT. Unlike | 1845 | | | | HIP_MAC, the HOST_ID | 1846 | | | | parameter is included | 1847 | | | | in HIP_MAC_2 | 1848 | | | | calculation. | 1849 | | | | | 1850 | HIP_SIGNATURE_2 | 61633 | variable | Signature used in R1 | 1851 | | | | packet | 1852 | | | | | 1853 | HIP_SIGNATURE | 61697 | variable | Signature of the | 1854 | | | | packet | 1855 | | | | | 1856 | ECHO_REQUEST_UNSIGNED | 63661 | variable | Opaque data to be | 1857 | | | | echoed back; after | 1858 | | | | signature | 1859 | | | | | 1860 | ECHO_RESPONSE_UNSIGNED | 63425 | variable | Opaque data echoed | 1861 | | | | back by request; | 1862 | | | | after signature | 1863 +------------------------+-------+----------+-----------------------+ 1865 As the ordering (from lowest to highest) of HIP parameters is 1866 strictly enforced (see Section 5.2.1), the parameter type values for 1867 existing parameters have been spaced to allow for future protocol 1868 extensions. 1870 The following parameter type number ranges are defined. 1872 +---------------+---------------------------------------------------+ 1873 | Type Range | Purpose | 1874 +---------------+---------------------------------------------------+ 1875 | 0 - 1023 | Handshake | 1876 | | | 1877 | 1024 - 2047 | Reserved | 1878 | | | 1879 | 2048 - 4095 | Parameters related to HIP transport types | 1880 | | | 1881 | 4096 - 8191 | Signed parameters allocated through specification | 1882 | | documents | 1883 | | | 1884 | 8192 - 32767 | Reserved | 1885 | | | 1886 | 32768 - 49151 | Free for experimentation. Signed parameters. | 1887 | | | 1888 | 41952 - 61439 | Reserved | 1889 | | | 1890 | 61440 - 64443 | Signatures and (signed) MACs | 1891 | | | 1892 | 62464 - 63487 | Parameters that are neither signed nor MACed | 1893 | | | 1894 | 63488 - 64511 | Rendezvous and relaying | 1895 | | | 1896 | 64512 - 65023 | Parameters that are neither signed nor MACed | 1897 | | | 1898 | 65024 - 65535 | Reserved | 1899 +---------------+---------------------------------------------------+ 1901 The process for defining new parameters is described in Section 5.2.2 1902 of this document. 1904 The range between 32768 (2^15) and 49151 (2^15 + 2^14) are free for 1905 experimentation. Types from this range SHOULD be selected in a 1906 random fashion to reduce the probability of collisions. 1908 5.2.1. TLV Format 1910 The TLV-encoded parameters are described in the following 1911 subsections. The type-field value also describes the order of these 1912 fields in the packet, except for type values from 2048 to 4095 which 1913 are reserved for new transport forms. The parameters MUST be 1914 included in the packet so that their types form an increasing order. 1915 If multiple parameters with the same type number are in one packet, 1916 the parameters with the same type MUST be consecutive in the packet. 1917 If the order does not follow this rule, the packet is considered to 1918 be malformed and it MUST be discarded. 1920 Parameters using type values from 2048 up to 4095 are transport 1921 formats. Currently, one transport format is defined: the ESP 1922 transport format [I-D.ietf-hip-rfc5202-bis]. The order of these 1923 parameters does not follow the order of their type value, but they 1924 are put in the packet in order of preference. The first of the 1925 transport formats it the most preferred, and so on. 1927 All of the encoded TLV parameters have a length (that includes the 1928 Type and Length fields), which is a multiple of 8 bytes. When 1929 needed, padding MUST be added to the end of the parameter so that the 1930 total length is a multiple of 8 bytes. This rule ensures proper 1931 alignment of data. Any added padding bytes MUST be zeroed by the 1932 sender, and their values SHOULD NOT be checked by the receiver. 1934 The Length field indicates the length of the Contents field (in 1935 bytes). Consequently, the total length of the TLV parameter 1936 (including Type, Length, Contents, and Padding) is related to the 1937 Length field according to the following formula: 1939 Total Length = 11 + Length - (Length + 3) % 8; 1941 where % is the modulo operator 1943 0 1 2 3 1944 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 1945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1946 | Type |C| Length | 1947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1948 | | 1949 / Contents / 1950 / +-+-+-+-+-+-+-+-+ 1951 | | Padding | 1952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1954 Type Type code for the parameter. 16 bits long, C-bit 1955 being part of the Type code. 1956 C Critical. One if this parameter is critical, and 1957 MUST be recognized by the recipient, zero otherwise. 1958 The C bit is considered to be a part of the Type 1959 field. Consequently, critical parameters are always 1960 odd and non-critical ones have an even value. 1961 Length Length of the Contents, in bytes excluding Type, 1962 Length, and Padding. 1963 Contents Parameter specific, defined by Type 1964 Padding Padding, 0-7 bytes, added if needed 1966 Critical parameters (indicated by the odd type number) MUST be 1967 recognized by the recipient. If a recipient encounters a critical 1968 parameter that it does not recognize, it MUST NOT process the packet 1969 any further. It MAY send an ICMP or NOTIFY, as defined in 1970 Section 4.3. 1972 Non-critical parameters MAY be safely ignored. If a recipient 1973 encounters a non-critical parameter that it does not recognize, it 1974 SHOULD proceed as if the parameter was not present in the received 1975 packet. 1977 5.2.2. Defining New Parameters 1979 Future specifications may define new parameters as needed. When 1980 defining new parameters, care must be taken to ensure that the 1981 parameter type values are appropriate and leave suitable space for 1982 other future extensions. One must remember that the parameters MUST 1983 always be arranged in numerically increasing order by Type code, 1984 thereby limiting the order of parameters (see Section 5.2.1). 1986 The following rules MUST be followed when defining new parameters. 1988 1. The low-order bit C of the Type code is used to distinguish 1989 between critical and non-critical parameters. Hence, even 1990 parameter type numbers indicate non-critical parameters while odd 1991 parameter type numbers indicate critical parameters. 1993 2. A new parameter MAY be critical only if an old implementation 1994 that ignored it would cause security problems. In general, new 1995 parameters SHOULD be defined as non-critical, and expect a reply 1996 from the recipient. 1998 3. If a system implements a new critical parameter, it MUST provide 1999 the ability to set the associated feature off, such that the 2000 critical parameter is not sent at all. The configuration option 2001 MUST be well documented. Implementations operating in a mode 2002 adhering to this specification MUST disable the sending of new 2003 critical parameters by default. In other words, the management 2004 interface MUST allow vanilla standards-only mode as a default 2005 configuration setting, and MAY allow new critical payloads to be 2006 configured on (and off). 2008 4. See Section 9 for allocation rules regarding Type codes. 2010 5.2.3. R1_COUNTER 2012 0 1 2 3 2013 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 2014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2015 | Type | Length | 2016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2017 | Reserved, 4 bytes | 2018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2019 | R1 generation counter, 8 bytes | 2020 | | 2021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2023 Type 128 2024 Length 12 2025 R1 generation 2026 counter The current generation of valid puzzles 2028 The R1_COUNTER parameter contains a 64-bit unsigned integer in 2029 network-byte order, indicating the current generation of valid 2030 puzzles. The sender SHOULD increment this counter periodically. It 2031 is RECOMMENDED that the counter value is incremented at least as 2032 often as old PUZZLE values are deprecated so that SOLUTIONs to them 2033 are no longer accepted. 2035 The R1_COUNTER parameter is optional. It SHOULD be included in the 2036 R1 (in which case, it is covered by the signature), and if present in 2037 the R1, it MAY be echoed (including the Reserved field verbatim) by 2038 the Initiator in the I2 packet. 2040 5.2.4. PUZZLE 2042 0 1 2 3 2043 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 2044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2045 | Type | Length | 2046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2047 | #K, 1 byte | Lifetime | Opaque, 2 bytes | 2048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2049 | Random #I, RHASH_len/8 bytes | 2050 / / 2051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2053 Type 257 2054 Length 4 + RHASH_len / 8 2055 #K #K is the number of verified bits 2056 Lifetime puzzle lifetime 2^(value-32) seconds 2057 Opaque data set by the Responder, indexing the puzzle 2058 Random #I random number of size RHASH_len bits 2060 Random #I is represented as a n-bit integer (where n is RHASH_len), 2061 #K and Lifetime as 8-bit integers, all in network byte order. 2063 The PUZZLE parameter contains the puzzle difficulty #K and a n-bit 2064 random integer #I. The Puzzle Lifetime indicates the time during 2065 which the puzzle solution is valid, and sets a time limit that should 2066 not be exceeded by the Initiator while it attempts to solve the 2067 puzzle. The lifetime is indicated as a power of 2 using the formula 2068 2^(Lifetime-32) seconds. A puzzle MAY be augmented with an 2069 ECHO_REQUEST_SIGNED or an ECHO_REQUEST_UNSIGNED parameter included in 2070 the R1; the contents of the echo request are then echoed back in the 2071 ECHO_RESPONSE_SIGNED or in the ECHO_RESPONSE_UNSIGNED parameter, 2072 allowing the Responder to use the included information as a part of 2073 its puzzle processing. 2075 The Opaque and Random #I field are not covered by the HIP_SIGNATURE_2 2076 parameter. 2078 5.2.5. SOLUTION 2080 0 1 2 3 2081 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 2082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2083 | Type | Length | 2084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2085 | #K, 1 byte | Reserved | Opaque, 2 bytes | 2086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2087 | Random #I, n bytes | 2088 / / 2089 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2090 | Puzzle solution #J, RHASH_len/8 bytes | 2091 / / 2092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2094 Type 321 2095 Length 4 + RHASH_len /4 2096 #K #K is the number of verified bits 2097 Reserved zero when sent, ignored when received 2098 Opaque copied unmodified from the received PUZZLE 2099 parameter 2100 Random #I random number of size RHASH_len bits 2101 Puzzle solution #J random number of size RHASH_len bits 2103 Random #I and Random #J are represented as n-bit unsigned integers 2104 (where n is RHASH_len), #K as an 8-bit unsigned integer, all in 2105 network byte order. 2107 The SOLUTION parameter contains a solution to a puzzle. It also 2108 echoes back the random difficulty #K, the Opaque field, and the 2109 puzzle integer #I. 2111 5.2.6. DIFFIE_HELLMAN 2113 0 1 2 3 2114 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 2115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2116 | Type | Length | 2117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2118 | Group ID | Public Value Length | Public Value / 2119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2120 / | 2121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2122 / | Padding | 2123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2125 Type 513 2126 Length length in octets, excluding Type, Length, and 2127 Padding 2128 Group ID defines values for p and g 2129 Public Value length of the following Public Value in octets 2130 Length 2131 Public Value the sender's public Diffie-Hellman key 2133 The following Group IDs have been defined: 2135 Group Value 2136 Reserved 0 2137 DEPRECATED 1 2138 DEPRECATED 2 2139 1536-bit MODP group 3 [RFC3526] 2140 3072-bit MODP group 4 [RFC3526] 2141 DEPRECATED 5 2142 DEPRECATED 6 2143 NIST P-256 7 [RFC5903] 2144 NIST P-384 8 [RFC5903] 2145 NIST P-521 9 [RFC5903] 2146 SECP160R1 10 [SECG] 2148 The MODP Diffie-Hellman groups are defined in [RFC3526]. The ECDH 2149 groups 8 - 10 are defined in [RFC5903] and [RFC6090]. ECDH group 7 2150 is covered in Appendix D. 2152 A HIP implementation MUST implement Group ID 3. The 160-bit 2153 SECP160R1 group can be used when lower security is enough (e.g., web 2154 surfing) and when the equipment is not powerful enough (e.g., some 2155 PDAs). Implementations SHOULD implement Group IDs 4 and 8. 2157 To avoid unnecessary failures during the base exchange, the rest of 2158 the groups SHOULD be implemented in hosts where resources are 2159 adequate. 2161 5.2.7. HIP_CIPHER 2163 0 1 2 3 2164 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 2165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2166 | Type | Length | 2167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2168 | Cipher ID #1 | Cipher ID #2 | 2169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2170 | Cipher ID #n | Padding | 2171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2173 Type 579 2174 Length length in octets, excluding Type, Length, and 2175 Padding 2176 Cipher ID defines the cipher algorithm to be used for 2177 encrypting the contents of the ENCRYPTED parameter 2179 The following Cipher IDs are defined: 2181 Suite ID Value 2183 RESERVED 0 2184 NULL-ENCRYPT 1 ([RFC2410]) 2185 AES-128-CBC 2 ([RFC3602]) 2186 3DES-CBC 3 ([RFC2451]) 2187 AES-256-CBC 4 ([RFC3602]) 2189 The sender of a HIP_CIPHER parameter MUST make sure that there are no 2190 more than six (6) Cipher IDs in one HIP_CIPHER parameter. 2191 Conversely, a recipient MUST be prepared to handle received transport 2192 parameters that contain more than six Cipher IDs by accepting the 2193 first six Cipher IDs and dropping the rest. The limited number of 2194 transforms sets the maximum size of the HIP_CIPHER parameter. As the 2195 default configuration, the HIP_CIPHER parameter MUST contain at least 2196 one of the mandatory Cipher IDs. There MAY be a configuration option 2197 that allows the administrator to override this default. 2199 The Responder lists supported and desired Cipher IDs in order of 2200 preference in the R1, up to the maximum of six Cipher IDs. The 2201 Initiator MUST choose only one of the corresponding Cipher IDs. This 2202 Cipher ID will be used for generating the ENCRYPTED parameter. 2204 Mandatory implementation: AES-128-CBC. NULL-ENCRYPTION is included 2205 for testing purposes. NULL-ENCRYPTION SHOULD NOT be configurable via 2206 the UI. 2208 5.2.8. HOST_ID 2210 0 1 2 3 2211 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 2212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2213 | Type | Length | 2214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2215 | HI Length |DI-type| DI Length | 2216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2217 | Algorithm | Host Identity / 2218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2219 / | Domain Identifier / 2220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2221 / | Padding | 2222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2224 Type 705 2225 Length length in octets, excluding Type, Length, and 2226 Padding 2227 HI Length length of the Host Identity in octets 2228 DI-type type of the following Domain Identifier field 2229 Algorithm index to the employed algorithm 2230 DI Length length of the Domain Identifier field in octets 2231 Host Identity actual Host Identity 2232 Domain Identifier the identifier of the sender 2234 The following DI-types have been defined: 2236 Type Value 2237 none included 0 2238 FQDN 1 2239 NAI 2 2241 FQDN Fully Qualified Domain Name, in binary format. 2242 NAI Network Access Identifier 2244 The format for the FQDN is defined in RFC 1035 [RFC1035] Section 3.1. 2245 The format for the NAI is defined in [RFC4282] 2247 If there is no Domain Identifier, i.e., the DI-type field is zero, 2248 the DI Length field is set to zero as well. 2250 The following HI Algorithms have been defined: 2252 Algorithm 2253 profiles Values 2255 RESERVED 0 2256 DSA 3 [RFC2536] (RECOMMENDED) 2257 RSA 5 [RFC3110] (REQUIRED) 2258 ECDSA 7 [RFC4754] (RECOMMENDED) 2259 ECDSA_LOW 9 [SECG] (RECOMMENDED) 2261 The Host Identity is derived from the DNSKEY format for RSA and DSA. 2262 For these, the Public Key field of the RDATA part from RFC 4034 2263 [RFC4034] is used. For ECC we distinguish two different profiles: 2264 ECDSA and ECDSA_LOW. ECC contains curves approved by NIST and 2265 defined in RFC 4754 [RFC4754]. ECDSA_LOW is defined for devices with 2266 low computational capabilities and uses shorter curves from SECG 2267 [SECG]. 2269 For ECDSA and ECDSA_LOW Host Identities are represented by the 2270 following fields: 2272 0 1 2 3 2273 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 2274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2275 | ECC Curve | / 2276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2277 / Public Key | 2278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2280 ECC Curve Curve label 2281 Public Key Represented in Octet-string format 2282 [RFC6090] 2284 For hosts that implement ECDSA as algorithm the following ECC curves 2285 are required: 2287 Algorithm Curve Values 2289 ECDSA RESERVED 0 2290 ECDSA NIST P-256 1 [RFC4754] 2291 ECDSA NIST P-384 2 [RFC4754] 2293 For hosts that implement the EDSA_LOW algorithm profile, the 2294 following curve is required: 2296 Algorithm Curve Values 2298 ECDSA_LOW RESERVED 0 2299 ECDSA_LOW SECP160R1 1 [SECG] 2301 5.2.9. HIT_SUITE_LIST 2303 The HIT_SUITE_LIST parameter contains a list of the supported HIT 2304 suite IDs of the Responder. The Responder sends the HIT_SUITE_LIST 2305 in the signed part of the R1 packet. Based on the HIT_SUITE_LIST, 2306 the Initiator can determine which source HITs are supported by the 2307 Responder. 2309 0 1 2 3 2310 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 2311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2312 | Type | Length | 2313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2314 | ID #1 | ID #2 | ID #3 | ID #4 | 2315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2316 | ID #n | Padding | 2317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2319 Type 715 2320 Length number of HIT Suite IDs 2321 ID defines a HIT Suite ID supported by the host. 2322 The list of IDs is ordered by preference of the 2323 host. Each HIT Suite ID is one octet long. The four 2324 higher-order bits of the ID field correspond to the 2325 HIT Suite ID in the ORCHID OGA field. The four 2326 lower-order bits are reserved and set to 0 and 2327 ignored by the receiver. 2329 The HIT Suite ID indexes a HIT Suite. HIT Suites are composed of 2330 signature algorithms as defined in Section 5.2.8 and hash functions. 2332 The ID field in the HIT_SUITE_LIST is defined as eight-bit field as 2333 opposed to the four-bit HIT Suite ID and OGA field in the ORCHID. 2334 This difference is a measure to accommodate larger HIT Suite IDs if 2335 the 16 available values prove insufficient. In that case, one of the 2336 16 values, zero, will be used to indicate that four additional bits 2337 of the ORCHID will be used to encode the HIT Suite ID. Hence, the 2338 current four-bit HIT Suite-IDs only use the four higher order bits in 2339 the ID field. Future documents may define the use of the four lower- 2340 order bits in the ID field. 2342 The following HIT Suites ID are defined: 2344 HIT Suite ID 2345 RESERVED 0 2346 RSA,DSA/SHA-1 1 (REQUIRED) 2347 ECDSA/SHA-384 2 (RECOMMENDED) 2348 ECDSA_LOW/SHA-1 3 (RECOMMENDED) 2350 5.2.10. DH_GROUP_LIST 2352 0 1 2 3 2353 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 2354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2355 | Type | Length | 2356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2357 | DH GROUP ID #1| DH GROUP ID #2| DH GROUP ID #3| DH GROUP ID #4| 2358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2359 | DH GROUP ID #n| Padding | 2360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2362 Type 2151 2363 Length number of DH Group IDs 2364 DH GROUP ID defines a DH GROUP ID supported by the host. 2365 The list of IDs is ordered by preference of the 2366 host. The list of define DH Group IDs in the 2367 DIFFIE_HELLMAN parameter. Each DH Group ID is one 2368 octet long. 2370 The DH_GROUP_LIST parameter contains the list of supported DH Group 2371 IDs of a host. The Initiator sends the DH_GROUP_LIST in the I1 2372 packet, the Responder sends its own list in the signed part of the R1 2373 packet. The DH Group IDs in the DH_GROUP_LIST are listed in the 2374 order of their preference of the host sending the list. DH Group IDs 2375 that are listed first are preferred over the DH Group IDs listed 2376 later. The information in the DH_GROUP_LIST allows the Responder to 2377 select the DH group preferred by itself and supported by the 2378 Initiator. Based on the DH_GROUP_LIST in the R1 packet, the 2379 Initiator can determine if the Responder has selected the best 2380 possible choice based on the Initiator's and Responder's preferences. 2381 If the Responder's choice differs from the best choice, the Initiator 2382 can conclude that there was an attempted downgrade attack (see 2383 Section 4.1.7). 2385 When selecting the DH group for the DIFFIE_HELLMAN parameter in the 2386 R1 packet, the Responder MUST select the first DH Group ID in its 2387 DH_GROUP_LIST in the R1 packet that is compatible with one of the 2388 Suite IDs in the Initiator's DH_GROUP_LIST in the I1 packet. The 2389 Responder MUST NOT select any other DH Group ID that is contained in 2390 both lists because a downgrade attack cannot be detected then. 2392 5.2.11. HIP_MAC 2394 0 1 2 3 2395 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 2396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2397 | Type | Length | 2398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2399 | | 2400 | HMAC | 2401 / / 2402 / +-------------------------------+ 2403 | | Padding | 2404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2406 Type 61505 2407 Length length in octets, excluding Type, Length, and 2408 Padding 2409 HMAC HMAC computed over the HIP packet, excluding the 2410 HIP_MAC parameter and any following parameters, such 2411 as HIP_SIGNATURE, HIP_SIGNATURE_2, 2412 ECHO_REQUEST_UNSIGNED, or ECHO_RESPONSE_UNSIGNED. 2413 The checksum field MUST be set to zero and the HIP 2414 header length in the HIP common header MUST be 2415 calculated not to cover any excluded parameters 2416 when the HMAC is calculated. The size of the 2417 HMAC is the natural size of the hash computation 2418 output depending on the used hash function. 2420 The HMAC uses RHASH as hash algorithm. The calculation and 2421 verification process is presented in Section 6.4.1. 2423 5.2.12. HIP_MAC_2 2425 The HIP_MAC_2 is a MAC of the packet and the HOST_ID parameter of the 2426 sender while only the packet without HOST_ID of the sender is sent. 2427 The parameter structure is the same as in Section 5.2.11. The fields 2428 are: 2430 Type 61569 2431 Length length in octets, excluding Type, Length, and 2432 Padding 2433 HMAC HMAC computed over the HIP packet, excluding the 2434 HIP_MAC_2 parameter and any following parameters 2435 such as HIP_SIGNATURE, HIP_SIGNATURE_2, 2436 ECHO_REQUEST_UNSIGNED, or ECHO_RESPONSE_UNSIGNED, 2437 and including an additional sender's HOST_ID 2438 parameter during the HMAC calculation. The checksum 2439 field MUST be set to zero and the HIP header length 2440 in the HIP common header MUST be calculated not to 2441 cover any excluded parameters when the HMAC is 2442 calculated. The size of the HMAC is the natural 2443 size of the hash computation output depending on the 2444 used hash function. 2446 The HMAC uses RHASH as hash algorithm. The calculation and 2447 verification process is presented in Section 6.4.1. 2449 5.2.13. HIP_SIGNATURE 2451 0 1 2 3 2452 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 2453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2454 | Type | Length | 2455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2456 | SIG alg | Signature / 2457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2458 / | Padding | 2459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2461 Type 61697 2462 Length length in octets, excluding Type, Length, and 2463 Padding 2464 SIG alg signature algorithm 2465 Signature the signature is calculated over the HIP packet, 2466 excluding the HIP_SIGNATURE parameter and any 2467 parameters that follow the HIP_SIGNATURE parameter. 2468 When the signature is calculated the checksum field 2469 MUST be set to zero, and the HIP header length in 2470 the HIP common header MUST be calculated only up to 2471 the beginning of the HIP_SIGNATURE parameter. 2473 The signature algorithms are defined in Section 5.2.8. The signature 2474 in the Signature field is encoded using the method depending on the 2475 signature algorithm (e.g., according to [RFC3110] in case of RSA/ 2476 SHA-1, according to [RFC5702] in case of RSA/SHA-256, according to 2477 [RFC2536] in case of DSA, or according to [RFC6090] in case of 2478 ECDSA). 2480 The HIP_SIGNATURE calculation and verification process are presented 2481 in Section 6.4.2. 2483 5.2.14. HIP_SIGNATURE_2 2485 The HIP_SIGNATURE_2 excludes the variable parameters in the R1 packet 2486 to allow R1 pre-creation. The parameter structure is the same as in 2487 Section 5.2.13. The fields are: 2489 Type 61633 2490 Length length in octets, excluding Type, Length, and 2491 Padding 2492 SIG alg signature algorithm 2493 Signature Within the R1 packet that contains the 2494 HIP_SIGNATURE_2 parameter, the Initiator's HIT, the 2495 checksum field, and the Opaque and Random #I fields 2496 in the PUZZLE parameter MUST be set to zero while 2497 computing the HIP_SIGNATURE_2 signature. Further, 2498 the HIP packet length in the HIP header MUST be 2499 adjusted as if the HIP_SIGNATURE_2 was not in the 2500 packet during the signature calculation, i.e., the 2501 HIP packet length points to the beginning of 2502 the HIP_SIGNATURE_2 parameter during signing and 2503 verification. 2505 Zeroing the Initiator's HIT makes it possible to create R1 packets 2506 beforehand, to minimize the effects of possible DoS attacks. Zeroing 2507 the Random #I and Opaque fields within the PUZZLE parameter allows 2508 these fields to be populated dynamically on precomputed R1s. 2510 Signature calculation and verification follows the process defined in 2511 Section 6.4.2. 2513 5.2.15. SEQ 2515 0 1 2 3 2516 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 2517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2518 | Type | Length | 2519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2520 | Update ID | 2521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2522 Type 385 2523 Length 8 2524 Update ID 32-bit sequence number 2526 The Update ID is an unsigned number in network byte order, 2527 initialized by a host to zero upon moving to ESTABLISHED state. The 2528 Update ID has scope within a single HIP association, and not across 2529 multiple associations or multiple hosts. The Update ID is 2530 incremented by one before each new UPDATE that is sent by the host; 2531 the first UPDATE packet originated by a host has an Update ID of 0. 2533 5.2.16. ACK 2535 0 1 2 3 2536 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 2537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2538 | Type | Length | 2539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2540 | peer Update ID 1 | 2541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2542 / peer Update ID n | 2543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2545 Type 449 2546 Length length in octets, excluding Type and Length 2547 peer Update ID 32-bit sequence number corresponding to the 2548 Update ID being ACKed. 2550 The ACK parameter includes one or more Update IDs that have been 2551 received from the peer. The number of peer Update IDs can be 2552 inferred from the length by dividing it by 4. 2554 5.2.17. ENCRYPTED 2556 0 1 2 3 2557 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 2558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2559 | Type | Length | 2560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2561 | Reserved | 2562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2563 | IV / 2564 / / 2565 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 2567 / Encrypted data / 2568 / / 2569 / +-------------------------------+ 2570 / | Padding | 2571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2573 Type 641 2574 Length length in octets, excluding Type, Length, and 2575 Padding 2576 Reserved zero when sent, ignored when received 2577 IV Initialization vector, if needed, otherwise 2578 nonexistent. The length of the IV is inferred from 2579 the HIP_CIPHER. 2580 Encrypted The data is encrypted using the encryption algorithm 2581 data defined in the HIP_CIPHER parameter. 2583 The ENCRYPTED parameter encapsulates other parameters, the encrypted 2584 data, which holds one or more HIP parameters in block encrypted form. 2586 Consequently, the first fields in the encapsulated parameter(s) are 2587 Type and Length of the first such parameter, allowing the contents to 2588 be easily parsed after decryption. 2590 The field labeled "Encrypted data" consists of the output of one or 2591 more HIP parameters concatenated together that have been passed 2592 through an encryption algorithm. Each of these inner parameters is 2593 padded according to the rules of Section 5.2.1 for padding individual 2594 parameters. As a result, the concatenated parameters will be a block 2595 of data that is 8-byte aligned. 2597 Some encryption algorithms require that the data to be encrypted must 2598 be a multiple of the cipher algorithm block size. In this case, the 2599 above block of data MUST include additional padding, as specified by 2600 the encryption algorithm. The size of the extra padding is selected 2601 so that the length of the unencrypted data block is a multiple of the 2602 cipher block size. The encryption algorithm may specify padding 2603 bytes other than zero; for example, AES [FIPS.197.2001] uses the 2604 PKCS5 padding scheme (see section 6.1.1 of [RFC2898]) where the 2605 remaining n bytes to fill the block each have the value of n. This 2606 yields an "unencrypted data" block that is transformed to an 2607 "encrypted data" block by the cipher suite. This extra padding added 2608 to the set of parameters to satisfy the cipher block alignment rules 2609 is not counted in HIP TLV length fields, and this extra padding 2610 should be removed by the cipher suite upon decryption. 2612 Note that the length of the cipher suite output may be smaller or 2613 larger than the length of the set of parameters to be encrypted, 2614 since the encryption process may compress the data or add additional 2615 padding to the data. 2617 Once this encryption process is completed, the Encrypted data field 2618 is ready for inclusion in the parameter. If necessary, additional 2619 Padding for 8-byte alignment is then added according to the rules of 2620 Section 5.2.1. 2622 5.2.18. NOTIFICATION 2624 The NOTIFICATION parameter is used to transmit informational data, 2625 such as error conditions and state transitions, to a HIP peer. A 2626 NOTIFICATION parameter may appear in NOTIFY packets. The use of the 2627 NOTIFICATION parameter in other packet types is for further study. 2629 0 1 2 3 2630 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 2631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2632 | Type | Length | 2633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2634 | Reserved | Notify Message Type | 2635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2636 | / 2637 / Notification Data / 2638 / +---------------+ 2639 / | Padding | 2640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2642 Type 832 2643 Length length in octets, excluding Type, Length, and 2644 Padding 2645 Reserved zero when sent, ignored when received 2646 Notify Message specifies the type of notification 2647 Type 2648 Notification informational or error data transmitted in addition 2649 Data to the Notify Message Type. Values for this field 2650 are type specific (see below). 2651 multiple of 8 bytes. 2653 Notification information can be error messages specifying why an HIP 2654 Security Association could not be established. It can also be status 2655 data that a HIP implementation wishes to communicate with a peer 2656 process. The table below lists the notification messages and their 2657 Notification Message Types. HIP packets MAY contain multiple notify 2658 parameters if several problems exist or several independent pieces of 2659 information must be transmitted. 2661 To avoid certain types of attacks, a Responder SHOULD avoid sending a 2662 NOTIFICATION to any host with which it has not successfully verified 2663 a puzzle solution. 2665 Notify Message Types in the range 0-16383 are intended for reporting 2666 errors and in the range 16384-65535 for other status information. An 2667 implementation that receives a NOTIFY packet with a Notify Message 2668 Type that indicates an error in response to a request packet (e.g., 2669 I1, I2, UPDATE) SHOULD assume that the corresponding request has 2670 failed entirely. Unrecognized error types MUST be ignored except 2671 that they SHOULD be logged. 2673 As currently defined, Notify Message Type values 1-10 are used for 2674 informing about errors in packet structures, values 11-20 for 2675 informing about problems in parameters. 2677 Notification Data in NOTIFICATION parameters with status Notify 2678 Message Types MUST be ignored if not recognized. 2680 Notify Message Types - Errors Value 2681 ----------------------------- ----- 2683 UNSUPPORTED_CRITICAL_PARAMETER_TYPE 1 2685 Sent if the parameter type has the "critical" bit set and the 2686 parameter type is not recognized. Notification Data contains the 2687 two-octet parameter type. 2689 INVALID_SYNTAX 7 2691 Indicates that the HIP message received was invalid because some 2692 type, length, or value was out of range or because the request 2693 was otherwise malformed. To avoid a denial- of-service 2694 attack using forged messages, this status may only be returned 2695 for packets whose HIP_MAC (if present) and SIGNATURE have been 2696 verified. This status MUST be sent in response to any error not 2697 covered by one of the other status types, and SHOULD NOT contain 2698 details to avoid leaking information to someone probing a node. 2699 To aid debugging, more detailed error information SHOULD be 2700 written to a console or log. 2702 NO_DH_PROPOSAL_CHOSEN 14 2704 None of the proposed group IDs was acceptable. 2706 INVALID_DH_CHOSEN 15 2708 The DH Group ID field does not correspond to one offered 2709 by the Responder. 2711 NO_HIP_PROPOSAL_CHOSEN 16 2713 None of the proposed HIT Suites or HIP Encryption Algorithms was 2714 acceptable. 2716 INVALID_HIP_CIPHER_CHOSEN 17 2718 The HIP_CIPHER Crypto ID does not correspond to one offered by 2719 the Responder. 2721 UNSUPPORTED_HIT_SUITE 20 2723 Sent in response to an I1 or R1 packet for which the HIT suite 2724 is not supported. 2726 AUTHENTICATION_FAILED 24 2728 Sent in response to a HIP signature failure, except when 2729 the signature verification fails in a NOTIFY message. 2731 CHECKSUM_FAILED 26 2733 Sent in response to a HIP checksum failure. 2735 HIP_MAC_FAILED 28 2737 Sent in response to a HIP HMAC failure. 2739 ENCRYPTION_FAILED 32 2741 The Responder could not successfully decrypt the 2742 ENCRYPTED parameter. 2744 INVALID_HIT 40 2746 Sent in response to a failure to validate the peer's 2747 HIT from the corresponding HI. 2749 BLOCKED_BY_POLICY 42 2751 The Responder is unwilling to set up an association 2752 for some policy reason (e.g., received HIT is NULL 2753 and policy does not allow opportunistic mode). 2755 RESPONDER_BUSY_PLEASE_RETRY 44 2757 The Responder is unwilling to set up an association as it is 2758 suffering under some kind of overload and has chosen to shed load 2759 by rejecting the Initiator's request. The Initiator may retry; 2760 however, the Initiator MUST find another (different) puzzle 2761 solution for any such retries. Note that the Initiator may need 2762 to obtain a new puzzle with a new I1/R1 exchange. 2764 Notify Message Types - Status Value 2765 ----------------------------- ----- 2767 I2_ACKNOWLEDGEMENT 16384 2769 The Responder has an I2 packet from the Initiator but had to 2770 queue the I2 packet for processing. The puzzle was correctly 2771 solved and the Responder is willing to set up an association but 2772 currently has a number of I2 packets in the processing queue. 2773 The R2 packet is sent after the I2 packet was processed. 2775 5.2.19. ECHO_REQUEST_SIGNED 2777 0 1 2 3 2778 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 2779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2780 | Type | Length | 2781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2782 | Opaque data (variable length) | 2783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2785 Type 897 2786 Length length of the opaque data in octets 2787 Opaque data opaque data, supposed to be meaningful only to the 2788 node that sends ECHO_REQUEST_SIGNED and receives a 2789 corresponding ECHO_RESPONSE_SIGNED or 2790 ECHO_RESPONSE_UNSIGNED. 2792 The ECHO_REQUEST_SIGNED parameter contains an opaque blob of data 2793 that the sender wants to get echoed back in the corresponding reply 2794 packet. 2796 The ECHO_REQUEST_SIGNED and corresponding echo response parameters 2797 MAY be used for any purpose where a node wants to carry some state in 2798 a request packet and get it back in a response packet. The 2799 ECHO_REQUEST_SIGNED is covered by the HIP_MAC and SIGNATURE. A HIP 2800 packet can contain only one ECHO_REQUEST_SIGNED parameter and MAY 2801 contain multiple ECHO_REQUEST_UNSIGNED parameter. The 2802 ECHO_REQUEST_SIGNED parameter MUST be responded to with an 2803 ECHO_RESPONSE_SIGNED. 2805 5.2.20. ECHO_REQUEST_UNSIGNED 2807 0 1 2 3 2808 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 2809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2810 | Type | Length | 2811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2812 | Opaque data (variable length) | 2813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2815 Type 63661 2816 Length length of the opaque data in octets 2817 Opaque data opaque data, supposed to be meaningful only to the 2818 node that sends ECHO_REQUEST_UNSIGNED and receives a 2819 corresponding ECHO_RESPONSE_UNSIGNED. 2821 The ECHO_REQUEST_UNSIGNED parameter contains an opaque blob of data 2822 that the sender wants to get echoed back in the corresponding reply 2823 packet. 2825 The ECHO_REQUEST_UNSIGNED and corresponding echo response parameters 2826 MAY be used for any purpose where a node wants to carry some state in 2827 a request packet and get it back in a response packet. The 2828 ECHO_REQUEST_UNSIGNED is not covered by the HIP_MAC and SIGNATURE. A 2829 HIP packet can contain one or more ECHO_REQUEST_UNSIGNED parameters. 2830 It is possible that middleboxes add ECHO_REQUEST_UNSIGNED parameters 2831 in HIP packets passing by. The creator of the ECHO_REQUEST_UNSIGNED 2832 (end-host or middlebox) has to create the Opaque field so that it can 2833 later identify and remove the corresponding ECHO_RESPONSE_UNSIGNED 2834 parameter. 2836 The ECHO_REQUEST_UNSIGNED parameter MUST be responded to with an 2837 ECHO_RESPONSE_UNSIGNED parameter. 2839 5.2.21. ECHO_RESPONSE_SIGNED 2841 0 1 2 3 2842 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 2843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2844 | Type | Length | 2845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2846 | Opaque data (variable length) | 2847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2849 Type 961 2850 Length length of the opaque data in octets 2851 Opaque data opaque data, copied unmodified from the 2852 ECHO_REQUEST_SIGNED or ECHO_REQUEST_UNSIGNED 2853 parameter that triggered this response. 2855 The ECHO_RESPONSE_SIGNED parameter contains an opaque blob of data 2856 that the sender of the ECHO_REQUEST_SIGNED wants to get echoed back. 2857 The opaque data is copied unmodified from the ECHO_REQUEST_SIGNED 2858 parameter. 2860 The ECHO_REQUEST_SIGNED and ECHO_RESPONSE_SIGNED parameters MAY be 2861 used for any purpose where a node wants to carry some state in a 2862 request packet and get it back in a response packet. The 2863 ECHO_RESPONSE_SIGNED is covered by the HIP_MAC and SIGNATURE. 2865 5.2.22. ECHO_RESPONSE_UNSIGNED 2867 0 1 2 3 2868 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 2869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2870 | Type | Length | 2871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2872 | Opaque data (variable length) | 2873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2875 Type 63425 2876 Length length of the opaque data in octets 2877 Opaque data opaque data, copied unmodified from the 2878 ECHO_REQUEST_SIGNED or ECHO_REQUEST_UNSIGNED 2879 parameter that triggered this response. 2881 The ECHO_RESPONSE_UNSIGNED parameter contains an opaque blob of data 2882 that the sender of the ECHO_REQUEST_SIGNED or ECHO_REQUEST_UNSIGNED 2883 wants to get echoed back. The opaque data is copied unmodified from 2884 the corresponding echo request parameter. 2886 The echo request and ECHO_RESPONSE_UNSIGNED parameters MAY be used 2887 for any purpose where a node wants to carry some state in a request 2888 packet and get it back in a response packet. The 2889 ECHO_RESPONSE_UNSIGNED is not covered by the HIP_MAC and SIGNATURE. 2891 5.3. HIP Packets 2893 There are eight basic HIP packets (see Table 10). Four are for the 2894 HIP base exchange, one is for updating, one is for sending 2895 notifications, and two are for closing a HIP association. 2897 +------------------+------------------------------------------------+ 2898 | Packet type | Packet name | 2899 +------------------+------------------------------------------------+ 2900 | 1 | I1 - the HIP Initiator Packet | 2901 | | | 2902 | 2 | R1 - the HIP Responder Packet | 2903 | | | 2904 | 3 | I2 - the Second HIP Initiator Packet | 2905 | | | 2906 | 4 | R2 - the Second HIP Responder Packet | 2907 | | | 2908 | 16 | UPDATE - the HIP Update Packet | 2909 | | | 2910 | 17 | NOTIFY - the HIP Notify Packet | 2911 | | | 2912 | 18 | CLOSE - the HIP Association Closing Packet | 2913 | | | 2914 | 19 | CLOSE_ACK - the HIP Closing Acknowledgment | 2915 | | Packet | 2916 +------------------+------------------------------------------------+ 2918 Table 10: HIP packets and packet type values 2920 Packets consist of the fixed header as described in Section 5.1, 2921 followed by the parameters. The parameter part, in turn, consists of 2922 zero or more TLV-coded parameters. 2924 In addition to the base packets, other packet types may be defined 2925 later in separate specifications. For example, support for mobility 2926 and multi-homing is not included in this specification. 2928 See Notation (Section 2.2) for the notation used in the operations. 2930 In the future, an optional upper-layer payload MAY follow the HIP 2931 header. The Next Header field in the header indicates if there is 2932 additional data following the HIP header. The HIP packet, however, 2933 MUST NOT be fragmented. This limits the size of the possible 2934 additional data in the packet. 2936 5.3.1. I1 - the HIP Initiator Packet 2938 The HIP header values for the I1 packet: 2940 Header: 2941 Packet Type = 1 2942 SRC HIT = Initiator's HIT 2943 DST HIT = Responder's HIT, or NULL 2945 IP ( HIP ( DH_GROUP_LIST ) ) 2947 The I1 packet contains the fixed HIP header and the Initiator's 2948 DH_GROUP_LIST. 2950 Valid control bits: none 2952 The Initiator receives the Responder's HIT either from a DNS lookup 2953 of the Responder's FQDN (see 5205-bis), from some other repository, 2954 or from a local table. If the Initiator does not know the 2955 Responder's HIT, it may attempt to use opportunistic mode by using 2956 NULL (all zeros) as the Responder's HIT. See also "HIP Opportunistic 2957 Mode" (Section 4.1.8). 2959 Since the I1 packet is so easy to spoof even if it were signed, no 2960 attempt is made to add to its generation or processing cost. 2962 The Initiator includes a DH_GROUP_LIST parameter in the I1 packet to 2963 inform the Responder of its preferred DH Group IDs. Note that the 2964 DH_GROUP_LIST in the I1 packet is not protected by a signature. 2966 Implementations MUST be able to handle a storm of received I1 2967 packets, discarding those with common content that arrive within a 2968 small time delta. 2970 5.3.2. R1 - the HIP Responder Packet 2972 The HIP header values for the R1 packet: 2974 Header: 2975 Packet Type = 2 2976 SRC HIT = Responder's HIT 2977 DST HIT = Initiator's HIT 2979 IP ( HIP ( [ R1_COUNTER, ] 2980 PUZZLE, 2981 DIFFIE_HELLMAN, 2982 HIP_CIPHER, 2983 HOST_ID, 2984 HIT_SUITE_LIST, 2985 DH_GROUP_LIST, 2986 [ ECHO_REQUEST_SIGNED, ] 2987 HIP_SIGNATURE_2 ) 2988 <, ECHO_REQUEST_UNSIGNED >i) 2990 Valid control bits: A 2992 If the Responder's HI is an anonymous one, the A control MUST be set. 2994 The Initiator's HIT MUST match the one received in the I1 packet if 2995 the R1 is a response to an I1. If the Responder has multiple HIs, 2996 the Responder's HIT used MUST match Initiator's request. If the 2997 Initiator used opportunistic mode, the Responder may select freely 2998 among its HIs. See also "HIP Opportunistic Mode" (Section 4.1.8). 3000 The R1 packet generation counter is used to determine the currently 3001 valid generation of puzzles. The value is increased periodically, 3002 and it is RECOMMENDED that it is increased at least as often as 3003 solutions to old puzzles are no longer accepted. 3005 The Puzzle contains a Random #I and the difficulty #K. The 3006 difficulty #K indicates the number of lower-order bits, in the puzzle 3007 hash result, that must be zeros; see Section 4.1.2. The Random #I is 3008 not covered by the signature and must be zeroed during the signature 3009 calculation, allowing the sender to select and set the #I into a 3010 precomputed R1 packet just prior sending it to the peer. 3012 The Responder selects the Diffie-Hellman public value based on the 3013 Initiator's preference expressed in the DH_GROUP_LIST parameter in 3014 the I1 packet. The Responder sends back its own preference based on 3015 which it chose the DH public value as DH_GROUP_LIST. This allows the 3016 Initiator to determine whether its own DH_GROUP_LIST in the sent I1 3017 packet was manipulated by an attacker. 3019 The Diffie-Hellman public value is ephemeral, and values SHOULD NOT 3020 be reused across different HIP sessions. Once the Responder has 3021 received a valid response to an R1 packet, that Diffie-Hellman value 3022 SHOULD be deprecated. It it is possible that the Responder has sent 3023 the same Diffie-Hellman value to different hosts simultaneously in 3024 corresponding R1 packets and those responses should also be accepted. 3025 However, as a defense against I1 packet storms, an implementation MAY 3026 propose, and re-use unless avoidable, the same Diffie-Hellman value 3027 for a period of time, for example, 15 minutes. By using a small 3028 number of different puzzles for a given Diffie-Hellman value, the R1 3029 packets can be precomputed and delivered as quickly as I1 packets 3030 arrive. A scavenger process should clean up unused Diffie-Hellman 3031 values and puzzles. 3033 Re-using Diffie-Hellman public values opens up the potential security 3034 risk of more than one Initiator ending up with the same keying 3035 material (due to faulty random number generators). Also, more than 3036 one Initiator using the same Responder public key half may lead to 3037 potentially easier cryptographic attacks and to imperfect forward 3038 security. 3040 However, these risks involved in re-using the same public value are 3041 statistical; that is, the authors are not aware of any mechanism that 3042 would allow manipulation of the protocol so that the risk of the re- 3043 use of any given Responder Diffie-Hellman public key would differ 3044 from the base probability. Consequently, it is RECOMMENDED that 3045 Responders avoid re-using the same DH key with multiple Initiators, 3046 but because the risk is considered statistical and not known to be 3047 manipulable, the implementations MAY re-use a key in order to ease 3048 resource-constrained implementations and to increase the probability 3049 of successful communication with legitimate clients even under an I1 3050 packet storm. In particular, when it is too expensive to generate 3051 enough precomputed R1 packets to supply each potential Initiator with 3052 a different DH key, the Responder MAY send the same DH key to several 3053 Initiators, thereby creating the possibility of multiple legitimate 3054 Initiators ending up using the same Responder-side public key. 3055 However, as soon as the Responder knows that it will use a particular 3056 DH key, it SHOULD stop offering it. This design is aimed to allow 3057 resource-constrained Responders to offer services under I1 packet 3058 storms and to simultaneously make the probability of DH key re-use 3059 both statistical and as low as possible. 3061 If a future version of this protocol is considered, we strongly 3062 recommend that these issues be studied again. Especially, the 3063 current design allows hosts to become potentially more vulnerable to 3064 a statistical, low-probability problem during I1 packet storm attacks 3065 than what they are if no attack is taking place; whether this is 3066 acceptable or not should be reconsidered in the light of any new 3067 experience gained. 3069 The HIP_CIPHER contains the encryption algorithms supported by the 3070 Responder to encrypt the contents of the ENCRYPTED parameter, in the 3071 order of preference. All implementations MUST support AES [RFC3602]. 3073 The HIT_SUITE_LIST parameter is an ordered list of the Responder's 3074 preferred and supported HIT Suites. The list allows the Initiator to 3075 determine whether its own source HIT matches any suite supported by 3076 the Responder. 3078 The ECHO_REQUEST_SIGNED and ECHO_REQUEST_UNSIGNED parameters contain 3079 data that the sender wants to receive unmodified in the corresponding 3080 response packet in the ECHO_RESPONSE_SIGNED or ECHO_RESPONSE_UNSIGNED 3081 parameter. The R1 packet may contain zero or more 3082 ECHO_REQUEST_UNSIGNED parameters as described in Section 3083 Section 5.2.20. 3085 The signature is calculated over the whole HIP packet, after setting 3086 the Initiator's HIT, header checksum, as well as the Opaque field and 3087 the Random #I in the PUZZLE parameter temporarily to zero, and 3088 excluding any parameters that follow the signature, as described in 3089 Section 5.2.14. This allows the Responder to use precomputed R1s. 3091 The Initiator SHOULD validate this signature. It MUST check that the 3092 Responder's HI matches with the one expected, if any. 3094 5.3.3. I2 - the Second HIP Initiator Packet 3096 The HIP header values for the I2 packet: 3098 Header: 3099 Type = 3 3100 SRC HIT = Initiator's HIT 3101 DST HIT = Responder's HIT 3103 IP ( HIP ( [R1_COUNTER,] 3104 SOLUTION, 3105 DIFFIE_HELLMAN, 3106 HIP_CIPHER, 3107 ENCRYPTED { HOST_ID } or HOST_ID, 3108 [ ECHO_RESPONSE_SIGNED ,] 3109 HIP_MAC, 3110 HIP_SIGNATURE 3111 <, ECHO_RESPONSE_UNSIGNED>i ) ) 3113 Valid control bits: A 3115 The HITs used MUST match the ones used in the R1. 3117 If the Initiator's HI is an anonymous one, the A control MUST be set. 3119 The Initiator MAY include an unmodified copy of the R1_COUNTER 3120 parameter received in the corresponding R1 packet into the I2 packet. 3122 The Solution contains the Random #I from R1 and the computed #J. The 3123 low-order #K bits of the RHASH(I | ... | J) MUST be zero. 3125 The Diffie-Hellman value is ephemeral. If precomputed, a scavenger 3126 process should clean up unused Diffie-Hellman values. The Responder 3127 MAY re-use Diffie-Hellman values under some conditions as specified 3128 in Section 5.3.2. 3130 The HIP_CIPHER contains the single encryption transform selected by 3131 the Initiator, that it uses to encrypt the ENCRYPTED parameters. The 3132 chosen cipher MUST correspond to one of the ciphers offered by the 3133 Responder in the R1. All implementations MUST support AES [RFC3602]. 3135 The Initiator's HI MAY be encrypted using the HIP_CIPHER encryption 3136 algorithm. The keying material is derived from the Diffie-Hellman 3137 exchanged as defined in Section 6.5. 3139 The ECHO_RESPONSE_SIGNED and ECHO_RESPONSE_UNSIGNED contain the 3140 unmodified Opaque data copied from the corresponding echo request 3141 parameter(s). 3143 The HMAC value in the HIP_MAC parameter is calculated over the whole 3144 HIP packet, excluding any parameters after the HIP_MAC, as described 3145 in Section 6.4.1. The Responder MUST validate the HIP_MAC. 3147 The signature is calculated over the whole HIP packet, excluding any 3148 parameters after the HIP_SIGNATURE, as described in Section 5.2.13. 3149 The Responder MUST validate this signature. The Responder uses the 3150 HI in the packet or a HI acquired by some other means for verifying 3151 the signature. 3153 5.3.4. R2 - the Second HIP Responder Packet 3155 The HIP header values for the R2 packet: 3157 Header: 3158 Packet Type = 4 3159 SRC HIT = Responder's HIT 3160 DST HIT = Initiator's HIT 3162 IP ( HIP ( HIP_MAC_2, HIP_SIGNATURE ) ) 3164 Valid control bits: none 3166 The HIP_MAC_2 is calculated over the whole HIP packet, with 3167 Responder's HOST_ID parameter concatenated with the HIP packet. The 3168 HOST_ID parameter is removed after the HMAC calculation. The 3169 procedure is described in Section 6.4.1. 3171 The signature is calculated over the whole HIP packet. 3173 The Initiator MUST validate both the HIP_MAC and the signature. 3175 5.3.5. UPDATE - the HIP Update Packet 3177 Support for the UPDATE packet is MANDATORY. 3179 The HIP header values for the UPDATE packet: 3181 Header: 3182 Packet Type = 16 3183 SRC HIT = Sender's HIT 3184 DST HIT = Recipient's HIT 3186 IP ( HIP ( [SEQ, ACK, ] HIP_MAC, HIP_SIGNATURE ) ) 3188 Valid control bits: None 3190 The UPDATE packet contains mandatory HIP_MAC and HIP_SIGNATURE 3191 parameters, and other optional parameters. 3193 The UPDATE packet contains zero or one SEQ parameter. The presence 3194 of a SEQ parameter indicates that the receiver MUST acknowledge the 3195 the UPDATE. An UPDATE that does not contain a SEQ but only an ACK 3196 parameter is simply an acknowledgment of a previous UPDATE and itself 3197 MUST NOT be acknowledged by a separate ACK. UPDATE packets without 3198 SEQ parameters do not require an acknowledgment and do not require 3199 processing in relative order to other UPDATE packets. 3201 An UPDATE packet contains zero or one ACK parameters. The ACK 3202 parameter echoes the SEQ sequence number of the UPDATE packet being 3203 ACKed. A host MAY choose to acknowledge more than one UPDATE packet 3204 at a time; e.g., the ACK may contain the last two SEQ values 3205 received, for resilience against ACK loss. ACK values are not 3206 cumulative; each received unique SEQ value requires at least one 3207 corresponding ACK value in reply. Received ACKs that are redundant 3208 are ignored. Hosts MUST implement the processing of ACKs with 3209 multiple SEQ numbers even if they do not implement sending ACKs with 3210 multiple SEQ numbers. 3212 The UPDATE packet may contain both a SEQ and an ACK parameter. In 3213 this case, the ACK is being piggybacked on an outgoing UPDATE. In 3214 general, UPDATEs carrying SEQ SHOULD be ACKed upon completion of the 3215 processing of the UPDATE. A host MAY choose to hold the UPDATE 3216 carrying ACK for a short period of time to allow for the possibility 3217 of piggybacking the ACK parameter, in a manner similar to TCP delayed 3218 acknowledgments. 3220 A sender MAY choose to forgo reliable transmission of a particular 3221 UPDATE (e.g., it becomes overcome by events). The semantics are such 3222 that the receiver MUST acknowledge the UPDATE, but the sender MAY 3223 choose to not care about receiving the ACK. 3225 UPDATEs MAY be retransmitted without incrementing SEQ. If the same 3226 subset of parameters is included in multiple UPDATEs with different 3227 SEQs, the host MUST ensure that the receiver's processing of the 3228 parameters multiple times will not result in a protocol error. 3230 5.3.6. NOTIFY - the HIP Notify Packet 3232 Implementing the NOTIFY packet is optional. The NOTIFY packet MAY be 3233 used to provide information to a peer. Typically, NOTIFY is used to 3234 indicate some type of protocol error or negotiation failure. NOTIFY 3235 packets are unacknowledged. The receiver can handle the packet only 3236 as informational, and SHOULD NOT change its HIP state (see 3237 Section 4.4.2) based purely on a received NOTIFY packet. 3239 The HIP header values for the NOTIFY packet: 3241 Header: 3242 Packet Type = 17 3243 SRC HIT = Sender's HIT 3244 DST HIT = Recipient's HIT, or zero if unknown 3246 IP ( HIP (i, [HOST_ID, ] HIP_SIGNATURE) ) 3248 Valid control bits: None 3250 The NOTIFY packet is used to carry one or more NOTIFICATION 3251 parameters. 3253 5.3.7. CLOSE - the HIP Association Closing Packet 3255 The HIP header values for the CLOSE packet: 3257 Header: 3258 Packet Type = 18 3259 SRC HIT = Sender's HIT 3260 DST HIT = Recipient's HIT 3262 IP ( HIP ( ECHO_REQUEST_SIGNED, HIP_MAC, HIP_SIGNATURE ) ) 3264 Valid control bits: none 3266 The sender MUST include an ECHO_REQUEST_SIGNED used to validate 3267 CLOSE_ACK received in response, and both a HIP_MAC and a signature 3268 (calculated over the whole HIP packet). 3270 The receiver peer MUST reply with a CLOSE_ACK containing an 3271 ECHO_RESPONSE_SIGNED corresponding to the received 3272 ECHO_REQUEST_SIGNED. 3274 5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet 3276 The HIP header values for the CLOSE_ACK packet: 3278 Header: 3279 Packet Type = 19 3280 SRC HIT = Sender's HIT 3281 DST HIT = Recipient's HIT 3283 IP ( HIP ( ECHO_RESPONSE_SIGNED, HIP_MAC, HIP_SIGNATURE ) ) 3285 Valid control bits: none 3287 The sender MUST include both an HMAC and signature (calculated over 3288 the whole HIP packet). 3290 The receiver peer MUST validate the ECHO_RESPONSE_SIGNED and validate 3291 both the HIP_MAC and the signature if the receiver has state for a 3292 HIP association. 3294 5.4. ICMP Messages 3296 When a HIP implementation detects a problem with an incoming packet, 3297 and it either cannot determine the identity of the sender of the 3298 packet or does not have any existing HIP association with the sender 3299 of the packet, it MAY respond with an ICMP packet. Any such replies 3300 MUST be rate-limited as described in [RFC4443]. In most cases, the 3301 ICMP packet has the Parameter Problem type (12 for ICMPv4, 4 for 3302 ICMPv6), with the Pointer field pointing to the field that caused the 3303 ICMP message to be generated. 3305 5.4.1. Invalid Version 3307 If a HIP implementation receives a HIP packet that has an 3308 unrecognized HIP version number, it SHOULD respond, rate-limited, 3309 with an ICMP packet with type Parameter Problem, with the Pointer 3310 pointing to the Version/RES. byte in the HIP header. 3312 5.4.2. Other Problems with the HIP Header and Packet Structure 3314 If a HIP implementation receives a HIP packet that has other 3315 unrecoverable problems in the header or packet format, it MAY 3316 respond, rate-limited, with an ICMP packet with type Parameter 3317 Problem, the Pointer pointing to the field that failed to pass the 3318 format checks. However, an implementation MUST NOT send an ICMP 3319 message if the checksum fails; instead, it MUST silently drop the 3320 packet. 3322 5.4.3. Invalid Puzzle Solution 3324 If a HIP implementation receives an I2 packet that has an invalid 3325 puzzle solution, the behavior depends on the underlying version of 3326 IP. If IPv6 is used, the implementation SHOULD respond with an ICMP 3327 packet with type Parameter Problem, the Pointer pointing to the 3328 beginning of the Puzzle solution #J field in the SOLUTION payload in 3329 the HIP message. 3331 If IPv4 is used, the implementation MAY respond with an ICMP packet 3332 with the type Parameter Problem, copying enough of bytes from the I2 3333 message so that the SOLUTION parameter fits into the ICMP message, 3334 the Pointer pointing to the beginning of the Puzzle solution #J 3335 field, as in the IPv6 case. Note, however, that the resulting ICMPv4 3336 message exceeds the typical ICMPv4 message size as defined in 3337 [RFC0792]. 3339 5.4.4. Non-Existing HIP Association 3341 If a HIP implementation receives a CLOSE or UPDATE packet, or any 3342 other packet whose handling requires an existing association, that 3343 has either a Receiver or Sender HIT that does not match with any 3344 existing HIP association, the implementation MAY respond, rate- 3345 limited, with an ICMP packet with the type Parameter Problem. The 3346 Pointer of the ICMP Parameter Problem packet is set pointing to the 3347 beginning of the first HIT that does not match. 3349 A host MUST NOT reply with such an ICMP if it receives any of the 3350 following messages: I1, R2, I2, R2, and NOTIFY packet. When 3351 introducing new packet types, a specification SHOULD define the 3352 appropriate rules for sending or not sending this kind of ICMP reply. 3354 6. Packet Processing 3356 Each host is assumed to have a single HIP protocol implementation 3357 that manages the host's HIP associations and handles requests for new 3358 ones. Each HIP association is governed by a conceptual state 3359 machine, with states defined above in Section 4.4. The HIP 3360 implementation can simultaneously maintain HIP associations with more 3361 than one host. Furthermore, the HIP implementation may have more 3362 than one active HIP association with another host; in this case, HIP 3363 associations are distinguished by their respective HITs. It is not 3364 possible to have more than one HIP association between any given pair 3365 of HITs. Consequently, the only way for two hosts to have more than 3366 one parallel association is to use different HITs, at least at one 3367 end. 3369 The processing of packets depends on the state of the HIP 3370 association(s) with respect to the authenticated or apparent 3371 originator of the packet. A HIP implementation determines whether it 3372 has an active association with the originator of the packet based on 3373 the HITs. In the case of user data carried in a specific transport 3374 format, the transport format document specifies how the incoming 3375 packets are matched with the active associations. 3377 6.1. Processing Outgoing Application Data 3379 In a HIP host, an application can send application-level data using 3380 an identifier specified via the underlying API. The API can be a 3381 backwards-compatible API (see [RFC5338]), using identifiers that look 3382 similar to IP addresses, or a completely new API, providing enhanced 3383 services related to Host Identities. Depending on the HIP 3384 implementation, the identifier provided to the application may be 3385 different; for example, it can be a HIT or an IP address. 3387 The exact format and method for transferring the user data from the 3388 source HIP host to the destination HIP host is defined in the 3389 corresponding transport format document. The actual data is 3390 transferred in the network using the appropriate source and 3391 destination IP addresses. 3393 In this document, conceptual processing rules are defined only for 3394 the base case where both hosts have only single usable IP addresses; 3395 the multi-address multi-homing case is specified separately. 3397 The following conceptual algorithm describes the steps that are 3398 required for handling outgoing datagrams destined to a HIT. 3400 1. If the datagram has a specified source address, it MUST be a HIT. 3401 If it is not, the implementation MAY replace the source address 3402 with a HIT. Otherwise, it MUST drop the packet. 3404 2. If the datagram has an unspecified source address, the 3405 implementation MUST choose a suitable source HIT for the 3406 datagram. Selecting the source HIT is subject to local policy. 3408 3. If there is no active HIP association with the given HIT pair, one MUST be created by running the base 3410 exchange. While waiting for the base exchange to complete, the 3411 implementation SHOULD queue at least one packet per HIP 3412 association to be formed, and it MAY queue more than one. 3414 4. Once there is an active HIP association for the given HIT pair, the outgoing datagram is passed to 3416 transport handling. The possible transport formats are defined 3417 in separate documents, of which the ESP transport format for HIP 3418 is mandatory for all HIP implementations. 3420 5. Before sending the packet, the HITs in the datagram are replaced 3421 with suitable IP addresses. For IPv6, the rules defined in 3423 [RFC3484] SHOULD be followed. Note that this HIT-to-IP-address 3424 conversion step MAY also be performed at some other point in the 3425 stack, e.g., before wrapping the packet into the output format. 3427 6.2. Processing Incoming Application Data 3429 The following conceptual algorithm describes the incoming datagram 3430 handling when HITs are used at the receiving host as application- 3431 level identifiers. More detailed steps for processing packets are 3432 defined in corresponding transport format documents. 3434 1. The incoming datagram is mapped to an existing HIP association, 3435 typically using some information from the packet. For example, 3436 such mapping may be based on the ESP Security Parameter Index 3437 (SPI). 3439 2. The specific transport format is unwrapped, in a way depending on 3440 the transport format, yielding a packet that looks like a 3441 standard (unencrypted) IP packet. If possible, this step SHOULD 3442 also verify that the packet was indeed (once) sent by the remote 3443 HIP host, as identified by the HIP association. 3445 Depending on the used transport mode, the verification method can 3446 vary. While the HI (as well as HIT) is used as the higher-layer 3447 identifier, the verification method has to verify that the data 3448 packet was sent by the correct node identity and that the actual 3449 identity maps to this particular HIT. When using ESP transport 3450 format [I-D.ietf-hip-rfc5202-bis], the verification is done using 3451 the SPI value in the data packet to find the corresponding SA 3452 with associated HIT and key, and decrypting the packet with that 3453 associated key. 3455 3. The IP addresses in the datagram are replaced with the HITs 3456 associated with the HIP association. Note that this IP-address- 3457 to-HIT conversion step MAY also be performed at some other point 3458 in the stack. 3460 4. The datagram is delivered to the upper layer (e.g., UDP or TCP). 3461 When demultiplexing the datagram, the right upper-layer socket is 3462 selected based on the HITs. 3464 6.3. Solving the Puzzle 3466 This subsection describes the details for solving the puzzle. 3468 In the R1 packet, the values #I and #K are sent in network byte 3469 order. Similarly, in the I2 packet, the values #I and #J are sent in 3470 network byte order. The hash is created by concatenating, in network 3471 byte order, the following data, in the following order and using the 3472 RHASH algorithm: 3474 n-bit random value #I (where n is RHASH_len), in network byte 3475 order, as appearing in the R1 and I2 packets. 3477 128-bit Initiator's HIT, in network byte order, as appearing in 3478 the HIP Payload in the R1 and I2 packets. 3480 128-bit Responder's HIT, in network byte order, as appearing in 3481 the HIP Payload in the R1 and I2 packets. 3483 n-bit random value #J (where n is RHASH_len), in network byte 3484 order, as appearing in the I2 packet. 3486 In a valid response puzzle, the #K low-order bits of the resulting 3487 RHASH digest MUST be zero. 3489 Notes: 3491 i) The length of the data to be hashed is variable depending on 3492 the output length of the Responder's hash function RHASH. 3494 ii) All the data in the hash input MUST be in network byte order. 3496 iii) The order of the Initiator's and Responder's HITs are 3497 different in the R1 and I2 packets; see Section 5.1. Care must be 3498 taken to copy the values in the right order to the hash input. 3500 iv) For a puzzle #I, there may exist multiple valid puzzle 3501 solutions #J. 3503 The following procedure describes the processing steps involved, 3504 assuming that the Responder chooses to precompute the R1 packets: 3506 Precomputation by the Responder: 3507 Sets up the puzzle difficulty #K. 3508 Creates a signed R1 and caches it. 3510 Responder: 3511 Selects a suitable cached R1. 3512 Generates a random number #I. 3513 Sends #I and #K in an R1. 3514 Saves #I and #K for a Delta time. 3516 Initiator: 3517 Generates repeated attempts to solve the puzzle until a matching 3518 #J is found: 3519 Ltrunc( RHASH( #I | HIT-I | HIT-R | #J ), #K ) == 0 3520 Sends #I and #J in an I2. 3522 Responder: 3523 Verifies that the received #I is a saved one. 3524 Finds the right #K based on #I. 3525 Computes V := Ltrunc( RHASH( #I | HIT-I | HIT-R | #J ), #K ) 3526 Rejects if V != 0 3527 Accept if V == 0 3529 6.4. HIP_MAC and SIGNATURE Calculation and Verification 3531 The following subsections define the actions for processing HIP_MAC, 3532 HIP_MAC_2, HIP_SIGNATURE and HIP_SIGNATURE_2 parameters. The 3533 HIP_MAC_2 parameter is contained in the R2 packet. The 3534 HIP_SIGNATURE_2 parameter is contained in the R1 packet. The 3535 HIP_SIGNATURE and HIP_MAC parameter are contained in other HIP 3536 control packets. 3538 6.4.1. HMAC Calculation 3540 The HMAC uses RHASH as underlying hash function. The type of RHASH 3541 depends on the HIT Suite of the Responder. Hence, HMAC-SHA-1 3542 [RFC2404] is used for HIT Suites RSA/DSA/SHA-1 and ECDSA_LOW/SHA-1 3543 and HMAC-SHA-256 [RFC4868] for ECDSA/SHA-384. 3545 The following process applies both to the HIP_MAC and HIP_MAC_2 3546 parameters. When processing HIP_MAC_2, the difference is that the 3547 HIP_MAC calculation includes a pseudo HOST_ID field containing the 3548 Responder's information as sent in the R1 packet earlier. 3550 Both the Initiator and the Responder should take some care when 3551 verifying or calculating the HIP_MAC_2. Specifically, the Initiator 3552 has to preserve the HOST_ID exactly as it was received in the R1 3553 packet until it receives the HIP_MAC_2 in the R2 packet. 3555 The scope of the calculation for HIP_MAC is: 3557 HMAC: { HIP header | [ Parameters ] } 3559 where Parameters include all HIP parameters of the packet that is 3560 being calculated with Type values ranging from 1 to (HIP_MAC's Type 3561 value - 1) and exclude parameters with Type values greater or equal 3562 to HIP_MAC's Type value. 3564 During HIP_MAC calculation, the following applies: 3566 o In the HIP header, the Checksum field is set to zero. 3568 o In the HIP header, the Header Length field value is calculated to 3569 the beginning of the HIP_MAC parameter. 3571 Parameter order is described in Section 5.2.1. 3573 The scope of the calculation for HIP_MAC_2 is: 3575 HIP_MAC_2: { HIP header | [ Parameters ] | HOST_ID } 3577 where Parameters include all HIP parameters for the packet that is 3578 being calculated with Type values from 1 to (HIP_MAC_2's Type value - 3579 1) and exclude parameters with Type values greater or equal to 3580 HIP_MAC_2's Type value. 3582 During HIP_MAC_2 calculation, the following applies: 3584 o In the HIP header, the Checksum field is set to zero. 3586 o In the HIP header, the Header Length field value is calculated to 3587 the beginning of the HIP_MAC_2 parameter and increased by the 3588 length of the concatenated HOST_ID parameter length (including 3589 type and length fields). 3591 o HOST_ID parameter is exactly in the form it was received in the R1 3592 packet from the Responder. 3594 Parameter order is described in Section 5.2.1, except that the 3595 HOST_ID parameter in this calculation is added to the end. 3597 The HIP_MAC parameter is defined in Section 5.2.11 and the HIP_MAC_2 3598 parameter in Section 5.2.12. The HMAC calculation and verification 3599 process (the process applies both to HIP_MAC and HIP_MAC_2 except 3600 where HIP_MAC_2 is mentioned separately) is as follows: 3602 Packet sender: 3604 1. Create the HIP packet, without the HIP_MAC, HIP_SIGNATURE, 3605 HIP_SIGNATURE_2, or any other parameter with greater Type value 3606 than the HIP_MAC parameter has. 3608 2. In case of HIP_MAC_2 calculation, add a HOST_ID (Responder) 3609 parameter to the end of the packet. 3611 3. Calculate the Header Length field in the HIP header including the 3612 added HOST_ID parameter in case of HIP_MAC_2. 3614 4. Compute the HMAC using either HIP-gl or HIP-lg integrity key 3615 retrieved from KEYMAT as defined in Section 6.5. 3617 5. In case of HIP_MAC_2, remove the HOST_ID parameter from the 3618 packet. 3620 6. Add the HIP_MAC parameter to the packet and any parameter with 3621 greater Type value than the HIP_MAC's (HIP_MAC_2's) that may 3622 follow, including possible HIP_SIGNATURE or HIP_SIGNATURE_2 3623 parameters 3625 7. Recalculate the Length field in the HIP header. 3627 Packet receiver: 3629 1. Verify the HIP header Length field. 3631 2. Remove the HIP_MAC or HIP_MAC_2 parameter, as well as all other 3632 parameters that follow it with greater Type value including 3633 possible HIP_SIGNATURE or HIP_SIGNATURE_2 fields, saving the 3634 contents if they are needed later. 3636 3. In case of HIP_MAC_2, build and add a HOST_ID parameter (with 3637 Responder information) to the packet. The HOST_ID parameter 3638 should be identical to the one previously received from the 3639 Responder. 3641 4. Recalculate the HIP packet length in the HIP header and clear the 3642 Checksum field (set it to all zeros). In case of HIP_MAC_2, the 3643 length is calculated with the added HOST_ID parameter. 3645 5. Compute the HMAC using either HIP-gl or HIP-lg integrity key as 3646 defined in Section 6.5 and verify it against the received HMAC. 3648 6. Set Checksum and Header Length field in the HIP header to 3649 original values. 3651 7. In case of HIP_MAC_2, remove the HOST_ID parameter from the 3652 packet before further processing. 3654 6.4.2. Signature Calculation 3656 The following process applies both to the HIP_SIGNATURE and 3657 HIP_SIGNATURE_2 parameters. When processing the HIP_SIGNATURE_2, the 3658 only difference is that instead of the HIP_SIGNATURE parameter, the 3659 HIP_SIGNATURE_2 parameter is used, and the Initiator's HIT and PUZZLE 3660 Opaque and Random #I fields are cleared (set to all zeros) before 3661 computing the signature. The HIP_SIGNATURE parameter is defined in 3662 Section 5.2.13 and the HIP_SIGNATURE_2 parameter in Section 5.2.14. 3664 The scope of the calculation for HIP_SIGNATURE and HIP_SIGNATURE_2 3665 is: 3667 HIP_SIGNATURE: { HIP header | [ Parameters ] } 3669 where Parameters include all HIP parameters for the packet that is 3670 being calculated with Type values from 1 to (HIP_SIGNATURE's Type 3671 value - 1). 3673 During signature calculation, the following applies: 3675 o In the HIP header, the Checksum field is set to zero. 3677 o In the HIP header, the Header Length field value is calculated to 3678 the beginning of the HIP_SIGNATURE parameter. 3680 The parameter order is described in Section 5.2.1. 3682 HIP_SIGNATURE_2: { HIP header | [ Parameters ] } 3684 where Parameters include all HIP parameters for the packet that is 3685 being calculated with Type values ranging from 1 to 3686 (HIP_SIGNATURE_2's Type value - 1). 3688 During signature calculation, the following apply: 3690 o In the HIP header, the Initiator's HIT field and Checksum fields 3691 are set to zero. 3693 o In the HIP header, the Header Length field value is calculated to 3694 the beginning of the HIP_SIGNATURE_2 parameter. 3696 o PUZZLE parameter's Opaque and Random #I fields are set to zero. 3698 Parameter order is described in Section 5.2.1. 3700 The signature calculation and verification process (the process 3701 applies both to HIP_SIGNATURE and HIP_SIGNATURE_2 except in the case 3702 where HIP_SIGNATURE_2 is separately mentioned) is as follows: 3704 Packet sender: 3706 1. Create the HIP packet without the HIP_SIGNATURE parameter or any 3707 other parameters that follow the HIP_SIGNATURE parameter. 3709 2. Calculate the Length field and zero the Checksum field in the HIP 3710 header. In case of HIP_SIGNATURE_2, set Initiator's HIT field in 3711 the HIP header as well as PUZZLE parameter's Opaque and Random #I 3712 fields to zero. 3714 3. Compute the signature using the private key corresponding to the 3715 Host Identifier (public key). 3717 4. Add the HIP_SIGNATURE parameter to the packet. 3719 5. Add any parameters that follow the HIP_SIGNATURE parameter. 3721 6. Recalculate the Length field in the HIP header, and calculate the 3722 Checksum field. 3724 Packet receiver: 3726 1. Verify the HIP header Length field and checksum. 3728 2. Save the contents of the HIP_SIGNATURE parameter and any other 3729 parameters following the HIP_SIGNATURE parameter and remove them 3730 from the packet. 3732 3. Recalculate the HIP packet Length in the HIP header and clear the 3733 Checksum field (set it to all zeros). In case of 3734 HIP_SIGNATURE_2, set Initiator's HIT field in the HIP header as 3735 well as PUZZLE parameter's Opaque and Random #I fields to zero. 3737 4. Compute the signature and verify it against the received 3738 signature using the packet sender's Host Identity (public key). 3740 5. Restore the original packet by adding removed parameters (in step 3741 2) and resetting the values that were set to zero (in step 3). 3743 The verification can use either the HI received from a HIP packet, 3744 the HI from a DNS query, if the FQDN has been received in the HOST_ID 3745 packet or one received by some other means. 3747 6.5. HIP KEYMAT Generation 3749 HIP keying material is derived from the Diffie-Hellman session key, 3750 Kij, produced during the HIP base exchange (see Section 4.1.3). The 3751 Initiator has Kij during the creation of the I2 packet, and the 3752 Responder has Kij once it receives the I2 packet. This is why I2 can 3753 already contain encrypted information. 3755 The KEYMAT is derived by feeding Kij into a Hash-based Key Derivation 3756 Function (HKDF) [RFC5869] using the RHASH hash function. 3758 where 3760 info = sort(HIT-I | HIT-R) 3761 salt = #I | #J 3763 Sort(HIT-I | HIT-R) is defined as the network byte order 3764 concatenation of the two HITs, with the smaller HIT preceding the 3765 larger HIT, resulting from the numeric comparison of the two HITs 3766 interpreted as positive (unsigned) 128-bit integers in network byte 3767 order. The #I and #J values are from the puzzle and its solution 3768 that were exchanged in R1 and I2 messages when this HIP association 3769 was set up. Both hosts have to store #I and #J values for the HIP 3770 association for future use. 3772 The initial keys are drawn sequentially in the order that is 3773 determined by the numeric comparison of the two HITs, with comparison 3774 method described in the previous paragraph. HOST_g denotes the host 3775 with the greater HIT value, and HOST_l the host with the lower HIT 3776 value. 3778 The drawing order for the initial keys is as follows: 3780 HIP-gl encryption key for HOST_g's ENCRYPTED parameter 3782 HIP-gl integrity (HMAC) key for HOST_g's outgoing HIP packets 3784 HIP-lg encryption key for HOST_l's ENCRYPTED parameter 3786 HIP-lg integrity (HMAC) key for HOST_l's outgoing HIP packets 3788 The number of bits drawn for a given algorithm is the "natural" size 3789 of the keys. For the mandatory algorithms, the following sizes 3790 apply: 3792 AES 128 or 256 bits 3794 SHA-1 160 bits 3796 SHA-256 256 bits 3798 SHA-384 384 bits 3799 NULL 0 bits 3801 If other key sizes are used, they MUST be treated as different 3802 encryption algorithms and defined separately. 3804 6.6. Initiation of a HIP Base Exchange 3806 An implementation may originate a HIP base exchange to another host 3807 based on a local policy decision, usually triggered by an application 3808 datagram, in much the same way that an IPsec IKE key exchange can 3809 dynamically create a Security Association. Alternatively, a system 3810 may initiate a HIP exchange if it has rebooted or timed out, or 3811 otherwise lost its HIP state, as described in Section 4.5.4. 3813 The implementation prepares an I1 packet and sends it to the IP 3814 address that corresponds to the peer host. The IP address of the 3815 peer host may be obtained via conventional mechanisms, such as DNS 3816 lookup. The I1 packet contents are specified in Section 5.3.1. The 3817 selection of which source or destination Host Identity to use, if a 3818 Initiator or Responder has more than one to choose from, is typically 3819 a policy decision. 3821 The following steps define the conceptual processing rules for 3822 initiating a HIP base exchange: 3824 1. The Initiator receives one or more of the Responder's HITs and 3825 one or more addresses either from a DNS lookup of the Responder's 3826 FQDN, from some other repository, or from a local database. If 3827 the Initiator does not know the Responder's HIT, it may attempt 3828 opportunistic mode by using NULL (all zeros) as the Responder's 3829 HIT (see also "HIP Opportunistic Mode" (Section 4.1.8)). If the 3830 Initiator can choose from multiple Responder HITs, it selects a 3831 HIT for which the Initiator supports the HIT Suite. 3833 2. The Initiator sends an I1 packet to one of the Responder's 3834 addresses. The selection of which address to use is a local 3835 policy decision. 3837 3. The Initiator includes the DH_GROUP_LIST in the I1 packet. The 3838 selection and order of DH Group IDs in the DH_GROUP_LIST MUST be 3839 stored by the Initiator because this list is needed for later R1 3840 processing. In most cases, the preferences regarding the DH 3841 Groups will be static, so no per-association storage is 3842 necessary. 3844 4. Upon sending an I1 packet, the sender transitions to state I1- 3845 SENT, starts a timer for which the timeout value SHOULD be larger 3846 than the worst-case anticipated RTT. The sender SHOULD also 3847 increment the timeout counter associated with the I1. 3849 5. Upon timeout, the sender SHOULD retransmit the I1 packet and 3850 restart the timer, up to a maximum of I1_RETRIES_MAX tries. 3852 6.6.1. Sending Multiple I1 Packets in Parallel 3854 For the sake of minimizing the session establishment latency, an 3855 implementation MAY send the same I1 packet to more than one of the 3856 Responder's addresses. However, it MUST NOT send to more than three 3857 (3) Responder addresses in parallel. Furthermore, upon timeout, the 3858 implementation MUST refrain from sending the same I1 packet to 3859 multiple addresses. That is, if it retries to initialize the 3860 connection after a timeout, it MUST NOT send the I1 packet to more 3861 than one destination address. These limitations are placed in order 3862 to avoid congestion of the network, and potential DoS attacks that 3863 might occur, e.g., because someone's claim to have hundreds or 3864 thousands of addresses could generate a huge number of I1 packets 3865 from the Initiator. 3867 As the Responder is not guaranteed to distinguish the duplicate I1 3868 packets it receives at several of its addresses (because it avoids 3869 storing states when it answers back an R1 packet), the Initiator may 3870 receive several duplicate R1 packets. 3872 The Initiator SHOULD then select the initial preferred destination 3873 address using the source address of the selected received R1, and use 3874 the preferred address as a source address for the I2 packet. 3875 Processing rules for received R1s are discussed in Section 6.8. 3877 6.6.2. Processing Incoming ICMP Protocol Unreachable Messages 3879 A host may receive an ICMP 'Destination Protocol Unreachable' message 3880 as a response to sending a HIP I1 packet. Such a packet may be an 3881 indication that the peer does not support HIP, or it may be an 3882 attempt to launch an attack by making the Initiator believe that the 3883 Responder does not support HIP. 3885 When a system receives an ICMP 'Destination Protocol Unreachable' 3886 message while it is waiting for an R1 packet, it MUST NOT terminate 3887 waiting. It MAY continue as if it had not received the ICMP message, 3888 and send a few more I1 packets. Alternatively, it MAY take the ICMP 3889 message as a hint that the peer most probably does not support HIP, 3890 and return to state UNASSOCIATED earlier than otherwise. However, at 3891 minimum, it MUST continue waiting for an R1 packet for a reasonable 3892 time before returning to UNASSOCIATED. 3894 6.7. Processing Incoming I1 Packets 3896 An implementation SHOULD reply to an I1 with an R1 packet, unless the 3897 implementation is unable or unwilling to set up a HIP association. 3898 If the implementation is unable to set up a HIP association, the host 3899 SHOULD send an ICMP Destination Protocol Unreachable, 3900 Administratively Prohibited, message to the I1 packet source IP 3901 address. If the implementation is unwilling to set up a HIP 3902 association, the host MAY ignore the I1 packet. This latter case may 3903 occur during a DoS attack such as an I1 packet flood. 3905 The implementation SHOULD be able to handle a storm of received I1 3906 packets, discarding those with common content that arrive within a 3907 small time delta. 3909 A spoofed I1 packet can result in an R1 attack on a system. An R1 3910 packet sender MUST have a mechanism to rate-limit R1 packets sent to 3911 an address. 3913 It is RECOMMENDED that the HIP state machine does not transition upon 3914 sending an R1 packet. 3916 The following steps define the conceptual processing rules for 3917 responding to an I1 packet: 3919 1. The Responder MUST check that the Responder's HIT in the received 3920 I1 packet is either one of its own HITs or NULL. Otherwise it 3921 must drop the packet. 3923 2. If the Responder is in ESTABLISHED state, the Responder MAY 3924 respond to this with an R1 packet, prepare to drop an existing 3925 HIP security association with the peer, and stay at ESTABLISHED 3926 state. 3928 3. If the Responder is in I1-SENT state, it MUST make a comparison 3929 between the sender's HIT and its own (i.e., the receiver's) HIT. 3930 If the sender's HIT is greater than its own HIT, it should drop 3931 the I1 packet and stay at I1-SENT. If the sender's HIT is 3932 smaller than its own HIT, it SHOULD send the R1 packet and stay 3933 at I1-SENT. The HIT comparison is performed as defined in 3934 Section 6.5. 3936 4. If the implementation chooses to respond to the I1 packet with an 3937 R1 packet, it creates a new R1 or selects a precomputed R1 3938 according to the format described in Section 5.3.2. It creates 3939 or chooses an R1 that contains its most preferred DH public value 3940 that is also contained in the DH_GROUP_LIST in the I1 packet. If 3941 no suitable DH Group ID was contained in the DH_GROUP_LIST in the 3942 I1 packet, it sends an R1 with any suitable DH public key. 3944 5. If the received Responder's HIT in the I1 is NULL, the Responder 3945 selects a HIT with a the same HIT Suite as the Initiator's HIT. 3946 If this HIT Suite is not supported by the Responder, it SHOULD 3947 select a REQUIRED HIT Suite from Section 5.2.9, which is 3948 currently RSA/DSA/SHA-1. Other than that, selecting the HIT is a 3949 local policy matter. 3951 6. The Responder sends the R1 packet to the source IP address of the 3952 I1 packet. 3954 6.7.1. R1 Management 3956 All compliant implementations MUST be able to produce R1 packets. An 3957 R1 packet MAY be precomputed. An R1 packet MAY be reused for time 3958 Delta T, which is implementation dependent, and SHOULD be deprecated 3959 and not used once a valid response I2 packet has been received from 3960 an Initiator. During an I1 message storm, an R1 packet MAY be re- 3961 used beyond this limit. R1 information MUST NOT be discarded until 3962 Delta S after T. Time S is the delay needed for the last I2 packet 3963 to arrive back to the Responder. 3965 Implementations that support multiple DH groups MAY pre-compute R1 3966 packets for each supported group so that incoming I1 packets with 3967 different DH Group IDs in the DH_GROUP_LIST can be served quickly. 3969 An implementation MAY keep state about received I1 packets and match 3970 the received I2 packets against the state, as discussed in 3971 Section 4.1.1. 3973 6.7.2. Handling Malformed Messages 3975 If an implementation receives a malformed I1 packet, it SHOULD NOT 3976 respond with a NOTIFY message, as such practice could open up a 3977 potential denial-of-service threat. Instead, it MAY respond with an 3978 ICMP packet, as defined in Section 5.4. 3980 6.8. Processing Incoming R1 Packets 3982 A system receiving an R1 packet MUST first check to see if it has 3983 sent an I1 packet to the originator of the R1 packet (i.e., it is in 3984 state I1-SENT). If so, it SHOULD process the R1 as described below, 3985 send an I2 packet, and transition to state I2-SENT, setting a timer 3986 to protect the I2 packet. If the system is in state I2-SENT, it MAY 3987 respond to the R1 packet if the R1 packet has a larger R1 generation 3988 counter; if so, it should drop its state due to processing the 3989 previous R1 packet and start over from state I1-SENT. If the system 3990 is in any other state with respect to that host, the system SHOULD 3991 silently drop the R1 packet. 3993 When sending multiple I1 packets, an Initiator SHOULD wait for a 3994 small amount of time after the first R1 reception to allow possibly 3995 multiple R1 packets to arrive, and it SHOULD respond to an R1 packet 3996 among the set with the largest R1 generation counter. 3998 The following steps define the conceptual processing rules for 3999 responding to an R1 packet: 4001 1. A system receiving an R1 MUST first check to see if it has sent 4002 an I1 packet to the originator of the R1 packet (i.e., it has a 4003 HIP association that is in state I1-SENT and that is associated 4004 with the HITs in the R1). Unless the I1 packet was sent in 4005 opportunistic mode (see Section 4.1.8), the IP addresses in the 4006 received R1 packet SHOULD be ignored and, when looking up the 4007 right HIP association, the received R1 packet SHOULD be matched 4008 against the associations using only the HITs. If a match 4009 exists, the system should process the R1 packet as described 4010 below. 4012 2. Otherwise, if the system is in any other state than I1-SENT or 4013 I2-SENT with respect to the HITs included in the R1 packet, it 4014 SHOULD silently drop the R1 packet and remain in the current 4015 state. 4017 3. If the HIP association state is I1-SENT or I2-SENT, the received 4018 Initiator's HIT MUST correspond to the HIT used in the original 4019 I1. Also, the Responder's HIT MUST correspond to the one used 4020 in the I1, unless the I1 packet contained a NULL HIT. 4022 4. The system SHOULD validate the R1 signature before applying 4023 further packet processing, according to Section 5.2.14. 4025 5. If the HIP association state is I1-SENT, and multiple valid R1 4026 packets are present, the system MUST select from among the R1 4027 packets with the largest R1 generation counter. 4029 6. The system MUST check that the Initiator HIT Suite is contained 4030 in the HIT_SUITE_LIST parameter in the R1 packet (i.e., the 4031 Initiator's HIT Suite is supported by the Responder). If the 4032 HIT Suite is supported by the Responder, the system proceeds 4033 normally. Otherwise, the system MAY stay in state I1-sent and 4034 restart the BEX by sending a new I1 packet with an Initiator HIT 4035 that is supported by the Responder and hence is contained in the 4036 HIT_SUITE_LIST in the R1 packet. The system MAY abort the BEX 4037 if no suitable source HIT is available. The system SHOULD wait 4038 for an acceptable time span to allow further R1 packets with 4039 higher R1 generation counters or different HIT and HIT Suites to 4040 arrive before restarting or aborting the BEX. 4042 7. The system MUST check that the DH Group ID in the DIFFIE_HELLMAN 4043 parameter in the R1 matches the first DH Suite ID in the 4044 Responder's DH_GROUP_LIST in the R1 packet that was also 4045 contained in the Initiator's DH_GROUP_LIST in the I1 packet. If 4046 the DH Group ID of the DIFFIE_HELLMAN parameter does not express 4047 the Responder's best choice, the Initiator can conclude that the 4048 DH_GROUP_LIST in the I1 packet was adversely modified. In such 4049 case, the Initiator MAY send a new I1 packet, however, it SHOULD 4050 NOT change its preference in the DH_GROUP_LIST in the new I1 4051 packet. Alternatively, the Initiator MAY abort the HIP base 4052 exchange. 4054 8. If the HIP association state is I2-SENT, the system MAY re-enter 4055 state I1-SENT and process the received R1 packet if it has a 4056 larger R1 generation counter than the R1 packet responded to 4057 previously. 4059 9. The R1 packet may have the A bit set -- in this case, the system 4060 MAY choose to refuse it by dropping the R1 packet and returning 4061 to state UNASSOCIATED. The system SHOULD consider dropping the 4062 R1 packet only if it used a NULL HIT in I1 packet. If the A bit 4063 is set, the Responder's HIT is anonymous and SHOULD NOT be 4064 stored permanently. 4066 10. The system SHOULD attempt to validate the HIT against the 4067 received Host Identity by using the received Host Identity to 4068 construct a HIT and verify that it matches the Sender's HIT. 4070 11. The system MUST store the received R1 generation counter for 4071 future reference. 4073 12. The system attempts to solve the puzzle in the R1 packet. The 4074 system MUST terminate the search after exceeding the remaining 4075 lifetime of the puzzle. If the puzzle is not successfully 4076 solved, the implementation MAY either resend the I1 packet 4077 within the retry bounds or abandon the HIP base exchange. 4079 13. The system computes standard Diffie-Hellman keying material 4080 according to the public value and Group ID provided in the 4081 DIFFIE_HELLMAN parameter. The Diffie-Hellman keying material 4082 Kij is used for key extraction as specified in Section 6.5. 4084 14. The system selects the HIP_CIPHER ID from the choices presented 4085 in the R1 packet and uses the selected values subsequently when 4086 generating and using encryption keys, and when sending the I2 4087 packet. If the proposed alternatives are not acceptable to the 4088 system, it may either resend an I1 within the retry bounds or 4089 abandon the HIP base exchange. 4091 15. The system initializes the remaining variables in the associated 4092 state, including Update ID counters. 4094 16. The system prepares and sends an I2 packet, as described in 4095 Section 5.3.3. 4097 17. The system SHOULD start a timer whose timeout value SHOULD be 4098 larger than the worst-case anticipated RTT, and MUST increment a 4099 timeout counter associated with the I2 packet. The sender 4100 SHOULD retransmit the I2 packet upon a timeout and restart the 4101 timer, up to a maximum of I2_RETRIES_MAX tries. 4103 18. If the system is in state I1-SENT, it SHALL transition to state 4104 I2-SENT. If the system is in any other state, it remains in the 4105 current state. 4107 6.8.1. Handling of Malformed Messages 4109 If an implementation receives a malformed R1 message, it MUST 4110 silently drop the packet. Sending a NOTIFY or ICMP would not help, 4111 as the sender of the R1 packet typically doesn't have any state. An 4112 implementation SHOULD wait for some more time for a possibly well- 4113 formed R1, after which it MAY try again by sending a new I1 packet. 4115 6.9. Processing Incoming I2 Packets 4117 Upon receipt of an I2 packet, the system MAY perform initial checks 4118 to determine whether the I2 packet corresponds to a recent R1 packet 4119 that has been sent out, if the Responder keeps such state. For 4120 example, the sender could check whether the I2 packet is from an 4121 address or HIT for which the Responder has recently received an I1. 4122 The R1 packet may have had Opaque data included that was echoed back 4123 in the I2 packet. If the I2 packet is considered to be suspect, it 4124 MAY be silently discarded by the system. 4126 Otherwise, the HIP implementation SHOULD process the I2 packet. This 4127 includes validation of the puzzle solution, generating the Diffie- 4128 Hellman key, possibly decrypting the Initiator's Host Identity, 4129 verifying the signature, creating state, and finally sending an R2 4130 packet. 4132 The following steps define the conceptual processing rules for 4133 responding to an I2 packet: 4135 1. The system MAY perform checks to verify that the I2 packet 4136 corresponds to a recently sent R1 packet. Such checks are 4137 implementation dependent. See Appendix A for a description of 4138 an example implementation. 4140 2. The system MUST check that the Responder's HIT corresponds to 4141 one of its own HITs and MUST drop the packet otherwise. 4143 3. The system MUST further check that the Initiator's HIT Suite is 4144 supported. The Responder SHOULD silently drop I2 packets with 4145 unsupported Initiator HITs. 4147 4. If the system's state machine is in the R2-SENT state, the 4148 system MAY check if the newly received I2 packet is similar to 4149 the one that triggered moving to R2-SENT. If so, it MAY 4150 retransmit a previously sent R2 packet, reset the R2-SENT timer, 4151 and the state machine stays in R2-SENT. 4153 5. If the system's state machine is in the I2-SENT state, the 4154 system makes a comparison between its local and sender's HITs 4155 (similarly as in Section 6.5). If the local HIT is smaller than 4156 the sender's HIT, it should drop the I2 packet, use the peer 4157 Diffie-Hellman key and nonce #I from the R1 packet received 4158 earlier, and get the local Diffie-Hellman key and nonce #J from 4159 the I2 packet sent to the peer earlier. Otherwise, the system 4160 should process the received I2 packet and drop any previously 4161 derived Diffie-Hellman keying material Kij it might have formed 4162 upon sending the I2 packet previously. The peer Diffie-Hellman 4163 key and the nonce #J are taken from the just arrived I2 packet. 4164 The local Diffie-Hellman key and the nonce I are the ones that 4165 were sent earlier in the R1 packet. 4167 6. If the system's state machine is in the I1-SENT state, and the 4168 HITs in the I2 packet match those used in the previously sent I1 4169 packet, the system uses this received I2 packet as the basis for 4170 the HIP association it was trying to form, and stops 4171 retransmitting I1 packets (provided that the I2 packet passes 4172 the additional checks below). 4174 7. If the system's state machine is in any other state than R2- 4175 SENT, the system SHOULD check that the echoed R1 generation 4176 counter in the I2 packet is within the acceptable range if the 4177 counter is included. Implementations MUST accept puzzles from 4178 the current generation and MAY accept puzzles from earlier 4179 generations. If the generation counter in the newly received I2 4180 packet is outside the accepted range, the I2 packet is stale 4181 (and perhaps replayed) and SHOULD be dropped. 4183 8. The system MUST validate the solution to the puzzle by computing 4184 the hash described in Section 5.3.3 using the same RHASH 4185 algorithm. 4187 9. The I2 packet MUST have a single value in the HIP_CIPHER 4188 parameter, which MUST match one of the values offered to the 4189 Initiator in the R1 packet. 4191 10. The system must derive Diffie-Hellman keying material Kij based 4192 on the public value and Group ID in the DIFFIE_HELLMAN 4193 parameter. This key is used to derive the HIP association keys, 4194 as described in Section 6.5. If the Diffie-Hellman Group ID is 4195 unsupported, the I2 packet is silently dropped. 4197 11. The encrypted HOST_ID is decrypted by the Initiator's encryption 4198 key defined in Section 6.5. If the decrypted data is not a 4199 HOST_ID parameter, the I2 packet is silently dropped. 4201 12. The implementation SHOULD also verify that the Initiator's HIT 4202 in the I2 packet corresponds to the Host Identity sent in the I2 4203 packet. (Note: some middleboxes may not able to make this 4204 verification.) 4206 13. The system MUST verify the HIP_MAC according to the procedures 4207 in Section 5.2.11. 4209 14. The system MUST verify the HIP_SIGNATURE according to 4210 Section 5.2.13 and Section 5.3.3. 4212 15. If the checks above are valid, then the system proceeds with 4213 further I2 processing; otherwise, it discards the I2 and its 4214 state machine remains in the same state. 4216 16. The I2 packet may have the A bit set -- in this case, the system 4217 MAY choose to refuse it by dropping the I2 and the state machine 4218 returns to state UNASSOCIATED. If the A bit is set, the 4219 Initiator's HIT is anonymous and should not be stored 4220 permanently. 4222 17. The system initializes the remaining variables in the associated 4223 state, including Update ID counters. 4225 18. Upon successful processing of an I2 message when the system's 4226 state machine is in state UNASSOCIATED, I1-SENT, I2-SENT, or R2- 4227 SENT, an R2 packet is sent and the system's state machine 4228 transitions to state R2-SENT. 4230 19. Upon successful processing of an I2 packet when the system's 4231 state machine is in state ESTABLISHED, the old HIP association 4232 is dropped and a new one is installed, an R2 packet is sent, and 4233 the system's state machine transitions to R2-SENT. 4235 20. Upon the system's state machine transitioning to R2-SENT, the 4236 system starts a timer. The state machine transitions to 4237 ESTABLISHED if some data has been received on the incoming HIP 4238 association, or an UPDATE packet has been received (or some 4239 other packet that indicates that the peer system's state machine 4240 has moved to ESTABLISHED). If the timer expires (allowing for 4241 maximal amount of retransmissions of I2 packets), the state 4242 machine transitions to ESTABLISHED. 4244 6.9.1. Handling of Malformed Messages 4246 If an implementation receives a malformed I2 message, the behavior 4247 SHOULD depend on how many checks the message has already passed. If 4248 the puzzle solution in the message has already been checked, the 4249 implementation SHOULD report the error by responding with a NOTIFY 4250 packet. Otherwise, the implementation MAY respond with an ICMP 4251 message as defined in Section 5.4. 4253 6.10. Processing of Incoming R2 Packets 4255 An R2 packet received in states UNASSOCIATED, I1-SENT, or ESTABLISHED 4256 results in the R2 packet being dropped and the state machine staying 4257 in the same state. If an R2 packet is received in state I2-SENT, it 4258 MUST be processed. 4260 The following steps define the conceptual processing rules for an 4261 incoming R2 packet: 4263 1. If the system is in any other state than I2-SENT, the R2 packet 4264 is silently dropped. 4266 2. The system MUST verify that the HITs in use correspond to the 4267 HITs that were received in the R1 packet that caused the 4268 transition to the I1-SENT state. 4270 3. The system MUST verify the HIP_MAC_2 according to the procedures 4271 in Section 5.2.12. 4273 4. The system MUST verify the HIP signature according to the 4274 procedures in Section 5.2.13. 4276 5. If any of the checks above fail, there is a high probability of 4277 an ongoing man-in-the-middle or other security attack. The 4278 system SHOULD act accordingly, based on its local policy. 4280 6. Upon successful processing of the R2 packet, the state machine 4281 transitions to state ESTABLISHED. 4283 6.11. Sending UPDATE Packets 4285 A host sends an UPDATE packet when it intends to update some 4286 information related to a HIP association. There are a number of 4287 possible scenarios when this can occur, e.g., mobility management and 4288 rekeying of an existing ESP Security Association. The following 4289 paragraphs define the conceptual rules for sending an UPDATE packet 4290 to the peer. Additional steps can be defined in other documents 4291 where the UPDATE packet is used. 4293 The sequence of UPDATE messages is indicated by their SEQ parameter. 4294 Before sending an UPDATE message, the system first determines whether 4295 there are any outstanding UPDATE messages that may conflict with the 4296 new UPDATE message under consideration. When multiple UPDATEs are 4297 outstanding (not yet acknowledged), the sender must assume that such 4298 UPDATEs may be processed in an arbitrary order by the receiver. 4299 Therefore, any new UPDATEs that depend on a previous outstanding 4300 UPDATE being successfully received and acknowledged MUST be postponed 4301 until reception of the necessary ACK(s) occurs. One way to prevent 4302 any conflicts is to only allow one outstanding UPDATE at a time. 4303 However, allowing multiple UPDATEs may improve the performance of 4304 mobility and multihoming protocols. 4306 The following steps define the conceptual processing rules for 4307 sending UPDATE packets. 4309 1. The first UPDATE packet is sent with Update ID of zero. 4310 Otherwise, the system increments its own Update ID value by one 4311 before continuing the steps below. 4313 2. The system creates an UPDATE packet that contains a SEQ parameter 4314 with the current value of Update ID. The UPDATE packet MAY also 4315 include zero or more ACKs of the peer's Update ID(s) from 4316 previously received UPDATE SEQ parameter(s) 4318 3. The system sends the created UPDATE packet and starts an UPDATE 4319 timer. The default value for the timer is 2 * RTT estimate. If 4320 multiple UPDATEs are outstanding, multiple timers are in effect. 4322 4. If the UPDATE timer expires, the UPDATE is resent. The UPDATE 4323 can be resent UPDATE_RETRY_MAX times. The UPDATE timer SHOULD be 4324 exponentially backed off for subsequent retransmissions. If no 4325 acknowledgment is received from the peer after UPDATE_RETRY_MAX 4326 times, the HIP association is considered to be broken and the 4327 state machine SHOULD move from state ESTABLISHED to state CLOSING 4328 as depicted in Section 4.4.4. The UPDATE timer is cancelled upon 4329 receiving an ACK from the peer that acknowledges receipt of the 4330 UPDATE. 4332 6.12. Receiving UPDATE Packets 4334 When a system receives an UPDATE packet, its processing depends on 4335 the state of the HIP association and the presence and values of the 4336 SEQ and ACK parameters. Typically, an UPDATE message also carries 4337 optional parameters whose handling is defined in separate documents. 4339 For each association, a host stores the peer's next expected in- 4340 sequence Update ID ("peer Update ID"). Initially, this value is 4341 zero. Update ID comparisons of "less than" and "greater than" are 4342 performed with respect to a circular sequence number space. Hence, a 4343 wrap around after 2^32 updates has to be expected and MUST be handled 4344 accordingly. 4346 The sender MAY send multiple outstanding UPDATE messages. These 4347 messages are processed in the order in which they are received at the 4348 receiver (i.e., no re-sequencing is performed). When processing 4349 UPDATEs out-of-order, the receiver MUST keep track of which UPDATEs 4350 were previously processed, so that duplicates or retransmissions are 4351 ACKed and not reprocessed. A receiver MAY choose to define a receive 4352 window of Update IDs that it is willing to process at any given time, 4353 and discard received UPDATEs falling outside of that window. 4355 The following steps define the conceptual processing rules for 4356 receiving UPDATE packets. 4358 1. If there is no corresponding HIP association, the implementation 4359 MAY reply with an ICMP Parameter Problem, as specified in 4360 Section 5.4.4. 4362 2. If the association is in the ESTABLISHED state and the SEQ (but 4363 not ACK) parameter is present, the UPDATE is processed and 4364 replied to as described in Section 6.12.1. 4366 3. If the association is in the ESTABLISHED state and the ACK (but 4367 not SEQ) parameter is present, the UPDATE is processed as 4368 described in Section 6.12.2. 4370 4. If the association is in the ESTABLISHED state and there is both 4371 an ACK and SEQ in the UPDATE, the ACK is first processed as 4372 described in Section 6.12.2, and then the rest of the UPDATE is 4373 processed as described in Section 6.12.1. 4375 6.12.1. Handling a SEQ Parameter in a Received UPDATE Message 4377 The following steps define the conceptual processing rules for 4378 handling a SEQ parameter in a received UPDATE packet. 4380 1. If the Update ID in the received SEQ is not the next in the 4381 sequence of Update IDs and is greater than the receiver's window 4382 for new UPDATEs, the packet MUST be dropped. 4384 2. If the Update ID in the received SEQ corresponds to an UPDATE 4385 that has recently been processed, the packet is treated as a 4386 retransmission. The HIP_MAC verification (next step) MUST NOT be 4387 skipped. (A byte-by-byte comparison of the received and a stored 4388 packet would be acceptable, though.) It is recommended that a 4389 host caches UPDATE packets sent with ACKs to avoid the cost of 4390 generating a new ACK packet to respond to a replayed UPDATE. The 4391 system MUST acknowledge, again, such (apparent) UPDATE message 4392 retransmissions but SHOULD also consider rate-limiting such 4393 retransmission responses to guard against replay attacks. 4395 3. The system MUST verify the HIP_MAC in the UPDATE packet. If the 4396 verification fails, the packet MUST be dropped. 4398 4. The system MAY verify the SIGNATURE in the UPDATE packet. If the 4399 verification fails, the packet SHOULD be dropped and an error 4400 message logged. 4402 5. If a new SEQ parameter is being processed, the parameters in the 4403 UPDATE are then processed. The system MUST record the Update ID 4404 in the received SEQ parameter, for replay protection. 4406 6. An UPDATE acknowledgment packet with ACK parameter is prepared 4407 and sent to the peer. This ACK parameter MAY be included in a 4408 separate UPDATE or piggybacked in an UPDATE with SEQ parameter, 4409 as described in Section 5.3.5. The ACK parameter MAY acknowledge 4410 more than one of the peer's Update IDs. 4412 6.12.2. Handling an ACK Parameter in a Received UPDATE Packet 4414 The following steps define the conceptual processing rules for 4415 handling an ACK parameter in a received UPDATE packet. 4417 1. The sequence number reported in the ACK must match with an UPDATE 4418 packet sent earlier that has not already been acknowledged. If 4419 no match is found or if the ACK does not acknowledge a new 4420 UPDATE, the packet MUST either be dropped if no SEQ parameter is 4421 present, or the processing steps in Section 6.12.1 are followed. 4423 2. The system MUST verify the HIP_MAC in the UPDATE packet. If the 4424 verification fails, the packet MUST be dropped. 4426 3. The system MAY verify the SIGNATURE in the UPDATE packet. If the 4427 verification fails, the packet SHOULD be dropped and an error 4428 message logged. 4430 4. The corresponding UPDATE timer is stopped (see Section 6.11) so 4431 that the now acknowledged UPDATE is no longer retransmitted. If 4432 multiple UPDATEs are acknowledged, multiple timers are stopped. 4434 6.13. Processing of NOTIFY Packets 4436 Processing of NOTIFY packets is OPTIONAL. If processed, any errors 4437 in a received NOTIFICATION parameter SHOULD be logged. Received 4438 errors MUST be considered only as informational, and the receiver 4439 SHOULD NOT change its HIP state (see Section 4.4.2) purely based on 4440 the received NOTIFY message. 4442 6.14. Processing CLOSE Packets 4444 When the host receives a CLOSE message, it responds with a CLOSE_ACK 4445 message and moves to CLOSED state. (The authenticity of the CLOSE 4446 message is verified using both HIP_MAC and SIGNATURE). This 4447 processing applies whether or not the HIP association state is 4448 CLOSING in order to handle simultaneous CLOSE messages from both ends 4449 that cross in flight. 4451 The HIP association is not discarded before the host moves to the 4452 UNASSOCIATED state. 4454 Once the closing process has started, any new need to send data 4455 packets triggers creating and establishing of a new HIP association, 4456 starting with sending of an I1 packet. 4458 If there is no corresponding HIP association, the CLOSE packet is 4459 dropped. 4461 6.15. Processing CLOSE_ACK Packets 4463 When a host receives a CLOSE_ACK message, it verifies that it is in 4464 CLOSING or CLOSED state and that the CLOSE_ACK was in response to the 4465 CLOSE. A host can map CLOSE messages to CLOSE_ACK messages by using 4466 the included ECHO_RESPONSE_SIGNED that was sent in the CLOSE_ACK 4467 packet in response to the ECHO_REQUEST_SIGNED in the CLOSE packet. 4469 The CLOSE_ACK contains the HIP_MAC and the SIGNATURE parameters for 4470 verification. The state is discarded when the state changes to 4471 UNASSOCIATED and, after that, the host MAY respond with an ICMP 4472 Parameter Problem to an incoming CLOSE message (see Section 5.4.4). 4474 6.16. Handling State Loss 4476 In the case of a system crash and unanticipated state loss, the 4477 system SHOULD delete the corresponding HIP state, including the 4478 keying material. That is, the state SHOULD NOT be stored in long- 4479 term storage. If the implementation does drop the state (as 4480 RECOMMENDED), it MUST also drop the peer's R1 generation counter 4481 value, unless a local policy explicitly defines that the value of 4482 that particular host is stored. An implementation MUST NOT store a 4483 peer's R1 generation counters by default, but storing R1 generation 4484 counter values, if done, MUST be configured by explicit HITs. 4486 7. HIP Policies 4488 There are a number of variables that will influence the HIP base 4489 exchanges that each host must support. All HIP implementations MUST 4490 support more than one simultaneous HI, at least one of which SHOULD 4491 be reserved for anonymous usage. Although anonymous HIs will be 4492 rarely used as Responders' HIs, they will be common for Initiators. 4493 Support for more than two HIs is RECOMMENDED. 4495 Initiators MAY use a different HI for different Responders to provide 4496 basic privacy. Whether such private HITs are used repeatedly with 4497 the same Responder and how long these HITs are used is decided by 4498 local policy and depends on the privacy requirements of the 4499 Initiator. 4501 The value of #K used in the HIP R1 must be chosen with care. Too 4502 high numbers of #K will exclude clients with weak CPUs because these 4503 devices cannot solve the puzzle within reasonable time. #K should 4504 only be raised if a Responder is under high load, i.e., it cannot 4505 process all incoming HIP handshakes any more. If a responder is not 4506 under high load, K SHOULD be 0. 4508 Responders that only respond to selected Initiators require an ACL, 4509 representing for which hosts they accept HIP base exchanges, and the 4510 preferred transform and local lifetimes. Wildcarding SHOULD be 4511 supported for such ACLs, and also for Responders that offer public or 4512 anonymous services. 4514 8. Security Considerations 4516 HIP is designed to provide secure authentication of hosts. HIP also 4517 attempts to limit the exposure of the host to various denial-of- 4518 service and man-in-the-middle (MitM) attacks. In doing so, HIP 4519 itself is subject to its own DoS and MitM attacks that potentially 4520 could be more damaging to a host's ability to conduct business as 4521 usual. 4523 Denial-of-service attacks often take advantage of asymmetries in the 4524 cost of an starting an association. One example of such asymmetry is 4525 the need of a Responder to store local state while a malicious 4526 Initiator can stay stateless. HIP makes no attempt to increase the 4527 cost of the start of state at the Initiator, but makes an effort to 4528 reduce the cost for the Responder. This is accomplished by having 4529 the Responder start the 3-way exchange instead of the Initiator, 4530 making the HIP protocol 4 packets long. In doing this, the first 4531 packet from the Responder, R1, becomes a 'stock' packet that the 4532 Responder MAY use many times, until some Initiator has provided a 4533 valid response to such an R1 packet. During an I1 packet storm, the 4534 host may reuse the same DH value also even if some Initiator has 4535 provided a valid response using that particular DH value. However, 4536 such behavior is discouraged and should be avoided. Using the same 4537 Diffie-Hellman values and random puzzle #I value has some risks. 4538 This risk needs to be balanced against a potential storm of HIP I1 4539 packets. 4541 This shifting of the start of state cost to the Initiator in creating 4542 the I2 HIP packet presents another DoS attack. The attacker can 4543 spoof the I1 packet and the Responder sends out the R1 HIP packet. 4544 This could conceivably tie up the 'Initiator' with evaluating the R1 4545 HIP packet, and creating the I2 packet. The defense against this 4546 attack is to simply ignore any R1 packet where a corresponding I1 4547 packet was not sent (as defined in Section 6.8 step 1). 4549 The R1 packet is considerably larger than the I1 packet. This 4550 asymmetry can be exploited in an reflection attack. A malicious 4551 attacker could spoof the IP address of a victim and send a flood of 4552 I1 messages to a powerful Responder. For each small I1 packet, the 4553 Responder would send a larger R1 packet to the victim. The 4554 difference in packet sizes can further amplify a flooding attack 4555 against the victim. To avoid such reflection attacks, the Responder 4556 SHOULD rate limit the sending of R1 packets in general or SHOULD rate 4557 limit the sending of R1 packets to a specific IP address. 4559 Floods of forged I2 packets form a second kind of DoS attack. Once 4560 the attacking Initiator has solved the puzzle, it can send packets 4561 with spoofed IP source addresses with either an invalid HIP signature 4562 or invalid encrypted HIP payload (in the ENCRYPTED parameter). This 4563 would take resources in the Responder's part to reach the point to 4564 discover that the I2 packet cannot be completely processed. The 4565 defense against this attack is after N bad I2 packets with the same 4566 puzzle solution, the Responder would discard any I2 packets that 4567 contain the given solution. This will shut down the attack. The 4568 attacker would have to request another R1 packet and use that to 4569 launch a new attack. The Responder could increase the value of #K 4570 while under attack. Keeping a list of solutions from malformed 4571 packets requires that the Responder keeps state for these malformed 4572 I2 packets. This state has to be kept until the R1 counter is 4573 increased. As malformed packets are generally filtered by their 4574 checksum before signature verification, only solutions in packets 4575 that are forged to pass the checksum and puzzle are put to the 4576 blacklist. In addition, a valid puzzle is required before a new list 4577 entry is created. Hence, attackers that intend to flood the 4578 blacklist must solve puzzles first. 4580 A third form of DoS attack is emulating the restart of state after a 4581 reboot of one of the peers. A restarting host would send an I1 4582 packet to the peers, which would respond with an R1 packet even if it 4583 were in the ESTABLISHED state. If the I1 packet were spoofed, the 4584 resulting R1 packet would be received unexpectedly by the spoofed 4585 host and would be dropped, as in the first case above. 4587 A fourth form of DoS attack is emulating closing of the HIP 4588 association. HIP relies on timers and a CLOSE/CLOSE_ACK handshake to 4589 explicitly signal the end of a HIP association. Because both CLOSE 4590 and CLOSE_ACK messages contain a HIP_MAC, an outsider cannot close a 4591 connection. The presence of an additional SIGNATURE allows 4592 middleboxes to inspect these messages and discard the associated 4593 state (for e.g., firewalling, SPI-based NATing, etc.). However, the 4594 optional behavior of replying to CLOSE with an ICMP Parameter Problem 4595 packet (as described in Section 5.4.4) might allow an attacker 4596 spoofing the source IP address to send CLOSE messages to launch 4597 reflection attacks. 4599 A fifth form of DoS attack is replaying R1s to cause the Initiator to 4600 solve stale puzzles and become out of synchronization with the 4601 Responder. The R1 generation counter is a monotonically increasing 4602 counter designed to protect against this attack, as described in 4603 Section 4.1.4. 4605 Man-in-the-middle attacks are difficult to defend against, without 4606 third-party authentication. A skillful MitM could easily handle all 4607 parts of HIP, but HIP indirectly provides the following protection 4608 from a MitM attack. If the Responder's HI is retrieved from a signed 4609 DNS zone, a certificate, or through some other secure means, the 4610 Initiator can use this to validate the R1 HIP packet. 4612 Likewise, if the Initiator's HI is in a secure DNS zone, a trusted 4613 certificate, or otherwise securely available, the Responder can 4614 retrieve the HI (after having got the I2 HIP packet) and verify that 4615 the HI indeed can be trusted. 4617 The HIP Opportunistic Mode concept has been introduced in this 4618 document, but this document does not specify what the semantics of 4619 such a connection setup are for applications. There are certain 4620 concerns with opportunistic mode, as discussed in Section 4.1.8. 4622 NOTIFY messages are used only for informational purposes and they are 4623 unacknowledged. A HIP implementation cannot rely solely on the 4624 information received in a NOTIFY message because the packet may have 4625 been replayed. An implementation SHOULD NOT change any state 4626 information purely based on a received NOTIFY message. 4628 Since not all hosts will ever support HIP, ICMP 'Destination Protocol 4629 Unreachable' messages are to be expected and may be used for a DoS 4630 attack. Against an Initiator, the attack would look like the 4631 Responder does not support HIP, but shortly after receiving the ICMP 4632 message, the Initiator would receive a valid R1 HIP packet. Thus, to 4633 protect from this attack, an Initiator SHOULD NOT react to an ICMP 4634 message until a reasonable delta time to get the real Responder's R1 4635 HIP packet. A similar attack against the Responder is more involved. 4636 Normally, if an I1 message received by a Responder was a bogus one 4637 sent by an attacker, the Responder may receive an ICMP message from 4638 the IP address the R1 message was sent to. However, a sophisticated 4639 attacker can try to take advantage of such a behavior and try to 4640 break up the HIP base exchange by sending such an ICMP message to the 4641 Responder before the Initiator has a chance to send a valid I2 4642 message. Hence, the Responder SHOULD NOT act on such an ICMP 4643 message. Especially, it SHOULD NOT remove any minimal state created 4644 when it sent the R1 HIP packet (if it did create one), but wait for 4645 either a valid I2 HIP packet or the natural timeout (that is, if R1 4646 packets are tracked at all). Likewise, the Initiator SHOULD ignore 4647 any ICMP message while waiting for an R2 HIP packet, and SHOULD 4648 delete any pending state only after a natural timeout. 4650 9. IANA Considerations 4652 IANA has reserved protocol number 139 for the Host Identity Protocol. 4654 This document defines a new 128-bit value under the CGA Message Type 4655 namespace [RFC3972], 0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA, to be 4656 used for HIT generation as specified in ORCHID 4657 [I-D.ietf-hip-rfc4843-bis]. 4659 This document uses HIP version number 2 for the four-bit Version 4660 field in a HIP protocol packet defined in [RFC5201]. 4662 This document also creates a set of new namespaces. These are 4663 described below. 4665 Packet Type 4667 The 7-bit Packet Type field in a HIP protocol packet describes the 4668 type of a HIP protocol message. It is defined in Section 5.1. 4669 The current values are defined in Sections 5.3.1 through 5.3.8. 4671 New values are assigned through IETF Review [RFC5226]. 4673 HIT Suite 4675 The four-bit HIT Suite ID uses the OGA field in the ORCHID to 4676 express the type of the HIT. This document defines two HIT Suites 4677 (see Appendix E). 4679 The HIT Suite ID is also carried in the four higher-order bits of 4680 the ID field in the HIT_SUITE_LIST parameter. The four lower- 4681 order bits are reserved for future extensions of the HIT Suite ID 4682 space beyond 16 values. 4684 At the time being, the HIT Suite uses only four bits because these 4685 bits have to be carried in the HIT. Using more bits for the HIT 4686 Suite ID reduces the cryptographic strength of the HIT. HIT Suite 4687 IDs must be allocated carefully to avoid namespace exhaustion. 4688 Moreover, deprecated IDs should be reused after an appropriate 4689 time span. If 16 Suite IDs prove insufficient and more HIT Suite 4690 IDs are needed concurrently, more bits can be used for the HIT 4691 Suite ID by using one HIT Suite ID (0) to indicate that more bits 4692 should be used. The HIT_SUITE_LIST parameter already supports 4693 8-bit HIT Suite IDs, should longer IDs be needed. Possible 4694 extensions of the HIT Suite ID space to accomodate eight bits and 4695 new HIT Suite IDs are defined through IETF Review. 4697 Parameter Type 4699 The 16-bit Type field in a HIP parameter describes the type of the 4700 parameter. It is defined in Section 5.2.1. The current values 4701 are defined in Sections 5.2.3 through 5.2.22. 4703 With the exception of the assigned Type codes, the Type codes 0 4704 through 1023 and 61440 through 65535 are reserved for future base 4705 protocol extensions, and are assigned through IETF Review. 4707 The Type codes 32768 through 49151 are reserved for 4708 experimentation. Types SHOULD be selected in a random fashion 4709 from this range, thereby reducing the probability of collisions. 4710 A method employing genuine randomness (such as flipping a coin) 4711 SHOULD be used. 4713 All other Type codes are assigned through First Come First Served, 4714 with Specification Required [RFC5226]. 4716 Group ID 4718 The eight-bit Group ID values appear in the DIFFIE_HELLMAN 4719 parameter and the DH_GROUP_LIST parameter and are defined in 4720 Section 5.2.6. New values are assigned through IETF Review. 4722 HIP Cipher ID 4724 The 16-bit Cipher ID values in a HIP_CIPHER parameter are defined 4725 in Section 5.2.7. New values either from the reserved or 4726 unassigned space are assigned through IETF Review. 4728 DI-Type 4730 The four-bit DI-Type values in a HOST_ID parameter are defined in 4731 Section 5.2.8. New values are assigned through IETF Review. 4733 Notify Message Type 4735 The 16-bit Notify Message Type values in a NOTIFICATION parameter 4736 are defined in Section 5.2.18. 4738 Notify Message Type values 1-10 are used for informing about 4739 errors in packet structures, values 11-20 for informing about 4740 problems in parameters containing cryptographic related material, 4741 values 21-30 for informing about problems in authentication or 4742 packet integrity verification. Parameter numbers above 30 can be 4743 used for informing about other types of errors or events. Values 4744 51-8191 are error types reserved to be allocated by IANA. Values 4745 8192-16383 are error types for experimentation. Values 16385- 4746 40959 are status types to be allocated by IANA, and values 40960- 4747 65535 are status types for experimentation. New values in ranges 4748 51-8191 and 16385-40959 are assigned through First Come First 4749 Served, with Specification Required. 4751 10. Acknowledgments 4753 The drive to create HIP came to being after attending the MALLOC 4754 meeting at the 43rd IETF meeting. Baiju Patel and Hilarie Orman 4755 really gave the original author, Bob Moskowitz, the assist to get HIP 4756 beyond 5 paragraphs of ideas. It has matured considerably since the 4757 early versions thanks to extensive input from IETFers. Most 4758 importantly, its design goals are articulated and are different from 4759 other efforts in this direction. Particular mention goes to the 4760 members of the NameSpace Research Group of the IRTF. Noel Chiappa 4761 provided valuable input at early stages of discussions about 4762 identifier handling and Keith Moore the impetus to provide 4763 resolvability. Steve Deering provided encouragement to keep working, 4764 as a solid proposal can act as a proof of ideas for a research group. 4766 Many others contributed; extensive security tips were provided by 4767 Steve Bellovin. Rob Austein kept the DNS parts on track. Paul 4768 Kocher taught Bob Moskowitz how to make the puzzle exchange expensive 4769 for the Initiator to respond, but easy for the Responder to validate. 4770 Bill Sommerfeld supplied the Birthday concept, which later evolved 4771 into the R1 generation counter, to simplify reboot management. Erik 4772 Nordmark supplied the CLOSE-mechanism for closing connections. 4773 Rodney Thayer and Hugh Daniels provided extensive feedback. In the 4774 early times of this document, John Gilmore kept Bob Moskowitz 4775 challenged to provide something of value. 4777 During the later stages of this document, when the editing baton was 4778 transferred to Pekka Nikander, the input from the early implementors 4779 was invaluable. Without having actual implementations, this document 4780 would not be on the level it is now. 4782 In the usual IETF fashion, a large number of people have contributed 4783 to the actual text or ideas. The list of these people include Jeff 4784 Ahrenholz, Francis Dupont, Derek Fawcus, George Gross, Andrew 4785 McGregor, Julien Laganier, Miika Komu, Mika Kousa, Jan Melen, Henrik 4786 Petander, Michael Richardson, Rene Hummen, Tim Shepard, Jorma Wall, 4787 and Jukka Ylitalo. Our apologies to anyone whose name is missing. 4789 Once the HIP Working Group was founded in early 2004, a number of 4790 changes were introduced through the working group process. Most 4791 notably, the original document was split in two, one containing the 4792 base exchange and the other one defining how to use ESP. Some 4793 modifications to the protocol proposed by Aura, et al., [AUR03] were 4794 added at a later stage. 4796 11. Changes from RFC 5201 4798 This section summarizes the changes made from [RFC5201]. 4800 11.1. Changes from draft-ietf-hip-rfc5201-bis-04 4802 o Moved this list farther to the back. 4804 o Clarifications of the Security Considerations section. One DoS 4805 defense mechanism was changed to be more effective and less prone 4806 to misuse. 4808 o Minor clarifications of the state machine. 4810 o Clarified text on HIP puzzle. 4812 o Added names and references for figures. 4814 o Extended the definitions section. 4816 o Added a reference to the HIP Version 1 certificate document. 4818 o Added Initiator, Responder, HIP association, and signed data to 4819 the definitions section. 4821 o Changed parameter figure for PUZZLE and SOLUTION to use 4822 RHASH_len/8 instead of n-byte. 4824 o Replaced occurrences of SHOULD not with SHOULD NOT. 4826 o Changed text to reflect the fact that several 4827 ECHO_REQUEST_UNSIGNED parameters may be present in an R1 and 4828 several ECHO_RESPONSE parameters may be present in an I2. 4830 o Added text on verifying the ECHO_RESPONSE_SIGNED parameter in 4831 CLOSE_ACK. 4833 o Changed wording from HMAC to HIP_MAC in Section 5.3.8. 4835 o Reflected fact that the UPDATE packet MAY include zero or more 4836 ACKs. 4838 o Added BEX to Definitions section. 4840 o Changed HIP_SIGNATURE algorithm field from 8 bit to 16 bit to 4841 achieve alignment with the HOST_ID parameters. 4843 o Fixed the wrong figures of the SEQ and ACK parameters. SEQ always 4844 contains ONE update ID. ACK may acknowledge SEVERAL update IDs. 4846 o Added wording that several NOTIFY parameters may be present in a 4847 HIP packet. 4849 o Changed wording for the ECHO_RESPONSE_SIGNED parameter. Also 4850 lifted the restriction that only one ECHO_RESPONSE_UNSIGNED 4851 parameter MUST be present in each HIP control packet. This did 4852 contradict the definition of the ECHO_RESPONSE_UNSIGNED parameter. 4854 o Changed IETF Consensus to IETF Review in IANA section. 4856 o Aligned use of I, J, and K. Now I is #I, J is #J and K is #K 4857 throughout the document. 4859 o Updated references. 4861 o Editorial changes. 4863 11.2. Changes from draft-ietf-hip-rfc5201-bis-03 4865 o Editorial changes to improve clarity and readability. 4867 o Removed obsoleted (not applicable) attack from security 4868 consideration section. 4870 o Added a requirement that hosts MUST support processing of ACK 4871 parameters with several SEQ numbers even when they do not support 4872 sending such parameters. 4874 o Removed note on memory bound puzzles. The use of memory bound 4875 puzzles was reconsidered but no convincing arguments for inclusion 4876 in this document have been made on the list. 4878 o Changed references to reference the new bis documents. 4880 o Specified the ECC curves and the hashes used for these. 4882 o Specified representation of ECC curves in the HI. 4884 o Added text on the dependency between RHASH and HMAC. 4886 o Rephrased part of the security considerations to make them 4887 clearer. 4889 o Clarified the use of HITs in opportunistic mode. 4891 o Clarified the difference between HIP_MAC and HIP_MAC_2 as well as 4892 between SIGNATURE and SIGNATURE_2. 4894 o Changed NOTIFY name for value 44 from SERVER_BUSY_PLEASE_RETRY to 4895 RESPONDER_BUSY_PLEASE_RETRY. 4897 o Mentioned that there are multiple valid puzzle solutions. 4899 11.3. Changes from draft-ietf-hip-rfc5201-bis-02 4901 o Added recommendation to not use puzzle #I twice for the same host 4902 to avoid identical key material. 4904 o Revised state machine and added missing event handling. 4906 o Added UNSUPPORTED_HIT_SUITE to NOTIFY to indicate unsupported HIT 4907 suites. 4909 o Revised parameter type numbers (corresponding to IANA allocations) 4910 and added missing "free for experimentation" range to the 4911 description. 4913 o Clarifying note on the use of the C bit in the parameter type 4914 numbers. 4916 11.4. Changes from draft-ietf-hip-rfc5201-bis-01 4918 o Changed RHASH-len to RHASH_len to avoid confusion in calculations 4919 (- could be minus) 4921 o Added RHASH_len to list of abbreviations 4923 o Fixed length of puzzle #I and #J to be 1*RHASH_len 4925 o Changed RHASH-len to RHASH_len to avoid confusion in calculations 4926 (- could be minus) 4928 o Added RHASH_len to list of abbreviations 4930 o Fixed length of puzzle #I and #J to be 1*RHASH_len 4932 o Included HIT_SUITEs. 4934 o Added DH negotiation to I1 and R1. 4936 o Added DH_LIST parameter. 4938 o Added text for DH Group negotiation. 4940 o Removed second DH public value from DH parameter. 4942 o Added ECC to HI generation. 4944 o Added Responder HIT selection to opportunistic mode. 4946 o Added ECDSA HI text and references (not complete yet). 4948 o Added separate section on aborting BEX. 4950 o Added separate section on downgrade attack prevention. 4952 o Added text about DH Group selection for use cases without I1. 4954 o Removed type range allocation for parameters related to HIP 4955 transform types. 4957 o New type range allocation for parameters that are only covered by 4958 a signature if a signature is present (Applies to DH_GROUP_LIST). 4960 o Renamed HIP_TRANSFORM to HIP_CIPHER and removed hashes from it - 4961 hashes are determined by RHASH. 4963 o The length of #I and #J for the puzzle now depends on RHASH. 4965 o New keymat generation. 4967 o Puzzle seed and solution now use RHASH and have variable length. 4969 o Moved timing definitions closer to state machine. 4971 o Simplified text regarding puzzle lifetime. 4973 o Clarified the description of the use of #I in the puzzle 4975 o Removed "Opportunistic mode" description from general definitions. 4977 o More consistency across the old RFC5201 text. Aligned 4978 capitalization and abbreviations. 4980 o Extended protocol overview to include restart option. 4982 o Extended state machine to include restart option because of 4983 unsupported Algorithms. 4985 o Replaced SHA-1 with SHA-256 for required implementation. 4987 o Added OGA list parameter (715) for detecting the Responder's set 4988 of OGAs. 4990 o Added Appendix on ORCHID use in HITs. 4992 o Added truncated SHA-256 option for HITs. 4994 o Added truncated SHA-1 option for HITs. 4996 o Added text about new ORCHID structure to HIT overview. 4998 o Moved Editor role to Robert Moskowitz. 5000 o Added SHA-256 to puzzle parameter. 5002 o Generalized LTRUNC to be hash-function agnostic. 5004 o Added text about RHASH depending on OGA. 5006 11.5. Changes from draft-ietf-hip-rfc5201-bis-00 5008 o Added reasoning why BIS document is needed. 5010 11.6. Contents of draft-ietf-hip-rfc5201-bis-00 5012 o RFC5201 was submitted as draft-RFC. 5014 12. References 5016 12.1. Normative References 5018 [FIPS.180-2.2002] National Institute of Standards and 5019 Technology, "Secure Hash Standard", 5020 FIPS PUB 180-2, August 2002, . 5024 [I-D.ietf-hip-rfc4843-bis] Laganier, J. and F. Dupont, "An IPv6 5025 Prefix for Overlay Routable Cryptographic 5026 Hash Identifiers (ORCHID)", 5027 draft-ietf-hip-rfc4843-bis-00 (work in 5028 progress), August 2010. 5030 [I-D.ietf-hip-rfc5202-bis] Jokela, P., Moskowitz, R., Nikander, P., 5031 and J. Melen, "Using the Encapsulating 5032 Security Payload (ESP) Transport Format 5033 with the Host Identity Protocol (HIP)", 5034 draft-ietf-hip-rfc5202-bis-00 (work in 5035 progress), September 2010. 5037 [RFC0768] Postel, J., "User Datagram Protocol", 5038 STD 6, RFC 768, August 1980. 5040 [RFC1035] Mockapetris, P., "Domain names - 5041 implementation and specification", 5042 STD 13, RFC 1035, November 1987. 5044 [RFC2119] Bradner, S., "Key words for use in RFCs 5045 to Indicate Requirement Levels", BCP 14, 5046 RFC 2119, March 1997. 5048 [RFC2404] Madson, C. and R. Glenn, "The Use of 5049 HMAC-SHA-1-96 within ESP and AH", 5050 RFC 2404, November 1998. 5052 [RFC2410] Glenn, R. and S. Kent, "The NULL 5053 Encryption Algorithm and Its Use With 5054 IPsec", RFC 2410, November 1998. 5056 [RFC2451] Pereira, R. and R. Adams, "The ESP CBC- 5057 Mode Cipher Algorithms", RFC 2451, 5058 November 1998. 5060 [RFC2460] Deering, S. and R. Hinden, "Internet 5061 Protocol, Version 6 (IPv6) 5062 Specification", RFC 2460, December 1998. 5064 [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the 5065 Domain Name System (DNS)", RFC 2536, 5066 March 1999. 5068 [RFC2898] Kaliski, B., "PKCS #5: Password-Based 5069 Cryptography Specification Version 2.0", 5070 RFC 2898, September 2000. 5072 [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA 5073 KEYs in the Domain Name System (DNS)", 5074 RFC 3110, May 2001. 5076 [RFC3484] Draves, R., "Default Address Selection 5077 for Internet Protocol version 6 (IPv6)", 5078 RFC 3484, February 2003. 5080 [RFC3526] Kivinen, T. and M. Kojo, "More Modular 5081 Exponential (MODP) Diffie-Hellman groups 5082 for Internet Key Exchange (IKE)", 5083 RFC 3526, May 2003. 5085 [RFC3602] Frankel, S., Glenn, R., and S. Kelly, 5086 "The AES-CBC Cipher Algorithm and Its Use 5087 with IPsec", RFC 3602, September 2003. 5089 [RFC3972] Aura, T., "Cryptographically Generated 5090 Addresses (CGA)", RFC 3972, March 2005. 5092 [RFC4034] Arends, R., Austein, R., Larson, M., 5093 Massey, D., and S. Rose, "Resource 5094 Records for the DNS Security Extensions", 5095 RFC 4034, March 2005. 5097 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. 5098 Eronen, "The Network Access Identifier", 5099 RFC 4282, December 2005. 5101 [RFC4443] Conta, A., Deering, S., and M. Gupta, 5102 "Internet Control Message Protocol 5103 (ICMPv6) for the Internet Protocol 5104 Version 6 (IPv6) Specification", 5105 RFC 4443, March 2006. 5107 [RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 5108 Authentication Using the Elliptic Curve 5109 Digital Signature Algorithm (ECDSA)", 5110 RFC 4754, January 2007. 5112 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC- 5113 SHA-256, HMAC-SHA-384, and HMAC-SHA-512 5114 with IPsec", RFC 4868, May 2007. 5116 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., 5117 and T. Henderson, "Host Identity 5118 Protocol", RFC 5201, April 2008. 5120 [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with 5121 RSA in DNSKEY and RRSIG Resource Records 5122 for DNSSEC", RFC 5702, October 2009. 5124 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based 5125 Extract-and-Expand Key Derivation 5126 Function (HKDF)", RFC 5869, May 2010. 5128 [RFC5903] Fu, D. and J. Solinas, "Elliptic Curve 5129 Groups modulo a Prime (ECP Groups) for 5130 IKE and IKEv2", RFC 5903, June 2010. 5132 [RFC6090] McGrew, D., Igoe, K., and M. Salter, 5133 "Fundamental Elliptic Curve Cryptography 5134 Algorithms", RFC 6090, February 2011. 5136 12.2. Informative References 5138 [AUR03] Aura, T., Nagarajan, A., and A. Gurtov, 5139 "Analysis of the HIP Base Exchange 5140 Protocol", in Proceedings of 10th 5141 Australasian Conference on Information 5142 Security and Privacy, July 2003. 5144 [CRO03] Crosby, SA. and DS. Wallach, "Denial of 5145 Service via Algorithmic Complexity 5146 Attacks", in Proceedings of Usenix 5147 Security Symposium 2003, Washington, 5148 DC., August 2003. 5150 [DIF76] Diffie, W. and M. Hellman, "New 5151 Directions in Cryptography", IEEE 5152 Transactions on Information Theory vol. 5153 IT-22, number 6, pages 644-654, Nov 1976. 5155 [FIPS.197.2001] National Institute of Standards and 5156 Technology, "Advanced Encryption Standard 5157 (AES)", FIPS PUB 197, November 2001, . 5161 [I-D.ietf-btns-c-api] Richardson, M., Williams, N., Komu, M., 5162 and S. Tarkoma, "C-Bindings for IPsec 5163 Application Programming Interfaces", 5164 draft-ietf-btns-c-api-04 (work in 5165 progress), March 2009. 5167 [I-D.ietf-hip-cert] Heer, T. and S. Varjonen, "Host Identity 5168 Protocol Certificates", 5169 draft-ietf-hip-cert-09 (work in 5170 progress), January 2011. 5172 [I-D.ietf-hip-rfc4423-bis] Moskowitz, R., "Host Identity Protocol 5173 Architecture", 5174 draft-ietf-hip-rfc4423-bis-02 (work in 5175 progress), February 2011. 5177 [I-D.ietf-hip-rfc5204-bis] Laganier, J. and L. Eggert, "Host 5178 Identity Protocol (HIP) Rendezvous 5179 Extension", draft-ietf-hip-rfc5204-bis-00 5180 (work in progress), August 2010. 5182 [I-D.ietf-hip-rfc5205-bis] Laganier, J., "Host Identity Protocol 5183 (HIP) Domain Name System (DNS) 5184 Extension", draft-ietf-hip-rfc5205-bis-00 5185 (work in progress), August 2010. 5187 [I-D.ietf-hip-rfc5206-bis] Nikander, P., Henderson, T., Vogt, C., 5188 and J. Arkko, "Host Mobility with the 5189 Host Identity Protocol", 5190 draft-ietf-hip-rfc5206-bis-01 (work in 5191 progress), October 2010. 5193 [KAU03] Kaufman, C., Perlman, R., and B. 5194 Sommerfeld, "DoS protection for UDP-based 5195 protocols", ACM Conference on Computer 5196 and Communications Security , Oct 2003. 5198 [KRA03] Krawczyk, H., "SIGMA: The 'SIGn-and-MAc' 5199 Approach to Authenticated Diffie-Hellman 5200 and Its Use in the IKE-Protocols", in 5201 Proceedings of CRYPTO 2003, pages 400- 5202 425, August 2003. 5204 [RFC0792] Postel, J., "Internet Control Message 5205 Protocol", STD 5, RFC 792, 5206 September 1981. 5208 [RFC4306] Kaufman, C., "Internet Key Exchange 5209 (IKEv2) Protocol", RFC 4306, 5210 December 2005. 5212 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines 5213 for Writing an IANA Considerations 5214 Section in RFCs", BCP 26, RFC 5226, 5215 May 2008. 5217 [RFC5338] Henderson, T., Nikander, P., and M. Komu, 5218 "Using the Host Identity Protocol with 5219 Legacy Applications", RFC 5338, 5220 September 2008. 5222 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: 5223 Level 3 Multihoming Shim Protocol for 5224 IPv6", RFC 5533, June 2009. 5226 [SECG] SECG, "Recommended Elliptic Curve Domain 5227 Parameters", SEC 2 , 2000, 5228 . 5230 Appendix A. Using Responder Puzzles 5232 As mentioned in Section 4.1.1, the Responder may delay state creation 5233 and still reject most spoofed I2 packets by using a number of pre- 5234 calculated R1 packets and a local selection function. This appendix 5235 defines one possible implementation in detail. The purpose of this 5236 appendix is to give the implementors an idea on how to implement the 5237 mechanism. If the implementation is based on this appendix, it MAY 5238 contain some local modification that makes an attacker's task harder. 5240 The Responder creates a secret value S, that it regenerates 5241 periodically. The Responder needs to remember the two latest values 5242 of S. Each time the S is regenerated, the R1 generation counter 5243 value is incremented by one. 5245 The Responder generates a pre-signed R1 packet. The signature for 5246 pre-generated R1s must be recalculated when the Diffie-Hellman key is 5247 recomputed or when the R1_COUNTER value changes due to S value 5248 regeneration. 5250 When the Initiator sends the I1 packet for initializing a connection, 5251 the Responder receives the HIT and IP address from the packet, and 5252 generates an #I value for the puzzle. The #I value is set to the 5253 pre-signed R1 packet. 5255 #I value calculation: 5256 #I = Ltrunc( RHASH ( S | HIT-I | HIT-R | IP-I | IP-R ), n) 5257 where n = RHASH_len 5259 The RHASH algorithm is the same that is used to generate the 5260 Responder's HIT value. 5262 From an incoming I2 packet, the Responder receives the required 5263 information to validate the puzzle: HITs, IP addresses, and the 5264 information of the used S value from the R1_COUNTER. Using these 5265 values, the Responder can regenerate the #I, and verify it against 5266 the #I received in the I2 packet. If the #I values match, it can 5267 verify the solution using #I, #J, and difficulty #K. If the #I values 5268 do not match, the I2 is dropped. 5270 puzzle_check: 5271 V := Ltrunc( RHASH( I2.I | I2.hit_i | I2.hit_r | I2.J ), #K ) 5272 if V != 0, drop the packet 5274 If the puzzle solution is correct, the #I and #J values are stored 5275 for later use. They are used as input material when keying material 5276 is generated. 5278 Keeping state about failed puzzle solutions depends on the 5279 implementation. Although it is possible for the Responder not to 5280 keep any state information, it still may do so to protect itself 5281 against certain attacks (see Section 4.1.1). 5283 Appendix B. Generating a Public Key Encoding from an HI 5285 The following pseudo-code illustrates the process to generate a 5286 public key encoding from an HI for both RSA and DSA. 5288 The symbol := denotes assignment; the symbol += denotes appending. 5290 The pseudo-function encode_in_network_byte_order takes two 5291 parameters, an integer (bignum) and a length in bytes, and returns 5292 the integer encoded into a byte string of the given length. 5294 switch ( HI.algorithm ) 5295 { 5297 case RSA: 5298 buffer := encode_in_network_byte_order ( HI.RSA.e_len, 5299 ( HI.RSA.e_len > 255 ) ? 3 : 1 ) 5300 buffer += encode_in_network_byte_order ( HI.RSA.e, HI.RSA.e_len ) 5301 buffer += encode_in_network_byte_order ( HI.RSA.n, HI.RSA.n_len ) 5302 break; 5304 case DSA: 5305 buffer := encode_in_network_byte_order ( HI.DSA.T , 1 ) 5306 buffer += encode_in_network_byte_order ( HI.DSA.Q , 20 ) 5307 buffer += encode_in_network_byte_order ( HI.DSA.P , 64 + 5308 8 * HI.DSA.T ) 5309 buffer += encode_in_network_byte_order ( HI.DSA.G , 64 + 5310 8 * HI.DSA.T ) 5311 buffer += encode_in_network_byte_order ( HI.DSA.Y , 64 + 5312 8 * HI.DSA.T ) 5313 break; 5315 } 5317 Appendix C. Example Checksums for HIP Packets 5319 The HIP checksum for HIP packets is specified in Section 5.1.1. 5320 Checksums for TCP and UDP packets running over HIP-enabled security 5321 associations are specified in Section 3.5. The examples below use IP 5322 addresses of 192.0.2.1 and 192.0.2.2 (and their respective IPv4- 5323 compatible IPv6 formats), and HITs with the prefix of 2001:10 5324 followed by zeros, followed by a decimal 1 or 2, respectively. 5326 The following example is defined only for testing the checksum 5327 calculation. The address format for the IPv4-compatible IPv6 address 5328 is not a valid one, but using these IPv6 addresses when testing an 5329 IPv6 implementation gives the same checksum output as an IPv4 5330 implementation with the corresponding IPv4 addresses. 5332 C.1. IPv6 HIP Example (I1 packet) 5334 Source Address: ::192.0.2.1 5335 Destination Address: ::192.0.2.2 5336 Upper-Layer Packet Length: 40 0x28 5337 Next Header: 139 0x8b 5338 Payload Protocol: 59 0x3b 5339 Header Length: 4 0x4 5340 Packet Type: 1 0x1 5341 Version: 1 0x1 5342 Reserved: 1 0x1 5343 Control: 0 0x0 5344 Checksum: 446 0x1be 5345 Sender's HIT : 2001:10::1 5346 Receiver's HIT: 2001:10::2 5348 C.2. IPv4 HIP Packet (I1 packet) 5350 The IPv4 checksum value for the example I1 packet equals the IPv6 5351 checksum value (since the checksum components due to the IPv4 and 5352 IPv6 pseudo-header are the same). . 5354 C.3. TCP Segment 5356 Regardless of whether IPv6 or IPv4 is used, the TCP and UDP sockets 5357 use the IPv6 pseudo-header format [RFC2460], with the HITs used in 5358 place of the IPv6 addresses. 5360 Sender's HIT: 2001:10::1 5361 Receiver's HIT: 2001:10::2 5362 Upper-Layer Packet Length: 20 0x14 5363 Next Header: 6 0x06 5364 Source port: 65500 0xffdc 5365 Destination port: 22 0x0016 5366 Sequence number: 1 0x00000001 5367 Acknowledgment number: 0 0x00000000 5368 Header length: 20 0x14 5369 Flags: SYN 0x02 5370 Window size: 65535 0xffff 5371 Checksum: 28618 0x6fca 5372 Urgent pointer: 0 0x0000 5374 0x0000: 6000 0000 0014 0640 2001 0010 0000 0000 5375 0x0010: 0000 0000 0000 0001 2001 0010 0000 0000 5376 0x0020: 0000 0000 0000 0002 ffdc 0016 0000 0001 5377 0x0030: 0000 0000 5002 ffff 6fca 0000 5379 Appendix D. ECDH and ECDSA 160 Bit Groups 5381 The ECDH and ECDSA 160-bit group SECP160R1 is rated at 80 bits 5382 symmetric strength. Once this was considered appropriate for one 5383 year of security. Today these groups should be used only when the 5384 host is not powerful enough (e.g., some embedded devices) and when 5385 security requirements are low (e.g., long-term confidentiality is not 5386 required). 5388 Appendix E. HIT Suites and HIT Generation 5390 The HIT as an ORCHID [I-D.ietf-hip-rfc4843-bis] consists of three 5391 parts: A 28-bit prefix, a 4-bit encoding of the ORCHID generation 5392 algorithm (OGA) and the representation of the public key. The OGA is 5393 an index pointing to the specific algorithm by which the public key 5394 and the 96-bit hashed encoding is generated. The OGA is protocol 5395 specific and is to be interpreted as defined below for all protocols 5396 that use the same context ID as HIP. HIP groups sets of valid 5397 combinations of signature and hash algorithms into HIT Suites. These 5398 HIT suites are addressed by an index, which is transmitted in the OGA 5399 field of the ORCHID. 5401 The set of used HIT Suites will be extended to counter the progress 5402 in computation capabilities and vulnerabilities in the employed 5403 algorithms. The intended use of the HIT Suites is to introduce a new 5404 HIT Suite and phase out an old one before it becomes insecure. Since 5405 the 4-bit OGA field only permits 15 HIT Suites (the HIT Suite with ID 5406 0 is reserved) to be used in parallel, phased-out HIT Suites must be 5407 reused at some point. In such a case, there will be a rollover of 5408 the HIT Suite ID and the next newly introduced HIT Suite will start 5409 with a lower HIT Suite index than the previously introduced one. The 5410 rollover effectively deprecates the reused HIT Suite. For a smooth 5411 transition, the HIT Suite should be deprecated a considerable time 5412 before the HIT Suite index is reused. 5414 Since the number of HIT Suites is tightly limited to 16, the HIT 5415 Suites must be assigned carefully. Hence, sets of suitable 5416 algorithms are grouped in a HIT Suite. 5418 The HIT Suite of the Responder's HIT determines the RHASH and the 5419 hash function to be used for the HMAC in HIP control packets as well 5420 as the signature algorithm family used for generating the HI. The 5421 list of HIT Suites is defined in Table 11. 5423 The following HIT Suites are defined for HIT generation. The input 5424 for each generation algorithm is the encoding of the HI as defined in 5425 Section 3.2. The output is 96 bits long and is directly used in the 5426 ORCHID. 5428 +-------+----------+--------------+-------------+-------------------+ 5429 | Index | Hash | HMAC | Signature | Description | 5430 | | function | | algorithm | | 5431 | | | | family | | 5432 +-------+----------+--------------+-------------+-------------------+ 5433 | 0 | | | | Reserved | 5434 | 1 | SHA-1 | HMAC-SHA-1 | RSA, DSA | RSA or DSA HI | 5435 | | | | | hashed with | 5436 | | | | | SHA-1, truncated | 5437 | | | | | to 96 bits | 5438 | 2 | SHA-384 | HMAC-SHA-384 | ECDSA | ECDSA HI hashed | 5439 | | | | | with SHA-384, | 5440 | | | | | truncated to 96 | 5441 | | | | | bits | 5442 | 3 | SHA-1 | HMAC-SHA-1 | ECDSA_LOW | ECDSA_LOW HI | 5443 | | | | | hashed with | 5444 | | | | | SHA-1, truncated | 5445 | | | | | to 96 bits | 5446 +-------+----------+--------------+-------------+-------------------+ 5448 Table 11: HIT Suites 5450 The hash of the responder as defined in the HIT Suite determines the 5451 HMAC to be used for the HMAC parameter. The HMACs currently defined 5452 here are SHA-1 [RFC2404] and HMAC-SHA-384 [RFC4868]. 5454 Authors' Addresses 5456 Robert Moskowitz (editor) 5457 Verizon Telcom and Business 5458 1000 Bent Creek Blvd, Suite 200 5459 Mechanicsburg, PA 5460 USA 5462 EMail: robert.moskowitz@verizonbusiness.com 5464 Tobias Heer 5465 RWTH Aachen University, Communication and Distributed Systems Group 5466 Ahornstrasse 55 5467 Aachen 52062 5468 Germany 5470 EMail: heer@cs.rwth-aachen.de 5471 URI: http://www.comsys.rwth-aachen.de/team/tobias-heer/ 5472 Petri Jokela 5473 Ericsson Research NomadicLab 5474 JORVAS FIN-02420 5475 FINLAND 5477 Phone: +358 9 299 1 5478 EMail: petri.jokela@nomadiclab.com 5480 Thomas R. Henderson 5481 The Boeing Company 5482 P.O. Box 3707 5483 Seattle, WA 5484 USA 5486 EMail: thomas.r.henderson@boeing.com