idnits 2.17.1 draft-ietf-hip-rfc5201-bis-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. == There are 3 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 2186 has weird spacing: '...c Value leng...' == Line 2188 has weird spacing: '...c Value the ...' == Line 2705 has weird spacing: '...ication info...' == Line 2844 has weird spacing: '...ue data opaqu...' == Line 2874 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 12, 2012) is 4425 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 13, 2012 Communication and Distributed 7 Systems Group 8 P. Jokela 9 Ericsson Research NomadicLab 10 T. Henderson 11 The Boeing Company 12 March 12, 2012 14 Host Identity Protocol Version 2 (HIPv2) 15 draft-ietf-hip-rfc5201-bis-08 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 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). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on September 13, 2012. 53 Copyright Notice 55 Copyright (c) 2012 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 This document may contain material from IETF Documents or IETF 69 Contributions published or made publicly available before November 70 10, 2008. The person(s) controlling the copyright in some of this 71 material may not have granted the IETF Trust the right to allow 72 modifications of such material outside the IETF Standards Process. 73 Without obtaining an adequate license from the person(s) controlling 74 the copyright in such materials, this document may not be modified 75 outside the IETF Standards Process, and derivative works of it may 76 not be created outside the IETF Standards Process, except to format 77 it for publication as an RFC or to translate it into languages other 78 than English. 80 Table of Contents 82 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 83 1.1. A New Namespace and Identifiers . . . . . . . . . . . . . 7 84 1.2. The HIP Base Exchange (BEX) . . . . . . . . . . . . . . . 7 85 1.3. Memo Structure . . . . . . . . . . . . . . . . . . . . . 8 86 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 8 87 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 8 88 2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 8 89 2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 9 90 3. Host Identity (HI) and its Structure . . . . . . . . . . . . 10 91 3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 11 92 3.2. Generating a HIT from an HI . . . . . . . . . . . . . . . 11 93 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 12 94 4.1. Creating a HIP Association . . . . . . . . . . . . . . . 13 95 4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . 14 96 4.1.2. Puzzle Exchange . . . . . . . . . . . . . . . . . . . 15 97 4.1.3. Authenticated Diffie-Hellman Protocol with DH 98 Group Negotiation . . . . . . . . . . . . . . . . . . 17 99 4.1.4. HIP Replay Protection . . . . . . . . . . . . . . . . 18 100 4.1.5. Refusing a HIP Base Exchange . . . . . . . . . . . . 19 101 4.1.6. Aborting a HIP Base Exchange . . . . . . . . . . . . 20 102 4.1.7. HIP Downgrade Protection . . . . . . . . . . . . . . 20 103 4.1.8. HIP Opportunistic Mode . . . . . . . . . . . . . . . 21 104 4.2. Updating a HIP Association . . . . . . . . . . . . . . . 24 105 4.3. Error Processing . . . . . . . . . . . . . . . . . . . . 24 106 4.4. HIP State Machine . . . . . . . . . . . . . . . . . . . . 25 107 4.4.1. State Machine Terminology . . . . . . . . . . . . . . 26 108 4.4.2. HIP States . . . . . . . . . . . . . . . . . . . . . 27 109 4.4.3. HIP State Processes . . . . . . . . . . . . . . . . . 27 110 4.4.4. Simplified HIP State Diagram . . . . . . . . . . . . 34 111 4.5. User Data Considerations . . . . . . . . . . . . . . . . 36 112 4.5.1. TCP and UDP Pseudo-Header Computation for User Data . 36 113 4.5.2. Sending Data on HIP Packets . . . . . . . . . . . . . 36 114 4.5.3. Transport Formats . . . . . . . . . . . . . . . . . . 36 115 4.5.4. Reboot, Timeout, and Restart of HIP . . . . . . . . . 36 116 4.6. Certificate Distribution . . . . . . . . . . . . . . . . 37 117 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 37 118 5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 37 119 5.1.1. Checksum . . . . . . . . . . . . . . . . . . . . . . 38 120 5.1.2. HIP Controls . . . . . . . . . . . . . . . . . . . . 39 121 5.1.3. HIP Fragmentation Support . . . . . . . . . . . . . . 39 122 5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 40 123 5.2.1. TLV Format . . . . . . . . . . . . . . . . . . . . . 43 124 5.2.2. Defining New Parameters . . . . . . . . . . . . . . . 45 125 5.2.3. R1_COUNTER . . . . . . . . . . . . . . . . . . . . . 46 126 5.2.4. PUZZLE . . . . . . . . . . . . . . . . . . . . . . . 47 127 5.2.5. SOLUTION . . . . . . . . . . . . . . . . . . . . . . 48 128 5.2.6. DH_GROUP_LIST . . . . . . . . . . . . . . . . . . . . 49 129 5.2.7. DIFFIE_HELLMAN . . . . . . . . . . . . . . . . . . . 50 130 5.2.8. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . 51 131 5.2.9. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 52 132 5.2.10. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 54 133 5.2.11. TRANSPORT_FORMAT_LIST . . . . . . . . . . . . . . . . 55 134 5.2.12. HIP_MAC . . . . . . . . . . . . . . . . . . . . . . . 56 135 5.2.13. HIP_MAC_2 . . . . . . . . . . . . . . . . . . . . . . 56 136 5.2.14. HIP_SIGNATURE . . . . . . . . . . . . . . . . . . . . 57 137 5.2.15. HIP_SIGNATURE_2 . . . . . . . . . . . . . . . . . . . 58 138 5.2.16. SEQ . . . . . . . . . . . . . . . . . . . . . . . . . 58 139 5.2.17. ACK . . . . . . . . . . . . . . . . . . . . . . . . . 59 140 5.2.18. ENCRYPTED . . . . . . . . . . . . . . . . . . . . . . 60 141 5.2.19. NOTIFICATION . . . . . . . . . . . . . . . . . . . . 61 142 5.2.20. ECHO_REQUEST_SIGNED . . . . . . . . . . . . . . . . . 65 143 5.2.21. ECHO_REQUEST_UNSIGNED . . . . . . . . . . . . . . . . 65 144 5.2.22. ECHO_RESPONSE_SIGNED . . . . . . . . . . . . . . . . 66 145 5.2.23. ECHO_RESPONSE_UNSIGNED . . . . . . . . . . . . . . . 67 146 5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 67 147 5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 68 148 5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 69 149 5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 72 150 5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 73 151 5.3.5. UPDATE - the HIP Update Packet . . . . . . . . . . . 73 152 5.3.6. NOTIFY - the HIP Notify Packet . . . . . . . . . . . 75 153 5.3.7. CLOSE - the HIP Association Closing Packet . . . . . 75 154 5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet . . 76 155 5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 76 156 5.4.1. Invalid Version . . . . . . . . . . . . . . . . . . . 76 157 5.4.2. Other Problems with the HIP Header and Packet 158 Structure . . . . . . . . . . . . . . . . . . . . . . 76 159 5.4.3. Invalid Puzzle Solution . . . . . . . . . . . . . . . 77 160 5.4.4. Non-Existing HIP Association . . . . . . . . . . . . 77 161 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 77 162 6.1. Processing Outgoing Application Data . . . . . . . . . . 78 163 6.2. Processing Incoming Application Data . . . . . . . . . . 79 164 6.3. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 80 165 6.4. HIP_MAC and SIGNATURE Calculation and Verification . . . 81 166 6.4.1. HMAC Calculation . . . . . . . . . . . . . . . . . . 81 167 6.4.2. Signature Calculation . . . . . . . . . . . . . . . . 84 168 6.5. HIP KEYMAT Generation . . . . . . . . . . . . . . . . . . 86 169 6.6. Initiation of a HIP Base Exchange . . . . . . . . . . . . 87 170 6.6.1. Sending Multiple I1 Packets in Parallel . . . . . . . 88 171 6.6.2. Processing Incoming ICMP Protocol Unreachable 172 Messages . . . . . . . . . . . . . . . . . . . . . . 88 173 6.7. Processing Incoming I1 Packets . . . . . . . . . . . . . 89 174 6.7.1. R1 Management . . . . . . . . . . . . . . . . . . . . 90 175 6.7.2. Handling Malformed Messages . . . . . . . . . . . . . 91 176 6.8. Processing Incoming R1 Packets . . . . . . . . . . . . . 91 177 6.8.1. Handling of Malformed Messages . . . . . . . . . . . 93 178 6.9. Processing Incoming I2 Packets . . . . . . . . . . . . . 94 179 6.9.1. Handling of Malformed Messages . . . . . . . . . . . 96 180 6.10. Processing of Incoming R2 Packets . . . . . . . . . . . . 96 181 6.11. Sending UPDATE Packets . . . . . . . . . . . . . . . . . 97 182 6.12. Receiving UPDATE Packets . . . . . . . . . . . . . . . . 98 183 6.12.1. Handling a SEQ Parameter in a Received UPDATE 184 Message . . . . . . . . . . . . . . . . . . . . . . . 99 185 6.12.2. Handling an ACK Parameter in a Received UPDATE 186 Packet . . . . . . . . . . . . . . . . . . . . . . . 100 187 6.13. Processing of NOTIFY Packets . . . . . . . . . . . . . . 100 188 6.14. Processing CLOSE Packets . . . . . . . . . . . . . . . . 100 189 6.15. Processing CLOSE_ACK Packets . . . . . . . . . . . . . . 101 190 6.16. Handling State Loss . . . . . . . . . . . . . . . . . . . 101 191 7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 101 192 8. Security Considerations . . . . . . . . . . . . . . . . . . . 102 193 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 105 194 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 107 195 11. Changes from RFC 5201 . . . . . . . . . . . . . . . . . . . . 108 196 11.1. Changes from draft-ietf-hip-rfc5201-bis-07 . . . . . . . 108 197 11.2. Changes from draft-ietf-hip-rfc5201-bis-06 . . . . . . . 108 198 11.3. Changes from draft-ietf-hip-rfc5201-bis-05 . . . . . . . 108 199 11.4. Changes from draft-ietf-hip-rfc5201-bis-04 . . . . . . . 109 200 11.5. Changes from draft-ietf-hip-rfc5201-bis-03 . . . . . . . 110 201 11.6. Changes from draft-ietf-hip-rfc5201-bis-02 . . . . . . . 111 202 11.7. Changes from draft-ietf-hip-rfc5201-bis-01 . . . . . . . 111 203 11.8. Changes from draft-ietf-hip-rfc5201-bis-00 . . . . . . . 113 204 11.9. Contents of draft-ietf-hip-rfc5201-bis-00 . . . . . . . . 113 205 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 113 206 12.1. Normative References . . . . . . . . . . . . . . . . . . 113 207 12.2. Informative References . . . . . . . . . . . . . . . . . 116 208 Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 118 209 Appendix B. Generating a Public Key Encoding from an HI . . . . 119 210 Appendix C. Example Checksums for HIP Packets . . . . . . . . . 120 211 C.1. IPv6 HIP Example (I1 packet) . . . . . . . . . . . . . . 121 212 C.2. IPv4 HIP Packet (I1 packet) . . . . . . . . . . . . . . . 121 213 C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . . 121 214 Appendix D. ECDH and ECDSA 160 Bit Groups . . . . . . . . . . . 122 215 Appendix E. HIT Suites and HIT Generation . . . . . . . . . . . 122 217 1. Introduction 219 This document specifies the details of the Host Identity Protocol 220 (HIP). A high-level description of the protocol and the underlying 221 architectural thinking is available in the separate HIP architecture 222 description [I-D.ietf-hip-rfc4423-bis]. Briefly, the HIP 223 architecture proposes an alternative to the dual use of IP addresses 224 as "locators" (routing labels) and "identifiers" (endpoint, or host, 225 identifiers). In HIP, public cryptographic keys, of a public/private 226 key pair, are used as Host Identifiers, to which higher layer 227 protocols are bound instead of an IP address. By using public keys 228 (and their representations) as host identifiers, dynamic changes to 229 IP address sets can be directly authenticated between hosts, and if 230 desired, strong authentication between hosts at the TCP/IP stack 231 level can be obtained. 233 This memo specifies the base HIP protocol ("base exchange") used 234 between hosts to establish an IP-layer communications context, called 235 a HIP association, prior to communications. It also defines a packet 236 format and procedures for updating an active HIP association. Other 237 elements of the HIP architecture are specified in other documents, 238 such as: 240 o "Using the Encapsulating Security Payload (ESP) transport format 241 with the Host Identity Protocol (HIP)" [I-D.ietf-hip-rfc5202-bis]: 242 how to use the Encapsulating Security Payload (ESP) for integrity 243 protection and optional encryption 245 o "Host Mobility with the Host Identity Protocol" 246 [I-D.ietf-hip-rfc5206-bis]: how to support host mobility in HIP 248 o "Host Identity Protocol (HIP) Domain Name System (DNS) Extensions" 249 [I-D.ietf-hip-rfc5205-bis]: how to extend DNS to contain Host 250 Identity information 252 o "Host Identity Protocol (HIP) Rendezvous Extension" 253 [I-D.ietf-hip-rfc5204-bis]: using a rendezvous mechanism to 254 contact mobile HIP hosts 256 Since the HIP Base Exchange was first developed, there have been a 257 few advances in cryptography and attacks against cryptographic 258 systems. As a result, all cryptographic protocols need to be agile. 259 That is, it should be a part of the protocol to be able to switch 260 from one cryptographic primitive to another. It is important to 261 support a reasonable set of mainstream algorithms to cater for 262 different use cases and allow moving away from algorithms that are 263 later discovered to be vulnerable This update to the Base Exchange 264 includes this needed cryptographic agility while addressing the 265 downgrade attacks that such flexibility introduces. In particular, 266 Elliptic Curve support by Elliptic Curve DSA (ECDSA) and Elliptic 267 Curve Diffie-Hellman (ECDH) and alternative hash functions have been 268 added. 270 1.1. A New Namespace and Identifiers 272 The Host Identity Protocol introduces a new namespace, the Host 273 Identity namespace. Some ramifications of this new namespace are 274 explained in the HIP architecture description 275 [I-D.ietf-hip-rfc4423-bis]. 277 There are two main representations of the Host Identity, the full 278 Host Identity (HI) and the Host Identity Tag (HIT). The HI is a 279 public key and directly represents the Identity of a host. Since 280 there are different public key algorithms that can be used with 281 different key lengths, the HI, as such, is unsuitable for use as a 282 packet identifier, or as an index into the various state-related 283 implementation structures needed to support HIP. Consequently, a 284 hash of the HI, the Host Identity Tag (HIT), is used as the 285 operational representation. The HIT is 128 bits long and is used in 286 the HIP headers and to index the corresponding state in the end 287 hosts. The HIT has an important security property in that it is 288 self-certifying (see Section 3). 290 1.2. The HIP Base Exchange (BEX) 292 The HIP base exchange is a two-party cryptographic protocol used to 293 establish communications context between hosts. The base exchange is 294 a SIGMA-compliant [KRA03] four-packet exchange. The first party is 295 called the Initiator and the second party the Responder. The 296 protocol exchanges Diffie-Hellman [DIF76] keys in the 2nd and 3rd 297 packets, and authenticates the parties in the 3rd and 4th packets. 298 The four-packet design helps to make HIP DoS resilient. It allows 299 the Responder to stay stateless until the IP address and the 300 cryptographic puzzle is verified. The Responder starts the puzzle 301 exchange in the 2nd packet, with the Initiator completing it in the 302 3rd packet before the Responder stores any state from the exchange. 304 The exchange can use the Diffie-Hellman output to encrypt the Host 305 Identity of the Initiator in the 3rd packet (although Aura, et al., 306 [AUR03] notes that such operation may interfere with packet- 307 inspecting middleboxes), or the Host Identity may instead be sent 308 unencrypted. The Responder's Host Identity is not protected. It 309 should be noted, however, that both the Initiator's and the 310 Responder's HITs are transported as such (in cleartext) in the 311 packets, allowing an eavesdropper with a priori knowledge about the 312 parties to identify them by their HITs. Hence, encrypting the HI of 313 any party does not provide privacy against such attacker. 315 Data packets start to flow after the 4th packet. The 3rd and 4th HIP 316 packets may carry a data payload in the future. However, the details 317 of this may be defined later. 319 An existing HIP association can be updated using the update mechanism 320 defined in this document, and when the association is no longer 321 needed, it can be closed using the defined closing mechanism. 323 Finally, HIP is designed as an end-to-end authentication and key 324 establishment protocol, to be used with Encapsulated Security Payload 325 (ESP) [I-D.ietf-hip-rfc5202-bis] and other end-to-end security 326 protocols. The base protocol does not cover all the fine-grained 327 policy control found in Internet Key Exchange (IKE) [RFC4306] that 328 allows IKE to support complex gateway policies. Thus, HIP is not a 329 complete replacement for IKE. 331 1.3. Memo Structure 333 The rest of this memo is structured as follows. Section 2 defines 334 the central keywords, notation, and terms used throughout the rest of 335 the document. Section 3 defines the structure of the Host Identity 336 and its various representations. Section 4 gives an overview of the 337 HIP base exchange protocol. Sections 5 and 6 define the detailed 338 packet formats and rules for packet processing. Finally, Sections 7, 339 8, and 9 discuss policy, security, and IANA considerations, 340 respectively. 342 2. Terms and Definitions 344 2.1. Requirements Terminology 346 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 347 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 348 document are to be interpreted as described in RFC 2119 [RFC2119]. 350 2.2. Notation 352 [x] indicates that x is optional. 354 {x} indicates that x is encrypted. 356 X(y) indicates that y is a parameter of X. 358 i indicates that x exists i times. 360 --> signifies "Initiator to Responder" communication (requests). 362 <-- signifies "Responder to Initiator" communication (replies). 364 | signifies concatenation of information (e.g., X | Y is the 365 concatenation of X with Y). 367 Ltrunc (H(x), K) denotes the lowest order #K bits of the result of 368 the hash function H on the input x. 370 2.3. Definitions 372 HIP Base Exchange (BEX): the handshake for establishing a new HIP 373 association. 375 Host Identity (HI): The public key of the signature algorithm that 376 represents the identity of the host. In HIP, a host proves its 377 identity by creating a signature with the private key belonging to 378 its HI (c.f. Section 3). 380 Host Identity Tag (HIT): A shorthand for the HI in IPv6 format. It 381 is generated by hashing the HI (c.f. Section 3.1). 383 HIT Suite: A HIT Suite groups all cryptographic algorithms that are 384 required to generate and use an HI and its HIT. In particular, 385 these algorithms are: 1) the public key signature algorithm and 2) 386 the hash function, 3) the truncation (c.f. Appendix E). 388 HIP association: The shared state between two peers after 389 completion of the BEX. 391 Initiator: The host that initiates the BEX. This role is typically 392 forgotten once the BEX is completed. 394 Responder: The host that responds to the Initiator in the BEX. 395 This role is typically forgotten once the BEX is completed. 397 Responder's HIT Hash Algorithm (RHASH): The Hash algorithm used for 398 various hash calculations in this document. The algorithm is the 399 same as is used to generate the Responder's HIT. The RHASH is the 400 hash function defined by the HIT Suite of the Responder's HIT 401 (c.f. Appendix E). 403 Length of the Responder's HIT Hash Algorithm (RHASH_len): The 404 natural output length of RHASH in bits. 406 Signed data: Data that is signed is protected by a digital 407 signature that was created by the sender of the data by using the 408 private key of its HI. 410 KDF: The Key Derivation Function (KDF) is used for deriving the 411 symmetric keys from the Diffie-Hellman key exchange. 413 KEYMAT: The keying material derived from the Diffie-Hellman key 414 exchange by using the KDF. Symmetric keys for encryption and 415 integrity protection of HIP control and payload packets are drawn 416 from this keying material. 418 3. Host Identity (HI) and its Structure 420 In this section, the properties of the Host Identity and Host 421 Identity Tag are discussed, and the exact format for them is defined. 422 In HIP, the public key of an asymmetric key pair is used as the Host 423 Identity (HI). Correspondingly, the host itself is defined as the 424 entity that holds the private key of the key pair. See the HIP 425 architecture specification [I-D.ietf-hip-rfc4423-bis] for more 426 details on the difference between an identity and the corresponding 427 identifier. 429 HIP implementations MUST support the Rivest Shamir Adelman (RSA) 430 [RFC3110] public key algorithm, and SHOULD support the Digital 431 Signature Algorithm (DSA) [RFC2536] algorithms, and Elliptic Curve 432 Digital Signature Algorithm (ECDSA) for generating the HI as defined 433 in Section 5.2.9. Additional algorithms MAY be supported. 435 A hashed encoding of the HI, the Host Identity Tag (HIT), is used in 436 protocols to represent the Host Identity. The HIT is 128 bits long 437 and has the following three key properties: i) it is the same length 438 as an IPv6 address and can be used in fixed address-sized fields in 439 APIs and protocols, ii) it is self-certifying (i.e., given a HIT, it 440 is computationally hard to find a Host Identity key that matches the 441 HIT), and iii) the probability of a HIT collision between two hosts 442 is very low, hence, it is infeasible for an attacker to find a 443 collision with a HIT that is in use. For details on the security 444 properties of the HIT see [I-D.ietf-hip-rfc4423-bis]. 446 The structure of the HIT is defined in [I-D.ietf-hip-rfc4843-bis]. 447 The HIT is an Overlay Routable Cryptographic Hash Identifier (ORCHID) 448 and consists of three parts: first, an IANA assigned prefix to 449 distinguish it from other IPv6 addresses. Second, a four-bit 450 encoding of the algorithms that were used for generating the HI and 451 the hashed representation of HI. Third, a 96-bit hashed 452 representation of the Host Identity. The encoding of the ORCHID 453 generation algorithm and the exact algorithm for generating the 454 hashed representation is specified in Appendix E. 456 Carrying HIs and HITs in the header of user data packets would 457 increase the overhead of packets. Thus, it is not expected that they 458 are carried in every packet, but other methods are used to map the 459 data packets to the corresponding HIs. In some cases, this makes it 460 possible to use HIP without any additional headers in the user data 461 packets. For example, if ESP is used to protect data traffic, the 462 Security Parameter Index (SPI) carried in the ESP header can be used 463 to map the encrypted data packet to the correct HIP association. 465 3.1. Host Identity Tag (HIT) 467 The Host Identity Tag is a 128-bit value -- a hashed encoding of the 468 Host Identifier. There are two advantages of using a hashed encoding 469 over the actual variable-sized Host Identity public key in protocols. 470 First, the fixed length of the HIT keeps packet sizes manageable and 471 eases protocol coding. Second, it presents a consistent format for 472 the protocol, independent of the underlying identity technology in 473 use. 475 RFC 4843-bis [I-D.ietf-hip-rfc4843-bis] specifies 128-bit hash-based 476 identifiers, called Overlay Routable Cryptographic Hash Identifiers, 477 ORCHIDs. Their prefix, allocated from the IPv6 address block, is 478 defined in [I-D.ietf-hip-rfc4843-bis]. The Host Identity Tag is one 479 type of an ORCHID. 481 This document extends the original, experimental HIP specification 482 [RFC5201] with measures to support crypto agility. One of these 483 measures is to allow different hash functions for creating a HIT. 484 HIT Suites group the sets of algorithms that are required to generate 485 and use a particular HIT. The Suites are encoded in HIT Suite IDs. 486 These HIT Suite IDs are transmitted in the ORCHID Generation 487 Algorithm (OGA) field in the ORCHID. With the HIT Suite ID in the 488 OGA field, a hosts can tell from another host's HIT, whether it 489 supports the necessary hash and signature algorithms to establish a 490 HIP association with that host. 492 3.2. Generating a HIT from an HI 494 The HIT MUST be generated according to the ORCHID generation method 495 described in [I-D.ietf-hip-rfc4843-bis] using a context ID value of 496 0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA (this tag value has been 497 generated randomly by the editor of this specification), and an input 498 that encodes the Host Identity field (see Section 5.2.9) present in a 499 HIP payload packet. The set of hash function, signature algorithm, 500 and the algorithm used for generating the HIT from the HI depends on 501 the HIT Suite (see Appendix E) and is indicated by the four bits of 502 the ORCHID Generation Algorithm (OGA) field in the ORCHID. 503 Currently, truncated SHA-1, truncated SHA-384, and truncated SHA-256 504 [FIPS.180-2.2002] are defined as hashes for generating a HIT. 506 For identities that are either RSA, Digital Signature Algorithm 507 (DSA), or Elliptic Curve DSA (ECDSA) public keys, the ORCHID input 508 consists of the public key encoding as specified for the Host 509 Identity field of the HOST_ID parameter (see Section 5.2.9). This 510 document defines four algorithm profiles: RSA, DSA, ECDSA, and 511 ECDSA_LOW. The ECDSA_LOW profile is meant for devices with low 512 computational capabilities. Hence, one 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 by using a Key Derivation Function 574 (KDF). If other cryptographic keys are needed, e.g., to be used with 575 ESP, they are expected to be drawn from the same keying material by 576 using the KDF. 578 The Initiator first sends a trigger packet, I1, to the Responder. 579 The packet contains the HIT of the Initiator and possibly the HIT of 580 the Responder, if it is known. Moreover, the I1 packet initializes 581 the negotiation of the Diffie-Hellman group that is used for 582 generating the keying material. Therefore, the I1 packet contains a 583 list of Diffie Hellman Group IDs supported by the Initiator. Note 584 that in some cases it may be possible to replace this trigger packet 585 by some other form of a trigger, in which case the protocol starts 586 with the Responder sending the R1 packet. In such cases, another 587 mechanism to convey the Initiator's supported DH Groups (e.g., by 588 using a default group) must be specified. 590 The second packet, R1, starts the actual authenticated Diffie-Hellman 591 exchange. It contains a puzzle -- a cryptographic challenge that the 592 Initiator must solve before continuing the exchange. The level of 593 difficulty of the puzzle can be adjusted based on level of trust with 594 the Initiator, current load, or other factors. In addition, the R1 595 contains the Responder's Diffie-Hellman parameter and lists of 596 cryptographic algorithms supported by the Responder. Based on these 597 lists, the Initiator can continue, abort, or restart the base 598 exchange with a different selection of cryptographic algorithms. 599 Also, the R1 packet contains a signature that covers selected parts 600 of the message. Some fields are left outside the signature to 601 support pre-created R1s. 603 In the I2 packet, the Initiator MUST display the solution to the 604 received puzzle. Without a correct solution, the I2 message is 605 discarded. The I2 packet also contains a Diffie-Hellman parameter 606 that carries needed information for the Responder. The I2 packet is 607 signed by the Initiator. 609 The R2 packet acknowledges the receipt of the I2 packet and completes 610 the base exchange. The packet is signed by the Responder. 612 The base exchange is illustrated below in Figure 1. The term "key" 613 refers to the Host Identity public key, and "sig" represents a 614 signature using such a key. The packets contain other parameters not 615 shown in this figure. 617 Initiator Responder 619 I1: DH list 620 --------------------------> 621 select precomputed R1 622 R1: puzzle, DH, key, sig 623 <------------------------- 624 check sig remain stateless 625 solve puzzle 626 I2: solution, DH, {key}, sig 627 --------------------------> 628 compute DH check puzzle 629 check sig 630 R2: sig 631 <-------------------------- 632 check sig compute DH 634 Figure 1 636 4.1.1. HIP Puzzle Mechanism 638 The purpose of the HIP puzzle mechanism is to protect the Responder 639 from a number of denial-of-service threats. It allows the Responder 640 to delay state creation until receiving the I2 packet. Furthermore, 641 the puzzle allows the Responder to use a fairly cheap calculation to 642 check that the Initiator is "sincere" in the sense that it has 643 churned enough CPU cycles in solving the puzzle. 645 The puzzle allows a Responder implementation to completely delay 646 session-specific state creation until a valid I2 packet is received. 647 An I2 packet without valid puzzle solution can be rejected 648 immediately once the Responder has checked the solution by computing 649 only one hash function before state is created and CPU-intensive 650 public-key signature verification and Diffie-Hellman key generation 651 are performed. By varying the difficulty of the puzzle, the 652 Responder can frustrate CPU or memory targeted DoS attacks. 654 The Responder can remain stateless and drop most spoofed I2 packets 655 because puzzle calculation is based on the Initiator's Host Identity 656 Tag. The idea is that the Responder has a (perhaps varying) number of 657 pre-calculated R1 packets, and it selects one of these based on the 658 information carried in the I1 packet. When the Responder then later 659 receives the I2 packet, it can verify that the puzzle has been solved 660 using the Initiator's HIT. This makes it impractical for the 661 attacker to first exchange one I1/R1 packet, and then generate a 662 large number of spoofed I2 packets that seemingly come from different 663 HITs. This method does not protect the Responder from an attacker 664 that uses fixed HITs, though. Against such an attacker, a viable 665 approach may be to create a piece of local state, and remember that 666 the puzzle check has previously failed. See Appendix A for one 667 possible implementation. Responder implementations SHOULD include 668 sufficient randomness in the puzzle values so that algorithmic 669 complexity attacks become impossible [CRO03]. 671 The Responder can set the puzzle difficulty for the Initiator, based 672 on its level of trust of the Initiator. Because the puzzle is not 673 included in the signature calculation, the Responder can use pre- 674 calculated R1 packets and include the puzzle just before sending the 675 R1 to the Initiator. The Responder SHOULD use heuristics to 676 determine when it is under a denial-of-service attack, and set the 677 puzzle difficulty value #K appropriately as explained later. 679 4.1.2. Puzzle Exchange 681 The Responder starts the puzzle exchange when it receives an I1 682 packet. The Responder supplies a random number #I, and requires the 683 Initiator to find a number J. To select a proper #J, the Initiator 684 must create the concatenation of #I, the HITs of the parties, and #J, 685 and calculate a hash over this concatenation using the RHASH 686 algorithm. The lowest order #K bits of the result MUST be zeros. 687 The value #K sets the difficulty of the puzzle. 689 To generate a proper number #J, the Initiator will have to generate a 690 number of Js until one produces the hash target of zeros. The 691 Initiator SHOULD give up after exceeding the puzzle Lifetime in the 692 PUZZLE parameter (as described in Section 5.2.4). The Responder 693 needs to re-create the concatenation of #I, the HITs, and the 694 provided #J, and compute the hash once to prove that the Initiator 695 completed its assigned task. 697 To prevent precomputation attacks, the Responder MUST select the 698 number #I in such a way that the Initiator cannot guess it. 699 Furthermore, the construction MUST allow the Responder to verify that 700 the value #I was indeed selected by it and not by the Initiator. See 701 Appendix A for an example on how to implement this. 703 Using the Opaque data field in the PUZZLE (see Section 5.2.4), in an 704 ECHO_REQUEST_SIGNED (see Section 5.2.20) or in an 705 ECHO_REQUEST_UNSIGNED parameter (see Section 5.2.21), the Responder 706 can include some data in R1 that the Initiator MUST copy unmodified 707 in the corresponding I2 packet. The Responder can use the opaque 708 data to transfer a piece of local state information to the Initiator 709 and back, for example to recognize that the I2 is a response to a 710 previously sent R1. The Responder can generate the Opaque data in 711 various ways; e.g., using encryption or hashing with some secret, the 712 sent #I, and possibly using other related data. With the same 713 secret, the received #I (from the I2 packet), and the other related 714 data (if any), the Responder can verify that it has itself sent the 715 #I to the Initiator. The Responder MUST periodically change such a 716 secret. 718 It is RECOMMENDED that the Responder generates new secrets for the 719 puzzle and new R1s once every few minutes. Furthermore, it is 720 RECOMMENDED that the Responder is able to verify valid puzzle 721 solution at least Lifetime seconds after the puzzle secret has been 722 deprecated. This time value guarantees that the puzzle is valid for 723 at least Lifetime and at most 2 * Lifetime seconds. This limits the 724 usability that an old, solved puzzle has to an attacker. Moreover, 725 it avoids problems with the validity of puzzles if the lifetime is 726 relatively short compared to the network delay and the time for 727 solving the puzzle. 729 The puzzle value #I and the solution #J are inputs for deriving the 730 keying material from the Diffie-Hellman key exchange (see 731 Section 6.5). Therefore, a Responder SHOULD NOT use the same puzzle 732 #I with the same DH keys for the same Initiator twice to ensure that 733 the derived keying material differs. Such uniqueness can be 734 achieved, for example, by using a counter as an additional input for 735 generating #I. This counter can be increased for each processed I1 736 packet. The state of the counter can be transmitted in the Opaque 737 data field in the PUZZLE (see Section 5.2.4), in an 738 ECHO_REQUEST_SIGNED (see Section 5.2.20) or in an 739 ECHO_REQUEST_UNSIGNED parameter (see Section 5.2.21) without the need 740 to establish state. 742 NOTE: The protocol developers explicitly considered whether R1 should 743 include a timestamp in order to protect the Initiator from replay 744 attacks. The decision was to NOT include a timestamp to avoid 745 problems with global time synchronization. 747 NOTE: The protocol developers explicitly considered whether a memory 748 bound function should be used for the puzzle instead of a CPU-bound 749 function. The decision was not to use memory-bound functions. 751 4.1.3. Authenticated Diffie-Hellman Protocol with DH Group Negotiation 753 The packets R1, I2, and R2 implement a standard authenticated Diffie- 754 Hellman exchange. The Responder sends one of its public Diffie- 755 Hellman keys and its public authentication key, i.e., its Host 756 Identity, in R1. The signature in the R1 packet allows the Initiator 757 to verify that the R1 has been once generated by the Responder. 758 However, since the R1 is precomputed and therefore does not cover 759 association-specific information in the I1 packet, it does not 760 protect from replay attacks. 762 Before the actual authenticated Diffie-Hellman exchange, the 763 Initiator expresses its preference regarding its choice of the DH 764 groups in the I1 packet. The preference is expressed as a sorted 765 list of DH Group IDs. The I1 packet is not protected by a signature. 766 Therefore, this list is sent in an unauthenticated way to avoid 767 costly computations for processing the I1 packet at the Responder 768 side. Based on the preferences of the Initiator, the Responder sends 769 an R1 packet containing its most suitable public DH value. The 770 Responder also attaches a list of its own preferences to the R1 to 771 convey the basis for the DH group selection to the Initiator. This 772 list is carried in the signed part of the R1 packet. If the choice 773 of the DH group value in the R1 does not match the preferences of the 774 Initiator and the Responder, the Initiator can detect that the list 775 of DH Group IDs in the I1 was manipulated (see below for details). 777 If none of the DH Group IDs in the I1 packet is supported by the 778 Responder, the Responder selects the DH Group most suitable for it 779 regardless of the Initiator's preference. It then sends the R1 780 containing this DH Group and its list of supported DH Group IDs to 781 the Initiator. 783 When the Initiator receives an R1, it receives one of the Responder's 784 public Diffie-Hellman values and the list of DH Group IDs supported 785 by the Responder. This list is covered by the signature in the R1 786 packet to avoid forgery. The Initiator compares the Group ID of the 787 public DH value in the R1 packet to the list of supported DH Group 788 IDs in the R1 packets and to its own preferences expressed in the 789 list of supported DH Group IDs. The Initiator continues the BEX only 790 if the Group ID of the public DH value of the Responder is the most 791 preferred of the IDs supported by both the Initiator and Responder. 792 Otherwise, the communication is subject of a downgrade attack and the 793 Initiator MUST either restart the base exchange with a new I1 packet 794 or abort the base exchange. If the Responder's choice of the DH 795 Group is not supported by the Initiator, the Initiator MAY abort the 796 handshake or send a new I1 packet with a different list of supported 797 DH Groups. However, the Initiator MUST verify the signature of the 798 R1 packet before restarting or aborting the handshake. It MUST 799 silently ignore the R1 packet if the signature is not valid. 801 If the preferences regarding the DH Group ID match, the Initiator 802 computes the Diffie-Hellman session key (Kij). The Initiator creates 803 a HIP association using keying material from the session key (see 804 Section 6.5), and may use the HIP association to encrypt its public 805 authentication key, i.e., the Host Identity. The resulting I2 packet 806 contains the Initiator's Diffie-Hellman key and its (optionally 807 encrypted) public authentication key. The signature of the I2 808 message covers all parameters of the signed parameter ranges (see 809 Section 5.2) in the packet without exceptions as in the R1. 811 The Responder extracts the Initiator's Diffie-Hellman public key from 812 the I2 packet, computes the Diffie-Hellman session key, creates a 813 corresponding HIP association, and decrypts the Initiator's public 814 authentication key. It can then verify the signature using the 815 authentication key. 817 The final message, R2, completes the BEX and protects the Initiator 818 against replay attacks because the Responder uses the shared key from 819 the Diffie-Hellman exchange to create an HMAC as well as uses the 820 private key of its Host Identity to sign the packet contents. 822 4.1.4. HIP Replay Protection 824 The HIP protocol includes the following mechanisms to protect against 825 malicious packet replays. Responders are protected against replays 826 of I1 packets by virtue of the stateless response to I1 packets with 827 pre-signed R1 messages. Initiators are protected against R1 replays 828 by a monotonically increasing "R1 generation counter" included in the 829 R1. Responders are protected against replays of forged I2 packets by 830 the puzzle mechanism (see Section 4.1.1 above), and optional use of 831 opaque data. Hosts are protected against replays of R2 packets and 832 UPDATEs by use of a less expensive HMAC verification preceding the 833 HIP signature verification. 835 The R1 generation counter is a monotonically increasing 64-bit 836 counter that may be initialized to any value. The scope of the 837 counter MAY be system-wide but there SHOULD be a separate counter for 838 each Host Identity, if there is more than one local host identity. 839 The value of this counter SHOULD be preserved across system reboots 840 and invocations of the HIP base exchange. This counter indicates the 841 current generation of puzzles. Implementations MUST accept puzzles 842 from the current generation and MAY accept puzzles from earlier 843 generations. A system's local counter MUST be incremented at least 844 as often as every time old R1s cease to be valid. The local counter 845 SHOULD never be decremented, otherwise the host exposes its peers to 846 the replay of previously generated, higher numbered R1s. The R1 847 counter SHOULD NOT roll over. 849 A host may receive more than one R1, either due to sending multiple 850 I1 packets (see Section 6.6.1) or due to a replay of an old R1. When 851 sending multiple I1 packets to the same host, an Initiator SHOULD 852 wait for a small amount of time (a reasonable time may be 2 * 853 expected RTT) after the first R1 reception to allow possibly multiple 854 R1s to arrive, and it SHOULD respond to an R1 among the set with the 855 largest R1 generation counter. If an Initiator is processing an R1 856 or has already sent an I2 packet (still waiting for the R2 packet) 857 and it receives another R1 with a larger R1 generation counter, it 858 MAY elect to restart R1 processing with the fresher R1, as if it were 859 the first R1 to arrive. 861 Upon conclusion of an active HIP association with another host, the 862 R1 generation counter associated with the peer host SHOULD be 863 flushed. A local policy MAY override the default flushing of R1 864 counters on a per-HIT basis. The reason for recommending the 865 flushing of this counter is that there may be hosts where the R1 866 generation counter (occasionally) decreases; e.g., due to hardware 867 failure. 869 4.1.5. Refusing a HIP Base Exchange 871 A HIP-aware host may choose not to accept a HIP base exchange. If 872 the host's policy is to only be an Initiator, it should begin its own 873 HIP base exchange. A host MAY choose to have such a policy since 874 only the privacy of the Initiator's HI is protected in the exchange. 875 It should be noted that such behavior can introduce the risk of a 876 race condition if each host's policy is to only be an Initiator, at 877 which point the HIP base exchange will fail. 879 If the host's policy does not permit it to enter into a HIP exchange 880 with the Initiator, it should send an ICMP 'Destination Unreachable, 881 Administratively Prohibited' message. A more complex HIP packet is 882 not used here as it actually opens up more potential DoS attacks than 883 a simple ICMP message. A HIP NOTIFY message is not used because no 884 HIP session exists between the two hosts at that time. 886 4.1.6. Aborting a HIP Base Exchange 888 Two HIP hosts may encounter situations in which they cannot complete 889 a HIP base exchange because of insufficient support for cryptographic 890 algorithms, in particular the HIT Suites and DH Groups. After 891 receiving the R1 packet, the Initiator can determine whether the 892 Responder supports the required cryptographic operations to 893 successfully establish a HIP association. The Initiator can abort 894 the BEX silently after receiving an R1 packet that indicates an 895 unsupported set of algorithms. The specific conditions are described 896 below. 898 The R1 packet contains a signed list of HIT Suite IDs as supported by 899 the Responder. Therefore, the Initiator can determine whether its 900 source HIT is supported by the Responder. If the HIT Suite ID of the 901 Initiator's HIT is not contained in the list of HIT Suites in the R1, 902 the Initiator MAY abort the handshake silently or MAY restart the 903 handshake with a new I1 packet that contains a source HIT supported 904 by the Responder. 906 During the Handshake, the Initiator and the Responder agree on a 907 single DH Group. The Responder selects the DH Group and its DH 908 public value in the R1 based on the list of DH Suite IDs in the I1 909 packet. If the responder supports none of the DH Groups requested by 910 the Initiator, the Responder selects an arbitrary DH and replies with 911 an R1 containing its list of supported DH Group IDs. In such case, 912 the Initiator receives an R1 packet containing the DH public value 913 for an unrequested DH Group and also the Responder's DH Group list in 914 the signed part of the R1 packet. At this point, the Initiator MAY 915 abort the handshake or MAY restart the handshake by sending a new I1 916 packet containing a selection of DH Group IDs that is supported by 917 the Responder. 919 4.1.7. HIP Downgrade Protection 921 In a downgrade attack, an attacker attempts to unnoticeably 922 manipulate the packets of an Initiator and/or a Responder to 923 influence the result of the cryptographic negotiations in the BEX to 924 its favor. As a result, the victims select weaker cryptographic 925 algorithms than they would otherwise have selected without the 926 attacker's interference. Downgrade attacks can only be successful if 927 they remain un-detected by the victims and the victims falsely assume 928 a secure communication channel. 930 In HIP, almost all packet parameters related to cryptographic 931 negotiations are covered by signatures. These parameters cannot be 932 directly manipulated in a downgrade attack without invalidating the 933 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]. The transport format to 1589 be chosen is negotiated in the base exchange. The Responder 1590 expresses its preference of the transport format in the 1591 TRANSPORT_FORMAT_LIST in the R1 packet and the Initiator selects one 1592 transform and adds the respective HIP parameter to the I2 packet. 1594 4.5.4. Reboot, Timeout, and Restart of HIP 1596 Simulating a loss of state is a potential DoS attack. The following 1597 process has been crafted to manage state recovery without presenting 1598 a DoS opportunity. 1600 If a host reboots or the HIP association times out, it has lost its 1601 HIP state. If the host that lost state has a datagram to send to the 1602 peer, it simply restarts the HIP base exchange. After the base 1603 exchange has completed, the Initiator can create a new payload 1604 association and start sending data. The peer does not reset its 1605 state until it receives a valid I2 packet. 1607 If a system receives a user data packet that cannot be matched to any 1608 existing HIP association, it is possible that it has lost the state 1609 and its peer has not. It MAY send an ICMP packet with the Parameter 1610 Problem type, and with the pointer pointing to the referred HIP- 1611 related association information. Reacting to such traffic depends on 1612 the implementation and the environment where the implementation is 1613 used. 1615 If the host, that apparently has lost its state, decides to restart 1616 the HIP base exchange, it sends an I1 packet to the peer. After the 1617 base exchange has been completed successfully, the Initiator can 1618 create a new HIP association and the peer drops its old payload 1619 associations and creates a new one. 1621 4.6. Certificate Distribution 1623 This document does not define how to use certificates or how to 1624 transfer them between hosts. These functions are expected to be 1625 defined in a future specification as for HIP Version 1 1626 [I-D.ietf-hip-cert]. A parameter type value, meant to be used for 1627 carrying certificates, is reserved, though: CERT, Type 768; see 1628 Section 5.2. 1630 5. Packet Formats 1632 5.1. Payload Format 1634 All HIP packets start with a fixed header. 1636 0 1 2 3 1637 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 1638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1639 | Next Header | Header Length |0| Packet Type |Version| RES.|1| 1640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1641 | Checksum | Controls | 1642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1643 | Sender's Host Identity Tag (HIT) | 1644 | | 1645 | | 1646 | | 1647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1648 | Receiver's Host Identity Tag (HIT) | 1649 | | 1650 | | 1651 | | 1652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1653 | | 1654 / HIP Parameters / 1655 / / 1656 | | 1657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1658 The HIP header is logically an IPv6 extension header. However, this 1659 document does not describe processing for Next Header values other 1660 than decimal 59, IPPROTO_NONE, the IPv6 'no next header' value. 1661 Future documents MAY define behavior for also other values. However, 1662 current implementations MUST ignore trailing data if an unimplemented 1663 Next Header value is received. 1665 The Header Length field contains the combined length of the HIP 1666 Header and HIP parameters in 8-byte units, excluding the first 8 1667 bytes. Since all HIP headers MUST contain the sender's and 1668 receiver's HIT fields, the minimum value for this field is 4, and 1669 conversely, the maximum length of the HIP Parameters field is 1670 (255*8)-32 = 2008 bytes. Note: this sets an additional limit for 1671 sizes of parameters included in the Parameters field, independent of 1672 the individual parameter maximum lengths. 1674 The Packet Type indicates the HIP packet type. The individual packet 1675 types are defined in the relevant sections. If a HIP host receives a 1676 HIP packet that contains an unrecognized packet type, it MUST drop 1677 the packet. 1679 The HIP Version field is four bits. The version defined in this 1680 document is 2. The version number is expected to be incremented only 1681 if there are incompatible changes to the protocol. Most extensions 1682 can be handled by defining new packet types, new parameter types, or 1683 new Controls (see Section 5.1.2) . 1685 The following three bits are reserved for future use. They MUST be 1686 zero when sent, and they SHOULD be ignored when handling a received 1687 packet. 1689 The two fixed bits in the header are reserved for SHIM6 compatibility 1690 [RFC5533], Section 5.3. For implementations adhering (only) to this 1691 specification, they MUST be set as shown when sending and MUST be 1692 ignored when receiving. This is to ensure optimal forward 1693 compatibility. Note that for implementations that implement other 1694 compatible specifications in addition to this specification, the 1695 corresponding rules may well be different. For example, an 1696 implementation that implements both this specification and the SHIM6 1697 protocol may need to check these bits in order to determine how to 1698 handle the packet. 1700 The HIT fields are always 128 bits (16 bytes) long. 1702 5.1.1. Checksum 1704 Since the checksum covers the source and destination addresses in the 1705 IP header, it MUST be recomputed on HIP-aware NAT devices. 1707 If IPv6 is used to carry the HIP packet, the pseudo-header [RFC2460] 1708 contains the source and destination IPv6 addresses, HIP packet length 1709 in the pseudo-header length field, a zero field, and the HIP protocol 1710 number (see Section 4) in the Next Header field. The length field is 1711 in bytes and can be calculated from the HIP header length field: (HIP 1712 Header Length + 1) * 8. 1714 In case of using IPv4, the IPv4 UDP pseudo-header format [RFC0768] is 1715 used. In the pseudo-header, the source and destination addresses are 1716 those used in the IP header, the zero field is obviously zero, the 1717 protocol is the HIP protocol number (see Section 4), and the length 1718 is calculated as in the IPv6 case. 1720 5.1.2. HIP Controls 1722 The HIP Controls field conveys information about the structure of the 1723 packet and capabilities of the host. 1725 The following fields have been defined: 1727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1728 | | | | | | | | | | | | | | | |A| 1729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1731 A - Anonymous: If this is set, the sender's HI in this packet is 1732 anonymous, i.e., one not listed in a directory. Anonymous HIs 1733 SHOULD NOT be stored. This control is set in packets using 1734 anonymous sender HIs. The peer receiving an anonymous HI in an R1 1735 or I2 may choose to refuse it. 1737 The rest of the fields are reserved for future use and MUST be set to 1738 zero in sent packets and ignored in received packets. 1740 5.1.3. HIP Fragmentation Support 1742 A HIP implementation MUST support IP fragmentation/reassembly. 1743 Fragment reassembly MUST be implemented in both IPv4 and IPv6, but 1744 fragment generation is REQUIRED to be implemented in IPv4 (IPv4 1745 stacks and networks will usually do this by default) and RECOMMENDED 1746 to be implemented in IPv6. In IPv6 networks, the minimum MTU is 1747 larger, 1280 bytes, than in IPv4 networks. The larger MTU size is 1748 usually sufficient for most HIP packets, and therefore fragment 1749 generation may not be needed. If a host expects to send HIP packets 1750 that are larger than the minimum IPv6 MTU, it MUST implement fragment 1751 generation even for IPv6. 1753 In IPv4 networks, HIP packets may encounter low MTUs along their 1754 routed path. Since basic HIP, as defined in this document, does not 1755 provide a mechanism to use multiple IP datagrams for a single HIP 1756 packet, support for path MTU discovery does not bring any value to 1757 HIP in IPv4 networks. HIP-aware NAT devices SHOULD perform IPv4 1758 reassembly/fragmentation for HIP control packets. 1760 All HIP implementations have to be careful while employing a 1761 reassembly algorithm so that the algorithm is sufficiently resistant 1762 to DoS attacks. 1764 Certificate chains can cause the packet to be fragmented and 1765 fragmentation can open implementations to denial-of-service attacks 1766 [KAU03]. "Hash and URL" schemes as defined in [I-D.ietf-hip-cert] 1767 for HIP version 1 may be used to avoid fragmentation and mitigate 1768 resulting DoS attacks. 1770 5.2. HIP Parameters 1772 The HIP parameters carry information that is necessary for 1773 establishing and maintaining a HIP association. For example, the 1774 peer's public keys as well as the signaling for negotiating ciphers 1775 and payload handling are encapsulated in HIP parameters. Additional 1776 information, meaningful for end-hosts or middleboxes, may also be 1777 included in HIP parameters. The specification of the HIP parameters 1778 and their mapping to HIP packets and packet types is flexible to 1779 allow HIP extensions to define new parameters and new protocol 1780 behavior. 1782 In HIP packets, HIP parameters are ordered according to their numeric 1783 type number and encoded in TLV format. 1785 The following parameter types are currently defined. 1787 +------------------------+-------+-----------+----------------------+ 1788 | TLV | Type | Length | Data | 1789 +------------------------+-------+-----------+----------------------+ 1790 | R1_COUNTER | 129 | 12 | Puzzle generation | 1791 | | | | counter | 1792 | | | | | 1793 | PUZZLE | 257 | 12 | K and Random #I | 1794 | | | | | 1795 | SOLUTION | 321 | 20 | K, Random #I and | 1796 | | | | puzzle solution J | 1797 | | | | | 1798 | SEQ | 385 | 4 | UPDATE packet ID | 1799 | | | | number | 1800 | | | | | 1801 | ACK | 449 | variable | UPDATE packet ID | 1802 | | | | number | 1803 | | | | | 1804 | DH_GROUP_LIST | 511 | variable | Ordered list of DH | 1805 | | | | Group IDs supported | 1806 | | | | by a host | 1807 | | | | | 1808 | DIFFIE_HELLMAN | 513 | variable | public key | 1809 | | | | | 1810 | HIP_CIPHER | 579 | variable | List of HIP | 1811 | | | | encryption | 1812 | | | | algorithms | 1813 | | | | | 1814 | ENCRYPTED | 641 | variable | Encrypted part of a | 1815 | | | | HIP packet | 1816 | | | | | 1817 | HOST_ID | 705 | variable | Host Identity with | 1818 | | | | Fully-Qualified | 1819 | | | | Domain FQDN (Name) | 1820 | | | | or Network Access | 1821 | | | | Identifier (NAI) | 1822 | | | | | 1823 | HIT_SUITE_LIST | 715 | variable | Ordered list of the | 1824 | | | | HIT suites supported | 1825 | | | | by the Responder | 1826 | | | | | 1827 | CERT | 768 | variable | HI Certificate; used | 1828 | | | | to transfer | 1829 | | | | certificates. | 1830 | | | | Specified in a | 1831 | | | | separate docment. | 1832 | | | | | 1833 | NOTIFICATION | 832 | variable | Informational data | 1834 | | | | | 1835 | ECHO_REQUEST_SIGNED | 897 | variable | Opaque data to be | 1836 | | | | echoed back; signed | 1837 | | | | | 1838 | ECHO_RESPONSE_SIGNED | 961 | variable | Opaque data echoed | 1839 | | | | back by request; | 1840 | | | | signed | 1841 | | | | | 1842 | TRANSPORT_FORMAT_LIST | 2049 | Ordered | variable | 1843 | | | list of | | 1844 | | | preferred | | 1845 | | | HIP | | 1846 | | | transport | | 1847 | | | type | | 1848 | | | numbers | | 1849 | | | | | 1850 | HIP_MAC | 61505 | variable | HMAC-based message | 1851 | | | | authentication code, | 1852 | | | | with key material | 1853 | | | | from KEYMAT | 1854 | | | | | 1855 | HIP_MAC_2 | 61569 | variable | HMAC based message | 1856 | | | | authentication code, | 1857 | | | | with key material | 1858 | | | | from KEYMAT. Unlike | 1859 | | | | HIP_MAC, the HOST_ID | 1860 | | | | parameter is | 1861 | | | | included in | 1862 | | | | HIP_MAC_2 | 1863 | | | | calculation. | 1864 | | | | | 1865 | HIP_SIGNATURE_2 | 61633 | variable | Signature used in R1 | 1866 | | | | packet | 1867 | | | | | 1868 | HIP_SIGNATURE | 61697 | variable | Signature of the | 1869 | | | | packet | 1870 | | | | | 1871 | ECHO_REQUEST_UNSIGNED | 63661 | variable | Opaque data to be | 1872 | | | | echoed back; after | 1873 | | | | signature | 1874 | | | | | 1875 | ECHO_RESPONSE_UNSIGNED | 63425 | variable | Opaque data echoed | 1876 | | | | back by request; | 1877 | | | | after signature | 1878 +------------------------+-------+-----------+----------------------+ 1880 As the ordering (from lowest to highest) of HIP parameters is 1881 strictly enforced (see Section 5.2.1), the parameter type values for 1882 existing parameters have been spaced to allow for future protocol 1883 extensions. 1885 The following parameter type number ranges are defined. 1887 +---------------+---------------------------------------------------+ 1888 | Type Range | Purpose | 1889 +---------------+---------------------------------------------------+ 1890 | 0 - 1023 | Handshake | 1891 | | | 1892 | 1024 - 2047 | Reserved | 1893 | | | 1894 | 2048 - 4095 | Parameters related to HIP transport formats | 1895 | | | 1896 | 4096 - 8191 | Signed parameters allocated through specification | 1897 | | documents | 1898 | | | 1899 | 8192 - 32767 | Reserved | 1900 | | | 1901 | 32768 - 49151 | Free for experimentation. Signed parameters. | 1902 | | | 1903 | 41952 - 61439 | Reserved | 1904 | | | 1905 | 61440 - 64443 | Signatures and (signed) MACs | 1906 | | | 1907 | 62464 - 63487 | Parameters that are neither signed nor MACed | 1908 | | | 1909 | 63488 - 64511 | Rendezvous and relaying | 1910 | | | 1911 | 64512 - 65023 | Parameters that are neither signed nor MACed | 1912 | | | 1913 | 65024 - 65535 | Reserved | 1914 +---------------+---------------------------------------------------+ 1916 The process for defining new parameters is described in Section 5.2.2 1917 of this document. 1919 The range between 32768 (2^15) and 49151 (2^15 + 2^14) are free for 1920 experimentation. Types from this range SHOULD be selected in a 1921 random fashion to reduce the probability of collisions. 1923 5.2.1. TLV Format 1925 The TLV-encoded parameters are described in the following 1926 subsections. The type-field value also describes the order of these 1927 fields in the packet. The parameters MUST be included in the packet 1928 so that their types form an increasing order. If multiple parameters 1929 with the same type number are in one packet, the parameters with the 1930 same type MUST be consecutive in the packet. If the order does not 1931 follow this rule, the packet is considered to be malformed and it 1932 MUST be discarded. 1934 Parameters using type values from 2048 up to 4095 are related to 1935 transport formats. Currently, one transport format is defined: the 1936 ESP transport format [I-D.ietf-hip-rfc5202-bis]. 1938 All of the encoded TLV parameters have a length (that includes the 1939 Type and Length fields), which is a multiple of 8 bytes. When 1940 needed, padding MUST be added to the end of the parameter so that the 1941 total length is a multiple of 8 bytes. This rule ensures proper 1942 alignment of data. Any added padding bytes MUST be zeroed by the 1943 sender, and their values SHOULD NOT be checked by the receiver. 1945 The Length field indicates the length of the Contents field (in 1946 bytes). Consequently, the total length of the TLV parameter 1947 (including Type, Length, Contents, and Padding) is related to the 1948 Length field according to the following formula: 1950 Total Length = 11 + Length - (Length + 3) % 8; 1952 where % is the modulo operator 1954 0 1 2 3 1955 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 1956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1957 | Type |C| Length | 1958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1959 | | 1960 / Contents / 1961 / +-+-+-+-+-+-+-+-+ 1962 | | Padding | 1963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1965 Type Type code for the parameter. 16 bits long, C-bit 1966 being part of the Type code. 1967 C Critical. One if this parameter is critical, and 1968 MUST be recognized by the recipient, zero otherwise. 1969 The C bit is considered to be a part of the Type 1970 field. Consequently, critical parameters are always 1971 odd and non-critical ones have an even value. 1972 Length Length of the Contents, in bytes excluding Type, 1973 Length, and Padding. 1974 Contents Parameter specific, defined by Type 1975 Padding Padding, 0-7 bytes, added if needed 1977 Critical parameters (indicated by the odd type number) MUST be 1978 recognized by the recipient. If a recipient encounters a critical 1979 parameter that it does not recognize, it MUST NOT process the packet 1980 any further. It MAY send an ICMP or NOTIFY, as defined in 1981 Section 4.3. 1983 Non-critical parameters MAY be safely ignored. If a recipient 1984 encounters a non-critical parameter that it does not recognize, it 1985 SHOULD proceed as if the parameter was not present in the received 1986 packet. 1988 5.2.2. Defining New Parameters 1990 Future specifications may define new parameters as needed. When 1991 defining new parameters, care must be taken to ensure that the 1992 parameter type values are appropriate and leave suitable space for 1993 other future extensions. One must remember that the parameters MUST 1994 always be arranged in numerically increasing order by Type code, 1995 thereby limiting the order of parameters (see Section 5.2.1). 1997 The following rules MUST be followed when defining new parameters. 1999 1. The low-order bit C of the Type code is used to distinguish 2000 between critical and non-critical parameters. Hence, even 2001 parameter type numbers indicate non-critical parameters while odd 2002 parameter type numbers indicate critical parameters. 2004 2. A new parameter MAY be critical only if an old implementation 2005 that ignored it would cause security problems. In general, new 2006 parameters SHOULD be defined as non-critical, and expect a reply 2007 from the recipient. 2009 3. If a system implements a new critical parameter, it MUST provide 2010 the ability to set the associated feature off, such that the 2011 critical parameter is not sent at all. The configuration option 2012 MUST be well documented. Implementations operating in a mode 2013 adhering to this specification MUST disable the sending of new 2014 critical parameters by default. In other words, the management 2015 interface MUST allow vanilla standards-only mode as a default 2016 configuration setting, and MAY allow new critical payloads to be 2017 configured on (and off). 2019 4. See Section 9 for allocation rules regarding Type codes. 2021 5.2.3. R1_COUNTER 2023 0 1 2 3 2024 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 2025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2026 | Type | Length | 2027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2028 | Reserved, 4 bytes | 2029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2030 | R1 generation counter, 8 bytes | 2031 | | 2032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2034 Type 129 2035 Length 12 2036 R1 generation 2037 counter The current generation of valid puzzles 2039 The R1_COUNTER parameter contains a 64-bit unsigned integer in 2040 network-byte order, indicating the current generation of valid 2041 puzzles. The sender SHOULD increment this counter periodically. It 2042 is RECOMMENDED that the counter value is incremented at least as 2043 often as old PUZZLE values are deprecated so that SOLUTIONs to them 2044 are no longer accepted. 2046 Support for the R1_COUNTER parameter is mandatory. It SHOULD be 2047 included in the R1 (in which case, it is covered by the signature), 2048 and if present in the R1, it MUST be echoed (including the Reserved 2049 field verbatim) by the Initiator in the I2 packet. 2051 5.2.4. PUZZLE 2053 0 1 2 3 2054 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 2055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2056 | Type | Length | 2057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2058 | #K, 1 byte | Lifetime | Opaque, 2 bytes | 2059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2060 | Random #I, RHASH_len/8 bytes | 2061 / / 2062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2064 Type 257 2065 Length 4 + RHASH_len / 8 2066 #K #K is the number of verified bits 2067 Lifetime puzzle lifetime 2^(value-32) seconds 2068 Opaque data set by the Responder, indexing the puzzle 2069 Random #I random number of size RHASH_len bits 2071 Random #I is represented as a n-bit integer (where n is RHASH_len), 2072 #K and Lifetime as 8-bit integers, all in network byte order. 2074 The PUZZLE parameter contains the puzzle difficulty #K and a n-bit 2075 random integer #I. The Puzzle Lifetime indicates the time during 2076 which the puzzle solution is valid, and sets a time limit that should 2077 not be exceeded by the Initiator while it attempts to solve the 2078 puzzle. The lifetime is indicated as a power of 2 using the formula 2079 2^(Lifetime-32) seconds. A puzzle MAY be augmented with an 2080 ECHO_REQUEST_SIGNED or an ECHO_REQUEST_UNSIGNED parameter included in 2081 the R1; the contents of the echo request are then echoed back in the 2082 ECHO_RESPONSE_SIGNED or in the ECHO_RESPONSE_UNSIGNED parameter, 2083 allowing the Responder to use the included information as a part of 2084 its puzzle processing. 2086 The Opaque and Random #I field are not covered by the HIP_SIGNATURE_2 2087 parameter. 2089 5.2.5. SOLUTION 2091 0 1 2 3 2092 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 2093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2094 | Type | Length | 2095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2096 | #K, 1 byte | Reserved | Opaque, 2 bytes | 2097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2098 | Random #I, n bytes | 2099 / / 2100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2101 | Puzzle solution #J, RHASH_len/8 bytes | 2102 / / 2103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2105 Type 321 2106 Length 4 + RHASH_len /4 2107 #K #K is the number of verified bits 2108 Reserved zero when sent, ignored when received 2109 Opaque copied unmodified from the received PUZZLE 2110 parameter 2111 Random #I random number of size RHASH_len bits 2112 Puzzle solution #J random number of size RHASH_len bits 2114 Random #I and Random #J are represented as n-bit unsigned integers 2115 (where n is RHASH_len), #K as an 8-bit unsigned integer, all in 2116 network byte order. 2118 The SOLUTION parameter contains a solution to a puzzle. It also 2119 echoes back the random difficulty #K, the Opaque field, and the 2120 puzzle integer #I. 2122 5.2.6. DH_GROUP_LIST 2124 0 1 2 3 2125 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 2126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2127 | Type | Length | 2128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2129 | DH GROUP ID #1| DH GROUP ID #2| DH GROUP ID #3| DH GROUP ID #4| 2130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2131 | DH GROUP ID #n| Padding | 2132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2134 Type 511 2135 Length number of DH Group IDs 2136 DH GROUP ID defines a DH GROUP ID supported by the host. 2137 The list of IDs is ordered by preference of the 2138 host. The list of define DH Group IDs in the 2139 DIFFIE_HELLMAN parameter. Each DH Group ID is one 2140 octet long. 2142 The DH_GROUP_LIST parameter contains the list of supported DH Group 2143 IDs of a host. The Initiator sends the DH_GROUP_LIST in the I1 2144 packet, the Responder sends its own list in the signed part of the R1 2145 packet. The DH Group IDs in the DH_GROUP_LIST are listed in the 2146 order of their preference of the host sending the list. DH Group IDs 2147 that are listed first are preferred over the DH Group IDs listed 2148 later. The information in the DH_GROUP_LIST allows the Responder to 2149 select the DH group preferred by itself and supported by the 2150 Initiator. Based on the DH_GROUP_LIST in the R1 packet, the 2151 Initiator can determine if the Responder has selected the best 2152 possible choice based on the Initiator's and Responder's preferences. 2153 If the Responder's choice differs from the best choice, the Initiator 2154 can conclude that there was an attempted downgrade attack (see 2155 Section 4.1.7). 2157 When selecting the DH group for the DIFFIE_HELLMAN parameter in the 2158 R1 packet, the Responder MUST select the first DH Group ID in its 2159 DH_GROUP_LIST in the R1 packet that is compatible with one of the 2160 Suite IDs in the Initiator's DH_GROUP_LIST in the I1 packet. The 2161 Responder MUST NOT select any other DH Group ID that is contained in 2162 both lists because a downgrade attack cannot be detected then. 2164 In general, hosts SHOULD prefer stronger groups over weaker ones if 2165 the computation overhead is not prohibitively high for the intended 2166 application. 2168 5.2.7. DIFFIE_HELLMAN 2170 0 1 2 3 2171 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 2172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2173 | Type | Length | 2174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2175 | Group ID | Public Value Length | Public Value / 2176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2177 / | 2178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2179 / | Padding | 2180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2182 Type 513 2183 Length length in octets, excluding Type, Length, and 2184 Padding 2185 Group ID defines values for p and g as well as the KDF 2186 Public Value length of the following Public Value in octets 2187 Length 2188 Public Value the sender's public Diffie-Hellman key 2190 The following Group IDs have been defined: 2192 Group KDF Value 2193 Reserved 0 2194 DEPRECATED 1 2195 DEPRECATED 2 2196 1536-bit MODP group [RFC3526] HKDF [RFC5869] 3 2197 3072-bit MODP group [RFC3526] HKDF [RFC5869] 4 2198 DEPRECATED 5 2199 DEPRECATED 6 2200 NIST P-256 [RFC5903] HKDF [RFC5869] 7 2201 NIST P-384 [RFC5903] HKDF [RFC5869] 8 2202 NIST P-521 [RFC5903] HKDF [RFC5869] 9 2203 SECP160R1 [SECG] HKDF [RFC5869] 10 2205 The MODP Diffie-Hellman groups are defined in [RFC3526]. The ECDH 2206 groups 8 - 10 are defined in [RFC5903] and [RFC6090]. ECDH group 7 2207 is covered in Appendix D. 2209 The Group ID also defines the key derivation function that is to be 2210 used for deriving the symmstric keys for the HMAC and symmetric 2211 encryption from the keying material from the Diffie Hellman key 2212 exchange (see Section 6.5). 2214 A HIP implementation MUST implement Group ID 3. The 160-bit 2215 SECP160R1 group can be used when lower security is enough (e.g., web 2216 surfing) and when the equipment is not powerful enough (e.g., some 2217 PDAs). Implementations SHOULD implement Group IDs 4 and 8. 2219 To avoid unnecessary failures during the base exchange, the rest of 2220 the groups SHOULD be implemented in hosts where resources are 2221 adequate. 2223 5.2.8. HIP_CIPHER 2225 0 1 2 3 2226 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 2227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2228 | Type | Length | 2229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2230 | Cipher ID #1 | Cipher ID #2 | 2231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2232 | Cipher ID #n | Padding | 2233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2235 Type 579 2236 Length length in octets, excluding Type, Length, and 2237 Padding 2238 Cipher ID defines the cipher algorithm to be used for 2239 encrypting the contents of the ENCRYPTED parameter 2241 The following Cipher IDs are defined: 2243 Suite ID Value 2245 RESERVED 0 2246 NULL-ENCRYPT 1 ([RFC2410]) 2247 AES-128-CBC 2 ([RFC3602]) 2248 3DES-CBC 3 ([RFC2451]) 2249 AES-256-CBC 4 ([RFC3602]) 2251 The sender of a HIP_CIPHER parameter MUST make sure that there are no 2252 more than six (6) Cipher IDs in one HIP_CIPHER parameter. 2253 Conversely, a recipient MUST be prepared to handle received transport 2254 parameters that contain more than six Cipher IDs by accepting the 2255 first six Cipher IDs and dropping the rest. The limited number of 2256 transforms sets the maximum size of the HIP_CIPHER parameter. As the 2257 default configuration, the HIP_CIPHER parameter MUST contain at least 2258 one of the mandatory Cipher IDs. There MAY be a configuration option 2259 that allows the administrator to override this default. 2261 The Responder lists supported and desired Cipher IDs in order of 2262 preference in the R1, up to the maximum of six Cipher IDs. The 2263 Initiator MUST choose only one of the corresponding Cipher IDs. This 2264 Cipher ID will be used for generating the ENCRYPTED parameter. 2266 Mandatory implementation: AES-128-CBC. NULL-ENCRYPTION is included 2267 for testing purposes. 2269 5.2.9. HOST_ID 2271 0 1 2 3 2272 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 2273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2274 | Type | Length | 2275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2276 | HI Length |DI-type| DI Length | 2277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2278 | Algorithm | Host Identity / 2279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2280 / | Domain Identifier / 2281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2282 / | Padding | 2283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2285 Type 705 2286 Length length in octets, excluding Type, Length, and 2287 Padding 2288 HI Length length of the Host Identity in octets 2289 DI-type type of the following Domain Identifier field 2290 DI Length length of the Domain Identifier field in octets 2291 Algorithm index to the employed algorithm 2292 Host Identity actual Host Identity 2293 Domain Identifier the identifier of the sender 2295 The following DI-types have been defined: 2297 Type Value 2298 none included 0 2299 FQDN 1 2300 NAI 2 2302 FQDN Fully Qualified Domain Name, in binary format. 2303 NAI Network Access Identifier 2305 The format for the FQDN is defined in RFC 1035 [RFC1035] Section 3.1. 2306 The format for the NAI is defined in [RFC4282] 2308 If there is no Domain Identifier, i.e., the DI-type field is zero, 2309 the DI Length field is set to zero as well. 2311 The following HI Algorithms have been defined: 2313 Algorithm 2314 profiles Values 2316 RESERVED 0 2317 DSA 3 [RFC2536] (RECOMMENDED) 2318 RSA 5 [RFC3110] (REQUIRED) 2319 ECDSA 7 [RFC4754] (RECOMMENDED) 2320 ECDSA_LOW 9 [SECG] (RECOMMENDED) 2322 The Host Identity is derived from the DNSKEY format for RSA and DSA. 2323 For these, the Public Key field of the RDATA part from RFC 4034 2324 [RFC4034] is used. For ECC we distinguish two different profiles: 2325 ECDSA and ECDSA_LOW. ECC contains curves approved by NIST and 2326 defined in RFC 4754 [RFC4754]. ECDSA_LOW is defined for devices with 2327 low computational capabilities and uses shorter curves from SECG 2328 [SECG]. 2330 For ECDSA and ECDSA_LOW Host Identities are represented by the 2331 following fields: 2333 0 1 2 3 2334 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 2335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2336 | ECC Curve | / 2337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2338 / Public Key | 2339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2341 ECC Curve Curve label 2342 Public Key Represented in Octet-string format 2343 [RFC6090] 2345 For hosts that implement ECDSA as algorithm the following ECC curves 2346 are required: 2348 Algorithm Curve Values 2350 ECDSA RESERVED 0 2351 ECDSA NIST P-256 1 [RFC4754] 2352 ECDSA NIST P-384 2 [RFC4754] 2354 For hosts that implement the EDSA_LOW algorithm profile, the 2355 following curve is required: 2357 Algorithm Curve Values 2359 ECDSA_LOW RESERVED 0 2360 ECDSA_LOW SECP160R1 1 [SECG] 2362 5.2.10. HIT_SUITE_LIST 2364 The HIT_SUITE_LIST parameter contains a list of the supported HIT 2365 suite IDs of the Responder. The Responder sends the HIT_SUITE_LIST 2366 in the signed part of the R1 packet. Based on the HIT_SUITE_LIST, 2367 the Initiator can determine which source HITs are supported by the 2368 Responder. 2370 0 1 2 3 2371 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 2372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2373 | Type | Length | 2374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2375 | ID #1 | ID #2 | ID #3 | ID #4 | 2376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2377 | ID #n | Padding | 2378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2380 Type 715 2381 Length number of HIT Suite IDs 2382 ID defines a HIT Suite ID supported by the host. 2383 The list of IDs is ordered by preference of the 2384 host. Each HIT Suite ID is one octet long. The four 2385 higher-order bits of the ID field correspond to the 2386 HIT Suite ID in the ORCHID OGA field. The four 2387 lower-order bits are reserved and set to 0 and 2388 ignored by the receiver. 2390 The HIT Suite ID indexes a HIT Suite. HIT Suites are composed of 2391 signature algorithms as defined in Section 5.2.9 and hash functions. 2393 The ID field in the HIT_SUITE_LIST is defined as eight-bit field as 2394 opposed to the four-bit HIT Suite ID and OGA field in the ORCHID. 2395 This difference is a measure to accommodate larger HIT Suite IDs if 2396 the 16 available values prove insufficient. In that case, one of the 2397 16 values, zero, will be used to indicate that four additional bits 2398 of the ORCHID will be used to encode the HIT Suite ID. Hence, the 2399 current four-bit HIT Suite-IDs only use the four higher order bits in 2400 the ID field. Future documents may define the use of the four lower- 2401 order bits in the ID field. 2403 The following HIT Suites ID are defined: 2405 HIT Suite ID 2406 RESERVED 0 2407 RSA,DSA/SHA-256 1 (REQUIRED) 2408 ECDSA/SHA-384 2 (RECOMMENDED) 2409 ECDSA_LOW/SHA-1 3 (RECOMMENDED) 2411 5.2.11. TRANSPORT_FORMAT_LIST 2413 The TRANSPORT_FORMAT_LIST parameter contains a list of the supported 2414 HIP transport formats (TFs) of the Responder. The Responder sends 2415 the TRANSPORT_FORMAT_LIST in the signed part of the R1 packet. Based 2416 on the TRANSPORT_FORMAT_LIST, the Initiator chooses one suitable 2417 transport format and includes the respective HIP transport format 2418 parameter in its response packet. 2420 0 1 2 3 2421 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 2422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2423 | Type | Length | 2424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2425 | TF type #1 | TF type #2 / 2426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2427 / TF type #n | Padding | 2428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2430 Type 2049 2431 Length 2x number of TF types 2432 TF Type defines a transport format (TF) type supported by the 2433 host. The TF type numbers correspond to the HIP 2434 parameter type numbers of the respective transform 2435 parameters. The list of TF types is ordered by preference 2436 of the sender 2438 The TF type numbers index the respective HIP parameters for the 2439 transport formats in the type number range between 2050 to 4095. The 2440 parameters and their use is defined in separate documents. 2441 Currently, the only transport format defined is IPsec ESP 2442 [I-D.ietf-hip-rfc5202-bis]. 2444 For each listed TF type, the sender of the parameter MUST include the 2445 repective transport form parameter in the HIP packet. The TF type in 2446 the TRANSPORT_FORM_LIST MUST be ignored if no matching transport form 2447 parameter is present in the packet. 2449 5.2.12. HIP_MAC 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 | | 2457 | HMAC | 2458 / / 2459 / +-------------------------------+ 2460 | | Padding | 2461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2463 Type 61505 2464 Length length in octets, excluding Type, Length, and 2465 Padding 2466 HMAC HMAC computed over the HIP packet, excluding the 2467 HIP_MAC parameter and any following parameters, such 2468 as HIP_SIGNATURE, HIP_SIGNATURE_2, 2469 ECHO_REQUEST_UNSIGNED, or ECHO_RESPONSE_UNSIGNED. 2470 The checksum field MUST be set to zero and the HIP 2471 header length in the HIP common header MUST be 2472 calculated not to cover any excluded parameters 2473 when the HMAC is calculated. The size of the 2474 HMAC is the natural size of the hash computation 2475 output depending on the used hash function. 2477 The HMAC uses RHASH as hash algorithm. The calculation and 2478 verification process is presented in Section 6.4.1. 2480 5.2.13. HIP_MAC_2 2482 The HIP_MAC_2 is a MAC of the packet and the HOST_ID parameter of the 2483 sender while only the packet without HOST_ID of the sender is sent. 2484 The parameter structure is the same as in Section 5.2.12. The fields 2485 are: 2487 Type 61569 2488 Length length in octets, excluding Type, Length, and 2489 Padding 2490 HMAC HMAC computed over the HIP packet, excluding the 2491 HIP_MAC_2 parameter and any following parameters 2492 such as HIP_SIGNATURE, HIP_SIGNATURE_2, 2493 ECHO_REQUEST_UNSIGNED, or ECHO_RESPONSE_UNSIGNED, 2494 and including an additional sender's HOST_ID 2495 parameter during the HMAC calculation. The checksum 2496 field MUST be set to zero and the HIP header length 2497 in the HIP common header MUST be calculated not to 2498 cover any excluded parameters when the HMAC is 2499 calculated. The size of the HMAC is the natural 2500 size of the hash computation output depending on the 2501 used hash function. 2503 The HMAC uses RHASH as hash algorithm. The calculation and 2504 verification process is presented in Section 6.4.1. 2506 5.2.14. HIP_SIGNATURE 2508 0 1 2 3 2509 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 2510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2511 | Type | Length | 2512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2513 | SIG alg | Signature / 2514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2515 / | Padding | 2516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2518 Type 61697 2519 Length length in octets, excluding Type, Length, and 2520 Padding 2521 SIG alg signature algorithm 2522 Signature the signature is calculated over the HIP packet, 2523 excluding the HIP_SIGNATURE parameter and any 2524 parameters that follow the HIP_SIGNATURE parameter. 2525 When the signature is calculated the checksum field 2526 MUST be set to zero, and the HIP header length in 2527 the HIP common header MUST be calculated only up to 2528 the beginning of the HIP_SIGNATURE parameter. 2530 The signature algorithms are defined in Section 5.2.9. The signature 2531 in the Signature field is encoded using the method depending on the 2532 signature algorithm (e.g., according to [RFC3110] in case of RSA/ 2533 SHA-1, according to [RFC5702] in case of RSA/SHA-256, according to 2534 [RFC2536] in case of DSA, or according to [RFC6090] in case of 2535 ECDSA). 2537 The HIP_SIGNATURE calculation and verification process are presented 2538 in Section 6.4.2. 2540 5.2.15. HIP_SIGNATURE_2 2542 The HIP_SIGNATURE_2 excludes the variable parameters in the R1 packet 2543 to allow R1 pre-creation. The parameter structure is the same as in 2544 Section 5.2.14. The fields are: 2546 Type 61633 2547 Length length in octets, excluding Type, Length, and 2548 Padding 2549 SIG alg signature algorithm 2550 Signature Within the R1 packet that contains the 2551 HIP_SIGNATURE_2 parameter, the Initiator's HIT, the 2552 checksum field, and the Opaque and Random #I fields 2553 in the PUZZLE parameter MUST be set to zero while 2554 computing the HIP_SIGNATURE_2 signature. Further, 2555 the HIP packet length in the HIP header MUST be 2556 adjusted as if the HIP_SIGNATURE_2 was not in the 2557 packet during the signature calculation, i.e., the 2558 HIP packet length points to the beginning of 2559 the HIP_SIGNATURE_2 parameter during signing and 2560 verification. 2562 Zeroing the Initiator's HIT makes it possible to create R1 packets 2563 beforehand, to minimize the effects of possible DoS attacks. Zeroing 2564 the Random #I and Opaque fields within the PUZZLE parameter allows 2565 these fields to be populated dynamically on precomputed R1s. 2567 Signature calculation and verification follows the process defined in 2568 Section 6.4.2. 2570 5.2.16. SEQ 2572 0 1 2 3 2573 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 2574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2575 | Type | Length | 2576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2577 | Update ID | 2578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2579 Type 385 2580 Length 8 2581 Update ID 32-bit sequence number 2583 The Update ID is an unsigned number in network byte order, 2584 initialized by a host to zero upon moving to ESTABLISHED state. The 2585 Update ID has scope within a single HIP association, and not across 2586 multiple associations or multiple hosts. The Update ID is 2587 incremented by one before each new UPDATE that is sent by the host; 2588 the first UPDATE packet originated by a host has an Update ID of 0. 2590 5.2.17. ACK 2592 0 1 2 3 2593 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 2594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2595 | Type | Length | 2596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2597 | peer Update ID 1 | 2598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2599 / peer Update ID n | 2600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2602 Type 449 2603 Length length in octets, excluding Type and Length 2604 peer Update ID 32-bit sequence number corresponding to the 2605 Update ID being ACKed. 2607 The ACK parameter includes one or more Update IDs that have been 2608 received from the peer. The number of peer Update IDs can be 2609 inferred from the length by dividing it by 4. 2611 5.2.18. ENCRYPTED 2613 0 1 2 3 2614 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 2615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2616 | Type | Length | 2617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2618 | Reserved | 2619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2620 | IV / 2621 / / 2622 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 2624 / Encrypted data / 2625 / / 2626 / +-------------------------------+ 2627 / | Padding | 2628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2630 Type 641 2631 Length length in octets, excluding Type, Length, and 2632 Padding 2633 Reserved zero when sent, ignored when received 2634 IV Initialization vector, if needed, otherwise 2635 nonexistent. The length of the IV is inferred from 2636 the HIP_CIPHER. 2637 Encrypted The data is encrypted using the encryption algorithm 2638 data defined in the HIP_CIPHER parameter. 2640 The ENCRYPTED parameter encapsulates other parameters, the encrypted 2641 data, which holds one or more HIP parameters in block encrypted form. 2643 Consequently, the first fields in the encapsulated parameter(s) are 2644 Type and Length of the first such parameter, allowing the contents to 2645 be easily parsed after decryption. 2647 The field labeled "Encrypted data" consists of the output of one or 2648 more HIP parameters concatenated together that have been passed 2649 through an encryption algorithm. Each of these inner parameters is 2650 padded according to the rules of Section 5.2.1 for padding individual 2651 parameters. As a result, the concatenated parameters will be a block 2652 of data that is 8-byte aligned. 2654 Some encryption algorithms require that the data to be encrypted must 2655 be a multiple of the cipher algorithm block size. In this case, the 2656 above block of data MUST include additional padding, as specified by 2657 the encryption algorithm. The size of the extra padding is selected 2658 so that the length of the unencrypted data block is a multiple of the 2659 cipher block size. The encryption algorithm may specify padding 2660 bytes other than zero; for example, AES [FIPS.197.2001] uses the 2661 PKCS5 padding scheme (see section 6.1.1 of [RFC2898]) where the 2662 remaining n bytes to fill the block each have the value of n. This 2663 yields an "unencrypted data" block that is transformed to an 2664 "encrypted data" block by the cipher suite. This extra padding added 2665 to the set of parameters to satisfy the cipher block alignment rules 2666 is not counted in HIP TLV length fields, and this extra padding 2667 should be removed by the cipher suite upon decryption. 2669 Note that the length of the cipher suite output may be smaller or 2670 larger than the length of the set of parameters to be encrypted, 2671 since the encryption process may compress the data or add additional 2672 padding to the data. 2674 Once this encryption process is completed, the Encrypted data field 2675 is ready for inclusion in the parameter. If necessary, additional 2676 Padding for 8-byte alignment is then added according to the rules of 2677 Section 5.2.1. 2679 5.2.19. NOTIFICATION 2681 The NOTIFICATION parameter is used to transmit informational data, 2682 such as error conditions and state transitions, to a HIP peer. A 2683 NOTIFICATION parameter may appear in NOTIFY packets. The use of the 2684 NOTIFICATION parameter in other packet types is for further study. 2686 0 1 2 3 2687 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 2688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2689 | Type | Length | 2690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2691 | Reserved | Notify Message Type | 2692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2693 | / 2694 / Notification Data / 2695 / +---------------+ 2696 / | Padding | 2697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2699 Type 832 2700 Length length in octets, excluding Type, Length, and 2701 Padding 2702 Reserved zero when sent, ignored when received 2703 Notify Message specifies the type of notification 2704 Type 2705 Notification informational or error data transmitted in addition 2706 Data to the Notify Message Type. Values for this field 2707 are type specific (see below). 2708 multiple of 8 bytes. 2710 Notification information can be error messages specifying why an HIP 2711 Security Association could not be established. It can also be status 2712 data that a HIP implementation wishes to communicate with a peer 2713 process. The table below lists the notification messages and their 2714 Notification Message Types. HIP packets MAY contain multiple 2715 NOTIFICATION parameters if several problems exist or several 2716 independent pieces of information must be transmitted. 2718 To avoid certain types of attacks, a Responder SHOULD avoid sending a 2719 NOTIFICATION to any host with which it has not successfully verified 2720 a puzzle solution. 2722 Notify Message Types in the range 0-16383 are intended for reporting 2723 errors and in the range 16384-65535 for other status information. An 2724 implementation that receives a NOTIFY packet with a Notify Message 2725 Type that indicates an error in response to a request packet (e.g., 2726 I1, I2, UPDATE) SHOULD assume that the corresponding request has 2727 failed entirely. Unrecognized error types MUST be ignored except 2728 that they SHOULD be logged. 2730 As currently defined, Notify Message Type values 1-10 are used for 2731 informing about errors in packet structures, values 11-20 for 2732 informing about problems in parameters. 2734 Notification Data in NOTIFICATION parameters with status Notify 2735 Message Types MUST be ignored if not recognized. 2737 Notify Message Types - Errors Value 2738 ----------------------------- ----- 2740 UNSUPPORTED_CRITICAL_PARAMETER_TYPE 1 2742 Sent if the parameter type has the "critical" bit set and the 2743 parameter type is not recognized. Notification Data contains the 2744 two-octet parameter type. 2746 INVALID_SYNTAX 7 2748 Indicates that the HIP message received was invalid because some 2749 type, length, or value was out of range or because the request 2750 was otherwise malformed. To avoid a denial- of-service 2751 attack using forged messages, this status may only be returned 2752 for packets whose HIP_MAC (if present) and SIGNATURE have been 2753 verified. This status MUST be sent in response to any error not 2754 covered by one of the other status types, and SHOULD NOT contain 2755 details to avoid leaking information to someone probing a node. 2756 To aid debugging, more detailed error information SHOULD be 2757 written to a console or log. 2759 NO_DH_PROPOSAL_CHOSEN 14 2761 None of the proposed group IDs was acceptable. 2763 INVALID_DH_CHOSEN 15 2765 The DH Group ID field does not correspond to one offered 2766 by the Responder. 2768 NO_HIP_PROPOSAL_CHOSEN 16 2770 None of the proposed HIT Suites or HIP Encryption Algorithms was 2771 acceptable. 2773 INVALID_HIP_CIPHER_CHOSEN 17 2775 The HIP_CIPHER Crypto ID does not correspond to one offered by 2776 the Responder. 2778 UNSUPPORTED_HIT_SUITE 20 2780 Sent in response to an I1 or R1 packet for which the HIT suite 2781 is not supported. 2783 AUTHENTICATION_FAILED 24 2785 Sent in response to a HIP signature failure, except when 2786 the signature verification fails in a NOTIFY message. 2788 CHECKSUM_FAILED 26 2790 Sent in response to a HIP checksum failure. 2792 HIP_MAC_FAILED 28 2794 Sent in response to a HIP HMAC failure. 2796 ENCRYPTION_FAILED 32 2798 The Responder could not successfully decrypt the 2799 ENCRYPTED parameter. 2801 INVALID_HIT 40 2803 Sent in response to a failure to validate the peer's 2804 HIT from the corresponding HI. 2806 BLOCKED_BY_POLICY 42 2808 The Responder is unwilling to set up an association 2809 for some policy reason (e.g., received HIT is NULL 2810 and policy does not allow opportunistic mode). 2812 RESPONDER_BUSY_PLEASE_RETRY 44 2814 The Responder is unwilling to set up an association as it is 2815 suffering under some kind of overload and has chosen to shed load 2816 by rejecting the Initiator's request. The Initiator may retry; 2817 however, the Initiator MUST find another (different) puzzle 2818 solution for any such retries. Note that the Initiator may need 2819 to obtain a new puzzle with a new I1/R1 exchange. 2821 Notify Message Types - Status Value 2822 ----------------------------- ----- 2824 I2_ACKNOWLEDGEMENT 16384 2826 The Responder has an I2 packet from the Initiator but had to 2827 queue the I2 packet for processing. The puzzle was correctly 2828 solved and the Responder is willing to set up an association but 2829 currently has a number of I2 packets in the processing queue. 2830 The R2 packet is sent after the I2 packet was processed. 2832 5.2.20. ECHO_REQUEST_SIGNED 2834 0 1 2 3 2835 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 2836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2837 | Type | Length | 2838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2839 | Opaque data (variable length) | 2840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2842 Type 897 2843 Length length of the opaque data in octets 2844 Opaque data opaque data, supposed to be meaningful only to the 2845 node that sends ECHO_REQUEST_SIGNED and receives a 2846 corresponding ECHO_RESPONSE_SIGNED or 2847 ECHO_RESPONSE_UNSIGNED. 2849 The ECHO_REQUEST_SIGNED parameter contains an opaque blob of data 2850 that the sender wants to get echoed back in the corresponding reply 2851 packet. 2853 The ECHO_REQUEST_SIGNED and corresponding echo response parameters 2854 MAY be used for any purpose where a node wants to carry some state in 2855 a request packet and get it back in a response packet. The 2856 ECHO_REQUEST_SIGNED is covered by the HIP_MAC and SIGNATURE. A HIP 2857 packet can contain only one ECHO_REQUEST_SIGNED parameter and MAY 2858 contain multiple ECHO_REQUEST_UNSIGNED parameter. The 2859 ECHO_REQUEST_SIGNED parameter MUST be responded to with an 2860 ECHO_RESPONSE_SIGNED. 2862 5.2.21. ECHO_REQUEST_UNSIGNED 2864 0 1 2 3 2865 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 2866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2867 | Type | Length | 2868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2869 | Opaque data (variable length) | 2870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2872 Type 63661 2873 Length length of the opaque data in octets 2874 Opaque data opaque data, supposed to be meaningful only to the 2875 node that sends ECHO_REQUEST_UNSIGNED and receives a 2876 corresponding ECHO_RESPONSE_UNSIGNED. 2878 The ECHO_REQUEST_UNSIGNED parameter contains an opaque blob of data 2879 that the sender wants to get echoed back in the corresponding reply 2880 packet. 2882 The ECHO_REQUEST_UNSIGNED and corresponding echo response parameters 2883 MAY be used for any purpose where a node wants to carry some state in 2884 a request packet and get it back in a response packet. The 2885 ECHO_REQUEST_UNSIGNED is not covered by the HIP_MAC and SIGNATURE. A 2886 HIP packet can contain one or more ECHO_REQUEST_UNSIGNED parameters. 2887 It is possible that middleboxes add ECHO_REQUEST_UNSIGNED parameters 2888 in HIP packets passing by. The creator of the ECHO_REQUEST_UNSIGNED 2889 (end-host or middlebox) has to create the Opaque field so that it can 2890 later identify and remove the corresponding ECHO_RESPONSE_UNSIGNED 2891 parameter. 2893 The ECHO_REQUEST_UNSIGNED parameter MUST be responded to with an 2894 ECHO_RESPONSE_UNSIGNED parameter. 2896 5.2.22. ECHO_RESPONSE_SIGNED 2898 0 1 2 3 2899 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 2900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2901 | Type | Length | 2902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2903 | Opaque data (variable length) | 2904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2906 Type 961 2907 Length length of the opaque data in octets 2908 Opaque data opaque data, copied unmodified from the 2909 ECHO_REQUEST_SIGNED or ECHO_REQUEST_UNSIGNED 2910 parameter that triggered this response. 2912 The ECHO_RESPONSE_SIGNED parameter contains an opaque blob of data 2913 that the sender of the ECHO_REQUEST_SIGNED wants to get echoed back. 2914 The opaque data is copied unmodified from the ECHO_REQUEST_SIGNED 2915 parameter. 2917 The ECHO_REQUEST_SIGNED and ECHO_RESPONSE_SIGNED parameters MAY be 2918 used for any purpose where a node wants to carry some state in a 2919 request packet and get it back in a response packet. The 2920 ECHO_RESPONSE_SIGNED is covered by the HIP_MAC and SIGNATURE. 2922 5.2.23. ECHO_RESPONSE_UNSIGNED 2924 0 1 2 3 2925 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 2926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2927 | Type | Length | 2928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2929 | Opaque data (variable length) | 2930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2932 Type 63425 2933 Length length of the opaque data in octets 2934 Opaque data opaque data, copied unmodified from the 2935 ECHO_REQUEST_SIGNED or ECHO_REQUEST_UNSIGNED 2936 parameter that triggered this response. 2938 The ECHO_RESPONSE_UNSIGNED parameter contains an opaque blob of data 2939 that the sender of the ECHO_REQUEST_SIGNED or ECHO_REQUEST_UNSIGNED 2940 wants to get echoed back. The opaque data is copied unmodified from 2941 the corresponding echo request parameter. 2943 The echo request and ECHO_RESPONSE_UNSIGNED parameters MAY be used 2944 for any purpose where a node wants to carry some state in a request 2945 packet and get it back in a response packet. The 2946 ECHO_RESPONSE_UNSIGNED is not covered by the HIP_MAC and SIGNATURE. 2948 5.3. HIP Packets 2950 There are eight basic HIP packets (see Table 10). Four are for the 2951 HIP base exchange, one is for updating, one is for sending 2952 notifications, and two are for closing a HIP association. 2954 +------------------+------------------------------------------------+ 2955 | Packet type | Packet name | 2956 +------------------+------------------------------------------------+ 2957 | 1 | I1 - the HIP Initiator Packet | 2958 | | | 2959 | 2 | R1 - the HIP Responder Packet | 2960 | | | 2961 | 3 | I2 - the Second HIP Initiator Packet | 2962 | | | 2963 | 4 | R2 - the Second HIP Responder Packet | 2964 | | | 2965 | 16 | UPDATE - the HIP Update Packet | 2966 | | | 2967 | 17 | NOTIFY - the HIP Notify Packet | 2968 | | | 2969 | 18 | CLOSE - the HIP Association Closing Packet | 2970 | | | 2971 | 19 | CLOSE_ACK - the HIP Closing Acknowledgment | 2972 | | Packet | 2973 +------------------+------------------------------------------------+ 2975 Table 10: HIP packets and packet type values 2977 Packets consist of the fixed header as described in Section 5.1, 2978 followed by the parameters. The parameter part, in turn, consists of 2979 zero or more TLV-coded parameters. 2981 In addition to the base packets, other packet types may be defined 2982 later in separate specifications. For example, support for mobility 2983 and multi-homing is not included in this specification. 2985 See Notation (Section 2.2) for the notation used in the operations. 2987 In the future, an optional upper-layer payload MAY follow the HIP 2988 header. The Next Header field in the header indicates if there is 2989 additional data following the HIP header. The HIP packet, however, 2990 MUST NOT be fragmented. This limits the size of the possible 2991 additional data in the packet. 2993 5.3.1. I1 - the HIP Initiator Packet 2995 The HIP header values for the I1 packet: 2997 Header: 2998 Packet Type = 1 2999 SRC HIT = Initiator's HIT 3000 DST HIT = Responder's HIT, or NULL 3002 IP ( HIP ( DH_GROUP_LIST ) ) 3004 The I1 packet contains the fixed HIP header and the Initiator's 3005 DH_GROUP_LIST. 3007 Valid control bits: none 3009 The Initiator receives the Responder's HIT either from a DNS lookup 3010 of the Responder's FQDN (see 5205-bis), from some other repository, 3011 or from a local table. If the Initiator does not know the 3012 Responder's HIT, it may attempt to use opportunistic mode by using 3013 NULL (all zeros) as the Responder's HIT. See also "HIP Opportunistic 3014 Mode" (Section 4.1.8). 3016 Since the I1 packet is so easy to spoof even if it were signed, no 3017 attempt is made to add to its generation or processing cost. 3019 The Initiator includes a DH_GROUP_LIST parameter in the I1 packet to 3020 inform the Responder of its preferred DH Group IDs. Note that the 3021 DH_GROUP_LIST in the I1 packet is not protected by a signature. 3023 Implementations MUST be able to handle a storm of received I1 3024 packets, discarding those with common content that arrive within a 3025 small time delta. 3027 5.3.2. R1 - the HIP Responder Packet 3029 The HIP header values for the R1 packet: 3031 Header: 3032 Packet Type = 2 3033 SRC HIT = Responder's HIT 3034 DST HIT = Initiator's HIT 3036 IP ( HIP ( [ R1_COUNTER, ] 3037 PUZZLE, 3038 DIFFIE_HELLMAN, 3039 HIP_CIPHER, 3040 HOST_ID, 3041 HIT_SUITE_LIST, 3042 DH_GROUP_LIST, 3043 [ ECHO_REQUEST_SIGNED, ] 3044 HIP_SIGNATURE_2 ) 3045 <, ECHO_REQUEST_UNSIGNED >i) 3047 Valid control bits: A 3049 If the Responder's HI is an anonymous one, the A control MUST be set. 3051 The Initiator's HIT MUST match the one received in the I1 packet if 3052 the R1 is a response to an I1. If the Responder has multiple HIs, 3053 the Responder's HIT used MUST match Initiator's request. If the 3054 Initiator used opportunistic mode, the Responder may select freely 3055 among its HIs. See also "HIP Opportunistic Mode" (Section 4.1.8). 3057 The R1 packet generation counter is used to determine the currently 3058 valid generation of puzzles. The value is increased periodically, 3059 and it is RECOMMENDED that it is increased at least as often as 3060 solutions to old puzzles are no longer accepted. 3062 The Puzzle contains a Random #I and the difficulty #K. The 3063 difficulty #K indicates the number of lower-order bits, in the puzzle 3064 hash result, that must be zeros; see Section 4.1.2. The Random #I is 3065 not covered by the signature and must be zeroed during the signature 3066 calculation, allowing the sender to select and set the #I into a 3067 precomputed R1 packet just prior sending it to the peer. 3069 The Responder selects the Diffie-Hellman public value based on the 3070 Initiator's preference expressed in the DH_GROUP_LIST parameter in 3071 the I1 packet. The Responder sends back its own preference based on 3072 which it chose the DH public value as DH_GROUP_LIST. This allows the 3073 Initiator to determine whether its own DH_GROUP_LIST in the sent I1 3074 packet was manipulated by an attacker. 3076 The Diffie-Hellman public value is ephemeral, and values SHOULD NOT 3077 be reused across different HIP sessions. Once the Responder has 3078 received a valid response to an R1 packet, that Diffie-Hellman value 3079 SHOULD be deprecated. It it is possible that the Responder has sent 3080 the same Diffie-Hellman value to different hosts simultaneously in 3081 corresponding R1 packets and those responses should also be accepted. 3082 However, as a defense against I1 packet storms, an implementation MAY 3083 propose, and re-use unless avoidable, the same Diffie-Hellman value 3084 for a period of time, for example, 15 minutes. By using a small 3085 number of different puzzles for a given Diffie-Hellman value, the R1 3086 packets can be precomputed and delivered as quickly as I1 packets 3087 arrive. A scavenger process should clean up unused Diffie-Hellman 3088 values and puzzles. 3090 Re-using Diffie-Hellman public values opens up the potential security 3091 risk of more than one Initiator ending up with the same keying 3092 material (due to faulty random number generators). Also, more than 3093 one Initiator using the same Responder public key half may lead to 3094 potentially easier cryptographic attacks and to imperfect forward 3095 security. 3097 However, these risks involved in re-using the same public value are 3098 statistical; that is, the authors are not aware of any mechanism that 3099 would allow manipulation of the protocol so that the risk of the re- 3100 use of any given Responder Diffie-Hellman public key would differ 3101 from the base probability. Consequently, it is RECOMMENDED that 3102 Responders avoid re-using the same DH key with multiple Initiators, 3103 but because the risk is considered statistical and not known to be 3104 manipulable, the implementations MAY re-use a key in order to ease 3105 resource-constrained implementations and to increase the probability 3106 of successful communication with legitimate clients even under an I1 3107 packet storm. In particular, when it is too expensive to generate 3108 enough precomputed R1 packets to supply each potential Initiator with 3109 a different DH key, the Responder MAY send the same DH key to several 3110 Initiators, thereby creating the possibility of multiple legitimate 3111 Initiators ending up using the same Responder-side public key. 3112 However, as soon as the Responder knows that it will use a particular 3113 DH key, it SHOULD stop offering it. This design is aimed to allow 3114 resource-constrained Responders to offer services under I1 packet 3115 storms and to simultaneously make the probability of DH key re-use 3116 both statistical and as low as possible. 3118 If a future version of this protocol is considered, we strongly 3119 recommend that these issues be studied again. Especially, the 3120 current design allows hosts to become potentially more vulnerable to 3121 a statistical, low-probability problem during I1 packet storm attacks 3122 than what they are if no attack is taking place; whether this is 3123 acceptable or not should be reconsidered in the light of any new 3124 experience gained. 3126 The HIP_CIPHER contains the encryption algorithms supported by the 3127 Responder to encrypt the contents of the ENCRYPTED parameter, in the 3128 order of preference. All implementations MUST support AES [RFC3602]. 3130 The HIT_SUITE_LIST parameter is an ordered list of the Responder's 3131 preferred and supported HIT Suites. The list allows the Initiator to 3132 determine whether its own source HIT matches any suite supported by 3133 the Responder. 3135 The ECHO_REQUEST_SIGNED and ECHO_REQUEST_UNSIGNED parameters contain 3136 data that the sender wants to receive unmodified in the corresponding 3137 response packet in the ECHO_RESPONSE_SIGNED or ECHO_RESPONSE_UNSIGNED 3138 parameter. The R1 packet may contain zero or more 3139 ECHO_REQUEST_UNSIGNED parameters as described in Section 3140 Section 5.2.21. 3142 The signature is calculated over the whole HIP packet, after setting 3143 the Initiator's HIT, header checksum, as well as the Opaque field and 3144 the Random #I in the PUZZLE parameter temporarily to zero, and 3145 excluding any parameters that follow the signature, as described in 3146 Section 5.2.15. This allows the Responder to use precomputed R1s. 3148 The Initiator SHOULD validate this signature. It MUST check that the 3149 Responder's HI matches with the one expected, if any. 3151 5.3.3. I2 - the Second HIP Initiator Packet 3153 The HIP header values for the I2 packet: 3155 Header: 3156 Type = 3 3157 SRC HIT = Initiator's HIT 3158 DST HIT = Responder's HIT 3160 IP ( HIP ( [R1_COUNTER,] 3161 SOLUTION, 3162 DIFFIE_HELLMAN, 3163 HIP_CIPHER, 3164 ENCRYPTED { HOST_ID } or HOST_ID, 3165 [ ECHO_RESPONSE_SIGNED ,] 3166 HIP_MAC, 3167 HIP_SIGNATURE 3168 <, ECHO_RESPONSE_UNSIGNED>i ) ) 3170 Valid control bits: A 3172 The HITs used MUST match the ones used in the R1. 3174 If the Initiator's HI is an anonymous one, the A control MUST be set. 3176 If present in the I1 packet, the Initiator MUST include an unmodified 3177 copy of the R1_COUNTER parameter received in the corresponding R1 3178 packet into the I2 packet. 3180 The Solution contains the Random #I from R1 and the computed #J. The 3181 low-order #K bits of the RHASH(I | ... | J) MUST be zero. 3183 The Diffie-Hellman value is ephemeral. If precomputed, a scavenger 3184 process should clean up unused Diffie-Hellman values. The Responder 3185 MAY re-use Diffie-Hellman values under some conditions as specified 3186 in Section 5.3.2. 3188 The HIP_CIPHER contains the single encryption transform selected by 3189 the Initiator, that it uses to encrypt the ENCRYPTED parameters. The 3190 chosen cipher MUST correspond to one of the ciphers offered by the 3191 Responder in the R1. All implementations MUST support AES [RFC3602]. 3193 The Initiator's HI MAY be encrypted using the HIP_CIPHER encryption 3194 algorithm. The keying material is derived from the Diffie-Hellman 3195 exchanged as defined in Section 6.5. 3197 The ECHO_RESPONSE_SIGNED and ECHO_RESPONSE_UNSIGNED contain the 3198 unmodified Opaque data copied from the corresponding echo request 3199 parameter(s). 3201 The HMAC value in the HIP_MAC parameter is calculated over the whole 3202 HIP packet, excluding any parameters after the HIP_MAC, as described 3203 in Section 6.4.1. The Responder MUST validate the HIP_MAC. 3205 The signature is calculated over the whole HIP packet, excluding any 3206 parameters after the HIP_SIGNATURE, as described in Section 5.2.14. 3207 The Responder MUST validate this signature. The Responder uses the 3208 HI in the packet or a HI acquired by some other means for verifying 3209 the signature. 3211 5.3.4. R2 - the Second HIP Responder Packet 3213 The HIP header values for the R2 packet: 3215 Header: 3216 Packet Type = 4 3217 SRC HIT = Responder's HIT 3218 DST HIT = Initiator's HIT 3220 IP ( HIP ( HIP_MAC_2, HIP_SIGNATURE ) ) 3222 Valid control bits: none 3224 The HIP_MAC_2 is calculated over the whole HIP packet, with 3225 Responder's HOST_ID parameter concatenated with the HIP packet. The 3226 HOST_ID parameter is removed after the HMAC calculation. The 3227 procedure is described in Section 6.4.1. 3229 The signature is calculated over the whole HIP packet. 3231 The Initiator MUST validate both the HIP_MAC and the signature. 3233 5.3.5. UPDATE - the HIP Update Packet 3235 Support for the UPDATE packet is MANDATORY. 3237 The HIP header values for the UPDATE packet: 3239 Header: 3240 Packet Type = 16 3241 SRC HIT = Sender's HIT 3242 DST HIT = Recipient's HIT 3244 IP ( HIP ( [SEQ, ACK, ] HIP_MAC, HIP_SIGNATURE ) ) 3246 Valid control bits: None 3248 The UPDATE packet contains mandatory HIP_MAC and HIP_SIGNATURE 3249 parameters, and other optional parameters. 3251 The UPDATE packet contains zero or one SEQ parameter. The presence 3252 of a SEQ parameter indicates that the receiver MUST acknowledge the 3253 the UPDATE. An UPDATE that does not contain a SEQ but only an ACK 3254 parameter is simply an acknowledgment of a previous UPDATE and itself 3255 MUST NOT be acknowledged by a separate ACK. Such UPDATE packets 3256 containing only an ACK parameter do not require processing in 3257 relative order to other UPDATE packets. An UPDATE packet without 3258 either a SEQ or an ACK parameter is invalid; such unacknowledged 3259 updates MUST instead use a NOTIFY packet. 3261 An UPDATE packet contains zero or one ACK parameters. The ACK 3262 parameter echoes the SEQ sequence number of the UPDATE packet being 3263 ACKed. A host MAY choose to acknowledge more than one UPDATE packet 3264 at a time; e.g., the ACK may contain the last two SEQ values 3265 received, for resilience against ACK loss. ACK values are not 3266 cumulative; each received unique SEQ value requires at least one 3267 corresponding ACK value in reply. Received ACKs that are redundant 3268 are ignored. Hosts MUST implement the processing of ACKs with 3269 multiple SEQ numbers even if they do not implement sending ACKs with 3270 multiple SEQ numbers. 3272 The UPDATE packet may contain both a SEQ and an ACK parameter. In 3273 this case, the ACK is being piggybacked on an outgoing UPDATE. In 3274 general, UPDATEs carrying SEQ SHOULD be ACKed upon completion of the 3275 processing of the UPDATE. A host MAY choose to hold the UPDATE 3276 carrying ACK for a short period of time to allow for the possibility 3277 of piggybacking the ACK parameter, in a manner similar to TCP delayed 3278 acknowledgments. 3280 A sender MAY choose to forgo reliable transmission of a particular 3281 UPDATE (e.g., it becomes overcome by events). The semantics are such 3282 that the receiver MUST acknowledge the UPDATE, but the sender MAY 3283 choose to not care about receiving the ACK. 3285 UPDATEs MAY be retransmitted without incrementing SEQ. If the same 3286 subset of parameters is included in multiple UPDATEs with different 3287 SEQs, the host MUST ensure that the receiver's processing of the 3288 parameters multiple times will not result in a protocol error. 3290 5.3.6. NOTIFY - the HIP Notify Packet 3292 Implementing the NOTIFY packet is optional. The NOTIFY packet MAY be 3293 used to provide information to a peer. Typically, NOTIFY is used to 3294 indicate some type of protocol error or negotiation failure. NOTIFY 3295 packets are unacknowledged. The receiver can handle the packet only 3296 as informational, and SHOULD NOT change its HIP state (see 3297 Section 4.4.2) based purely on a received NOTIFY packet. 3299 The HIP header values for the NOTIFY packet: 3301 Header: 3302 Packet Type = 17 3303 SRC HIT = Sender's HIT 3304 DST HIT = Recipient's HIT, or zero if unknown 3306 IP ( HIP (i, [HOST_ID, ] HIP_SIGNATURE) ) 3308 Valid control bits: None 3310 The NOTIFY packet is used to carry one or more NOTIFICATION 3311 parameters. 3313 5.3.7. CLOSE - the HIP Association Closing Packet 3315 The HIP header values for the CLOSE packet: 3317 Header: 3318 Packet Type = 18 3319 SRC HIT = Sender's HIT 3320 DST HIT = Recipient's HIT 3322 IP ( HIP ( ECHO_REQUEST_SIGNED, HIP_MAC, HIP_SIGNATURE ) ) 3324 Valid control bits: none 3326 The sender MUST include an ECHO_REQUEST_SIGNED used to validate 3327 CLOSE_ACK received in response, and both a HIP_MAC and a signature 3328 (calculated over the whole HIP packet). 3330 The receiver peer MUST reply with a CLOSE_ACK containing an 3331 ECHO_RESPONSE_SIGNED corresponding to the received 3332 ECHO_REQUEST_SIGNED. 3334 5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet 3336 The HIP header values for the CLOSE_ACK packet: 3338 Header: 3339 Packet Type = 19 3340 SRC HIT = Sender's HIT 3341 DST HIT = Recipient's HIT 3343 IP ( HIP ( ECHO_RESPONSE_SIGNED, HIP_MAC, HIP_SIGNATURE ) ) 3345 Valid control bits: none 3347 The sender MUST include both an HMAC and signature (calculated over 3348 the whole HIP packet). 3350 The receiver peer MUST validate the ECHO_RESPONSE_SIGNED and validate 3351 both the HIP_MAC and the signature if the receiver has state for a 3352 HIP association. 3354 5.4. ICMP Messages 3356 When a HIP implementation detects a problem with an incoming packet, 3357 and it either cannot determine the identity of the sender of the 3358 packet or does not have any existing HIP association with the sender 3359 of the packet, it MAY respond with an ICMP packet. Any such replies 3360 MUST be rate-limited as described in [RFC4443]. In most cases, the 3361 ICMP packet has the Parameter Problem type (12 for ICMPv4, 4 for 3362 ICMPv6), with the Pointer field pointing to the field that caused the 3363 ICMP message to be generated. 3365 5.4.1. Invalid Version 3367 If a HIP implementation receives a HIP packet that has an 3368 unrecognized HIP version number, it SHOULD respond, rate-limited, 3369 with an ICMP packet with type Parameter Problem, with the Pointer 3370 pointing to the Version/RES. byte in the HIP header. 3372 5.4.2. Other Problems with the HIP Header and Packet Structure 3374 If a HIP implementation receives a HIP packet that has other 3375 unrecoverable problems in the header or packet format, it MAY 3376 respond, rate-limited, with an ICMP packet with type Parameter 3377 Problem, the Pointer pointing to the field that failed to pass the 3378 format checks. However, an implementation MUST NOT send an ICMP 3379 message if the checksum fails; instead, it MUST silently drop the 3380 packet. 3382 5.4.3. Invalid Puzzle Solution 3384 If a HIP implementation receives an I2 packet that has an invalid 3385 puzzle solution, the behavior depends on the underlying version of 3386 IP. If IPv6 is used, the implementation SHOULD respond with an ICMP 3387 packet with type Parameter Problem, the Pointer pointing to the 3388 beginning of the Puzzle solution #J field in the SOLUTION payload in 3389 the HIP message. 3391 If IPv4 is used, the implementation MAY respond with an ICMP packet 3392 with the type Parameter Problem, copying enough of bytes from the I2 3393 message so that the SOLUTION parameter fits into the ICMP message, 3394 the Pointer pointing to the beginning of the Puzzle solution #J 3395 field, as in the IPv6 case. Note, however, that the resulting ICMPv4 3396 message exceeds the typical ICMPv4 message size as defined in 3397 [RFC0792]. 3399 5.4.4. Non-Existing HIP Association 3401 If a HIP implementation receives a CLOSE or UPDATE packet, or any 3402 other packet whose handling requires an existing association, that 3403 has either a Receiver or Sender HIT that does not match with any 3404 existing HIP association, the implementation MAY respond, rate- 3405 limited, with an ICMP packet with the type Parameter Problem. The 3406 Pointer of the ICMP Parameter Problem packet is set pointing to the 3407 beginning of the first HIT that does not match. 3409 A host MUST NOT reply with such an ICMP if it receives any of the 3410 following messages: I1, R2, I2, R2, and NOTIFY packet. When 3411 introducing new packet types, a specification SHOULD define the 3412 appropriate rules for sending or not sending this kind of ICMP reply. 3414 6. Packet Processing 3416 Each host is assumed to have a single HIP protocol implementation 3417 that manages the host's HIP associations and handles requests for new 3418 ones. Each HIP association is governed by a conceptual state 3419 machine, with states defined above in Section 4.4. The HIP 3420 implementation can simultaneously maintain HIP associations with more 3421 than one host. Furthermore, the HIP implementation may have more 3422 than one active HIP association with another host; in this case, HIP 3423 associations are distinguished by their respective HITs. It is not 3424 possible to have more than one HIP association between any given pair 3425 of HITs. Consequently, the only way for two hosts to have more than 3426 one parallel association is to use different HITs, at least at one 3427 end. 3429 The processing of packets depends on the state of the HIP 3430 association(s) with respect to the authenticated or apparent 3431 originator of the packet. A HIP implementation determines whether it 3432 has an active association with the originator of the packet based on 3433 the HITs. In the case of user data carried in a specific transport 3434 format, the transport format document specifies how the incoming 3435 packets are matched with the active associations. 3437 6.1. Processing Outgoing Application Data 3439 In a HIP host, an application can send application-level data using 3440 an identifier specified via the underlying API. The API can be a 3441 backwards-compatible API (see [RFC5338]), using identifiers that look 3442 similar to IP addresses, or a completely new API, providing enhanced 3443 services related to Host Identities. Depending on the HIP 3444 implementation, the identifier provided to the application may be 3445 different; for example, it can be a HIT or an IP address. 3447 The exact format and method for transferring the user data from the 3448 source HIP host to the destination HIP host is defined in the 3449 corresponding transport format document. The actual data is 3450 transferred in the network using the appropriate source and 3451 destination IP addresses. 3453 In this document, conceptual processing rules are defined only for 3454 the base case where both hosts have only single usable IP addresses; 3455 the multi-address multi-homing case is specified separately. 3457 The following conceptual algorithm describes the steps that are 3458 required for handling outgoing datagrams destined to a HIT. 3460 1. If the datagram has a specified source address, it MUST be a HIT. 3461 If it is not, the implementation MAY replace the source address 3462 with a HIT. Otherwise, it MUST drop the packet. 3464 2. If the datagram has an unspecified source address, the 3465 implementation MUST choose a suitable source HIT for the 3466 datagram. Selecting the source HIT is subject to local policy. 3468 3. If there is no active HIP association with the given HIT pair, one MUST be created by running the base 3470 exchange. While waiting for the base exchange to complete, the 3471 implementation SHOULD queue at least one packet per HIP 3472 association to be formed, and it MAY queue more than one. 3474 4. Once there is an active HIP association for the given HIT pair, the outgoing datagram is passed to 3476 transport handling. The possible transport formats are defined 3477 in separate documents, of which the ESP transport format for HIP 3478 is mandatory for all HIP implementations. 3480 5. Before sending the packet, the HITs in the datagram are replaced 3481 with suitable IP addresses. For IPv6, the rules defined in 3482 [RFC3484] SHOULD be followed. Note that this HIT-to-IP-address 3483 conversion step MAY also be performed at some other point in the 3484 stack, e.g., before wrapping the packet into the output format. 3486 6.2. Processing Incoming Application Data 3488 The following conceptual algorithm describes the incoming datagram 3489 handling when HITs are used at the receiving host as application- 3490 level identifiers. More detailed steps for processing packets are 3491 defined in corresponding transport format documents. 3493 1. The incoming datagram is mapped to an existing HIP association, 3494 typically using some information from the packet. For example, 3495 such mapping may be based on the ESP Security Parameter Index 3496 (SPI). 3498 2. The specific transport format is unwrapped, in a way depending on 3499 the transport format, yielding a packet that looks like a 3500 standard (unencrypted) IP packet. If possible, this step SHOULD 3501 also verify that the packet was indeed (once) sent by the remote 3502 HIP host, as identified by the HIP association. 3504 Depending on the used transport mode, the verification method can 3505 vary. While the HI (as well as HIT) is used as the higher-layer 3506 identifier, the verification method has to verify that the data 3507 packet was sent by the correct node identity and that the actual 3508 identity maps to this particular HIT. When using ESP transport 3509 format [I-D.ietf-hip-rfc5202-bis], the verification is done using 3510 the SPI value in the data packet to find the corresponding SA 3511 with associated HIT and key, and decrypting the packet with that 3512 associated key. 3514 3. The IP addresses in the datagram are replaced with the HITs 3515 associated with the HIP association. Note that this IP-address- 3516 to-HIT conversion step MAY also be performed at some other point 3517 in the stack. 3519 4. The datagram is delivered to the upper layer (e.g., UDP or TCP). 3520 When demultiplexing the datagram, the right upper-layer socket is 3521 selected based on the HITs. 3523 6.3. Solving the Puzzle 3525 This subsection describes the details for solving the puzzle. 3527 In the R1 packet, the values #I and #K are sent in network byte 3528 order. Similarly, in the I2 packet, the values #I and #J are sent in 3529 network byte order. The hash is created by concatenating, in network 3530 byte order, the following data, in the following order and using the 3531 RHASH algorithm: 3533 n-bit random value #I (where n is RHASH_len), in network byte 3534 order, as appearing in the R1 and I2 packets. 3536 128-bit Initiator's HIT, in network byte order, as appearing in 3537 the HIP Payload in the R1 and I2 packets. 3539 128-bit Responder's HIT, in network byte order, as appearing in 3540 the HIP Payload in the R1 and I2 packets. 3542 n-bit random value #J (where n is RHASH_len), in network byte 3543 order, as appearing in the I2 packet. 3545 In a valid response puzzle, the #K low-order bits of the resulting 3546 RHASH digest MUST be zero. 3548 Notes: 3550 i) The length of the data to be hashed is variable depending on 3551 the output length of the Responder's hash function RHASH. 3553 ii) All the data in the hash input MUST be in network byte order. 3555 iii) The order of the Initiator's and Responder's HITs are 3556 different in the R1 and I2 packets; see Section 5.1. Care must be 3557 taken to copy the values in the right order to the hash input. 3559 iv) For a puzzle #I, there may exist multiple valid puzzle 3560 solutions #J. 3562 The following procedure describes the processing steps involved, 3563 assuming that the Responder chooses to precompute the R1 packets: 3565 Precomputation by the Responder: 3566 Sets up the puzzle difficulty #K. 3567 Creates a signed R1 and caches it. 3569 Responder: 3570 Selects a suitable cached R1. 3571 Generates a random number #I. 3572 Sends #I and #K in an R1. 3573 Saves #I and #K for a Delta time. 3575 Initiator: 3576 Generates repeated attempts to solve the puzzle until a matching 3577 #J is found: 3578 Ltrunc( RHASH( #I | HIT-I | HIT-R | #J ), #K ) == 0 3579 Sends #I and #J in an I2. 3581 Responder: 3582 Verifies that the received #I is a saved one. 3583 Finds the right #K based on #I. 3584 Computes V := Ltrunc( RHASH( #I | HIT-I | HIT-R | #J ), #K ) 3585 Rejects if V != 0 3586 Accept if V == 0 3588 6.4. HIP_MAC and SIGNATURE Calculation and Verification 3590 The following subsections define the actions for processing HIP_MAC, 3591 HIP_MAC_2, HIP_SIGNATURE and HIP_SIGNATURE_2 parameters. The 3592 HIP_MAC_2 parameter is contained in the R2 packet. The 3593 HIP_SIGNATURE_2 parameter is contained in the R1 packet. The 3594 HIP_SIGNATURE and HIP_MAC parameter are contained in other HIP 3595 control packets. 3597 6.4.1. HMAC Calculation 3599 The HMAC uses RHASH as underlying hash function. The type of RHASH 3600 depends on the HIT Suite of the Responder. Hence, HMAC-SHA-256 3601 [RFC4868] is used for HIT Suite RSA/DSA/SHA-256, HMAC-SHA-1 [RFC2404] 3602 is used for HIT Suite ECDSA_LOW/SHA-1, and HMAC-SHA-384 [RFC4868] for 3603 HIT Suite ECDSA/SHA-384. 3605 The following process applies both to the HIP_MAC and HIP_MAC_2 3606 parameters. When processing HIP_MAC_2, the difference is that the 3607 HIP_MAC calculation includes a pseudo HOST_ID field containing the 3608 Responder's information as sent in the R1 packet earlier. 3610 Both the Initiator and the Responder should take some care when 3611 verifying or calculating the HIP_MAC_2. Specifically, the Initiator 3612 has to preserve the HOST_ID exactly as it was received in the R1 3613 packet until it receives the HIP_MAC_2 in the R2 packet. 3615 The scope of the calculation for HIP_MAC is: 3617 HMAC: { HIP header | [ Parameters ] } 3619 where Parameters include all HIP parameters of the packet that is 3620 being calculated with Type values ranging from 1 to (HIP_MAC's Type 3621 value - 1) and exclude parameters with Type values greater or equal 3622 to HIP_MAC's Type value. 3624 During HIP_MAC calculation, the following applies: 3626 o In the HIP header, the Checksum field is set to zero. 3628 o In the HIP header, the Header Length field value is calculated to 3629 the beginning of the HIP_MAC parameter. 3631 Parameter order is described in Section 5.2.1. 3633 The scope of the calculation for HIP_MAC_2 is: 3635 HIP_MAC_2: { HIP header | [ Parameters ] | HOST_ID } 3637 where Parameters include all HIP parameters for the packet that is 3638 being calculated with Type values from 1 to (HIP_MAC_2's Type value - 3639 1) and exclude parameters with Type values greater or equal to 3640 HIP_MAC_2's Type value. 3642 During HIP_MAC_2 calculation, the following applies: 3644 o In the HIP header, the Checksum field is set to zero. 3646 o In the HIP header, the Header Length field value is calculated to 3647 the beginning of the HIP_MAC_2 parameter and increased by the 3648 length of the concatenated HOST_ID parameter length (including 3649 type and length fields). 3651 o HOST_ID parameter is exactly in the form it was received in the R1 3652 packet from the Responder. 3654 Parameter order is described in Section 5.2.1, except that the 3655 HOST_ID parameter in this calculation is added to the end. 3657 The HIP_MAC parameter is defined in Section 5.2.12 and the HIP_MAC_2 3658 parameter in Section 5.2.13. The HMAC calculation and verification 3659 process (the process applies both to HIP_MAC and HIP_MAC_2 except 3660 where HIP_MAC_2 is mentioned separately) is as follows: 3662 Packet sender: 3664 1. Create the HIP packet, without the HIP_MAC, HIP_SIGNATURE, 3665 HIP_SIGNATURE_2, or any other parameter with greater Type value 3666 than the HIP_MAC parameter has. 3668 2. In case of HIP_MAC_2 calculation, add a HOST_ID (Responder) 3669 parameter to the end of the packet. 3671 3. Calculate the Header Length field in the HIP header including the 3672 added HOST_ID parameter in case of HIP_MAC_2. 3674 4. Compute the HMAC using either HIP-gl or HIP-lg integrity key 3675 retrieved from KEYMAT as defined in Section 6.5. 3677 5. In case of HIP_MAC_2, remove the HOST_ID parameter from the 3678 packet. 3680 6. Add the HIP_MAC parameter to the packet and any parameter with 3681 greater Type value than the HIP_MAC's (HIP_MAC_2's) that may 3682 follow, including possible HIP_SIGNATURE or HIP_SIGNATURE_2 3683 parameters 3685 7. Recalculate the Length field in the HIP header. 3687 Packet receiver: 3689 1. Verify the HIP header Length field. 3691 2. Remove the HIP_MAC or HIP_MAC_2 parameter, as well as all other 3692 parameters that follow it with greater Type value including 3693 possible HIP_SIGNATURE or HIP_SIGNATURE_2 fields, saving the 3694 contents if they are needed later. 3696 3. In case of HIP_MAC_2, build and add a HOST_ID parameter (with 3697 Responder information) to the packet. The HOST_ID parameter 3698 should be identical to the one previously received from the 3699 Responder. 3701 4. Recalculate the HIP packet length in the HIP header and clear the 3702 Checksum field (set it to all zeros). In case of HIP_MAC_2, the 3703 length is calculated with the added HOST_ID parameter. 3705 5. Compute the HMAC using either HIP-gl or HIP-lg integrity key as 3706 defined in Section 6.5 and verify it against the received HMAC. 3708 6. Set Checksum and Header Length field in the HIP header to 3709 original values. Note that the checksum and length fields 3710 contain incorrect values after this step. 3712 7. In case of HIP_MAC_2, remove the HOST_ID parameter from the 3713 packet before further processing. 3715 6.4.2. Signature Calculation 3717 The following process applies both to the HIP_SIGNATURE and 3718 HIP_SIGNATURE_2 parameters. When processing the HIP_SIGNATURE_2, the 3719 only difference is that instead of the HIP_SIGNATURE parameter, the 3720 HIP_SIGNATURE_2 parameter is used, and the Initiator's HIT and PUZZLE 3721 Opaque and Random #I fields are cleared (set to all zeros) before 3722 computing the signature. The HIP_SIGNATURE parameter is defined in 3723 Section 5.2.14 and the HIP_SIGNATURE_2 parameter in Section 5.2.15. 3725 The scope of the calculation for HIP_SIGNATURE and HIP_SIGNATURE_2 3726 is: 3728 HIP_SIGNATURE: { HIP header | [ Parameters ] } 3730 where Parameters include all HIP parameters for the packet that is 3731 being calculated with Type values from 1 to (HIP_SIGNATURE's Type 3732 value - 1). 3734 During signature calculation, the following applies: 3736 o In the HIP header, the Checksum field is set to zero. 3738 o In the HIP header, the Header Length field value is calculated to 3739 the beginning of the HIP_SIGNATURE parameter. 3741 The parameter order is described in Section 5.2.1. 3743 HIP_SIGNATURE_2: { HIP header | [ Parameters ] } 3745 where Parameters include all HIP parameters for the packet that is 3746 being calculated with Type values ranging from 1 to 3747 (HIP_SIGNATURE_2's Type value - 1). 3749 During signature calculation, the following apply: 3751 o In the HIP header, the Initiator's HIT field and Checksum fields 3752 are set to zero. 3754 o In the HIP header, the Header Length field value is calculated to 3755 the beginning of the HIP_SIGNATURE_2 parameter. 3757 o PUZZLE parameter's Opaque and Random #I fields are set to zero. 3759 Parameter order is described in Section 5.2.1. 3761 The signature calculation and verification process (the process 3762 applies both to HIP_SIGNATURE and HIP_SIGNATURE_2 except in the case 3763 where HIP_SIGNATURE_2 is separately mentioned) is as follows: 3765 Packet sender: 3767 1. Create the HIP packet without the HIP_SIGNATURE parameter or any 3768 other parameters that follow the HIP_SIGNATURE parameter. 3770 2. Calculate the Length field and zero the Checksum field in the HIP 3771 header. In case of HIP_SIGNATURE_2, set Initiator's HIT field in 3772 the HIP header as well as PUZZLE parameter's Opaque and Random #I 3773 fields to zero. 3775 3. Compute the signature using the private key corresponding to the 3776 Host Identifier (public key). 3778 4. Add the HIP_SIGNATURE parameter to the packet. 3780 5. Add any parameters that follow the HIP_SIGNATURE parameter. 3782 6. Recalculate the Length field in the HIP header, and calculate the 3783 Checksum field. 3785 Packet receiver: 3787 1. Verify the HIP header Length field and checksum. 3789 2. Save the contents of the HIP_SIGNATURE parameter and any other 3790 parameters following the HIP_SIGNATURE parameter and remove them 3791 from the packet. 3793 3. Recalculate the HIP packet Length in the HIP header and clear the 3794 Checksum field (set it to all zeros). In case of 3795 HIP_SIGNATURE_2, set Initiator's HIT field in the HIP header as 3796 well as PUZZLE parameter's Opaque and Random #I fields to zero. 3798 4. Compute the signature and verify it against the received 3799 signature using the packet sender's Host Identity (public key). 3801 5. Restore the original packet by adding removed parameters (in step 3802 2) and resetting the values that were set to zero (in step 3). 3804 The verification can use either the HI received from a HIP packet, 3805 the HI from a DNS query, if the FQDN has been received in the HOST_ID 3806 packet or one received by some other means. 3808 6.5. HIP KEYMAT Generation 3810 HIP keying material is derived from the Diffie-Hellman session key, 3811 Kij, produced during the HIP base exchange (see Section 4.1.3). The 3812 Initiator has Kij during the creation of the I2 packet, and the 3813 Responder has Kij once it receives the I2 packet. This is why I2 can 3814 already contain encrypted information. 3816 The KEYMAT is derived by feeding Kij into the key derivation function 3817 defined by the DH Group ID. Currently the only key derivation 3818 function defied in this document is the Hash-based Key Derivation 3819 Function (HKDF) [RFC5869] using the RHASH hash function. Other 3820 documents may define new DH Group IDs and corresponding key 3821 distribution functions. 3823 In the following we provide the details for deriving the keying 3824 material using HKDF. 3826 where 3828 info = sort(HIT-I | HIT-R) 3829 salt = #I | #J 3831 Sort(HIT-I | HIT-R) is defined as the network byte order 3832 concatenation of the two HITs, with the smaller HIT preceding the 3833 larger HIT, resulting from the numeric comparison of the two HITs 3834 interpreted as positive (unsigned) 128-bit integers in network byte 3835 order. The #I and #J values are from the puzzle and its solution 3836 that were exchanged in R1 and I2 messages when this HIP association 3837 was set up. Both hosts have to store #I and #J values for the HIP 3838 association for future use. 3840 The initial keys are drawn sequentially in the order that is 3841 determined by the numeric comparison of the two HITs, with comparison 3842 method described in the previous paragraph. HOST_g denotes the host 3843 with the greater HIT value, and HOST_l the host with the lower HIT 3844 value. 3846 The drawing order for the four initial keys is as follows: 3848 HIP-gl encryption key for HOST_g's ENCRYPTED parameter 3850 HIP-gl integrity (HMAC) key for HOST_g's outgoing HIP packets 3852 HIP-lg encryption key for HOST_l's ENCRYPTED parameter 3854 HIP-lg integrity (HMAC) key for HOST_l's outgoing HIP packets 3856 The number of bits drawn for a given algorithm is the "natural" size 3857 of the keys. For the mandatory algorithms, the following sizes 3858 apply: 3860 AES 128 or 256 bits 3862 SHA-1 160 bits 3864 SHA-256 256 bits 3866 SHA-384 384 bits 3868 NULL 0 bits 3870 If other key sizes are used, they MUST be treated as different 3871 encryption algorithms and defined separately. 3873 6.6. Initiation of a HIP Base Exchange 3875 An implementation may originate a HIP base exchange to another host 3876 based on a local policy decision, usually triggered by an application 3877 datagram, in much the same way that an IPsec IKE key exchange can 3878 dynamically create a Security Association. Alternatively, a system 3879 may initiate a HIP exchange if it has rebooted or timed out, or 3880 otherwise lost its HIP state, as described in Section 4.5.4. 3882 The implementation prepares an I1 packet and sends it to the IP 3883 address that corresponds to the peer host. The IP address of the 3884 peer host may be obtained via conventional mechanisms, such as DNS 3885 lookup. The I1 packet contents are specified in Section 5.3.1. The 3886 selection of which source or destination Host Identity to use, if a 3887 Initiator or Responder has more than one to choose from, is typically 3888 a policy decision. 3890 The following steps define the conceptual processing rules for 3891 initiating a HIP base exchange: 3893 1. The Initiator receives one or more of the Responder's HITs and 3894 one or more addresses either from a DNS lookup of the Responder's 3895 FQDN, from some other repository, or from a local database. If 3896 the Initiator does not know the Responder's HIT, it may attempt 3897 opportunistic mode by using NULL (all zeros) as the Responder's 3898 HIT (see also "HIP Opportunistic Mode" (Section 4.1.8)). If the 3899 Initiator can choose from multiple Responder HITs, it selects a 3900 HIT for which the Initiator supports the HIT Suite. 3902 2. The Initiator sends an I1 packet to one of the Responder's 3903 addresses. The selection of which address to use is a local 3904 policy decision. 3906 3. The Initiator includes the DH_GROUP_LIST in the I1 packet. The 3907 selection and order of DH Group IDs in the DH_GROUP_LIST MUST be 3908 stored by the Initiator because this list is needed for later R1 3909 processing. In most cases, the preferences regarding the DH 3910 Groups will be static, so no per-association storage is 3911 necessary. 3913 4. Upon sending an I1 packet, the sender transitions to state I1- 3914 SENT, starts a timer for which the timeout value SHOULD be larger 3915 than the worst-case anticipated RTT. The sender SHOULD also 3916 increment the timeout counter associated with the I1. 3918 5. Upon timeout, the sender SHOULD retransmit the I1 packet and 3919 restart the timer, up to a maximum of I1_RETRIES_MAX tries. 3921 6.6.1. Sending Multiple I1 Packets in Parallel 3923 For the sake of minimizing the session establishment latency, an 3924 implementation MAY send the same I1 packet to more than one of the 3925 Responder's addresses. However, it MUST NOT send to more than three 3926 (3) Responder addresses in parallel. Furthermore, upon timeout, the 3927 implementation MUST refrain from sending the same I1 packet to 3928 multiple addresses. That is, if it retries to initialize the 3929 connection after a timeout, it MUST NOT send the I1 packet to more 3930 than one destination address. These limitations are placed in order 3931 to avoid congestion of the network, and potential DoS attacks that 3932 might occur, e.g., because someone's claim to have hundreds or 3933 thousands of addresses could generate a huge number of I1 packets 3934 from the Initiator. 3936 As the Responder is not guaranteed to distinguish the duplicate I1 3937 packets it receives at several of its addresses (because it avoids 3938 storing states when it answers back an R1 packet), the Initiator may 3939 receive several duplicate R1 packets. 3941 The Initiator SHOULD then select the initial preferred destination 3942 address using the source address of the selected received R1, and use 3943 the preferred address as a source address for the I2 packet. 3944 Processing rules for received R1s are discussed in Section 6.8. 3946 6.6.2. Processing Incoming ICMP Protocol Unreachable Messages 3948 A host may receive an ICMP 'Destination Protocol Unreachable' message 3949 as a response to sending a HIP I1 packet. Such a packet may be an 3950 indication that the peer does not support HIP, or it may be an 3951 attempt to launch an attack by making the Initiator believe that the 3952 Responder does not support HIP. 3954 When a system receives an ICMP 'Destination Protocol Unreachable' 3955 message while it is waiting for an R1 packet, it MUST NOT terminate 3956 waiting. It MAY continue as if it had not received the ICMP message, 3957 and send a few more I1 packets. Alternatively, it MAY take the ICMP 3958 message as a hint that the peer most probably does not support HIP, 3959 and return to state UNASSOCIATED earlier than otherwise. However, at 3960 minimum, it MUST continue waiting for an R1 packet for a reasonable 3961 time before returning to UNASSOCIATED. 3963 6.7. Processing Incoming I1 Packets 3965 An implementation SHOULD reply to an I1 with an R1 packet, unless the 3966 implementation is unable or unwilling to set up a HIP association. 3967 If the implementation is unable to set up a HIP association, the host 3968 SHOULD send an ICMP Destination Protocol Unreachable, 3969 Administratively Prohibited, message to the I1 packet source IP 3970 address. If the implementation is unwilling to set up a HIP 3971 association, the host MAY ignore the I1 packet. This latter case may 3972 occur during a DoS attack such as an I1 packet flood. 3974 The implementation SHOULD be able to handle a storm of received I1 3975 packets, discarding those with common content that arrive within a 3976 small time delta. 3978 A spoofed I1 packet can result in an R1 attack on a system. An R1 3979 packet sender MUST have a mechanism to rate-limit R1 packets sent to 3980 an address. 3982 It is RECOMMENDED that the HIP state machine does not transition upon 3983 sending an R1 packet. 3985 The following steps define the conceptual processing rules for 3986 responding to an I1 packet: 3988 1. The Responder MUST check that the Responder's HIT in the received 3989 I1 packet is either one of its own HITs or NULL. Otherwise it 3990 must drop the packet. 3992 2. If the Responder is in ESTABLISHED state, the Responder MAY 3993 respond to this with an R1 packet, prepare to drop an existing 3994 HIP security association with the peer, and stay at ESTABLISHED 3995 state. 3997 3. If the Responder is in I1-SENT state, it MUST make a comparison 3998 between the sender's HIT and its own (i.e., the receiver's) HIT. 3999 If the sender's HIT is greater than its own HIT, it should drop 4000 the I1 packet and stay at I1-SENT. If the sender's HIT is 4001 smaller than its own HIT, it SHOULD send the R1 packet and stay 4002 at I1-SENT. The HIT comparison is performed as defined in 4003 Section 6.5. 4005 4. If the implementation chooses to respond to the I1 packet with an 4006 R1 packet, it creates a new R1 or selects a precomputed R1 4007 according to the format described in Section 5.3.2. It creates 4008 or chooses an R1 that contains its most preferred DH public value 4009 that is also contained in the DH_GROUP_LIST in the I1 packet. If 4010 no suitable DH Group ID was contained in the DH_GROUP_LIST in the 4011 I1 packet, it sends an R1 with any suitable DH public key. 4013 5. If the received Responder's HIT in the I1 is NULL, the Responder 4014 selects a HIT with a the same HIT Suite as the Initiator's HIT. 4015 If this HIT Suite is not supported by the Responder, it SHOULD 4016 select a REQUIRED HIT Suite from Section 5.2.10, which is 4017 currently RSA/DSA/SHA-256. Other than that, selecting the HIT is 4018 a local policy matter. 4020 6. The responder expresses its supported HIP transport formats in 4021 the TRANSPORT_FORMAT_LIST as described in Section 5.2.10. The 4022 Responder MUST at least provide one payload transport format 4023 type. 4025 7. The Responder sends the R1 packet to the source IP address of the 4026 I1 packet. 4028 6.7.1. R1 Management 4030 All compliant implementations MUST be able to produce R1 packets. An 4031 R1 packet MAY be precomputed. An R1 packet MAY be reused for time 4032 Delta T, which is implementation dependent, and SHOULD be deprecated 4033 and not used once a valid response I2 packet has been received from 4034 an Initiator. During an I1 message storm, an R1 packet MAY be re- 4035 used beyond this limit. R1 information MUST NOT be discarded until 4036 Delta S after T. Time S is the delay needed for the last I2 packet 4037 to arrive back to the Responder. 4039 Implementations that support multiple DH groups MAY pre-compute R1 4040 packets for each supported group so that incoming I1 packets with 4041 different DH Group IDs in the DH_GROUP_LIST can be served quickly. 4043 An implementation MAY keep state about received I1 packets and match 4044 the received I2 packets against the state, as discussed in 4045 Section 4.1.1. 4047 6.7.2. Handling Malformed Messages 4049 If an implementation receives a malformed I1 packet, it SHOULD NOT 4050 respond with a NOTIFY message, as such practice could open up a 4051 potential denial-of-service threat. Instead, it MAY respond with an 4052 ICMP packet, as defined in Section 5.4. 4054 6.8. Processing Incoming R1 Packets 4056 A system receiving an R1 packet MUST first check to see if it has 4057 sent an I1 packet to the originator of the R1 packet (i.e., it is in 4058 state I1-SENT). If so, it SHOULD process the R1 as described below, 4059 send an I2 packet, and transition to state I2-SENT, setting a timer 4060 to protect the I2 packet. If the system is in state I2-SENT, it MAY 4061 respond to the R1 packet if the R1 packet has a larger R1 generation 4062 counter; if so, it should drop its state due to processing the 4063 previous R1 packet and start over from state I1-SENT. If the system 4064 is in any other state with respect to that host, the system SHOULD 4065 silently drop the R1 packet. 4067 When sending multiple I1 packets, an Initiator SHOULD wait for a 4068 small amount of time after the first R1 reception to allow possibly 4069 multiple R1 packets to arrive, and it SHOULD respond to an R1 packet 4070 among the set with the largest R1 generation counter. 4072 The following steps define the conceptual processing rules for 4073 responding to an R1 packet: 4075 1. A system receiving an R1 MUST first check to see if it has sent 4076 an I1 packet to the originator of the R1 packet (i.e., it has a 4077 HIP association that is in state I1-SENT and that is associated 4078 with the HITs in the R1). Unless the I1 packet was sent in 4079 opportunistic mode (see Section 4.1.8), the IP addresses in the 4080 received R1 packet SHOULD be ignored by the R1 processing and, 4081 when looking up the right HIP association, the received R1 4082 packet SHOULD be matched against the associations using only the 4083 HITs. If a match exists, the system should process the R1 4084 packet as described below. 4086 2. Otherwise, if the system is in any other state than I1-SENT or 4087 I2-SENT with respect to the HITs included in the R1 packet, it 4088 SHOULD silently drop the R1 packet and remain in the current 4089 state. 4091 3. If the HIP association state is I1-SENT or I2-SENT, the received 4092 Initiator's HIT MUST correspond to the HIT used in the original 4093 I1. Also, the Responder's HIT MUST correspond to the one used 4094 in the I1, unless the I1 packet contained a NULL HIT. 4096 4. The system SHOULD validate the R1 signature before applying 4097 further packet processing, according to Section 5.2.15. 4099 5. If the HIP association state is I1-SENT, and multiple valid R1 4100 packets are present, the system MUST select from among the R1 4101 packets with the largest R1 generation counter. 4103 6. The system MUST check that the Initiator HIT Suite is contained 4104 in the HIT_SUITE_LIST parameter in the R1 packet (i.e., the 4105 Initiator's HIT Suite is supported by the Responder). If the 4106 HIT Suite is supported by the Responder, the system proceeds 4107 normally. Otherwise, the system MAY stay in state I1-sent and 4108 restart the BEX by sending a new I1 packet with an Initiator HIT 4109 that is supported by the Responder and hence is contained in the 4110 HIT_SUITE_LIST in the R1 packet. The system MAY abort the BEX 4111 if no suitable source HIT is available. The system SHOULD wait 4112 for an acceptable time span to allow further R1 packets with 4113 higher R1 generation counters or different HIT and HIT Suites to 4114 arrive before restarting or aborting the BEX. 4116 7. The system MUST check that the DH Group ID in the DIFFIE_HELLMAN 4117 parameter in the R1 matches the first DH Suite ID in the 4118 Responder's DH_GROUP_LIST in the R1 packet that was also 4119 contained in the Initiator's DH_GROUP_LIST in the I1 packet. If 4120 the DH Group ID of the DIFFIE_HELLMAN parameter does not express 4121 the Responder's best choice, the Initiator can conclude that the 4122 DH_GROUP_LIST in the I1 packet was adversely modified. In such 4123 case, the Initiator MAY send a new I1 packet, however, it SHOULD 4124 NOT change its preference in the DH_GROUP_LIST in the new I1 4125 packet. Alternatively, the Initiator MAY abort the HIP base 4126 exchange. 4128 8. If the HIP association state is I2-SENT, the system MAY re-enter 4129 state I1-SENT and process the received R1 packet if it has a 4130 larger R1 generation counter than the R1 packet responded to 4131 previously. 4133 9. The R1 packet may have the A bit set -- in this case, the system 4134 MAY choose to refuse it by dropping the R1 packet and returning 4135 to state UNASSOCIATED. The system SHOULD consider dropping the 4136 R1 packet only if it used a NULL HIT in I1 packet. If the A bit 4137 is set, the Responder's HIT is anonymous and SHOULD NOT be 4138 stored permanently. 4140 10. The system SHOULD attempt to validate the HIT against the 4141 received Host Identity by using the received Host Identity to 4142 construct a HIT and verify that it matches the Sender's HIT. 4144 11. The system MUST store the received R1 generation counter for 4145 future reference. 4147 12. The system attempts to solve the puzzle in the R1 packet. The 4148 system MUST terminate the search after exceeding the remaining 4149 lifetime of the puzzle. If the puzzle is not successfully 4150 solved, the implementation MAY either resend the I1 packet 4151 within the retry bounds or abandon the HIP base exchange. 4153 13. The system computes standard Diffie-Hellman keying material 4154 according to the public value and Group ID provided in the 4155 DIFFIE_HELLMAN parameter. The Diffie-Hellman keying material 4156 Kij is used for key extraction as specified in Section 6.5. 4158 14. The system selects the HIP_CIPHER ID from the choices presented 4159 in the R1 packet and uses the selected values subsequently when 4160 generating and using encryption keys, and when sending the I2 4161 packet. If the proposed alternatives are not acceptable to the 4162 system, it may either resend an I1 within the retry bounds or 4163 abandon the HIP base exchange. 4165 15. The system chooses one suitable transport format from the 4166 TRANSPORT_FORMAT_LIST and includes the respective transport 4167 format parameter in the subsequent I2 packet. 4169 16. The system initializes the remaining variables in the associated 4170 state, including Update ID counters. 4172 17. The system prepares and sends an I2 packet, as described in 4173 Section 5.3.3. 4175 18. The system SHOULD start a timer whose timeout value SHOULD be 4176 larger than the worst-case anticipated RTT, and MUST increment a 4177 timeout counter associated with the I2 packet. The sender 4178 SHOULD retransmit the I2 packet upon a timeout and restart the 4179 timer, up to a maximum of I2_RETRIES_MAX tries. 4181 19. If the system is in state I1-SENT, it SHALL transition to state 4182 I2-SENT. If the system is in any other state, it remains in the 4183 current state. 4185 6.8.1. Handling of Malformed Messages 4187 If an implementation receives a malformed R1 message, it MUST 4188 silently drop the packet. Sending a NOTIFY or ICMP would not help, 4189 as the sender of the R1 packet typically doesn't have any state. An 4190 implementation SHOULD wait for some more time for a possibly well- 4191 formed R1, after which it MAY try again by sending a new I1 packet. 4193 6.9. Processing Incoming I2 Packets 4195 Upon receipt of an I2 packet, the system MAY perform initial checks 4196 to determine whether the I2 packet corresponds to a recent R1 packet 4197 that has been sent out, if the Responder keeps such state. For 4198 example, the sender could check whether the I2 packet is from an 4199 address or HIT for which the Responder has recently received an I1. 4200 The R1 packet may have had Opaque data included that was echoed back 4201 in the I2 packet. If the I2 packet is considered to be suspect, it 4202 MAY be silently discarded by the system. 4204 Otherwise, the HIP implementation SHOULD process the I2 packet. This 4205 includes validation of the puzzle solution, generating the Diffie- 4206 Hellman key, possibly decrypting the Initiator's Host Identity, 4207 verifying the signature, creating state, and finally sending an R2 4208 packet. 4210 The following steps define the conceptual processing rules for 4211 responding to an I2 packet: 4213 1. The system MAY perform checks to verify that the I2 packet 4214 corresponds to a recently sent R1 packet. Such checks are 4215 implementation dependent. See Appendix A for a description of 4216 an example implementation. 4218 2. The system MUST check that the Responder's HIT corresponds to 4219 one of its own HITs and MUST drop the packet otherwise. 4221 3. The system MUST further check that the Initiator's HIT Suite is 4222 supported. The Responder SHOULD silently drop I2 packets with 4223 unsupported Initiator HITs. 4225 4. If the system's state machine is in the R2-SENT state, the 4226 system MAY check if the newly received I2 packet is similar to 4227 the one that triggered moving to R2-SENT. If so, it MAY 4228 retransmit a previously sent R2 packet, reset the R2-SENT timer, 4229 and the state machine stays in R2-SENT. 4231 5. If the system's state machine is in the I2-SENT state, the 4232 system makes a comparison between its local and sender's HITs 4233 (similarly as in Section 6.5). If the local HIT is smaller than 4234 the sender's HIT, it should drop the I2 packet, use the peer 4235 Diffie-Hellman key and nonce #I from the R1 packet received 4236 earlier, and get the local Diffie-Hellman key and nonce #J from 4237 the I2 packet sent to the peer earlier. Otherwise, the system 4238 should process the received I2 packet and drop any previously 4239 derived Diffie-Hellman keying material Kij it might have formed 4240 upon sending the I2 packet previously. The peer Diffie-Hellman 4241 key and the nonce #J are taken from the just arrived I2 packet. 4242 The local Diffie-Hellman key and the nonce I are the ones that 4243 were sent earlier in the R1 packet. 4245 6. If the system's state machine is in the I1-SENT state, and the 4246 HITs in the I2 packet match those used in the previously sent I1 4247 packet, the system uses this received I2 packet as the basis for 4248 the HIP association it was trying to form, and stops 4249 retransmitting I1 packets (provided that the I2 packet passes 4250 the additional checks below). 4252 7. If the system's state machine is in any other state than R2- 4253 SENT, the system SHOULD check that the echoed R1 generation 4254 counter in the I2 packet is within the acceptable range if the 4255 counter is included. Implementations MUST accept puzzles from 4256 the current generation and MAY accept puzzles from earlier 4257 generations. If the generation counter in the newly received I2 4258 packet is outside the accepted range, the I2 packet is stale 4259 (and perhaps replayed) and SHOULD be dropped. 4261 8. The system MUST validate the solution to the puzzle by computing 4262 the hash described in Section 5.3.3 using the same RHASH 4263 algorithm. 4265 9. The I2 packet MUST have a single value in the HIP_CIPHER 4266 parameter, which MUST match one of the values offered to the 4267 Initiator in the R1 packet. 4269 10. The system must derive Diffie-Hellman keying material Kij based 4270 on the public value and Group ID in the DIFFIE_HELLMAN 4271 parameter. This key is used to derive the HIP association keys, 4272 as described in Section 6.5. If the Diffie-Hellman Group ID is 4273 unsupported, the I2 packet is silently dropped. 4275 11. The encrypted HOST_ID is decrypted by the Initiator's encryption 4276 key defined in Section 6.5. If the decrypted data is not a 4277 HOST_ID parameter, the I2 packet is silently dropped. 4279 12. The implementation SHOULD also verify that the Initiator's HIT 4280 in the I2 packet corresponds to the Host Identity sent in the I2 4281 packet. (Note: some middleboxes may not able to make this 4282 verification.) 4284 13. The system MUST verify the HIP_MAC according to the procedures 4285 in Section 5.2.12. 4287 14. The system MUST verify the HIP_SIGNATURE according to 4288 Section 5.2.14 and Section 5.3.3. 4290 15. If the checks above are valid, then the system proceeds with 4291 further I2 processing; otherwise, it discards the I2 and its 4292 state machine remains in the same state. 4294 16. The I2 packet may have the A bit set -- in this case, the system 4295 MAY choose to refuse it by dropping the I2 and the state machine 4296 returns to state UNASSOCIATED. If the A bit is set, the 4297 Initiator's HIT is anonymous and should not be stored 4298 permanently. 4300 17. The system initializes the remaining variables in the associated 4301 state, including Update ID counters. 4303 18. Upon successful processing of an I2 message when the system's 4304 state machine is in state UNASSOCIATED, I1-SENT, I2-SENT, or R2- 4305 SENT, an R2 packet is sent and the system's state machine 4306 transitions to state R2-SENT. 4308 19. Upon successful processing of an I2 packet when the system's 4309 state machine is in state ESTABLISHED, the old HIP association 4310 is dropped and a new one is installed, an R2 packet is sent, and 4311 the system's state machine transitions to R2-SENT. 4313 20. Upon the system's state machine transitioning to R2-SENT, the 4314 system starts a timer. The state machine transitions to 4315 ESTABLISHED if some data has been received on the incoming HIP 4316 association, or an UPDATE packet has been received (or some 4317 other packet that indicates that the peer system's state machine 4318 has moved to ESTABLISHED). If the timer expires (allowing for 4319 maximal amount of retransmissions of I2 packets), the state 4320 machine transitions to ESTABLISHED. 4322 6.9.1. Handling of Malformed Messages 4324 If an implementation receives a malformed I2 message, the behavior 4325 SHOULD depend on how many checks the message has already passed. If 4326 the puzzle solution in the message has already been checked, the 4327 implementation SHOULD report the error by responding with a NOTIFY 4328 packet. Otherwise, the implementation MAY respond with an ICMP 4329 message as defined in Section 5.4. 4331 6.10. Processing of Incoming R2 Packets 4333 An R2 packet received in states UNASSOCIATED, I1-SENT, or ESTABLISHED 4334 results in the R2 packet being dropped and the state machine staying 4335 in the same state. If an R2 packet is received in state I2-SENT, it 4336 MUST be processed. 4338 The following steps define the conceptual processing rules for an 4339 incoming R2 packet: 4341 1. If the system is in any other state than I2-SENT, the R2 packet 4342 is silently dropped. 4344 2. The system MUST verify that the HITs in use correspond to the 4345 HITs that were received in the R1 packet that caused the 4346 transition to the I1-SENT state. 4348 3. The system MUST verify the HIP_MAC_2 according to the procedures 4349 in Section 5.2.13. 4351 4. The system MUST verify the HIP signature according to the 4352 procedures in Section 5.2.14. 4354 5. If any of the checks above fail, there is a high probability of 4355 an ongoing man-in-the-middle or other security attack. The 4356 system SHOULD act accordingly, based on its local policy. 4358 6. Upon successful processing of the R2 packet, the state machine 4359 transitions to state ESTABLISHED. 4361 6.11. Sending UPDATE Packets 4363 A host sends an UPDATE packet when it intends to update some 4364 information related to a HIP association. There are a number of 4365 possible scenarios when this can occur, e.g., mobility management and 4366 rekeying of an existing ESP Security Association. The following 4367 paragraphs define the conceptual rules for sending an UPDATE packet 4368 to the peer. Additional steps can be defined in other documents 4369 where the UPDATE packet is used. 4371 The sequence of UPDATE messages is indicated by their SEQ parameter. 4372 Before sending an UPDATE message, the system first determines whether 4373 there are any outstanding UPDATE messages that may conflict with the 4374 new UPDATE message under consideration. When multiple UPDATEs are 4375 outstanding (not yet acknowledged), the sender must assume that such 4376 UPDATEs may be processed in an arbitrary order by the receiver. 4377 Therefore, any new UPDATEs that depend on a previous outstanding 4378 UPDATE being successfully received and acknowledged MUST be postponed 4379 until reception of the necessary ACK(s) occurs. One way to prevent 4380 any conflicts is to only allow one outstanding UPDATE at a time. 4381 However, allowing multiple UPDATEs may improve the performance of 4382 mobility and multihoming protocols. 4384 The following steps define the conceptual processing rules for 4385 sending UPDATE packets. 4387 1. The first UPDATE packet is sent with Update ID of zero. 4388 Otherwise, the system increments its own Update ID value by one 4389 before continuing the steps below. 4391 2. The system creates an UPDATE packet that contains a SEQ parameter 4392 with the current value of Update ID. The UPDATE packet MAY also 4393 include zero or more ACKs of the peer's Update ID(s) from 4394 previously received UPDATE SEQ parameter(s) 4396 3. The system sends the created UPDATE packet and starts an UPDATE 4397 timer. The default value for the timer is 2 * RTT estimate. If 4398 multiple UPDATEs are outstanding, multiple timers are in effect. 4400 4. If the UPDATE timer expires, the UPDATE is resent. The UPDATE 4401 can be resent UPDATE_RETRY_MAX times. The UPDATE timer SHOULD be 4402 exponentially backed off for subsequent retransmissions. If no 4403 acknowledgment is received from the peer after UPDATE_RETRY_MAX 4404 times, the HIP association is considered to be broken and the 4405 state machine SHOULD move from state ESTABLISHED to state CLOSING 4406 as depicted in Section 4.4.4. The UPDATE timer is cancelled upon 4407 receiving an ACK from the peer that acknowledges receipt of the 4408 UPDATE. 4410 6.12. Receiving UPDATE Packets 4412 When a system receives an UPDATE packet, its processing depends on 4413 the state of the HIP association and the presence and values of the 4414 SEQ and ACK parameters. Typically, an UPDATE message also carries 4415 optional parameters whose handling is defined in separate documents. 4417 For each association, a host stores the peer's next expected in- 4418 sequence Update ID ("peer Update ID"). Initially, this value is 4419 zero. Update ID comparisons of "less than" and "greater than" are 4420 performed with respect to a circular sequence number space. Hence, a 4421 wrap around after 2^32 updates has to be expected and MUST be handled 4422 accordingly. 4424 The sender MAY send multiple outstanding UPDATE messages. These 4425 messages are processed in the order in which they are received at the 4426 receiver (i.e., no re-sequencing is performed). When processing 4427 UPDATEs out-of-order, the receiver MUST keep track of which UPDATEs 4428 were previously processed, so that duplicates or retransmissions are 4429 ACKed and not reprocessed. A receiver MAY choose to define a receive 4430 window of Update IDs that it is willing to process at any given time, 4431 and discard received UPDATEs falling outside of that window. 4433 The following steps define the conceptual processing rules for 4434 receiving UPDATE packets. 4436 1. If there is no corresponding HIP association, the implementation 4437 MAY reply with an ICMP Parameter Problem, as specified in 4438 Section 5.4.4. 4440 2. If the association is in the ESTABLISHED state and the SEQ (but 4441 not ACK) parameter is present, the UPDATE is processed and 4442 replied to as described in Section 6.12.1. 4444 3. If the association is in the ESTABLISHED state and the ACK (but 4445 not SEQ) parameter is present, the UPDATE is processed as 4446 described in Section 6.12.2. 4448 4. If the association is in the ESTABLISHED state and there is both 4449 an ACK and SEQ in the UPDATE, the ACK is first processed as 4450 described in Section 6.12.2, and then the rest of the UPDATE is 4451 processed as described in Section 6.12.1. 4453 6.12.1. Handling a SEQ Parameter in a Received UPDATE Message 4455 The following steps define the conceptual processing rules for 4456 handling a SEQ parameter in a received UPDATE packet. 4458 1. If the Update ID in the received SEQ is not the next in the 4459 sequence of Update IDs and is greater than the receiver's window 4460 for new UPDATEs, the packet MUST be dropped. 4462 2. If the Update ID in the received SEQ corresponds to an UPDATE 4463 that has recently been processed, the packet is treated as a 4464 retransmission. The HIP_MAC verification (next step) MUST NOT be 4465 skipped. (A byte-by-byte comparison of the received and a stored 4466 packet would be acceptable, though.) It is recommended that a 4467 host caches UPDATE packets sent with ACKs to avoid the cost of 4468 generating a new ACK packet to respond to a replayed UPDATE. The 4469 system MUST acknowledge, again, such (apparent) UPDATE message 4470 retransmissions but SHOULD also consider rate-limiting such 4471 retransmission responses to guard against replay attacks. 4473 3. The system MUST verify the HIP_MAC in the UPDATE packet. If the 4474 verification fails, the packet MUST be dropped. 4476 4. The system MAY verify the SIGNATURE in the UPDATE packet. If the 4477 verification fails, the packet SHOULD be dropped and an error 4478 message logged. 4480 5. If a new SEQ parameter is being processed, the parameters in the 4481 UPDATE are then processed. The system MUST record the Update ID 4482 in the received SEQ parameter, for replay protection. 4484 6. An UPDATE acknowledgment packet with ACK parameter is prepared 4485 and sent to the peer. This ACK parameter MAY be included in a 4486 separate UPDATE or piggybacked in an UPDATE with SEQ parameter, 4487 as described in Section 5.3.5. The ACK parameter MAY acknowledge 4488 more than one of the peer's Update IDs. 4490 6.12.2. Handling an ACK Parameter in a Received UPDATE Packet 4492 The following steps define the conceptual processing rules for 4493 handling an ACK parameter in a received UPDATE packet. 4495 1. The sequence number reported in the ACK must match with an UPDATE 4496 packet sent earlier that has not already been acknowledged. If 4497 no match is found or if the ACK does not acknowledge a new 4498 UPDATE, the packet MUST either be dropped if no SEQ parameter is 4499 present, or the processing steps in Section 6.12.1 are followed. 4501 2. The system MUST verify the HIP_MAC in the UPDATE packet. If the 4502 verification fails, the packet MUST be dropped. 4504 3. The system MAY verify the SIGNATURE in the UPDATE packet. If the 4505 verification fails, the packet SHOULD be dropped and an error 4506 message logged. 4508 4. The corresponding UPDATE timer is stopped (see Section 6.11) so 4509 that the now acknowledged UPDATE is no longer retransmitted. If 4510 multiple UPDATEs are acknowledged, multiple timers are stopped. 4512 6.13. Processing of NOTIFY Packets 4514 Processing of NOTIFY packets is OPTIONAL. If processed, any errors 4515 in a received NOTIFICATION parameter SHOULD be logged. Received 4516 errors MUST be considered only as informational, and the receiver 4517 SHOULD NOT change its HIP state (see Section 4.4.2) purely based on 4518 the received NOTIFY message. 4520 6.14. Processing CLOSE Packets 4522 When the host receives a CLOSE message, it responds with a CLOSE_ACK 4523 message and moves to CLOSED state. (The authenticity of the CLOSE 4524 message is verified using both HIP_MAC and SIGNATURE). This 4525 processing applies whether or not the HIP association state is 4526 CLOSING in order to handle simultaneous CLOSE messages from both ends 4527 that cross in flight. 4529 The HIP association is not discarded before the host moves to the 4530 UNASSOCIATED state. 4532 Once the closing process has started, any new need to send data 4533 packets triggers creating and establishing of a new HIP association, 4534 starting with sending of an I1 packet. 4536 If there is no corresponding HIP association, the CLOSE packet is 4537 dropped. 4539 6.15. Processing CLOSE_ACK Packets 4541 When a host receives a CLOSE_ACK message, it verifies that it is in 4542 CLOSING or CLOSED state and that the CLOSE_ACK was in response to the 4543 CLOSE. A host can map CLOSE_ACK messages to CLOSE messages by 4544 comparing the value of ECHO_REQUEST_SIGNED (in the CLOSE packet) to 4545 the value of ECHO_RESPONSE_SIGNED (in the CLOSE_ACK packet). 4547 The CLOSE_ACK contains the HIP_MAC and the SIGNATURE parameters for 4548 verification. The state is discarded when the state changes to 4549 UNASSOCIATED and, after that, the host MAY respond with an ICMP 4550 Parameter Problem to an incoming CLOSE message (see Section 5.4.4). 4552 6.16. Handling State Loss 4554 In the case of a system crash and unanticipated state loss, the 4555 system SHOULD delete the corresponding HIP state, including the 4556 keying material. That is, the state SHOULD NOT be stored in long- 4557 term storage. If the implementation does drop the state (as 4558 RECOMMENDED), it MUST also drop the peer's R1 generation counter 4559 value, unless a local policy explicitly defines that the value of 4560 that particular host is stored. An implementation MUST NOT store a 4561 peer's R1 generation counters by default, but storing R1 generation 4562 counter values, if done, MUST be configured by explicit HITs. 4564 7. HIP Policies 4566 There are a number of variables that will influence the HIP base 4567 exchanges that each host must support. All HIP implementations MUST 4568 support more than one simultaneous HI, at least one of which SHOULD 4569 be reserved for anonymous usage. Although anonymous HIs will be 4570 rarely used as Responders' HIs, they will be common for Initiators. 4571 Support for more than two HIs is RECOMMENDED. 4573 Initiators MAY use a different HI for different Responders to provide 4574 basic privacy. Whether such private HIs are used repeatedly with the 4575 same Responder and how long these HIs are used is decided by local 4576 policy and depends on the privacy requirements of the Initiator. 4578 The value of #K used in the HIP R1 must be chosen with care. Too 4579 high numbers of #K will exclude clients with weak CPUs because these 4580 devices cannot solve the puzzle within reasonable time. #K should 4581 only be raised if a Responder is under high load, i.e., it cannot 4582 process all incoming HIP handshakes any more. If a responder is not 4583 under high load, K SHOULD be 0. 4585 Responders that only respond to selected Initiators require an ACL, 4586 representing for which hosts they accept HIP base exchanges, and the 4587 preferred transform and local lifetimes. Wildcarding SHOULD be 4588 supported for such ACLs, and also for Responders that offer public or 4589 anonymous services. 4591 8. Security Considerations 4593 HIP is designed to provide secure authentication of hosts. HIP also 4594 attempts to limit the exposure of the host to various denial-of- 4595 service and man-in-the-middle (MitM) attacks. In doing so, HIP 4596 itself is subject to its own DoS and MitM attacks that potentially 4597 could be more damaging to a host's ability to conduct business as 4598 usual. 4600 Denial-of-service attacks often take advantage of asymmetries in the 4601 cost of an starting an association. One example of such asymmetry is 4602 the need of a Responder to store local state while a malicious 4603 Initiator can stay stateless. HIP makes no attempt to increase the 4604 cost of the start of state at the Initiator, but makes an effort to 4605 reduce the cost for the Responder. This is accomplished by having 4606 the Responder start the 3-way exchange instead of the Initiator, 4607 making the HIP protocol 4 packets long. In doing this, the first 4608 packet from the Responder, R1, becomes a 'stock' packet that the 4609 Responder MAY use many times, until some Initiator has provided a 4610 valid response to such an R1 packet. During an I1 packet storm, the 4611 host may reuse the same DH value also even if some Initiator has 4612 provided a valid response using that particular DH value. However, 4613 such behavior is discouraged and should be avoided. Using the same 4614 Diffie-Hellman values and random puzzle #I value has some risks. 4615 This risk needs to be balanced against a potential storm of HIP I1 4616 packets. 4618 This shifting of the start of state cost to the Initiator in creating 4619 the I2 HIP packet presents another DoS attack. The attacker can 4620 spoof the I1 packet and the Responder sends out the R1 HIP packet. 4621 This could conceivably tie up the 'Initiator' with evaluating the R1 4622 HIP packet, and creating the I2 packet. The defense against this 4623 attack is to simply ignore any R1 packet where a corresponding I1 4624 packet was not sent (as defined in Section 6.8 step 1). 4626 The R1 packet is considerably larger than the I1 packet. This 4627 asymmetry can be exploited in an reflection attack. A malicious 4628 attacker could spoof the IP address of a victim and send a flood of 4629 I1 messages to a powerful Responder. For each small I1 packet, the 4630 Responder would send a larger R1 packet to the victim. The 4631 difference in packet sizes can further amplify a flooding attack 4632 against the victim. To avoid such reflection attacks, the Responder 4633 SHOULD rate limit the sending of R1 packets in general or SHOULD rate 4634 limit the sending of R1 packets to a specific IP address. 4636 Floods of forged I2 packets form a second kind of DoS attack. Once 4637 the attacking Initiator has solved the puzzle, it can send packets 4638 with spoofed IP source addresses with either an invalid HIP signature 4639 or invalid encrypted HIP payload (in the ENCRYPTED parameter). This 4640 would take resources in the Responder's part to reach the point to 4641 discover that the I2 packet cannot be completely processed. The 4642 defense against this attack is after N bad I2 packets with the same 4643 puzzle solution, the Responder would discard any I2 packets that 4644 contain the given solution. This will shut down the attack. The 4645 attacker would have to request another R1 packet and use that to 4646 launch a new attack. The Responder could increase the value of #K 4647 while under attack. Keeping a list of solutions from malformed 4648 packets requires that the Responder keeps state for these malformed 4649 I2 packets. This state has to be kept until the R1 counter is 4650 increased. As malformed packets are generally filtered by their 4651 checksum before signature verification, only solutions in packets 4652 that are forged to pass the checksum and puzzle are put to the 4653 blacklist. In addition, a valid puzzle is required before a new list 4654 entry is created. Hence, attackers that intend to flood the 4655 blacklist must solve puzzles first. 4657 A third form of DoS attack is emulating the restart of state after a 4658 reboot of one of the peers. A restarting host would send an I1 4659 packet to the peers, which would respond with an R1 packet even if it 4660 were in the ESTABLISHED state. If the I1 packet were spoofed, the 4661 resulting R1 packet would be received unexpectedly by the spoofed 4662 host and would be dropped, as in the first case above. 4664 A fourth form of DoS attack is emulating closing of the HIP 4665 association. HIP relies on timers and a CLOSE/CLOSE_ACK handshake to 4666 explicitly signal the end of a HIP association. Because both CLOSE 4667 and CLOSE_ACK messages contain a HIP_MAC, an outsider cannot close a 4668 connection. The presence of an additional SIGNATURE allows 4669 middleboxes to inspect these messages and discard the associated 4670 state (for e.g., firewalling, SPI-based NATing, etc.). However, the 4671 optional behavior of replying to CLOSE with an ICMP Parameter Problem 4672 packet (as described in Section 5.4.4) might allow an attacker 4673 spoofing the source IP address to send CLOSE messages to launch 4674 reflection attacks. 4676 A fifth form of DoS attack is replaying R1s to cause the Initiator to 4677 solve stale puzzles and become out of synchronization with the 4678 Responder. The R1 generation counter is a monotonically increasing 4679 counter designed to protect against this attack, as described in 4680 Section 4.1.4. 4682 Man-in-the-middle attacks are difficult to defend against, without 4683 third-party authentication. A skillful MitM could easily handle all 4684 parts of HIP, but HIP indirectly provides the following protection 4685 from a MitM attack. If the Responder's HI is retrieved from a signed 4686 DNS zone, a certificate, or through some other secure means, the 4687 Initiator can use this to validate the R1 HIP packet. 4689 Likewise, if the Initiator's HI is in a secure DNS zone, a trusted 4690 certificate, or otherwise securely available, the Responder can 4691 retrieve the HI (after having got the I2 HIP packet) and verify that 4692 the HI indeed can be trusted. 4694 The HIP Opportunistic Mode concept has been introduced in this 4695 document, but this document does not specify what the semantics of 4696 such a connection setup are for applications. There are certain 4697 concerns with opportunistic mode, as discussed in Section 4.1.8. 4699 NOTIFY messages are used only for informational purposes and they are 4700 unacknowledged. A HIP implementation cannot rely solely on the 4701 information received in a NOTIFY message because the packet may have 4702 been replayed. An implementation SHOULD NOT change any state 4703 information purely based on a received NOTIFY message. 4705 Since not all hosts will ever support HIP, ICMP 'Destination Protocol 4706 Unreachable' messages are to be expected and may be used for a DoS 4707 attack. Against an Initiator, the attack would look like the 4708 Responder does not support HIP, but shortly after receiving the ICMP 4709 message, the Initiator would receive a valid R1 HIP packet. Thus, to 4710 protect from this attack, an Initiator SHOULD NOT react to an ICMP 4711 message until a reasonable delta time to get the real Responder's R1 4712 HIP packet. A similar attack against the Responder is more involved. 4713 Normally, if an I1 message received by a Responder was a bogus one 4714 sent by an attacker, the Responder may receive an ICMP message from 4715 the IP address the R1 message was sent to. However, a sophisticated 4716 attacker can try to take advantage of such a behavior and try to 4717 break up the HIP base exchange by sending such an ICMP message to the 4718 Responder before the Initiator has a chance to send a valid I2 4719 message. Hence, the Responder SHOULD NOT act on such an ICMP 4720 message. Especially, it SHOULD NOT remove any minimal state created 4721 when it sent the R1 HIP packet (if it did create one), but wait for 4722 either a valid I2 HIP packet or the natural timeout (that is, if R1 4723 packets are tracked at all). Likewise, the Initiator SHOULD ignore 4724 any ICMP message while waiting for an R2 HIP packet, and SHOULD 4725 delete any pending state only after a natural timeout. 4727 9. IANA Considerations 4729 IANA has reserved protocol number 139 for the Host Identity Protocol. 4731 This document defines a new 128-bit value under the CGA Message Type 4732 namespace [RFC3972], 0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA, to be 4733 used for HIT generation as specified in ORCHID 4734 [I-D.ietf-hip-rfc4843-bis]. 4736 This document uses HIP version number 2 for the four-bit Version 4737 field in a HIP protocol packet defined in [RFC5201]. 4739 This document also creates a set of new namespaces. These are 4740 described below. 4742 Packet Type 4744 The 7-bit Packet Type field in a HIP protocol packet describes the 4745 type of a HIP protocol message. It is defined in Section 5.1. 4746 The current values are defined in Sections 5.3.1 through 5.3.8. 4748 New values are assigned through IETF Review or IESG Approval 4749 [RFC5226]. 4751 HIT Suite 4753 The four-bit HIT Suite ID uses the OGA field in the ORCHID to 4754 express the type of the HIT. This document defines two HIT Suites 4755 (see Appendix E). 4757 The HIT Suite ID is also carried in the four higher-order bits of 4758 the ID field in the HIT_SUITE_LIST parameter. The four lower- 4759 order bits are reserved for future extensions of the HIT Suite ID 4760 space beyond 16 values. 4762 At the time being, the HIT Suite uses only four bits because these 4763 bits have to be carried in the HIT. Using more bits for the HIT 4764 Suite ID reduces the cryptographic strength of the HIT. HIT Suite 4765 IDs must be allocated carefully to avoid namespace exhaustion. 4766 Moreover, deprecated IDs should be reused after an appropriate 4767 time span. If 16 Suite IDs prove insufficient and more HIT Suite 4768 IDs are needed concurrently, more bits can be used for the HIT 4769 Suite ID by using one HIT Suite ID (0) to indicate that more bits 4770 should be used. The HIT_SUITE_LIST parameter already supports 4771 8-bit HIT Suite IDs, should longer IDs be needed. Possible 4772 extensions of the HIT Suite ID space to accommodate eight bits and 4773 new HIT Suite IDs are defined through IETF Review or IESG 4774 Approval. 4776 Parameter Type 4778 The 16-bit Type field in a HIP parameter describes the type of the 4779 parameter. It is defined in Section 5.2.1. The current values 4780 are defined in Sections 5.2.3 through 5.2.23. 4782 With the exception of the assigned Type codes, the Type codes 0 4783 through 1023 and 61440 through 65535 are reserved for future base 4784 protocol extensions, and are assigned through IETF Review or IESG 4785 Approval. 4787 The Type codes 32768 through 49151 are reserved for 4788 experimentation. Types SHOULD be selected in a random fashion 4789 from this range, thereby reducing the probability of collisions. 4790 A method employing genuine randomness (such as flipping a coin) 4791 SHOULD be used. 4793 All other Type codes are assigned through First Come First Served, 4794 with Specification Required [RFC5226]. 4796 Group ID 4798 The eight-bit Group ID values appear in the DIFFIE_HELLMAN 4799 parameter and the DH_GROUP_LIST parameter and are defined in 4800 Section 5.2.7. New values are assigned through IETF Review or 4801 IESG Approval. 4803 HIP Cipher ID 4805 The 16-bit Cipher ID values in a HIP_CIPHER parameter are defined 4806 in Section 5.2.8. New values either from the reserved or 4807 unassigned space are assigned through IETF Review or IESG 4808 Approval. 4810 DI-Type 4812 The four-bit DI-Type values in a HOST_ID parameter are defined in 4813 Section 5.2.9. New values are assigned through IETF Review or 4814 IESG Approval. 4816 Notify Message Type 4818 The 16-bit Notify Message Type values in a NOTIFICATION parameter 4819 are defined in Section 5.2.19. 4821 Notify Message Type values 1-10 are used for informing about 4822 errors in packet structures, values 11-20 for informing about 4823 problems in parameters containing cryptographic related material, 4824 values 21-30 for informing about problems in authentication or 4825 packet integrity verification. Parameter numbers above 30 can be 4826 used for informing about other types of errors or events. Values 4827 51-8191 are error types reserved to be allocated by IANA. Values 4828 8192-16383 are error types for experimentation. Values 16385- 4829 40959 are status types to be allocated by IANA, and values 40960- 4830 65535 are status types for experimentation. New values in ranges 4831 51-8191 and 16385-40959 are assigned through First Come First 4832 Served, with Specification Required. 4834 10. Acknowledgments 4836 The drive to create HIP came to being after attending the MALLOC 4837 meeting at the 43rd IETF meeting. Baiju Patel and Hilarie Orman 4838 really gave the original author, Bob Moskowitz, the assist to get HIP 4839 beyond 5 paragraphs of ideas. It has matured considerably since the 4840 early versions thanks to extensive input from IETFers. Most 4841 importantly, its design goals are articulated and are different from 4842 other efforts in this direction. Particular mention goes to the 4843 members of the NameSpace Research Group of the IRTF. Noel Chiappa 4844 provided valuable input at early stages of discussions about 4845 identifier handling and Keith Moore the impetus to provide 4846 resolvability. Steve Deering provided encouragement to keep working, 4847 as a solid proposal can act as a proof of ideas for a research group. 4849 Many others contributed; extensive security tips were provided by 4850 Steve Bellovin. Rob Austein kept the DNS parts on track. Paul 4851 Kocher taught Bob Moskowitz how to make the puzzle exchange expensive 4852 for the Initiator to respond, but easy for the Responder to validate. 4853 Bill Sommerfeld supplied the Birthday concept, which later evolved 4854 into the R1 generation counter, to simplify reboot management. Erik 4855 Nordmark supplied the CLOSE-mechanism for closing connections. 4856 Rodney Thayer and Hugh Daniels provided extensive feedback. In the 4857 early times of this document, John Gilmore kept Bob Moskowitz 4858 challenged to provide something of value. 4860 During the later stages of this document, when the editing baton was 4861 transferred to Pekka Nikander, the input from the early implementors 4862 was invaluable. Without having actual implementations, this document 4863 would not be on the level it is now. 4865 In the usual IETF fashion, a large number of people have contributed 4866 to the actual text or ideas. The list of these people include Jeff 4867 Ahrenholz, Francis Dupont, Derek Fawcus, George Gross, Andrew 4868 McGregor, Julien Laganier, Miika Komu, Mika Kousa, Jan Melen, Henrik 4869 Petander, Michael Richardson, Rene Hummen, Tim Shepard, Jorma Wall, 4870 and Jukka Ylitalo. Our apologies to anyone whose name is missing. 4872 Once the HIP Working Group was founded in early 2004, a number of 4873 changes were introduced through the working group process. Most 4874 notably, the original document was split in two, one containing the 4875 base exchange and the other one defining how to use ESP. Some 4876 modifications to the protocol proposed by Aura, et al., [AUR03] were 4877 added at a later stage. 4879 11. Changes from RFC 5201 4881 This section summarizes the changes made from [RFC5201]. 4883 11.1. Changes from draft-ietf-hip-rfc5201-bis-07 4885 o Removed lingering references to SHA-1 as the mandatory hash 4886 algorithm (which was changed to SHA-256 in the -02 draft version). 4888 o For parameter type number changes, changed "IETF Review" to "IETF 4889 Review or IESG Approval". 4891 o Updated Appendix C checksum examples to conform to HIPv2 packets. 4893 11.2. Changes from draft-ietf-hip-rfc5201-bis-06 4895 o Made echoing the R1_COUNTER in the I2 mandatory if the R1 contains 4896 an R1_COUNTER. This required to make the R1 counter a critical 4897 parameter. Hence, the parameter type number of the R1_COUNTER 4898 changed from 128 to 129. 4900 o Made KDF dependent on DH Group to enable negotiation of the KDF. 4902 11.3. Changes from draft-ietf-hip-rfc5201-bis-05 4904 o Changed type number of DH_GROUP_LIST from 2151 to 511 because it 4905 was in the number space that is reserved for the HIP transport 4906 mode negotiations. 4908 o Added transport form type list parameter. Transport forms are now 4909 negotiated with this list instead of by their order in the HIP 4910 packet. This allows to remove the exception of the transport 4911 format parameters that were ordered by their preference instead of 4912 by their type number. This should remove complexity from 4913 implementations. 4915 o Clarify that in HIP signature processing, the restored checksum 4916 and length fields have been rendered invalid by the previous 4917 steps. 4919 o Clarify behavior for when UPDATE does not contain SEQ or ACQ 4920 (disallow this). 4922 o For namespace changes, changed "IETF Review" to "IETF Review or 4923 IESG Approval". 4925 o Addressed IESG comment about ignoring packet IP addresses. 4927 o Permit using Anonymous HI control in packets other than R1/I2. 4929 o Fixed minor reference error (RFC2418, RFC2410). 4931 o Deleted comment that NULL-ENCRYPTION SHOULD NOT be configurable 4932 via the UI. 4934 o Editorial changes. 4936 11.4. Changes from draft-ietf-hip-rfc5201-bis-04 4938 o Clarifications of the Security Considerations section. One DoS 4939 defense mechanism was changed to be more effective and less prone 4940 to misuse. 4942 o Minor clarifications of the state machine. 4944 o Clarified text on HIP puzzle. 4946 o Added names and references for figures. 4948 o Extended the definitions section. 4950 o Added a reference to the HIP Version 1 certificate document. 4952 o Added Initiator, Responder, HIP association, and signed data to 4953 the definitions section. 4955 o Changed parameter figure for PUZZLE and SOLUTION to use 4956 RHASH_len/8 instead of n-byte. 4958 o Replaced occurrences of SHOULD not with SHOULD NOT. 4960 o Changed text to reflect the fact that several 4961 ECHO_REQUEST_UNSIGNED parameters may be present in an R1 and 4962 several ECHO_RESPONSE parameters may be present in an I2. 4964 o Added text on verifying the ECHO_RESPONSE_SIGNED parameter in 4965 CLOSE_ACK. 4967 o Changed wording from HMAC to HIP_MAC in Section 5.3.8. 4969 o Reflected fact that the UPDATE packet MAY include zero or more 4970 ACKs. 4972 o Added BEX to Definitions section. 4974 o Changed HIP_SIGNATURE algorithm field from 8 bit to 16 bit to 4975 achieve alignment with the HOST_ID parameters. 4977 o Fixed the wrong figures of the SEQ and ACK parameters. SEQ always 4978 contains ONE update ID. ACK may acknowledge SEVERAL update IDs. 4980 o Added wording that several NOTIFY parameters may be present in a 4981 HIP packet. 4983 o Changed wording for the ECHO_RESPONSE_SIGNED parameter. Also 4984 lifted the restriction that only one ECHO_RESPONSE_UNSIGNED 4985 parameter MUST be present in each HIP control packet. This did 4986 contradict the definition of the ECHO_RESPONSE_UNSIGNED parameter. 4988 o Changed IETF Consensus to IETF Review or IESG Approval in IANA 4989 section. 4991 o Aligned use of I, J, and K. Now I is #I, J is #J and K is #K 4992 throughout the document. 4994 o Updated references. 4996 o Editorial changes. 4998 11.5. Changes from draft-ietf-hip-rfc5201-bis-03 5000 o Editorial changes to improve clarity and readability. 5002 o Removed obsoleted (not applicable) attack from security 5003 consideration section. 5005 o Added a requirement that hosts MUST support processing of ACK 5006 parameters with several SEQ numbers even when they do not support 5007 sending such parameters. 5009 o Removed note on memory bound puzzles. The use of memory bound 5010 puzzles was reconsidered but no convincing arguments for inclusion 5011 in this document have been made on the list. 5013 o Changed references to reference the new bis documents. 5015 o Specified the ECC curves and the hashes used for these. 5017 o Specified representation of ECC curves in the HI. 5019 o Added text on the dependency between RHASH and HMAC. 5021 o Rephrased part of the security considerations to make them 5022 clearer. 5024 o Clarified the use of HITs in opportunistic mode. 5026 o Clarified the difference between HIP_MAC and HIP_MAC_2 as well as 5027 between SIGNATURE and SIGNATURE_2. 5029 o Changed NOTIFY name for value 44 from SERVER_BUSY_PLEASE_RETRY to 5030 RESPONDER_BUSY_PLEASE_RETRY. 5032 o Mentioned that there are multiple valid puzzle solutions. 5034 11.6. Changes from draft-ietf-hip-rfc5201-bis-02 5036 o Added recommendation to not use puzzle #I twice for the same host 5037 to avoid identical key material. 5039 o Revised state machine and added missing event handling. 5041 o Added UNSUPPORTED_HIT_SUITE to NOTIFY to indicate unsupported HIT 5042 suites. 5044 o Revised parameter type numbers (corresponding to IANA allocations) 5045 and added missing "free for experimentation" range to the 5046 description. 5048 o Clarifying note on the use of the C bit in the parameter type 5049 numbers. 5051 11.7. Changes from draft-ietf-hip-rfc5201-bis-01 5053 o Changed RHASH-len to RHASH_len to avoid confusion in calculations 5054 (- could be minus) 5056 o Added RHASH_len to list of abbreviations 5058 o Fixed length of puzzle #I and #J to be 1*RHASH_len 5059 o Changed RHASH-len to RHASH_len to avoid confusion in calculations 5060 (- could be minus) 5062 o Added RHASH_len to list of abbreviations 5064 o Fixed length of puzzle #I and #J to be 1*RHASH_len 5066 o Included HIT_SUITEs. 5068 o Added DH negotiation to I1 and R1. 5070 o Added DH_LIST parameter. 5072 o Added text for DH Group negotiation. 5074 o Removed second DH public value from DH parameter. 5076 o Added ECC to HI generation. 5078 o Added Responder HIT selection to opportunistic mode. 5080 o Added ECDSA HI text and references (not complete yet). 5082 o Added separate section on aborting BEX. 5084 o Added separate section on downgrade attack prevention. 5086 o Added text about DH Group selection for use cases without I1. 5088 o Removed type range allocation for parameters related to HIP 5089 transform types. 5091 o New type range allocation for parameters that are only covered by 5092 a signature if a signature is present (Applies to DH_GROUP_LIST). 5094 o Renamed HIP_TRANSFORM to HIP_CIPHER and removed hashes from it - 5095 hashes are determined by RHASH. 5097 o The length of #I and #J for the puzzle now depends on RHASH. 5099 o New keymat generation. 5101 o Puzzle seed and solution now use RHASH and have variable length. 5103 o Moved timing definitions closer to state machine. 5105 o Simplified text regarding puzzle lifetime. 5107 o Clarified the description of the use of #I in the puzzle 5109 o Removed "Opportunistic mode" description from general definitions. 5111 o More consistency across the old RFC5201 text. Aligned 5112 capitalization and abbreviations. 5114 o Extended protocol overview to include restart option. 5116 o Extended state machine to include restart option because of 5117 unsupported Algorithms. 5119 o Replaced SHA-1 with SHA-256 for required implementation. 5121 o Added OGA list parameter (715) for detecting the Responder's set 5122 of OGAs. 5124 o Added Appendix on ORCHID use in HITs. 5126 o Added truncated SHA-256 option for HITs. 5128 o Added truncated SHA-1 option for HITs. 5130 o Added text about new ORCHID structure to HIT overview. 5132 o Moved Editor role to Robert Moskowitz. 5134 o Added SHA-256 to puzzle parameter. 5136 o Generalized LTRUNC to be hash-function agnostic. 5138 o Added text about RHASH depending on OGA. 5140 11.8. Changes from draft-ietf-hip-rfc5201-bis-00 5142 o Added reasoning why BIS document is needed. 5144 11.9. Contents of draft-ietf-hip-rfc5201-bis-00 5146 o RFC5201 was submitted as draft-RFC. 5148 12. References 5150 12.1. Normative References 5152 [FIPS.180-2.2002] National Institute of Standards and 5153 Technology, "Secure Hash Standard", 5154 FIPS PUB 180-2, August 2002, . 5158 [I-D.ietf-hip-rfc4843-bis] Laganier, J. and F. Dupont, "An IPv6 5159 Prefix for Overlay Routable Cryptographic 5160 Hash Identifiers (ORCHID)", 5161 draft-ietf-hip-rfc4843-bis-00 (work in 5162 progress), August 2010. 5164 [I-D.ietf-hip-rfc5202-bis] Jokela, P., Moskowitz, R., Nikander, P., 5165 and J. Melen, "Using the Encapsulating 5166 Security Payload (ESP) Transport Format 5167 with the Host Identity Protocol (HIP)", 5168 draft-ietf-hip-rfc5202-bis-00 (work in 5169 progress), September 2010. 5171 [RFC0768] Postel, J., "User Datagram Protocol", 5172 STD 6, RFC 768, August 1980. 5174 [RFC1035] Mockapetris, P., "Domain names - 5175 implementation and specification", 5176 STD 13, RFC 1035, November 1987. 5178 [RFC2119] Bradner, S., "Key words for use in RFCs 5179 to Indicate Requirement Levels", BCP 14, 5180 RFC 2119, March 1997. 5182 [RFC2404] Madson, C. and R. Glenn, "The Use of 5183 HMAC-SHA-1-96 within ESP and AH", 5184 RFC 2404, November 1998. 5186 [RFC2410] Glenn, R. and S. Kent, "The NULL 5187 Encryption Algorithm and Its Use With 5188 IPsec", RFC 2410, November 1998. 5190 [RFC2451] Pereira, R. and R. Adams, "The ESP CBC- 5191 Mode Cipher Algorithms", RFC 2451, 5192 November 1998. 5194 [RFC2460] Deering, S. and R. Hinden, "Internet 5195 Protocol, Version 6 (IPv6) 5196 Specification", RFC 2460, December 1998. 5198 [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the 5199 Domain Name System (DNS)", RFC 2536, 5200 March 1999. 5202 [RFC2898] Kaliski, B., "PKCS #5: Password-Based 5203 Cryptography Specification Version 2.0", 5204 RFC 2898, September 2000. 5206 [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA 5207 KEYs in the Domain Name System (DNS)", 5208 RFC 3110, May 2001. 5210 [RFC3484] Draves, R., "Default Address Selection 5211 for Internet Protocol version 6 (IPv6)", 5212 RFC 3484, February 2003. 5214 [RFC3526] Kivinen, T. and M. Kojo, "More Modular 5215 Exponential (MODP) Diffie-Hellman groups 5216 for Internet Key Exchange (IKE)", 5217 RFC 3526, May 2003. 5219 [RFC3602] Frankel, S., Glenn, R., and S. Kelly, 5220 "The AES-CBC Cipher Algorithm and Its Use 5221 with IPsec", RFC 3602, September 2003. 5223 [RFC3972] Aura, T., "Cryptographically Generated 5224 Addresses (CGA)", RFC 3972, March 2005. 5226 [RFC4034] Arends, R., Austein, R., Larson, M., 5227 Massey, D., and S. Rose, "Resource 5228 Records for the DNS Security Extensions", 5229 RFC 4034, March 2005. 5231 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. 5232 Eronen, "The Network Access Identifier", 5233 RFC 4282, December 2005. 5235 [RFC4443] Conta, A., Deering, S., and M. Gupta, 5236 "Internet Control Message Protocol 5237 (ICMPv6) for the Internet Protocol 5238 Version 6 (IPv6) Specification", 5239 RFC 4443, March 2006. 5241 [RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 5242 Authentication Using the Elliptic Curve 5243 Digital Signature Algorithm (ECDSA)", 5244 RFC 4754, January 2007. 5246 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC- 5247 SHA-256, HMAC-SHA-384, and HMAC-SHA-512 5248 with IPsec", RFC 4868, May 2007. 5250 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., 5251 and T. Henderson, "Host Identity 5252 Protocol", RFC 5201, April 2008. 5254 [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with 5255 RSA in DNSKEY and RRSIG Resource Records 5256 for DNSSEC", RFC 5702, October 2009. 5258 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based 5259 Extract-and-Expand Key Derivation 5260 Function (HKDF)", RFC 5869, May 2010. 5262 [RFC5903] Fu, D. and J. Solinas, "Elliptic Curve 5263 Groups modulo a Prime (ECP Groups) for 5264 IKE and IKEv2", RFC 5903, June 2010. 5266 [RFC6090] McGrew, D., Igoe, K., and M. Salter, 5267 "Fundamental Elliptic Curve Cryptography 5268 Algorithms", RFC 6090, February 2011. 5270 12.2. Informative References 5272 [AUR03] Aura, T., Nagarajan, A., and A. Gurtov, 5273 "Analysis of the HIP Base Exchange 5274 Protocol", in Proceedings of 10th 5275 Australasian Conference on Information 5276 Security and Privacy, July 2003. 5278 [CRO03] Crosby, SA. and DS. Wallach, "Denial of 5279 Service via Algorithmic Complexity 5280 Attacks", in Proceedings of Usenix 5281 Security Symposium 2003, Washington, 5282 DC., August 2003. 5284 [DIF76] Diffie, W. and M. Hellman, "New 5285 Directions in Cryptography", IEEE 5286 Transactions on Information Theory vol. 5287 IT-22, number 6, pages 644-654, Nov 1976. 5289 [FIPS.197.2001] National Institute of Standards and 5290 Technology, "Advanced Encryption Standard 5291 (AES)", FIPS PUB 197, November 2001, . 5295 [I-D.ietf-btns-c-api] Richardson, M., Williams, N., Komu, M., 5296 and S. Tarkoma, "C-Bindings for IPsec 5297 Application Programming Interfaces", 5298 draft-ietf-btns-c-api-04 (work in 5299 progress), March 2009. 5301 [I-D.ietf-hip-cert] Heer, T. and S. Varjonen, "Host Identity 5302 Protocol Certificates", 5303 draft-ietf-hip-cert-09 (work in 5304 progress), January 2011. 5306 [I-D.ietf-hip-rfc4423-bis] Moskowitz, R., "Host Identity Protocol 5307 Architecture", 5308 draft-ietf-hip-rfc4423-bis-02 (work in 5309 progress), February 2011. 5311 [I-D.ietf-hip-rfc5204-bis] Laganier, J. and L. Eggert, "Host 5312 Identity Protocol (HIP) Rendezvous 5313 Extension", draft-ietf-hip-rfc5204-bis-00 5314 (work in progress), August 2010. 5316 [I-D.ietf-hip-rfc5205-bis] Laganier, J., "Host Identity Protocol 5317 (HIP) Domain Name System (DNS) 5318 Extension", draft-ietf-hip-rfc5205-bis-00 5319 (work in progress), August 2010. 5321 [I-D.ietf-hip-rfc5206-bis] Nikander, P., Henderson, T., Vogt, C., 5322 and J. Arkko, "Host Mobility with the 5323 Host Identity Protocol", 5324 draft-ietf-hip-rfc5206-bis-01 (work in 5325 progress), October 2010. 5327 [KAU03] Kaufman, C., Perlman, R., and B. 5328 Sommerfeld, "DoS protection for UDP-based 5329 protocols", ACM Conference on Computer 5330 and Communications Security , Oct 2003. 5332 [KRA03] Krawczyk, H., "SIGMA: The 'SIGn-and-MAc' 5333 Approach to Authenticated Diffie-Hellman 5334 and Its Use in the IKE-Protocols", in 5335 Proceedings of CRYPTO 2003, pages 400- 5336 425, August 2003. 5338 [RFC0792] Postel, J., "Internet Control Message 5339 Protocol", STD 5, RFC 792, 5340 September 1981. 5342 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 5343 Address Prefix Reserved for 5344 Documentation", RFC 3849, July 2004. 5346 [RFC4306] Kaufman, C., "Internet Key Exchange 5347 (IKEv2) Protocol", RFC 4306, 5348 December 2005. 5350 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines 5351 for Writing an IANA Considerations 5352 Section in RFCs", BCP 26, RFC 5226, 5353 May 2008. 5355 [RFC5338] Henderson, T., Nikander, P., and M. Komu, 5356 "Using the Host Identity Protocol with 5357 Legacy Applications", RFC 5338, 5358 September 2008. 5360 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: 5361 Level 3 Multihoming Shim Protocol for 5362 IPv6", RFC 5533, June 2009. 5364 [RFC5747] Wu, J., Cui, Y., Li, X., Xu, M., and C. 5365 Metz, "4over6 Transit Solution Using IP 5366 Encapsulation and MP-BGP Extensions", 5367 RFC 5747, March 2010. 5369 [SECG] SECG, "Recommended Elliptic Curve Domain 5370 Parameters", SEC 2 , 2000, 5371 . 5373 Appendix A. Using Responder Puzzles 5375 As mentioned in Section 4.1.1, the Responder may delay state creation 5376 and still reject most spoofed I2 packets by using a number of pre- 5377 calculated R1 packets and a local selection function. This appendix 5378 defines one possible implementation in detail. The purpose of this 5379 appendix is to give the implementors an idea on how to implement the 5380 mechanism. If the implementation is based on this appendix, it MAY 5381 contain some local modification that makes an attacker's task harder. 5383 The Responder creates a secret value S, that it regenerates 5384 periodically. The Responder needs to remember the two latest values 5385 of S. Each time the S is regenerated, the R1 generation counter 5386 value is incremented by one. 5388 The Responder generates a pre-signed R1 packet. The signature for 5389 pre-generated R1s must be recalculated when the Diffie-Hellman key is 5390 recomputed or when the R1_COUNTER value changes due to S value 5391 regeneration. 5393 When the Initiator sends the I1 packet for initializing a connection, 5394 the Responder receives the HIT and IP address from the packet, and 5395 generates an #I value for the puzzle. The #I value is set to the 5396 pre-signed R1 packet. 5398 #I value calculation: 5399 #I = Ltrunc( RHASH ( S | HIT-I | HIT-R | IP-I | IP-R ), n) 5400 where n = RHASH_len 5402 The RHASH algorithm is the same that is used to generate the 5403 Responder's HIT value. 5405 From an incoming I2 packet, the Responder receives the required 5406 information to validate the puzzle: HITs, IP addresses, and the 5407 information of the used S value from the R1_COUNTER. Using these 5408 values, the Responder can regenerate the #I, and verify it against 5409 the #I received in the I2 packet. If the #I values match, it can 5410 verify the solution using #I, #J, and difficulty #K. If the #I values 5411 do not match, the I2 is dropped. 5413 puzzle_check: 5414 V := Ltrunc( RHASH( I2.I | I2.hit_i | I2.hit_r | I2.J ), #K ) 5415 if V != 0, drop the packet 5417 If the puzzle solution is correct, the #I and #J values are stored 5418 for later use. They are used as input material when keying material 5419 is generated. 5421 Keeping state about failed puzzle solutions depends on the 5422 implementation. Although it is possible for the Responder not to 5423 keep any state information, it still may do so to protect itself 5424 against certain attacks (see Section 4.1.1). 5426 Appendix B. Generating a Public Key Encoding from an HI 5428 The following pseudo-code illustrates the process to generate a 5429 public key encoding from an HI for both RSA and DSA. 5431 The symbol := denotes assignment; the symbol += denotes appending. 5432 The pseudo-function encode_in_network_byte_order takes two 5433 parameters, an integer (bignum) and a length in bytes, and returns 5434 the integer encoded into a byte string of the given length. 5436 switch ( HI.algorithm ) 5437 { 5439 case RSA: 5440 buffer := encode_in_network_byte_order ( HI.RSA.e_len, 5441 ( HI.RSA.e_len > 255 ) ? 3 : 1 ) 5442 buffer += encode_in_network_byte_order ( HI.RSA.e, HI.RSA.e_len ) 5443 buffer += encode_in_network_byte_order ( HI.RSA.n, HI.RSA.n_len ) 5444 break; 5446 case DSA: 5447 buffer := encode_in_network_byte_order ( HI.DSA.T , 1 ) 5448 buffer += encode_in_network_byte_order ( HI.DSA.Q , 20 ) 5449 buffer += encode_in_network_byte_order ( HI.DSA.P , 64 + 5450 8 * HI.DSA.T ) 5451 buffer += encode_in_network_byte_order ( HI.DSA.G , 64 + 5452 8 * HI.DSA.T ) 5453 buffer += encode_in_network_byte_order ( HI.DSA.Y , 64 + 5454 8 * HI.DSA.T ) 5455 break; 5457 } 5459 Appendix C. Example Checksums for HIP Packets 5461 The HIP checksum for HIP packets is specified in Section 5.1.1. 5462 Checksums for TCP and UDP packets running over HIP-enabled security 5463 associations are specified in Section 3.5. The examples below use 5464 [RFC3849] and [RFC5747] addresses, and HITs with the prefix of 5465 2001:10 followed by zeros, followed by a decimal 1 or 2, 5466 respectively. 5468 The following example is defined only for testing the checksum 5469 calculation. 5471 C.1. IPv6 HIP Example (I1 packet) 5473 Source Address: 2001:d88::1 5474 Destination Address: 2001:d88::2 5475 Upper-Layer Packet Length: 48 0x30 5476 Next Header: 139 0x8b 5477 Payload Protocol: 59 0x3b 5478 Header Length: 4 0x4 5479 Packet Type: 1 0x1 5480 Version: 2 0x2 5481 Reserved: 1 0x1 5482 Control: 0 0x0 5483 Checksum: 6878 0x1ade 5484 Sender's HIT : 2001:10::1 5485 Receiver's HIT: 2001:10::2 5486 DH_GROUP_LIST type: 511 0x1ff 5487 DH_GROUP_LIST length: 3 0x3 5488 DH_GROUP_LIST group IDs: 3,4,8 5490 C.2. IPv4 HIP Packet (I1 packet) 5492 The IPv4 checksum value for the example I1 packet is shown below. 5494 Source Address: 192.0.2.1 5495 Destination Address: 192.0.2.2 5496 Upper-Layer Packet Length: 48 0x30 5497 Next Header: 139 0x8b 5498 Payload Protocol: 59 0x3b 5499 Header Length: 4 0x4 5500 Packet Type: 1 0x1 5501 Version: 2 0x2 5502 Reserved: 1 0x1 5503 Control: 0 0x0 5504 Checksum: 61934 0xf1ee 5505 Sender's HIT : 2001:10::1 5506 Receiver's HIT: 2001:10::2 5507 DH_GROUP_LIST type: 511 0x1ff 5508 DH_GROUP_LIST length: 3 0x3 5509 DH_GROUP_LIST group IDs: 3,4,8 5511 C.3. TCP Segment 5513 Regardless of whether IPv6 or IPv4 is used, the TCP and UDP sockets 5514 use the IPv6 pseudo-header format [RFC2460], with the HITs used in 5515 place of the IPv6 addresses. 5517 Sender's HIT: 2001:10::1 5518 Receiver's HIT: 2001:10::2 5519 Upper-Layer Packet Length: 20 0x14 5520 Next Header: 6 0x06 5521 Source port: 65500 0xffdc 5522 Destination port: 22 0x0016 5523 Sequence number: 1 0x00000001 5524 Acknowledgment number: 0 0x00000000 5525 Header length: 20 0x14 5526 Flags: SYN 0x02 5527 Window size: 65535 0xffff 5528 Checksum: 28618 0x6fca 5529 Urgent pointer: 0 0x0000 5531 0x0000: 6000 0000 0014 0640 2001 0010 0000 0000 5532 0x0010: 0000 0000 0000 0001 2001 0010 0000 0000 5533 0x0020: 0000 0000 0000 0002 ffdc 0016 0000 0001 5534 0x0030: 0000 0000 5002 ffff 6fca 0000 5536 Appendix D. ECDH and ECDSA 160 Bit Groups 5538 The ECDH and ECDSA 160-bit group SECP160R1 is rated at 80 bits 5539 symmetric strength. Once this was considered appropriate for one 5540 year of security. Today these groups should be used only when the 5541 host is not powerful enough (e.g., some embedded devices) and when 5542 security requirements are low (e.g., long-term confidentiality is not 5543 required). 5545 Appendix E. HIT Suites and HIT Generation 5547 The HIT as an ORCHID [I-D.ietf-hip-rfc4843-bis] consists of three 5548 parts: A 28-bit prefix, a 4-bit encoding of the ORCHID generation 5549 algorithm (OGA) and the representation of the public key. The OGA is 5550 an index pointing to the specific algorithm by which the public key 5551 and the 96-bit hashed encoding is generated. The OGA is protocol 5552 specific and is to be interpreted as defined below for all protocols 5553 that use the same context ID as HIP. HIP groups sets of valid 5554 combinations of signature and hash algorithms into HIT Suites. These 5555 HIT suites are addressed by an index, which is transmitted in the OGA 5556 field of the ORCHID. 5558 The set of used HIT Suites will be extended to counter the progress 5559 in computation capabilities and vulnerabilities in the employed 5560 algorithms. The intended use of the HIT Suites is to introduce a new 5561 HIT Suite and phase out an old one before it becomes insecure. Since 5562 the 4-bit OGA field only permits 15 HIT Suites (the HIT Suite with ID 5563 0 is reserved) to be used in parallel, phased-out HIT Suites must be 5564 reused at some point. In such a case, there will be a rollover of 5565 the HIT Suite ID and the next newly introduced HIT Suite will start 5566 with a lower HIT Suite index than the previously introduced one. The 5567 rollover effectively deprecates the reused HIT Suite. For a smooth 5568 transition, the HIT Suite should be deprecated a considerable time 5569 before the HIT Suite index is reused. 5571 Since the number of HIT Suites is tightly limited to 16, the HIT 5572 Suites must be assigned carefully. Hence, sets of suitable 5573 algorithms are grouped in a HIT Suite. 5575 The HIT Suite of the Responder's HIT determines the RHASH and the 5576 hash function to be used for the HMAC in HIP control packets as well 5577 as the signature algorithm family used for generating the HI. The 5578 list of HIT Suites is defined in Table 11. 5580 The following HIT Suites are defined for HIT generation. The input 5581 for each generation algorithm is the encoding of the HI as defined in 5582 Section 3.2. The output is 96 bits long and is directly used in the 5583 ORCHID. 5585 +-------+----------+--------------+------------+--------------------+ 5586 | Index | Hash | HMAC | Signature | Description | 5587 | | function | | algorithm | | 5588 | | | | family | | 5589 +-------+----------+--------------+------------+--------------------+ 5590 | 0 | | | | Reserved | 5591 | 1 | SHA-256 | HMAC-SHA-256 | RSA, DSA | RSA or DSA HI | 5592 | | | | | hashed with | 5593 | | | | | SHA-256, truncated | 5594 | | | | | to 96 bits | 5595 | 2 | SHA-384 | HMAC-SHA-384 | ECDSA | ECDSA HI hashed | 5596 | | | | | with SHA-384, | 5597 | | | | | truncated to 96 | 5598 | | | | | bits | 5599 | 3 | SHA-1 | HMAC-SHA-1 | ECDSA_LOW | ECDSA_LOW HI | 5600 | | | | | hashed with SHA-1, | 5601 | | | | | truncated to 96 | 5602 | | | | | bits | 5603 +-------+----------+--------------+------------+--------------------+ 5605 Table 11: HIT Suites 5607 The hash of the responder as defined in the HIT Suite determines the 5608 HMAC to be used for the HMAC parameter. The HMACs currently defined 5609 here are HMAC-SHA-256 [RFC4868], HMAC-SHA-384 [RFC4868], and HMAC- 5610 SHA-1 [RFC2404]. 5612 Authors' Addresses 5614 Robert Moskowitz (editor) 5615 Verizon Telcom and Business 5616 1000 Bent Creek Blvd, Suite 200 5617 Mechanicsburg, PA 5618 USA 5620 EMail: robert.moskowitz@verizonbusiness.com 5622 Tobias Heer 5623 RWTH Aachen University, Communication and Distributed Systems Group 5624 Ahornstrasse 55 5625 Aachen 52062 5626 Germany 5628 EMail: heer@cs.rwth-aachen.de 5629 URI: http://www.comsys.rwth-aachen.de/team/tobias-heer/ 5631 Petri Jokela 5632 Ericsson Research NomadicLab 5633 JORVAS FIN-02420 5634 FINLAND 5636 Phone: +358 9 299 1 5637 EMail: petri.jokela@nomadiclab.com 5639 Thomas R. Henderson 5640 The Boeing Company 5641 P.O. Box 3707 5642 Seattle, WA 5643 USA 5645 EMail: thomas.r.henderson@boeing.com