idnits 2.17.1 draft-ietf-hip-rfc5201-bis-19.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 are 3 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 2193 has weird spacing: '...c Value leng...' == Line 2195 has weird spacing: '...c Value the ...' == Line 2726 has weird spacing: '...ication info...' == Line 2864 has weird spacing: '...ue data opaqu...' == Line 2894 has weird spacing: '...ue data opaqu...' == (2 more instances...) -- The document date (September 22, 2014) is 3476 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 (-07) exists of draft-ietf-hip-rfc5202-bis-05 ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542) == Outdated reference: A later version (-20) exists of draft-ietf-hip-rfc4423-bis-05 == Outdated reference: A later version (-08) exists of draft-ietf-hip-rfc5204-bis-02 == Outdated reference: A later version (-10) exists of draft-ietf-hip-rfc5205-bis-02 == Outdated reference: A later version (-14) exists of draft-ietf-hip-rfc5206-bis-06 -- Obsolete informational reference (is this intentional?): RFC 2898 (Obsoleted by RFC 8018) -- Obsolete informational reference (is this intentional?): RFC 3447 (Obsoleted by RFC 8017) -- Obsolete informational reference (is this intentional?): RFC 5201 (Obsoleted by RFC 7401) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) -- Obsolete informational reference (is this intentional?): RFC 6253 (Obsoleted by RFC 8002) Summary: 3 errors (**), 0 flaws (~~), 13 warnings (==), 8 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 Hirschmann Automation and Control 6 Expires: March 26, 2015 P. Jokela 7 Ericsson Research NomadicLab 8 T. Henderson 9 University of Washington 10 September 22, 2014 12 Host Identity Protocol Version 2 (HIPv2) 13 draft-ietf-hip-rfc5201-bis-19 15 Abstract 17 This document specifies the details of the Host Identity Protocol 18 (HIP). HIP allows consenting hosts to securely establish and 19 maintain shared IP-layer state, allowing separation of the identifier 20 and locator roles of IP addresses, thereby enabling continuity of 21 communications across IP address changes. HIP is based on a Diffie- 22 Hellman key exchange, using public key identifiers from a new Host 23 Identity namespace for mutual peer authentication. The protocol is 24 designed to be resistant to denial-of-service (DoS) and man-in-the- 25 middle (MitM) attacks. When used together with another suitable 26 security protocol, such as the Encapsulated Security Payload (ESP), 27 it provides integrity protection and optional encryption for upper- 28 layer protocols, such as TCP and UDP. 30 This document obsoletes RFC 5201 and addresses the concerns raised by 31 the IESG, particularly that of crypto agility. It also incorporates 32 lessons learned from the implementations of RFC 5201. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on March 26, 2015. 50 Copyright Notice 52 Copyright (c) 2014 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 68 1.1. A New Namespace and Identifiers . . . . . . . . . . . . . 6 69 1.2. The HIP Base Exchange (BEX) . . . . . . . . . . . . . . . 7 70 1.3. Memo Structure . . . . . . . . . . . . . . . . . . . . . 7 71 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 8 72 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 8 73 2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 8 74 2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 8 75 3. Host Identity (HI) and its Structure . . . . . . . . . . . . 9 76 3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 10 77 3.2. Generating a HIT from an HI . . . . . . . . . . . . . . . 11 78 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 12 79 4.1. Creating a HIP Association . . . . . . . . . . . . . . . 12 80 4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . 14 81 4.1.2. Puzzle Exchange . . . . . . . . . . . . . . . . . . . 15 82 4.1.3. Authenticated Diffie-Hellman Protocol with DH Group 83 Negotiation . . . . . . . . . . . . . . . . . . . . . 16 84 4.1.4. HIP Replay Protection . . . . . . . . . . . . . . . . 18 85 4.1.5. Refusing a HIP base exchange . . . . . . . . . . . . 19 86 4.1.6. Aborting a HIP base exchange . . . . . . . . . . . . 19 87 4.1.7. HIP Downgrade Protection . . . . . . . . . . . . . . 20 88 4.1.8. HIP Opportunistic Mode . . . . . . . . . . . . . . . 21 89 4.2. Updating a HIP Association . . . . . . . . . . . . . . . 23 90 4.3. Error Processing . . . . . . . . . . . . . . . . . . . . 24 91 4.4. HIP State Machine . . . . . . . . . . . . . . . . . . . . 25 92 4.4.1. State Machine Terminology . . . . . . . . . . . . . . 26 93 4.4.2. HIP States . . . . . . . . . . . . . . . . . . . . . 26 94 4.4.3. HIP State Processes . . . . . . . . . . . . . . . . . 27 95 4.4.4. Simplified HIP State Diagram . . . . . . . . . . . . 35 97 4.5. User Data Considerations . . . . . . . . . . . . . . . . 37 98 4.5.1. TCP and UDP Pseudo-Header Computation for User Data . 37 99 4.5.2. Sending Data on HIP Packets . . . . . . . . . . . . . 37 100 4.5.3. Transport Formats . . . . . . . . . . . . . . . . . . 37 101 4.5.4. Reboot, Timeout, and Restart of HIP . . . . . . . . . 37 102 4.6. Certificate Distribution . . . . . . . . . . . . . . . . 38 103 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 38 104 5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 38 105 5.1.1. Checksum . . . . . . . . . . . . . . . . . . . . . . 40 106 5.1.2. HIP Controls . . . . . . . . . . . . . . . . . . . . 40 107 5.1.3. HIP Fragmentation Support . . . . . . . . . . . . . . 40 108 5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 41 109 5.2.1. TLV Format . . . . . . . . . . . . . . . . . . . . . 44 110 5.2.2. Defining New Parameters . . . . . . . . . . . . . . . 46 111 5.2.3. R1_COUNTER . . . . . . . . . . . . . . . . . . . . . 46 112 5.2.4. PUZZLE . . . . . . . . . . . . . . . . . . . . . . . 47 113 5.2.5. SOLUTION . . . . . . . . . . . . . . . . . . . . . . 48 114 5.2.6. DH_GROUP_LIST . . . . . . . . . . . . . . . . . . . . 49 115 5.2.7. DIFFIE_HELLMAN . . . . . . . . . . . . . . . . . . . 51 116 5.2.8. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . 52 117 5.2.9. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 53 118 5.2.10. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 55 119 5.2.11. TRANSPORT_FORMAT_LIST . . . . . . . . . . . . . . . . 56 120 5.2.12. HIP_MAC . . . . . . . . . . . . . . . . . . . . . . . 57 121 5.2.13. HIP_MAC_2 . . . . . . . . . . . . . . . . . . . . . . 58 122 5.2.14. HIP_SIGNATURE . . . . . . . . . . . . . . . . . . . . 59 123 5.2.15. HIP_SIGNATURE_2 . . . . . . . . . . . . . . . . . . . 60 124 5.2.16. SEQ . . . . . . . . . . . . . . . . . . . . . . . . . 60 125 5.2.17. ACK . . . . . . . . . . . . . . . . . . . . . . . . . 61 126 5.2.18. ENCRYPTED . . . . . . . . . . . . . . . . . . . . . . 61 127 5.2.19. NOTIFICATION . . . . . . . . . . . . . . . . . . . . 63 128 5.2.20. ECHO_REQUEST_SIGNED . . . . . . . . . . . . . . . . . 66 129 5.2.21. ECHO_REQUEST_UNSIGNED . . . . . . . . . . . . . . . . 67 130 5.2.22. ECHO_RESPONSE_SIGNED . . . . . . . . . . . . . . . . 67 131 5.2.23. ECHO_RESPONSE_UNSIGNED . . . . . . . . . . . . . . . 68 132 5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 69 133 5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 70 134 5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 70 135 5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 73 136 5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 75 137 5.3.5. UPDATE - the HIP Update Packet . . . . . . . . . . . 75 138 5.3.6. NOTIFY - the HIP Notify Packet . . . . . . . . . . . 76 139 5.3.7. CLOSE - the HIP Association Closing Packet . . . . . 77 140 5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet . . 77 141 5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 78 142 5.4.1. Invalid Version . . . . . . . . . . . . . . . . . . . 78 143 5.4.2. Other Problems with the HIP Header and Packet 144 Structure . . . . . . . . . . . . . . . . . . . . . . 78 146 5.4.3. Invalid Puzzle Solution . . . . . . . . . . . . . . . 78 147 5.4.4. Non-Existing HIP Association . . . . . . . . . . . . 79 148 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 79 149 6.1. Processing Outgoing Application Data . . . . . . . . . . 79 150 6.2. Processing Incoming Application Data . . . . . . . . . . 80 151 6.3. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 81 152 6.4. HIP_MAC and SIGNATURE Calculation and Verification . . . 83 153 6.4.1. HMAC Calculation . . . . . . . . . . . . . . . . . . 83 154 6.4.2. Signature Calculation . . . . . . . . . . . . . . . . 85 155 6.5. HIP KEYMAT Generation . . . . . . . . . . . . . . . . . . 87 156 6.6. Initiation of a HIP Base Exchange . . . . . . . . . . . . 89 157 6.6.1. Sending Multiple I1 Packets in Parallel . . . . . . . 90 158 6.6.2. Processing Incoming ICMP Protocol Unreachable 159 Messages . . . . . . . . . . . . . . . . . . . . . . 90 160 6.7. Processing Incoming I1 Packets . . . . . . . . . . . . . 91 161 6.7.1. R1 Management . . . . . . . . . . . . . . . . . . . . 92 162 6.7.2. Handling Malformed Messages . . . . . . . . . . . . . 92 163 6.8. Processing Incoming R1 Packets . . . . . . . . . . . . . 93 164 6.8.1. Handling of Malformed Messages . . . . . . . . . . . 95 165 6.9. Processing Incoming I2 Packets . . . . . . . . . . . . . 95 166 6.9.1. Handling of Malformed Messages . . . . . . . . . . . 98 167 6.10. Processing of Incoming R2 Packets . . . . . . . . . . . . 99 168 6.11. Sending UPDATE Packets . . . . . . . . . . . . . . . . . 99 169 6.12. Receiving UPDATE Packets . . . . . . . . . . . . . . . . 100 170 6.12.1. Handling a SEQ Parameter in a Received UPDATE 171 Message . . . . . . . . . . . . . . . . . . . . . . 101 172 6.12.2. Handling an ACK Parameter in a Received UPDATE 173 Packet . . . . . . . . . . . . . . . . . . . . . . . 102 174 6.13. Processing of NOTIFY Packets . . . . . . . . . . . . . . 102 175 6.14. Processing CLOSE Packets . . . . . . . . . . . . . . . . 103 176 6.15. Processing CLOSE_ACK Packets . . . . . . . . . . . . . . 103 177 6.16. Handling State Loss . . . . . . . . . . . . . . . . . . . 103 178 7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 104 179 8. Security Considerations . . . . . . . . . . . . . . . . . . . 104 180 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 107 181 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 111 182 11. Changes from RFC 5201 . . . . . . . . . . . . . . . . . . . . 112 183 11.1. Changes from draft-ietf-hip-rfc5201-bis-18 . . . . . . . 112 184 11.2. Changes from draft-ietf-hip-rfc5201-bis-17 . . . . . . . 112 185 11.3. Changes from draft-ietf-hip-rfc5201-bis-16 . . . . . . . 112 186 11.4. Changes from draft-ietf-hip-rfc5201-bis-15 . . . . . . . 113 187 11.5. Changes from draft-ietf-hip-rfc5201-bis-14 . . . . . . . 113 188 11.6. Changes from draft-ietf-hip-rfc5201-bis-13 . . . . . . . 113 189 11.7. Changes from draft-ietf-hip-rfc5201-bis-12 . . . . . . . 113 190 11.8. Changes from draft-ietf-hip-rfc5201-bis-11 . . . . . . . 113 191 11.9. Changes from draft-ietf-hip-rfc5201-bis-10 . . . . . . . 113 192 11.10. Changes from draft-ietf-hip-rfc5201-bis-09 . . . . . . . 113 193 11.11. Changes from draft-ietf-hip-rfc5201-bis-08 . . . . . . . 113 194 11.12. Changes from draft-ietf-hip-rfc5201-bis-07 . . . . . . . 114 195 11.13. Changes from draft-ietf-hip-rfc5201-bis-06 . . . . . . . 114 196 11.14. Changes from draft-ietf-hip-rfc5201-bis-05 . . . . . . . 114 197 11.15. Changes from draft-ietf-hip-rfc5201-bis-04 . . . . . . . 115 198 11.16. Changes from draft-ietf-hip-rfc5201-bis-03 . . . . . . . 116 199 11.17. Changes from draft-ietf-hip-rfc5201-bis-02 . . . . . . . 117 200 11.18. Changes from draft-ietf-hip-rfc5201-bis-01 . . . . . . . 117 201 11.19. Changes from draft-ietf-hip-rfc5201-bis-00 . . . . . . . 119 202 11.20. Contents of draft-ietf-hip-rfc5201-bis-00 . . . . . . . 119 203 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 119 204 12.1. Normative References . . . . . . . . . . . . . . . . . . 119 205 12.2. Informative References . . . . . . . . . . . . . . . . . 121 206 Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 124 207 Appendix B. Generating a Public Key Encoding from an HI . . 125 208 Appendix C. Example Checksums for HIP Packets . . . . . . . . . 125 209 C.1. IPv6 HIP Example (I1 packet) . . . . . . . . . . . . . . 126 210 C.2. IPv4 HIP Packet (I1 packet) . . . . . . . . . . . . . . . 126 211 C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . . 127 212 Appendix D. ECDH and ECDSA 160 Bit Groups . . . . . . . . . . . 127 213 Appendix E. HIT Suites and HIT Generation . . . . . . . . . . . 127 215 1. Introduction 217 This document specifies the details of the Host Identity Protocol 218 (HIP). A high-level description of the protocol and the underlying 219 architectural thinking is available in the separate HIP architecture 220 description [I-D.ietf-hip-rfc4423-bis]. Briefly, the HIP 221 architecture proposes an alternative to the dual use of IP addresses 222 as "locators" (routing labels) and "identifiers" (endpoint, or host, 223 identifiers). In HIP, public cryptographic keys, of a public/private 224 key pair, are used as Host Identifiers, to which higher layer 225 protocols are bound instead of an IP address. By using public keys 226 (and their representations) as host identifiers, dynamic changes to 227 IP address sets can be directly authenticated between hosts, and if 228 desired, strong authentication between hosts at the TCP/IP stack 229 level can be obtained. 231 This memo specifies the base HIP protocol ("base exchange") used 232 between hosts to establish an IP-layer communications context, called 233 a HIP association, prior to communications. It also defines a packet 234 format and procedures for updating and terminating an active HIP 235 association. Other elements of the HIP architecture are specified in 236 other documents, such as: 238 o "Using the Encapsulating Security Payload (ESP) transport format 239 with the Host Identity Protocol (HIP)" [I-D.ietf-hip-rfc5202-bis]: 240 how to use the Encapsulating Security Payload (ESP) for integrity 241 protection and optional encryption 243 o "Host Mobility with the Host Identity Protocol" 244 [I-D.ietf-hip-rfc5206-bis]: how to support host mobility in HIP 246 o "Host Identity Protocol (HIP) Domain Name System (DNS) Extensions" 247 [I-D.ietf-hip-rfc5205-bis]: how to extend DNS to contain Host 248 Identity information 250 o "Host Identity Protocol (HIP) Rendezvous Extension" 251 [I-D.ietf-hip-rfc5204-bis]: using a rendezvous mechanism to 252 contact mobile HIP hosts 254 Since the HIP base exchange was first developed, there have been a 255 few advances in cryptography and attacks against cryptographic 256 systems. As a result, all cryptographic protocols need to be agile. 257 That is, it should be a part of the protocol to be able to switch 258 from one cryptographic primitive to another. It is important to 259 support a reasonable set of mainstream algorithms to cater for 260 different use cases and allow moving away from algorithms that are 261 later discovered to be vulnerable. This update to the base exchange 262 includes this needed cryptographic agility while addressing the 263 downgrade attacks that such flexibility introduces. In particular, 264 Elliptic Curve support by Elliptic Curve DSA (ECDSA) and Elliptic 265 Curve Diffie-Hellman (ECDH) and alternative hash functions have been 266 added. 268 1.1. A New Namespace and Identifiers 270 The Host Identity Protocol introduces a new namespace, the Host 271 Identity namespace. Some ramifications of this new namespace are 272 explained in the HIP architecture description 273 [I-D.ietf-hip-rfc4423-bis]. 275 There are two main representations of the Host Identity, the full 276 Host Identity (HI) and the Host Identity Tag (HIT). The HI is a 277 public key and directly represents the Identity of a host. Since 278 there are different public key algorithms that can be used with 279 different key lengths, the HI, as such, is unsuitable for use as a 280 packet identifier, or as an index into the various state-related 281 implementation structures needed to support HIP. Consequently, a 282 hash of the HI, the Host Identity Tag (HIT), is used as the 283 operational representation. The HIT is 128 bits long and is used in 284 the HIP headers and to index the corresponding state in the end 285 hosts. The HIT has an important security property in that it is 286 self-certifying (see Section 3). 288 1.2. The HIP Base Exchange (BEX) 290 The HIP base exchange is a two-party cryptographic protocol used to 291 establish communications context between hosts. The base exchange is 292 a SIGMA-compliant [KRA03] four-packet exchange. The first party is 293 called the Initiator and the second party the Responder. The 294 protocol exchanges Diffie-Hellman [DIF76] keys in the 2nd and 3rd 295 packets, and authenticates the parties in the 3rd and 4th packets. 296 The four-packet design helps to make HIP DoS resilient. It allows 297 the Responder to stay stateless until the IP address and the 298 cryptographic puzzle is verified. The Responder starts the puzzle 299 exchange in the 2nd packet, with the Initiator completing it in the 300 3rd packet before the Responder stores any state from the exchange. 302 The exchange can use the Diffie-Hellman output to encrypt the Host 303 Identity of the Initiator in the 3rd packet (although Aura, et al., 304 [AUR03] notes that such operation may interfere with packet- 305 inspecting middleboxes), or the Host Identity may instead be sent 306 unencrypted. The Responder's Host Identity is not protected. It 307 should be noted, however, that both the Initiator's and the 308 Responder's HITs are transported as such (in cleartext) in the 309 packets, allowing an eavesdropper with a priori knowledge about the 310 parties to identify them by their HITs. Hence, encrypting the HI of 311 any party does not provide privacy against such attacker. 313 Data packets start to flow after the 4th packet. The 3rd and 4th HIP 314 packets may carry a data payload in the future. However, the details 315 of this may be defined later. 317 An existing HIP association can be updated using the update mechanism 318 defined in this document, and when the association is no longer 319 needed, it can be closed using the defined closing mechanism. 321 Finally, HIP is designed as an end-to-end authentication and key 322 establishment protocol, to be used with Encapsulated Security Payload 323 (ESP) [I-D.ietf-hip-rfc5202-bis] and other end-to-end security 324 protocols. The base protocol does not cover all the fine-grained 325 policy control found in Internet Key Exchange (IKE) [RFC5996] that 326 allows IKE to support complex gateway policies. Thus, HIP is not a 327 complete replacement for IKE. 329 1.3. Memo Structure 331 The rest of this memo is structured as follows. Section 2 defines 332 the central keywords, notation, and terms used throughout the rest of 333 the document. Section 3 defines the structure of the Host Identity 334 and its various representations. Section 4 gives an overview of the 335 HIP base exchange protocol. Sections 5 and 6 define the detailed 336 packet formats and rules for packet processing. Finally, Sections 7, 337 8, and 9 discuss policy, security, and IANA considerations, 338 respectively. 340 2. Terms and Definitions 342 2.1. Requirements Terminology 344 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 345 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 346 document are to be interpreted as described in RFC 2119 [RFC2119]. 348 2.2. Notation 350 [x] indicates that x is optional. 352 {x} indicates that x is encrypted. 354 X(y) indicates that y is a parameter of X. 356 i indicates that x exists i times. 358 --> signifies "Initiator to Responder" communication (requests). 360 <-- signifies "Responder to Initiator" communication (replies). 362 | signifies concatenation of information (e.g., X | Y is the 363 concatenation of X with Y). 365 Ltrunc (H(x), K) denotes the lowest order #K bits of the result of 366 the hash function H on the input x. 368 2.3. Definitions 370 HIP base exchange (BEX): the handshake for establishing a new HIP 371 association. 373 Host Identity (HI): The public key of the signature algorithm that 374 represents the identity of the host. In HIP, a host proves its 375 identity by creating a signature with the private key belonging to 376 its HI (c.f. Section 3). 378 Host Identity Tag (HIT): A shorthand for the HI in IPv6 format. It 379 is generated by hashing the HI (c.f. Section 3.1). 381 HIT Suite: A HIT Suite groups all cryptographic algorithms that are 382 required to generate and use an HI and its HIT. In particular, 383 these algorithms are: 1) the public key signature algorithm and 2) 384 the hash function, 3) the truncation (c.f. Appendix E). 386 HIP association: The shared state between two peers after 387 completion of the BEX. 389 HIP packet: A control packet carrying a HIP packet header relating 390 to the establishment, maintenance, or termination of the HIP 391 association. 393 Initiator: The host that initiates the BEX. This role is typically 394 forgotten once the BEX is completed. 396 Responder: The host that responds to the Initiator in the BEX. 397 This role is typically forgotten once the BEX is completed. 399 Responder's HIT Hash Algorithm (RHASH): The Hash algorithm used for 400 various hash calculations in this document. The algorithm is the 401 same as is used to generate the Responder's HIT. The RHASH is the 402 hash function defined by the HIT Suite of the Responder's HIT 403 (c.f. Appendix E). 405 Length of the Responder's HIT Hash Algorithm (RHASH_len): The 406 natural output length of RHASH in bits. 408 Signed data: Data that is signed is protected by a digital 409 signature that was created by the sender of the data by using the 410 private key of its HI. 412 KDF: The Key Derivation Function (KDF) is used for deriving the 413 symmetric keys from the Diffie-Hellman key exchange. 415 KEYMAT: The keying material derived from the Diffie-Hellman key 416 exchange by using the KDF. Symmetric keys for encryption and 417 integrity protection of HIP packets and encrypted user data 418 packets are drawn from this keying material. 420 3. Host Identity (HI) and its Structure 422 In this section, the properties of the Host Identity and Host 423 Identity Tag are discussed, and the exact format for them is defined. 424 In HIP, the public key of an asymmetric key pair is used as the Host 425 Identity (HI). Correspondingly, the host itself is defined as the 426 entity that holds the private key of the key pair. See the HIP 427 architecture specification [I-D.ietf-hip-rfc4423-bis] for more 428 details on the difference between an identity and the corresponding 429 identifier. 431 HIP implementations MUST support the Rivest Shamir Adelman [RSA] 432 public key algorithm and the Elliptic Curve Digital Signature 433 Algorithm (ECDSA) for generating the HI as defined in Section 5.2.9. 434 Additional algorithms MAY be supported. 436 A hashed encoding of the HI, the Host Identity Tag (HIT), is used in 437 protocols to represent the Host Identity. The HIT is 128 bits long 438 and has the following three key properties: i) it is the same length 439 as an IPv6 address and can be used in fixed address-sized fields in 440 APIs and protocols, ii) it is self-certifying (i.e., given a HIT, it 441 is computationally hard to find a Host Identity key that matches the 442 HIT), and iii) the probability of a HIT collision between two hosts 443 is very low, hence, it is infeasible for an attacker to find a 444 collision with a HIT that is in use. For details on the security 445 properties of the HIT see [I-D.ietf-hip-rfc4423-bis]. 447 The structure of the HIT is defined in [RFC7343]. The HIT is an 448 Overlay Routable Cryptographic Hash Identifier (ORCHID) and consists 449 of three parts: first, an IANA assigned prefix to distinguish it from 450 other IPv6 addresses. Second, a four-bit encoding of the algorithms 451 that were used for generating the HI and the hashed representation of 452 HI. Third, a 96-bit hashed representation of the Host Identity. The 453 encoding of the ORCHID generation algorithm and the exact algorithm 454 for generating the 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 7343 [RFC7343] specifies 128-bit hash-based identifiers, called 476 Overlay Routable Cryptographic Hash Identifiers, ORCHIDs. Their 477 prefix, allocated from the IPv6 address block, is defined in 478 [RFC7343]. The Host Identity Tag is one type of an ORCHID. 480 This document extends the original, experimental HIP specification 481 [RFC5201] with measures to support crypto agility. One of these 482 measures is to allow different hash functions for creating a HIT. 483 HIT Suites group the sets of algorithms that are required to generate 484 and use a particular HIT. The Suites are encoded in HIT Suite IDs. 485 These HIT Suite IDs are transmitted in the ORCHID Generation 486 Algorithm (OGA) field in the ORCHID. With the HIT Suite ID in the 487 OGA field, a host can tell from another host's HIT, whether it 488 supports the necessary hash and signature algorithms to establish a 489 HIP association with that host. 491 3.2. Generating a HIT from an HI 493 The HIT MUST be generated according to the ORCHID generation method 494 described in [RFC7343] using a context ID value of 0xF0EF F02F BFF4 495 3D0F E793 0C3C 6E61 74EA (this tag value has been generated randomly 496 by the editor of this specification), and an input that encodes the 497 Host Identity field (see Section 5.2.9) present in a HIP payload 498 packet. The set of hash function, signature algorithm, and the 499 algorithm used for generating the HIT from the HI depends on the HIT 500 Suite (see Appendix E) and is indicated by the four bits of the 501 ORCHID Generation Algorithm (OGA) field in the ORCHID. Currently, 502 truncated SHA-1, truncated SHA-384, and truncated SHA-256 503 [FIPS.180-2.2002] are defined as hashes for generating a HIT. 505 For identities that are either RSA, Digital Signature Algorithm (DSA) 506 [FIPS186-3], or Elliptic Curve DSA (ECDSA) public keys, the ORCHID 507 input consists of the public key encoding as specified for the Host 508 Identity field of the HOST_ID parameter (see Section 5.2.9). This 509 document defines four algorithm profiles: RSA, DSA, ECDSA, and 510 ECDSA_LOW. The ECDSA_LOW profile is meant for devices with low 511 computational capabilities. Hence, one of the following applies: 513 The RSA public key is encoded as defined in [RFC3110] Section 2, 514 taking the exponent length (e_len), exponent (e), and modulus (n) 515 fields concatenated. The length (n_len) of the modulus (n) can be 516 determined from the total HI Length and the preceding HI fields 517 including the exponent (e). Thus, the data that serves as input 518 for the HIT generation has the same length as the HI. The fields 519 MUST be encoded in network byte order, as defined in [RFC3110]. 521 The DSA public key is encoded as defined in [RFC2536] Section 2, 522 taking the fields T, Q, P, G, and Y, concatenated as input. Thus, 523 the data to be hashed is 1 + 20 + 3 * 64 + 3 * 8 * T octets long, 524 where T is the size parameter as defined in [RFC2536]. The size 525 parameter T, affecting the field lengths, MUST be selected as the 526 minimum value that is long enough to accommodate P, G, and Y. The 527 fields MUST be encoded in network byte order, as defined in 528 [RFC2536]. 530 The ECDSA public keys are encoded as defined in [RFC6090] 531 Section 4.2 and 6. 533 In Appendix B, the public key encoding process is illustrated using 534 pseudo-code. 536 4. Protocol Overview 538 This section is a simplified overview of the HIP protocol operation, 539 and does not contain all the details of the packet formats or the 540 packet processing steps. Sections 5 and 6 describe in more detail 541 the packet formats and packet processing steps, respectively, and are 542 normative in case of any conflicts with this section. 544 The protocol number 139 has been assigned by IANA to the Host 545 Identity Protocol. 547 The HIP payload (Section 5.1) header could be carried in every IP 548 datagram. However, since HIP headers are relatively large (40 549 bytes), it is desirable to 'compress' the HIP header so that the HIP 550 header only occurs in control packets used to establish or change HIP 551 association state. The actual method for header 'compression' and 552 for matching data packets with existing HIP associations (if any) is 553 defined in separate documents, describing transport formats and 554 methods. All HIP implementations MUST implement, at minimum, the ESP 555 transport format for HIP [I-D.ietf-hip-rfc5202-bis]. 557 4.1. Creating a HIP Association 559 By definition, the system initiating a HIP base exchange is the 560 Initiator, and the peer is the Responder. This distinction is 561 typically forgotten once the base exchange completes, and either 562 party can become the Initiator in future communications. 564 The HIP base exchange serves to manage the establishment of state 565 between an Initiator and a Responder. The first packet, I1, 566 initiates the exchange, and the last three packets, R1, I2, and R2, 567 constitute an authenticated Diffie-Hellman [DIF76] key exchange for 568 session-key generation. In the first two packets, the hosts agree on 569 a set of cryptographic identifiers and algorithms that are then used 570 in and after the exchange. During the Diffie-Hellman key exchange, a 571 piece of keying material is generated. The HIP association keys are 572 drawn from this keying material by using a Key Derivation Function 573 (KDF). If other cryptographic keys are needed, e.g., to be used with 574 ESP, they are expected to be drawn from the same keying material by 575 using the KDF. 577 The Initiator first sends a trigger packet, I1, to the Responder. 578 The packet contains the HIT of the Initiator and possibly the HIT of 579 the Responder, if it is known. Moreover, the I1 packet initializes 580 the negotiation of the Diffie-Hellman group that is used for 581 generating the keying material. Therefore, the I1 packet contains a 582 list of Diffie Hellman Group IDs supported by the Initiator. Note 583 that in some cases it may be possible to replace this trigger packet 584 by some other form of a trigger, in which case the protocol starts 585 with the Responder sending the R1 packet. In such cases, another 586 mechanism to convey the Initiator's supported DH Groups (e.g., by 587 using a default group) must be specified. 589 The second packet, R1, starts the actual authenticated Diffie-Hellman 590 exchange. It contains a puzzle -- a cryptographic challenge that the 591 Initiator must solve before continuing the exchange. The level of 592 difficulty of the puzzle can be adjusted based on level of trust with 593 the Initiator, current load, or other factors. In addition, the R1 594 contains the Responder's Diffie-Hellman parameter and lists of 595 cryptographic algorithms supported by the Responder. Based on these 596 lists, the Initiator can continue, abort, or restart the base 597 exchange with a different selection of cryptographic algorithms. 598 Also, the R1 packet contains a signature that covers selected parts 599 of the message. Some fields are left outside the signature to 600 support pre-created R1s. 602 In the I2 packet, the Initiator MUST display the solution to the 603 received puzzle. Without a correct solution, the I2 message is 604 discarded. The I2 packet also contains a Diffie-Hellman parameter 605 that carries needed information for the Responder. The I2 packet is 606 signed by the Initiator. 608 The R2 packet acknowledges the receipt of the I2 packet and completes 609 the base exchange. The packet is signed by the Responder. 611 The base exchange is illustrated below in Figure 1. The term "key" 612 refers to the Host Identity public key, and "sig" represents a 613 signature using such a key. The packets contain other parameters not 614 shown in this figure. 616 Initiator Responder 618 I1: DH list 619 --------------------------> 620 select precomputed R1 621 R1: puzzle, DH, key, sig 622 <------------------------- 623 check sig remain stateless 624 solve puzzle 625 I2: solution, DH, {key}, sig 626 --------------------------> 627 compute DH check puzzle 628 check sig 629 R2: sig 630 <-------------------------- 631 check sig compute DH 633 Figure 1 635 4.1.1. HIP Puzzle Mechanism 637 The purpose of the HIP puzzle mechanism is to protect the Responder 638 from a number of denial-of-service threats. It allows the Responder 639 to delay state creation until receiving the I2 packet. Furthermore, 640 the puzzle allows the Responder to use a fairly cheap calculation to 641 check that the Initiator is "sincere" in the sense that it has 642 churned enough CPU cycles in solving the puzzle. 644 The puzzle allows a Responder implementation to completely delay 645 association-specific state creation until a valid I2 packet is 646 received. An I2 packet without valid puzzle solution can be rejected 647 immediately once the Responder has checked the solution by computing 648 only one hash function before state is created and CPU-intensive 649 public-key signature verification and Diffie-Hellman key generation 650 are performed. By varying the difficulty of the puzzle, the 651 Responder can frustrate CPU or memory targeted DoS attacks. 653 The Responder can remain stateless and drop most spoofed I2 packets 654 because puzzle calculation is based on the Initiator's Host Identity 655 Tag. The idea is that the Responder has a (perhaps varying) number of 656 pre-calculated R1 packets, and it selects one of these based on the 657 information carried in the I1 packet. When the Responder then later 658 receives the I2 packet, it can verify that the puzzle has been solved 659 using the Initiator's HIT. This makes it impractical for the 660 attacker to first exchange one I1/R1 packet, and then generate a 661 large number of spoofed I2 packets that seemingly come from different 662 HITs. This method does not protect the Responder from an attacker 663 that uses fixed HITs, though. Against such an attacker, a viable 664 approach may be to create a piece of local state, and remember that 665 the puzzle check has previously failed. See Appendix A for one 666 possible implementation. Responder implementations SHOULD include 667 sufficient randomness in the puzzle values so that algorithmic 668 complexity attacks become impossible [CRO03]. 670 The Responder can set the puzzle difficulty for the Initiator, based 671 on its level of trust of the Initiator. Because the puzzle is not 672 included in the signature calculation, the Responder can use pre- 673 calculated R1 packets and include the puzzle just before sending the 674 R1 to the Initiator. The Responder SHOULD use heuristics to 675 determine when it is under a denial-of-service attack, and set the 676 puzzle difficulty value #K appropriately as explained later. 678 4.1.2. Puzzle Exchange 680 The Responder starts the puzzle exchange when it receives an I1 681 packet. The Responder supplies a random number #I, and requires the 682 Initiator to find a number J. To select a proper #J, the Initiator 683 must create the concatenation of #I, the HITs of the parties, and #J, 684 and calculate a hash over this concatenation using the RHASH 685 algorithm. The lowest order #K bits of the result MUST be zeros. 686 The value #K sets the difficulty of the puzzle. 688 To generate a proper number #J, the Initiator will have to generate a 689 number of Js until one produces the hash target of zeros. The 690 Initiator SHOULD give up after exceeding the puzzle Lifetime in the 691 PUZZLE parameter (as described in Section 5.2.4). The Responder 692 needs to re-create the concatenation of #I, the HITs, and the 693 provided #J, and compute the hash once to prove that the Initiator 694 completed its assigned task. 696 To prevent precomputation attacks, the Responder MUST select the 697 number #I in such a way that the Initiator cannot guess it. 698 Furthermore, the construction MUST allow the Responder to verify that 699 the value #I was indeed selected by it and not by the Initiator. See 700 Appendix A for an example on how to implement this. 702 Using the Opaque data field in the PUZZLE (see Section 5.2.4), in an 703 ECHO_REQUEST_SIGNED (see Section 5.2.20) or in an 704 ECHO_REQUEST_UNSIGNED parameter (see Section 5.2.21), the Responder 705 can include some data in R1 that the Initiator MUST copy unmodified 706 in the corresponding I2 packet. The Responder can use the opaque 707 data to transfer a piece of local state information to the Initiator 708 and back, for example to recognize that the I2 is a response to a 709 previously sent R1. The Responder can generate the Opaque data in 710 various ways; e.g., using encryption or hashing with some secret, the 711 sent #I, and possibly using other related data. With the same 712 secret, the received #I (from the I2 packet), and the other related 713 data (if any), the Responder can verify that it has itself sent the 714 #I to the Initiator. The Responder MUST periodically change such a 715 secret. 717 It is RECOMMENDED that the Responder generates new secrets for the 718 puzzle and new R1s once every few minutes. Furthermore, it is 719 RECOMMENDED that the Responder is able to verify valid puzzle 720 solution at least Lifetime seconds after the puzzle secret has been 721 deprecated. This time value guarantees that the puzzle is valid for 722 at least Lifetime and at most 2 * Lifetime seconds. This limits the 723 usability that an old, solved puzzle has to an attacker. Moreover, 724 it avoids problems with the validity of puzzles if the lifetime is 725 relatively short compared to the network delay and the time for 726 solving the puzzle. 728 The puzzle value #I and the solution #J are inputs for deriving the 729 keying material from the Diffie-Hellman key exchange (see 730 Section 6.5). Therefore, a Responder SHOULD NOT use the same puzzle 731 #I with the same DH keys for the same Initiator twice to ensure that 732 the derived keying material differs. Such uniqueness can be 733 achieved, for example, by using a counter as an additional input for 734 generating #I. This counter can be increased for each processed I1 735 packet. The state of the counter can be transmitted in the Opaque 736 data field in the PUZZLE (see Section 5.2.4), in an 737 ECHO_REQUEST_SIGNED (see Section 5.2.20) or in an 738 ECHO_REQUEST_UNSIGNED parameter (see Section 5.2.21) without the need 739 to establish state. 741 NOTE: The protocol developers explicitly considered whether R1 should 742 include a timestamp in order to protect the Initiator from replay 743 attacks. The decision was to NOT include a timestamp to avoid 744 problems with global time synchronization. 746 NOTE: The protocol developers explicitly considered whether a memory 747 bound function should be used for the puzzle instead of a CPU-bound 748 function. The decision was not to use memory-bound functions. 750 4.1.3. Authenticated Diffie-Hellman Protocol with DH Group Negotiation 752 The packets R1, I2, and R2 implement a standard authenticated Diffie- 753 Hellman exchange. The Responder sends one of its public Diffie- 754 Hellman keys and its public authentication key, i.e., its Host 755 Identity, in R1. The signature in the R1 packet allows the Initiator 756 to verify that the R1 has been once generated by the Responder. 757 However, since the R1 is precomputed and therefore does not cover 758 association-specific information in the I1 packet, it does not 759 protect from replay attacks. 761 Before the actual authenticated Diffie-Hellman exchange, the 762 Initiator expresses its preference regarding its choice of the DH 763 groups in the I1 packet. The preference is expressed as a sorted 764 list of DH Group IDs. The I1 packet is not protected by a signature. 765 Therefore, this list is sent in an unauthenticated way to avoid 766 costly computations for processing the I1 packet at the Responder 767 side. Based on the preferences of the Initiator, the Responder sends 768 an R1 packet containing its most suitable public DH value. The 769 Responder also attaches a list of its own preferences to the R1 to 770 convey the basis for the DH group selection to the Initiator. This 771 list is carried in the signed part of the R1 packet. If the choice 772 of the DH group value in the R1 does not match the preferences of the 773 Initiator and the Responder, the Initiator can detect that the list 774 of DH Group IDs in the I1 was manipulated (see below for details). 776 If none of the DH Group IDs in the I1 packet is supported by the 777 Responder, the Responder selects the DH Group most suitable for it 778 regardless of the Initiator's preference. It then sends the R1 779 containing this DH Group and its list of supported DH Group IDs to 780 the Initiator. 782 When the Initiator receives an R1, it receives one of the Responder's 783 public Diffie-Hellman values and the list of DH Group IDs supported 784 by the Responder. This list is covered by the signature in the R1 785 packet to avoid forgery. The Initiator compares the Group ID of the 786 public DH value in the R1 packet to the list of supported DH Group 787 IDs in the R1 packets and to its own preferences expressed in the 788 list of supported DH Group IDs. The Initiator continues the BEX only 789 if the Group ID of the public DH value of the Responder is the most 790 preferred of the IDs supported by both the Initiator and Responder. 791 Otherwise, the communication is subject of a downgrade attack and the 792 Initiator MUST either restart the base exchange with a new I1 packet 793 or abort the base exchange. If the Responder's choice of the DH 794 Group is not supported by the Initiator, the Initiator MAY abort the 795 handshake or send a new I1 packet with a different list of supported 796 DH Groups. However, the Initiator MUST verify the signature of the 797 R1 packet before restarting or aborting the handshake. It MUST 798 silently ignore the R1 packet if the signature is not valid. 800 If the preferences regarding the DH Group ID match, the Initiator 801 computes the Diffie-Hellman session key (Kij). The Initiator creates 802 a HIP association using keying material from the session key (see 803 Section 6.5), and may use the HIP association to encrypt its public 804 authentication key, i.e., the Host Identity. The resulting I2 packet 805 contains the Initiator's Diffie-Hellman key and its (optionally 806 encrypted) public authentication key. The signature of the I2 807 message covers all parameters of the signed parameter ranges (see 808 Section 5.2) in the packet without exceptions as in the R1. 810 The Responder extracts the Initiator's Diffie-Hellman public key from 811 the I2 packet, computes the Diffie-Hellman session key, creates a 812 corresponding HIP association, and decrypts the Initiator's public 813 authentication key. It can then verify the signature using the 814 authentication key. 816 The final message, R2, completes the BEX and protects the Initiator 817 against replay attacks because the Responder uses the shared key from 818 the Diffie-Hellman exchange to create an HMAC as well as uses the 819 private key of its Host Identity to sign the packet contents. 821 4.1.4. HIP Replay Protection 823 The HIP protocol includes the following mechanisms to protect against 824 malicious packet replays. Responders are protected against replays 825 of I1 packets by virtue of the stateless response to I1 packets with 826 pre-signed R1 messages. Initiators are protected against R1 replays 827 by a monotonically increasing "R1 generation counter" included in the 828 R1. Responders are protected against replays of forged I2 packets by 829 the puzzle mechanism (see Section 4.1.1 above), and optional use of 830 opaque data. Hosts are protected against replays of R2 packets and 831 UPDATEs by use of a less expensive HMAC verification preceding the 832 HIP signature verification. 834 The R1 generation counter is a monotonically increasing 64-bit 835 counter that may be initialized to any value. The scope of the 836 counter MAY be system-wide but there SHOULD be a separate counter for 837 each Host Identity, if there is more than one local host identity. 838 The value of this counter SHOULD be preserved across system reboots 839 and invocations of the HIP base exchange. This counter indicates the 840 current generation of puzzles. Implementations MUST accept puzzles 841 from the current generation and MAY accept puzzles from earlier 842 generations. A system's local counter MUST be incremented at least 843 as often as every time old R1s cease to be valid. The local counter 844 SHOULD never be decremented, otherwise the host exposes its peers to 845 the replay of previously generated, higher numbered R1s. 847 A host may receive more than one R1, either due to sending multiple 848 I1 packets (see Section 6.6.1) or due to a replay of an old R1. When 849 sending multiple I1 packets to the same host, an Initiator SHOULD 850 wait for a small amount of time (a reasonable time may be 2 * 851 expected RTT) after the first R1 reception to allow possibly multiple 852 R1s to arrive, and it SHOULD respond to an R1 among the set with the 853 largest R1 generation counter. If an Initiator is processing an R1 854 or has already sent an I2 packet (still waiting for the R2 packet) 855 and it receives another R1 with a larger R1 generation counter, it 856 MAY elect to restart R1 processing with the fresher R1, as if it were 857 the first R1 to arrive. 859 The R1 generation counter may roll over or may become reset. It is 860 important for an Initiator to be robust to the loss of state about 861 the R1 generation counter of a peer, or to a reset of the peer's 862 counter. It is recommended that, when choosing between multiple R1s, 863 the Initiator prefer to use the R1 that corresponds to the current R1 864 generation counter, but that if it is unable to make progress with 865 that R1, the Initiator may try the other R1s beginning with the R1 866 packet with the highest counter. 868 4.1.5. Refusing a HIP base exchange 870 A HIP-aware host may choose not to accept a HIP base exchange. If 871 the host's policy is to only be an Initiator, and policy allows the 872 establishment of a HIP association with the original Initiator, it 873 should begin its own HIP base exchange. A host MAY choose to have 874 such a policy since only the privacy of the Initiator's HI is 875 protected in the exchange. It should be noted that such behavior can 876 introduce the risk of a race condition if each host's policy is to 877 only be an Initiator, at 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 association 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 select its HIT from the same HIT 979 Suite as the Initiator's HIT (indicated by the HIT suite information 980 in the OGA field of the Initiator's HIT) because this HIT Suite is 981 obviously supported by the Initiator. If the Responder selects a 982 different HIT that is not supported by the Initiator, the Initiator 983 MAY restart the BEX with an I1 packet with a source HIT that is 984 contained in the list of the Responder's HIT Suites in the R1 packet. 986 Note that the Initiator cannot verify the signature of the R1 packet 987 if the Responder's HIT Suite is not supported. Therefore, the 988 Initiator MUST treat R1 packets with unsupported Responder HITs as 989 potentially forged and MUST NOT use any parameters from the 990 unverified R1 besides the HIT Suite List. Moreover, an Initiator 991 that uses an unverified HIT Suite List from an R1 packet to determine 992 a possible source HIT MUST verify that the HIT_SUITE_LIST in the 993 first unverified R1 packet matches the HIT_SUITE_LIST in the second 994 R1 packet for which the Initiator supports the signature algorithm. 995 The Initiator MUST restart the BEX with a new I1 packet for which the 996 algorithm was mentioned in the verifiable R1 if the two lists do not 997 match. This procedure is necessary to mitigate downgrade attacks. 999 There are both security and API issues involved with the 1000 opportunistic mode. These issues are described in the reminder of 1001 this section. 1003 Given that the Responder's HI is not known by the Initiator, there 1004 must be suitable API calls that allow the Initiator to request, 1005 directly or indirectly, that the underlying system initiates the HIP 1006 base exchange solely based on locators. The Responder's HI will be 1007 tentatively available in the R1 packet, and in an authenticated form 1008 once the R2 packet has been received and verified. Hence, the 1009 Responder's HIT could be communicated to the application via new API 1010 mechanisms. However, with a backwards-compatible API the application 1011 sees only the locators used for the initial contact. Depending on 1012 the desired semantics of the API, this can raise the following 1013 issues: 1015 o The actual locators may later change if an UPDATE message is used, 1016 even if from the API perspective the association still appears to 1017 be between two specific locators. However, the locator update is 1018 still secure and the association is still between the same nodes. 1020 o Different associations between the same two locators may result in 1021 connections to different nodes, if the implementation no longer 1022 remembers which identifier the peer had in an earlier association. 1023 This is possible when the peer's locator has changed for 1024 legitimate reasons or when an attacker pretends to be a node that 1025 has the peer's locator. Therefore, when using opportunistic mode, 1026 HIP implementations MUST NOT place any expectation that the peer's 1027 HI returned in the R1 message matches any HI previously seen from 1028 that address. 1030 If the HIP implementation and application do not have the same 1031 understanding of what constitutes an association, this may even 1032 happen within the same association. For instance, an 1033 implementation may not know when HIP state can be purged for UDP- 1034 based applications. 1036 In addition, the following security considerations apply. The 1037 generation counter mechanism will be less efficient in protecting 1038 against replays of the R1 packet, given that the Responder can choose 1039 a replay that uses an arbitrary HI, not just the one given in the I1 1040 packet. 1042 More importantly, the opportunistic exchange is vulnerable to man-in- 1043 the-middle attacks, because the Initiator does not have any public 1044 key information about the peer. To assess the impacts of this 1045 vulnerability, we compare it to vulnerabilities in current, non-HIP- 1046 capable communications. 1048 An attacker on the path between the two peers can insert itself as a 1049 man-in-the-middle by providing its own identifier to the Initiator 1050 and then initiating another HIP association towards the Responder. 1051 For this to be possible, the Initiator must employ opportunistic 1052 mode, and the Responder must be configured to accept a connection 1053 from any HIP-enabled node. 1055 An attacker outside the path will be unable to do so, given that it 1056 cannot respond to the messages in the base exchange. 1058 These security properties are characteristic also of communications 1059 in the current Internet. A client contacting a server without 1060 employing end-to-end security may find itself talking to the server 1061 via a man-in-the-middle, assuming again that the server is willing to 1062 talk to anyone. 1064 If end-to-end security is in place, then the worst that can happen in 1065 both the opportunistic HIP and non-HIP (normal IP) cases is denial- 1066 of-service; an entity on the path can disrupt communications, but 1067 will be unable to successfully insert itself as a man-in-the-middle. 1069 However, once the opportunistic exchange has successfully completed, 1070 HIP provides confidentiality and integrity protection for the 1071 communications, and can securely change the locators of the 1072 endpoints. 1074 As a result, opportunistic mode in HIP offers a "better than nothing" 1075 security model. Initially, a base exchange authenticated in the 1076 opportunistic mode involves a leap of faith subject to man-in-the- 1077 middle attacks, but subsequent datagrams related to the same HIP 1078 association cannot be compromised by a new man-in-the-middle attack, 1079 and further, if the man-in-the-middle moves away from the path of the 1080 active association, the attack would be exposed after the fact. 1081 Thus, it can be stated that opportunistic mode in HIP is at least as 1082 secure as unprotected IP-based communications. 1084 4.2. Updating a HIP Association 1086 A HIP association between two hosts may need to be updated over time. 1087 Examples include the need to rekey expiring security associations, 1088 add new security associations, or change IP addresses associated with 1089 hosts. The UPDATE packet is used for those and other similar 1090 purposes. This document only specifies the UPDATE packet format and 1091 basic processing rules, with mandatory parameters. The actual usage 1092 is defined in separate specifications. 1094 HIP provides a general purpose UPDATE packet, which can carry 1095 multiple HIP parameters, for updating the HIP state between two 1096 peers. The UPDATE mechanism has the following properties: 1098 UPDATE messages carry a monotonically increasing sequence number 1099 and are explicitly acknowledged by the peer. Lost UPDATEs or 1100 acknowledgments may be recovered via retransmission. Multiple 1101 UPDATE messages may be outstanding under certain circumstances. 1103 UPDATE is protected by both HIP_MAC and HIP_SIGNATURE parameters, 1104 since processing UPDATE signatures alone is a potential DoS attack 1105 against intermediate systems. 1107 UPDATE packets are explicitly acknowledged by the use of an 1108 acknowledgment parameter that echoes an individual sequence number 1109 received from the peer. A single UPDATE packet may contain both a 1110 sequence number and one or more acknowledgment numbers (i.e., 1111 piggybacked acknowledgment(s) for the peer's UPDATE). 1113 The UPDATE packet is defined in Section 5.3.5. 1115 4.3. Error Processing 1117 HIP error processing behavior depends on whether or not there exists 1118 an active HIP association. In general, if a HIP association exists 1119 between the sender and receiver of a packet causing an error 1120 condition, the receiver SHOULD respond with a NOTIFY packet. On the 1121 other hand, if there are no existing HIP associations between the 1122 sender and receiver, or the receiver cannot reasonably determine the 1123 identity of the sender, the receiver MAY respond with a suitable ICMP 1124 message; see Section 5.4 for more details. 1126 The HIP protocol and state machine are designed to recover from one 1127 of the parties crashing and losing its state. The following 1128 scenarios describe the main use cases covered by the design. 1130 No prior state between the two systems. 1132 The system with data to send is the Initiator. The process 1133 follows the standard four-packet base exchange, establishing 1134 the HIP association. 1136 The system with data to send has no state with the receiver, but 1137 the receiver has a residual HIP association. 1139 The system with data to send is the Initiator. The Initiator 1140 acts as in no prior state, sending an I1 packet and receiving 1141 an R1 packet. When the Responder receives a valid I2 packet, 1142 the old association is 'discovered' and deleted, and the new 1143 association is established. 1145 The system with data to send has a HIP association, but the 1146 receiver does not. 1148 The system sends data on the outbound user data security 1149 association. The receiver 'detects' the situation when it 1150 receives a user data packet that it cannot match to any HIP 1151 association. The receiving host MUST discard this packet. 1153 The receiving host SHOULD send an ICMP packet, with the type 1154 Parameter Problem, to inform the sender that the HIP 1155 association does not exist (see Section 5.4), and it MAY 1156 initiate a new HIP BEX. However, responding with these 1157 optional mechanisms is implementation or policy dependent. If 1158 the sending application doesn't expect a response, the system 1159 could possibly send a large number of packets in this state, so 1160 for this reason, the sending of one or more ICMP packets is 1161 RECOMMENDED. However, any such responses MUST be rate-limited 1162 to prevent abuse (see Section 5.4). 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 HIP packet is 1205 expected to spend in the network. A default value of 2 minutes 1206 has been borrowed from [RFC0793] because it is a prevailing 1207 assumption for packet lifetimes. 1209 Exchange Complete (EC): Time that the host spends at the R2-SENT 1210 state before it moves to the ESTABLISHED state. The time is n * 1211 I2 retransmission timeout, where n is about I2_RETRIES_MAX. 1213 Receive ANYOTHER: Any received packet for which no state 1214 transitions or processing rules are defined for a given state. 1216 4.4.2. HIP States 1217 +---------------------+---------------------------------------------+ 1218 | State | Explanation | 1219 +---------------------+---------------------------------------------+ 1220 | UNASSOCIATED | State machine start | 1221 | | | 1222 | I1-SENT | Initiating base exchange | 1223 | | | 1224 | I2-SENT | Waiting to complete base exchange | 1225 | | | 1226 | R2-SENT | Waiting to complete base exchange | 1227 | | | 1228 | ESTABLISHED | HIP association established | 1229 | | | 1230 | CLOSING | HIP association closing, no data can be | 1231 | | sent | 1232 | | | 1233 | CLOSED | HIP association closed, no data can be sent | 1234 | | | 1235 | E-FAILED | HIP base exchange failed | 1236 +---------------------+---------------------------------------------+ 1238 Table 1: HIP States 1240 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 | 1253 | | R2-SENT | 1254 | | | 1255 | | If fail, stay at UNASSOCIATED | 1256 | | | 1257 | Receive user data for an | Optionally send ICMP as defined in | 1258 | unknown HIP association | Section 5.4 and stay at UNASSOCIATED | 1259 | | | 1260 | Receive CLOSE | Optionally send ICMP Parameter | 1261 | | Problem and stay at UNASSOCIATED | 1262 | | | 1263 | Receive ANYOTHER | Drop and stay at UNASSOCIATED | 1264 +----------------------------+--------------------------------------+ 1266 Table 2: UNASSOCIATED - Start state 1268 System behavior in state I1-SENT, Table 3. 1270 +---------------------+---------------------------------------------+ 1271 | Trigger | Action | 1272 +---------------------+---------------------------------------------+ 1273 | Receive I1 from | If the local HIT is smaller than the peer | 1274 | Responder | HIT, drop I1 and stay at I1-SENT (see | 1275 | | Section 6.5 for HIT comparison) | 1276 | | | 1277 | | If the local HIT is greater than the peer | 1278 | | HIT, send R1 and stay at I1-SENT | 1279 | | | 1280 | Receive I2, process | If successful, send R2 and go to R2-SENT | 1281 | | | 1282 | | If fail, stay at I1-SENT | 1283 | | | 1284 | Receive R1, process | If the HIT Suite of the local HIT is not | 1285 | | supported by the peer, select supported | 1286 | | local HIT, send I1 and stay at I1-SENT | 1287 | | | 1288 | | If successful, send I2 and go to I2-SENT | 1289 | | | 1290 | | If fail, stay at I1-SENT | 1291 | | | 1292 | Receive ANYOTHER | Drop and stay at I1-SENT | 1293 | | | 1294 | Timeout | Increment trial counter | 1295 | | | 1296 | | If counter is less than I1_RETRIES_MAX, | 1297 | | send I1 and stay at I1-SENT | 1298 | | | 1299 | | If counter is greater than I1_RETRIES_MAX, | 1300 | | go to E-FAILED | 1301 +---------------------+---------------------------------------------+ 1303 Table 3: I1-SENT - Initiating the HIP base exchange 1305 System behavior in state I2-SENT, Table 4. 1307 +---------------------+---------------------------------------------+ 1308 | Trigger | Action | 1309 +---------------------+---------------------------------------------+ 1310 | Receive I1 | Send R1 and stay at I2-SENT | 1311 | | | 1312 | Receive R1, process | If successful, send I2 and stay at I2-SENT | 1313 | | | 1314 | | If fail, stay at I2-SENT | 1315 | | | 1316 | Receive I2, process | If successful and local HIT is smaller than | 1317 | | the peer HIT, drop I2 and stay at I2-SENT | 1318 | | | 1319 | | If successful and local HIT is greater than | 1320 | | the peer HIT, send R2 and go to R2-SENT | 1321 | | | 1322 | | If fail, stay at I2-SENT | 1323 | | | 1324 | Receive R2, process | If successful, go to ESTABLISHED | 1325 | | | 1326 | | If fail, stay at I2-SENT | 1327 | | | 1328 | Receive CLOSE, | If successful, send CLOSE_ACK and go to | 1329 | process | CLOSED | 1330 | | | 1331 | | If fail, stay at I2-SENT | 1332 | | | 1333 | Receive ANYOTHER | Drop and stay at I2-SENT | 1334 | | | 1335 | Timeout | Increment trial counter | 1336 | | | 1337 | | If counter is less than I2_RETRIES_MAX, | 1338 | | send I2 and stay at I2-SENT | 1339 | | | 1340 | | If counter is greater than I2_RETRIES_MAX, | 1341 | | go to E-FAILED | 1342 +---------------------+---------------------------------------------+ 1344 Table 4: I2-SENT - Waiting to finish the HIP base exchange 1346 System behavior in state R2-SENT, Table 5. 1348 +------------------------+------------------------------------------+ 1349 | Trigger | Action | 1350 +------------------------+------------------------------------------+ 1351 | Receive I1 | Send R1 and stay at R2-SENT | 1352 | | | 1353 | Receive I2, process | If successful, send R2 and stay at | 1354 | | R2-SENT | 1355 | | | 1356 | | If fail, stay at R2-SENT | 1357 | | | 1358 | Receive R1 | Drop and stay at R2-SENT | 1359 | | | 1360 | Receive R2 | Drop and stay at R2-SENT | 1361 | | | 1362 | Receive data or UPDATE | Move to ESTABLISHED | 1363 | | | 1364 | Exchange Complete | Move to ESTABLISHED | 1365 | Timeout | | 1366 | | | 1367 | Receive CLOSE, process | If successful, send CLOSE_ACK and go to | 1368 | | CLOSED | 1369 | | | 1370 | | If fail, stay at ESTABLISHED | 1371 | | | 1372 | Receive CLOSE_ACK | Drop and stay at R2-SENT | 1373 | | | 1374 | Receive NOTIFY | Process and stay at R2-SENT | 1375 +------------------------+------------------------------------------+ 1377 Table 5: R2-SENT - Waiting to finish HIP 1379 System behavior in state ESTABLISHED, Table 6. 1381 +---------------------+---------------------------------------------+ 1382 | Trigger | Action | 1383 +---------------------+---------------------------------------------+ 1384 | Receive I1 | Send R1 and stay at ESTABLISHED | 1385 | | | 1386 | Receive I2 | Process with puzzle and possible Opaque | 1387 | | data verification | 1388 | | | 1389 | | If successful, send R2, drop old HIP | 1390 | | association, establish a new HIP | 1391 | | association and go to R2-SENT | 1392 | | | 1393 | | If fail, stay at ESTABLISHED | 1394 | | | 1395 | Receive R1 | Drop and stay at ESTABLISHED | 1396 | | | 1397 | Receive R2 | Drop and stay at ESTABLISHED | 1398 | | | 1399 | Receive user data | Process and stay at ESTABLISHED | 1400 | for HIP association | | 1401 | | | 1402 | No packet | Send CLOSE and go to CLOSING | 1403 | sent/received | | 1404 | during UAL minutes | | 1405 | | | 1406 | Receive UPDATE | Process and stay at ESTABLISHED | 1407 | | | 1408 | Receive CLOSE, | If successful, send CLOSE_ACK and go to | 1409 | process | CLOSED | 1410 | | | 1411 | | If fail, stay at ESTABLISHED | 1412 | | | 1413 | Receive CLOSE_ACK | Drop and stay at ESTABLISHED | 1414 | | | 1415 | Receive NOTIFY | Process and stay at ESTABLISHED | 1416 +---------------------+---------------------------------------------+ 1418 Table 6: ESTABLISHED - HIP association established 1420 System behavior in state CLOSING, Table 7. 1422 +----------------------------+--------------------------------------+ 1423 | Trigger | Action | 1424 +----------------------------+--------------------------------------+ 1425 | User data to send, | Send I1 and go to I1-SENT | 1426 | requires the creation of | | 1427 | another 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 | 1433 | | R2-SENT | 1434 | | | 1435 | | If fail, stay at CLOSING | 1436 | | | 1437 | Receive R1, process | If successful, send I2 and go to | 1438 | | I2-SENT | 1439 | | | 1440 | | If fail, stay at CLOSING | 1441 | | | 1442 | Receive CLOSE, process | If successful, send CLOSE_ACK, | 1443 | | discard state and go to CLOSED | 1444 | | | 1445 | | If fail, stay at CLOSING | 1446 | | | 1447 | Receive CLOSE_ACK, process | If successful, discard state and go | 1448 | | to UNASSOCIATED | 1449 | | | 1450 | | If fail, stay at CLOSING | 1451 | | | 1452 | Receive ANYOTHER | Drop and stay at CLOSING | 1453 | | | 1454 | Timeout | Increment timeout sum and reset | 1455 | | timer. If timeout sum is less than | 1456 | | UAL+MSL minutes, retransmit CLOSE | 1457 | | and stay at CLOSING | 1458 | | | 1459 | | If timeout sum is greater than | 1460 | | UAL+MSL minutes, go to UNASSOCIATED | 1461 +----------------------------+--------------------------------------+ 1463 Table 7: CLOSING - HIP association has not been used for UAL minutes 1464 System behavior in state CLOSED, Table 8. 1466 +----------------------------------------+--------------------------+ 1467 | Trigger | Action | 1468 +----------------------------------------+--------------------------+ 1469 | Datagram to send, requires the | Send I1, and stay at | 1470 | creation of another incarnation of the | CLOSED | 1471 | HIP association | | 1472 | | | 1473 | Receive I1 | Send R1 and stay at | 1474 | | CLOSED | 1475 | | | 1476 | Receive I2, process | If successful, send R2 | 1477 | | and go to R2-SENT | 1478 | | | 1479 | | If fail, stay at CLOSED | 1480 | | | 1481 | Receive R1, process | If successful, send I2 | 1482 | | and go to I2-SENT | 1483 | | | 1484 | | If fail, stay at CLOSED | 1485 | | | 1486 | Receive CLOSE, process | If successful, send | 1487 | | CLOSE_ACK, stay at | 1488 | | CLOSED | 1489 | | | 1490 | | If fail, stay at CLOSED | 1491 | | | 1492 | Receive CLOSE_ACK, process | If successful, discard | 1493 | | state and go to | 1494 | | UNASSOCIATED | 1495 | | | 1496 | | If fail, stay at CLOSED | 1497 | | | 1498 | Receive ANYOTHER | Drop and stay at CLOSED | 1499 | | | 1500 | Timeout (UAL+2MSL) | Discard state, and go to | 1501 | | UNASSOCIATED | 1502 +----------------------------------------+--------------------------+ 1504 Table 8: CLOSED - CLOSE_ACK sent, resending CLOSE_ACK if necessary 1506 System behavior in state E-FAILED, Table 9. 1508 +-------------------------+-----------------------------------------+ 1509 | Trigger | Action | 1510 +-------------------------+-----------------------------------------+ 1511 | Wait for | Go to UNASSOCIATED. Re-negotiation is | 1512 | implementation-specific | possible after moving to UNASSOCIATED | 1513 | time | state. | 1514 +-------------------------+-----------------------------------------+ 1516 Table 9: E-FAILED - HIP failed to establish association with peer 1518 4.4.4. Simplified HIP State Diagram 1520 The following diagram (Figure 2) shows the major state transitions. 1521 Transitions based on received packets implicitly assume that the 1522 packets are successfully authenticated or processed. 1524 +--+ +----------------------------+ 1525 recv I1, send R1 | | | | 1526 | v v | 1527 +--------------+ recv I2, send R2 | 1528 +----------------| UNASSOCIATED |----------------+ | 1529 datagram | +--+ +--------------+ | | 1530 to send, | | | Alg. not supported, | | 1531 send I1 | | | send I1 | | 1532 . v | v | | 1533 . +---------+ recv I2, send R2 | | 1534 +---->| I1-SENT |--------------------------------------+ | | 1535 | +---------+ +----------------------+ | | | 1536 | | recv R2, | recv I2, send R2 | | | | 1537 | v send I2 | v v v | 1538 | +---------+ | +---------+ | 1539 | +--->| I2-SENT |----------+ +--------------| R2-SENT |<---+ | 1540 | | +---------+ | +---------+ | | 1541 | | | |recv R2 | data or| | | 1542 | |recv R1, | | | EC timeout| | | 1543 | |send I2 +--|-----------------+ | receive I2,| | 1544 | | | | +-------------+ | send R2| | 1545 | | | +------>| ESTABLISHED |<----------+ | | 1546 | | | +-------------+ | | 1547 | | | | | | receive I2, send R2 | | 1548 | | +------------+ | +-------------------------------+ | 1549 | | | +-----------+ | | 1550 | | | no packet sent/received| +---+ | | 1551 | | | for UAL min, send CLOSE| | |timeout | | 1552 | | | v v |(UAL+MSL) | | 1553 | | | +---------+ |retransmit | | 1554 +--|----------|------------------------| CLOSING |-+CLOSE | | 1555 | | +---------+ | | 1556 | | | | | | | | 1557 +----------|-------------------------+ | | +----------------+ | 1558 | | +-----------+ +------------------|--+ 1559 | | |recv CLOSE, recv CLOSE_ACK | | 1560 | +-------------+ |send CLOSE_ACK or timeout | | 1561 | recv CLOSE, | | (UAL+MSL) | | 1562 | send CLOSE_ACK v v | | 1563 | +--------+ receive I2, send R2 | | 1564 +---------------------| CLOSED |------------------------------+ | 1565 +--------+ | 1566 ^ | | | 1567 recv CLOSE, send CLOSE_ACK| | | timeout (UAL+2MSL) | 1568 +-+ +------------------------------------+ 1570 Figure 2 1572 4.5. User Data Considerations 1574 4.5.1. TCP and UDP Pseudo-Header Computation for User Data 1576 When computing TCP and UDP checksums on user data packets that flow 1577 through sockets bound to HITs, the IPv6 pseudo-header format 1578 [RFC2460] MUST be used, even if the actual addresses in the header of 1579 the packet are IPv4 addresses. Additionally, the HITs MUST be used 1580 in place of the IPv6 addresses in the IPv6 pseudo-header. Note that 1581 the pseudo-header for actual HIP payloads is computed differently; 1582 see Section 5.1.1. 1584 4.5.2. Sending Data on HIP Packets 1586 Other documents may define how to include user data in various HIP 1587 packets. However, currently the HIP header is a terminal header, and 1588 not followed by any other headers. 1590 4.5.3. Transport Formats 1592 The actual data transmission format, used for user data after the HIP 1593 base exchange, is not defined in this document. Such transport 1594 formats and methods are described in separate specifications. All 1595 HIP implementations MUST implement, at minimum, the ESP transport 1596 format for HIP [I-D.ietf-hip-rfc5202-bis]. The transport format to 1597 be chosen is negotiated in the base exchange. The Responder 1598 expresses its preference of the transport format in the 1599 TRANSPORT_FORMAT_LIST in the R1 packet and the Initiator selects one 1600 transport format and adds the respective HIP parameter to the I2 1601 packet. 1603 4.5.4. Reboot, Timeout, and Restart of HIP 1605 Simulating a loss of state is a potential DoS attack. The following 1606 process has been crafted to manage state recovery without presenting 1607 a DoS opportunity. 1609 If a host reboots or the HIP association times out, it has lost its 1610 HIP state. If the host that lost state has a datagram to send to the 1611 peer, it simply restarts the HIP base exchange. After the base 1612 exchange has completed, the Initiator can create a new payload 1613 association and start sending data. The peer does not reset its 1614 state until it receives a valid I2 packet. 1616 If a system receives a user data packet that cannot be matched to any 1617 existing HIP association, it is possible that it has lost the state 1618 and its peer has not. It MAY send an ICMP packet with the Parameter 1619 Problem type, and with the pointer pointing to the referred HIP- 1620 related association information. Reacting to such traffic depends on 1621 the implementation and the environment where the implementation is 1622 used. 1624 If the host, that apparently has lost its state, decides to restart 1625 the HIP base exchange, it sends an I1 packet to the peer. After the 1626 base exchange has been completed successfully, the Initiator can 1627 create a new HIP association and the peer drops its old payload 1628 associations and creates a new one. 1630 4.6. Certificate Distribution 1632 This document does not define how to use certificates or how to 1633 transfer them between hosts. These functions are expected to be 1634 defined in a future specification as for HIP Version 1 [RFC6253]. A 1635 parameter type value, meant to be used for carrying certificates, is 1636 reserved, though: CERT, Type 768; see Section 5.2. 1638 5. Packet Formats 1640 5.1. Payload Format 1642 All HIP packets start with a fixed header. 1644 0 1 2 3 1645 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1647 | Next Header | Header Length |0| Packet Type |Version| RES.|1| 1648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1649 | Checksum | Controls | 1650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1651 | Sender's Host Identity Tag (HIT) | 1652 | | 1653 | | 1654 | | 1655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1656 | Receiver's Host Identity Tag (HIT) | 1657 | | 1658 | | 1659 | | 1660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1661 | | 1662 / HIP Parameters / 1663 / / 1664 | | 1665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1666 The HIP header is logically an IPv6 extension header. However, this 1667 document does not describe processing for Next Header values other 1668 than decimal 59, IPPROTO_NONE, the IPv6 'no next header' value. 1669 Future documents MAY define behavior for also other values. However, 1670 current implementations MUST ignore trailing data if an unimplemented 1671 Next Header value is received. 1673 The Header Length field contains the combined length of the HIP 1674 Header and HIP parameters in 8-byte units, excluding the first 8 1675 bytes. Since all HIP headers MUST contain the sender's and 1676 receiver's HIT fields, the minimum value for this field is 4, and 1677 conversely, the maximum length of the HIP Parameters field is 1678 (255*8)-32 = 2008 bytes (see Section 5.1.3 regarding HIP 1679 fragmentation). Note: this sets an additional limit for sizes of 1680 parameters included in the Parameters field, independent of the 1681 individual parameter maximum lengths. 1683 The Packet Type indicates the HIP packet type. The individual packet 1684 types are defined in the relevant sections. If a HIP host receives a 1685 HIP packet that contains an unrecognized packet type, it MUST drop 1686 the packet. 1688 The HIP Version field is four bits. The version defined in this 1689 document is 2. The version number is expected to be incremented only 1690 if there are incompatible changes to the protocol. Most extensions 1691 can be handled by defining new packet types, new parameter types, or 1692 new Controls (see Section 5.1.2) . 1694 The following three bits are reserved for future use. They MUST be 1695 zero when sent, and they MUST be ignored when handling a received 1696 packet. 1698 The two fixed bits in the header are reserved for SHIM6 compatibility 1699 [RFC5533], Section 5.3. For implementations adhering (only) to this 1700 specification, they MUST be set as shown when sending and MUST be 1701 ignored when receiving. This is to ensure optimal forward 1702 compatibility. Note that for implementations that implement other 1703 compatible specifications in addition to this specification, the 1704 corresponding rules may well be different. For example, an 1705 implementation that implements both this specification and the SHIM6 1706 protocol may need to check these bits in order to determine how to 1707 handle the packet. 1709 The HIT fields are always 128 bits (16 bytes) long. 1711 5.1.1. Checksum 1713 Since the checksum covers the source and destination addresses in the 1714 IP header, it MUST be recomputed on HIP-aware NAT devices. 1716 If IPv6 is used to carry the HIP packet, the pseudo-header [RFC2460] 1717 contains the source and destination IPv6 addresses, HIP packet length 1718 in the pseudo-header length field, a zero field, and the HIP protocol 1719 number (see Section 5.1) in the Next Header field. The length field 1720 is in bytes and can be calculated from the HIP header length field: 1722 (HIP Header Length + 1) * 8. 1724 In case of using IPv4, the IPv4 UDP pseudo-header format [RFC0768] is 1725 used. In the pseudo-header, the source and destination addresses are 1726 those used in the IP header, the zero field is obviously zero, the 1727 protocol is the HIP protocol number (see Section 4), and the length 1728 is calculated as in the IPv6 case. 1730 5.1.2. HIP Controls 1732 The HIP Controls field conveys information about the structure of the 1733 packet and capabilities of the host. 1735 The following fields have been defined: 1737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1738 | | | | | | | | | | | | | | | |A| 1739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1741 A - Anonymous: If this is set, the sender's HI in this packet is 1742 anonymous, i.e., one not listed in a directory. Anonymous HIs 1743 SHOULD NOT be stored. This control is set in packets using 1744 anonymous sender HIs. The peer receiving an anonymous HI in an R1 1745 or I2 may choose to refuse it. 1747 The rest of the fields are reserved for future use and MUST be set to 1748 zero in sent packets and MUST be ignored in received packets. 1750 5.1.3. HIP Fragmentation Support 1752 A HIP implementation MUST support IP fragmentation/reassembly. 1753 Fragment reassembly MUST be implemented in both IPv4 and IPv6, but 1754 fragment generation is REQUIRED to be implemented in IPv4 (IPv4 1755 stacks and networks will usually do this by default) and RECOMMENDED 1756 to be implemented in IPv6. In IPv6 networks, the minimum MTU is 1757 larger, 1280 bytes, than in IPv4 networks. The larger MTU size is 1758 usually sufficient for most HIP packets, and therefore fragment 1759 generation may not be needed. If it is expected that a host will 1760 send HIP packets that are larger than the minimum IPv6 MTU, the 1761 implementation MUST implement fragment generation even for IPv6. 1763 In IPv4 networks, HIP packets may encounter low MTUs along their 1764 routed path. Since basic HIP, as defined in this document, does not 1765 provide a mechanism to use multiple IP datagrams for a single HIP 1766 packet, support for path MTU discovery does not bring any value to 1767 HIP in IPv4 networks. HIP-aware NAT devices SHOULD perform IPv4 1768 reassembly/fragmentation for HIP packets. 1770 All HIP implementations have to be careful while employing a 1771 reassembly algorithm so that the algorithm is sufficiently resistant 1772 to DoS attacks. 1774 Certificate chains can cause the packet to be fragmented and 1775 fragmentation can open implementations to denial-of-service attacks 1776 [KAU03]. "Hash and URL" schemes as defined in [RFC6253] for HIP 1777 version 1 may be used to avoid fragmentation and mitigate resulting 1778 DoS attacks. 1780 5.2. HIP Parameters 1782 The HIP parameters carry information that is necessary for 1783 establishing and maintaining a HIP association. For example, the 1784 peer's public keys as well as the signaling for negotiating ciphers 1785 and payload handling are encapsulated in HIP parameters. Additional 1786 information, meaningful for end-hosts or middleboxes, may also be 1787 included in HIP parameters. The specification of the HIP parameters 1788 and their mapping to HIP packets and packet types is flexible to 1789 allow HIP extensions to define new parameters and new protocol 1790 behavior. 1792 In HIP packets, HIP parameters are ordered according to their numeric 1793 type number and encoded in TLV format. 1795 The following parameter types are currently defined. 1797 +------------------------+-------+-----------+----------------------+ 1798 | TLV | Type | Length | Data | 1799 +------------------------+-------+-----------+----------------------+ 1800 | R1_COUNTER | 129 | 12 | Puzzle generation | 1801 | | | | counter | 1802 | | | | | 1803 | PUZZLE | 257 | 12 | K and Random #I | 1804 | | | | | 1805 | SOLUTION | 321 | 20 | K, Random #I and | 1806 | | | | puzzle solution J | 1807 | | | | | 1808 | SEQ | 385 | 4 | UPDATE packet ID | 1809 | | | | number | 1810 | | | | | 1811 | ACK | 449 | variable | UPDATE packet ID | 1812 | | | | number | 1813 | | | | | 1814 | DH_GROUP_LIST | 511 | variable | Ordered list of DH | 1815 | | | | Group IDs supported | 1816 | | | | by a host | 1817 | | | | | 1818 | DIFFIE_HELLMAN | 513 | variable | public key | 1819 | | | | | 1820 | HIP_CIPHER | 579 | variable | List of HIP | 1821 | | | | encryption | 1822 | | | | algorithms | 1823 | | | | | 1824 | ENCRYPTED | 641 | variable | Encrypted part of a | 1825 | | | | HIP packet | 1826 | | | | | 1827 | HOST_ID | 705 | variable | Host Identity with | 1828 | | | | Fully-Qualified | 1829 | | | | Domain FQDN (Name) | 1830 | | | | or Network Access | 1831 | | | | Identifier (NAI) | 1832 | | | | | 1833 | HIT_SUITE_LIST | 715 | variable | Ordered list of the | 1834 | | | | HIT suites supported | 1835 | | | | by the Responder | 1836 | | | | | 1837 | CERT | 768 | variable | HI Certificate; used | 1838 | | | | to transfer | 1839 | | | | certificates. | 1840 | | | | Specified in a | 1841 | | | | separate docment. | 1842 | | | | | 1843 | NOTIFICATION | 832 | variable | Informational data | 1844 | | | | | 1845 | ECHO_REQUEST_SIGNED | 897 | variable | Opaque data to be | 1846 | | | | echoed back; signed | 1847 | | | | | 1848 | ECHO_RESPONSE_SIGNED | 961 | variable | Opaque data echoed | 1849 | | | | back by request; | 1850 | | | | signed | 1851 | | | | | 1852 | TRANSPORT_FORMAT_LIST | 2049 | Ordered | variable | 1853 | | | list of | | 1854 | | | preferred | | 1855 | | | HIP | | 1856 | | | transport | | 1857 | | | type | | 1858 | | | numbers | | 1859 | | | | | 1860 | HIP_MAC | 61505 | variable | HMAC-based message | 1861 | | | | authentication code, | 1862 | | | | with key material | 1863 | | | | from KEYMAT | 1864 | | | | | 1865 | HIP_MAC_2 | 61569 | variable | HMAC based message | 1866 | | | | authentication code, | 1867 | | | | with key material | 1868 | | | | from KEYMAT. Unlike | 1869 | | | | HIP_MAC, the HOST_ID | 1870 | | | | parameter is | 1871 | | | | included in | 1872 | | | | HIP_MAC_2 | 1873 | | | | calculation. | 1874 | | | | | 1875 | HIP_SIGNATURE_2 | 61633 | variable | Signature used in R1 | 1876 | | | | packet | 1877 | | | | | 1878 | HIP_SIGNATURE | 61697 | variable | Signature of the | 1879 | | | | packet | 1880 | | | | | 1881 | ECHO_REQUEST_UNSIGNED | 63661 | variable | Opaque data to be | 1882 | | | | echoed back; after | 1883 | | | | signature | 1884 | | | | | 1885 | ECHO_RESPONSE_UNSIGNED | 63425 | variable | Opaque data echoed | 1886 | | | | back by request; | 1887 | | | | after signature | 1888 +------------------------+-------+-----------+----------------------+ 1890 As the ordering (from lowest to highest) of HIP parameters is 1891 strictly enforced (see Section 5.2.1), the parameter type values for 1892 existing parameters have been spaced to allow for future protocol 1893 extensions. 1895 The following parameter type number ranges are defined. 1897 +---------------+---------------------------------------------------+ 1898 | Type Range | Purpose | 1899 +---------------+---------------------------------------------------+ 1900 | 0 - 1023 | Handshake | 1901 | | | 1902 | 1024 - 2047 | Reserved | 1903 | | | 1904 | 2048 - 4095 | Parameters related to HIP transport formats | 1905 | | | 1906 | 4096 - 8191 | Signed parameters allocated through specification | 1907 | | documents | 1908 | | | 1909 | 8192 - 32767 | Reserved | 1910 | | | 1911 | 32768 - 49151 | Free for experimentation. Signed parameters. | 1912 | | | 1913 | 49152 - 61439 | Reserved | 1914 | | | 1915 | 61440 - 62463 | Signatures and (signed) MACs | 1916 | | | 1917 | 62464 - 63487 | Parameters that are neither signed nor MACed | 1918 | | | 1919 | 63488 - 64511 | Rendezvous and relaying | 1920 | | | 1921 | 64512 - 65023 | Parameters that are neither signed nor MACed | 1922 | | | 1923 | 65024 - 65535 | Reserved | 1924 +---------------+---------------------------------------------------+ 1926 The process for defining new parameters is described in Section 5.2.2 1927 of this document. 1929 The range between 32768 (2^15) and 49151 (2^15 + 2^14) are free for 1930 experimentation. Types from this range SHOULD be selected in a 1931 random fashion to reduce the probability of collisions. 1933 5.2.1. TLV Format 1935 The TLV-encoded parameters are described in the following 1936 subsections. The type-field value also describes the order of these 1937 fields in the packet. The parameters MUST be included in the packet 1938 so that their types form an increasing order. If multiple parameters 1939 with the same type number are in one packet, the parameters with the 1940 same type MUST be consecutive in the packet. If the order does not 1941 follow this rule, the packet is considered to be malformed and it 1942 MUST be discarded. 1944 Parameters using type values from 2048 up to 4095 are related to 1945 transport formats. Currently, one transport format is defined: the 1946 ESP transport format [I-D.ietf-hip-rfc5202-bis]. 1948 All of the encoded TLV parameters have a length (that includes the 1949 Type and Length fields), which is a multiple of 8 bytes. When 1950 needed, padding MUST be added to the end of the parameter so that the 1951 total length is a multiple of 8 bytes. This rule ensures proper 1952 alignment of data. Any added padding bytes MUST be zeroed by the 1953 sender, and their values SHOULD NOT be checked by the receiver. 1955 The Length field indicates the length of the Contents field (in 1956 bytes). Consequently, the total length of the TLV parameter 1957 (including Type, Length, Contents, and Padding) is related to the 1958 Length field according to the following formula: 1960 Total Length = 11 + Length - (Length + 3) % 8; 1962 where % is the modulo operator 1964 0 1 2 3 1965 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 1966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1967 | Type |C| Length | 1968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1969 | | 1970 / Contents / 1971 / +-+-+-+-+-+-+-+-+ 1972 | | Padding | 1973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1975 Type Type code for the parameter. 16 bits long, C-bit 1976 being part of the Type code. 1977 C Critical. One if this parameter is critical, and 1978 MUST be recognized by the recipient, zero otherwise. 1979 The C bit is considered to be a part of the Type 1980 field. Consequently, critical parameters are always 1981 odd and non-critical ones have an even value. 1982 Length Length of the Contents, in bytes excluding Type, 1983 Length, and Padding. 1984 Contents Parameter specific, defined by Type 1985 Padding Padding, 0-7 bytes, added if needed 1987 Critical parameters (indicated by the odd type number) MUST be 1988 recognized by the recipient. If a recipient encounters a critical 1989 parameter that it does not recognize, it MUST NOT process the packet 1990 any further. It MAY send an ICMP or NOTIFY, as defined in 1991 Section 4.3. 1993 Non-critical parameters MAY be safely ignored. If a recipient 1994 encounters a non-critical parameter that it does not recognize, it 1995 SHOULD proceed as if the parameter was not present in the received 1996 packet. 1998 5.2.2. Defining New Parameters 2000 Future specifications may define new parameters as needed. When 2001 defining new parameters, care must be taken to ensure that the 2002 parameter type values are appropriate and leave suitable space for 2003 other future extensions. One must remember that the parameters MUST 2004 always be arranged in numerically increasing order by Type code, 2005 thereby limiting the order of parameters (see Section 5.2.1). 2007 The following rules MUST be followed when defining new parameters. 2009 1. The low-order bit C of the Type code is used to distinguish 2010 between critical and non-critical parameters. Hence, even 2011 parameter type numbers indicate non-critical parameters while odd 2012 parameter type numbers indicate critical parameters. 2014 2. A new parameter MAY be critical only if an old implementation 2015 that ignored it would cause security problems. In general, new 2016 parameters SHOULD be defined as non-critical, and expect a reply 2017 from the recipient. 2019 3. If a system implements a new critical parameter, it MUST provide 2020 the ability to set the associated feature off, such that the 2021 critical parameter is not sent at all. The configuration option 2022 MUST be well documented. Implementations operating in a mode 2023 adhering to this specification MUST disable the sending of new 2024 critical parameters by default. In other words, the management 2025 interface MUST allow vanilla standards-only mode as a default 2026 configuration setting, and MAY allow new critical payloads to be 2027 configured on (and off). 2029 4. See Section 9 for allocation rules regarding Type codes. 2031 5.2.3. R1_COUNTER 2032 0 1 2 3 2033 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 2034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2035 | Type | Length | 2036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2037 | Reserved, 4 bytes | 2038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2039 | R1 generation counter, 8 bytes | 2040 | | 2041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2043 Type 129 2044 Length 12 2045 R1 generation 2046 counter The current generation of valid puzzles 2048 The R1_COUNTER parameter contains a 64-bit unsigned integer in 2049 network-byte order, indicating the current generation of valid 2050 puzzles. The sender SHOULD increment this counter periodically. It 2051 is RECOMMENDED that the counter value is incremented at least as 2052 often as old PUZZLE values are deprecated so that SOLUTIONs to them 2053 are no longer accepted. 2055 Support for the R1_COUNTER parameter is mandatory although its 2056 inclusion in the R1 packet is optional. It SHOULD be included in the 2057 R1 (in which case, it is covered by the signature), and if present in 2058 the R1, it MUST be echoed (including the Reserved field verbatim) by 2059 the Initiator in the I2 packet. 2061 5.2.4. PUZZLE 2062 0 1 2 3 2063 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 2064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2065 | Type | Length | 2066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2067 | #K, 1 byte | Lifetime | Opaque, 2 bytes | 2068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2069 | Random #I, RHASH_len/8 bytes | 2070 / / 2071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2073 Type 257 2074 Length 4 + RHASH_len / 8 2075 #K #K is the number of verified bits 2076 Lifetime puzzle lifetime 2^(value-32) seconds 2077 Opaque data set by the Responder, indexing the puzzle 2078 Random #I random number of size RHASH_len bits 2080 Random #I is represented as a n-bit integer (where n is RHASH_len), 2081 #K and Lifetime as 8-bit integers, all in network byte order. 2083 The PUZZLE parameter contains the puzzle difficulty #K and a n-bit 2084 random integer #I. The Puzzle Lifetime indicates the time during 2085 which the puzzle solution is valid, and sets a time limit that should 2086 not be exceeded by the Initiator while it attempts to solve the 2087 puzzle. The lifetime is indicated as a power of 2 using the formula 2088 2^(Lifetime-32) seconds. A puzzle MAY be augmented with an 2089 ECHO_REQUEST_SIGNED or an ECHO_REQUEST_UNSIGNED parameter included in 2090 the R1; the contents of the echo request are then echoed back in the 2091 ECHO_RESPONSE_SIGNED or in the ECHO_RESPONSE_UNSIGNED parameter, 2092 allowing the Responder to use the included information as a part of 2093 its puzzle processing. 2095 The Opaque and Random #I field are not covered by the HIP_SIGNATURE_2 2096 parameter. 2098 5.2.5. SOLUTION 2099 0 1 2 3 2100 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 2101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2102 | Type | Length | 2103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2104 | #K, 1 byte | Reserved | Opaque, 2 bytes | 2105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2106 | Random #I, n bytes | 2107 / / 2108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2109 | Puzzle solution #J, RHASH_len/8 bytes | 2110 / / 2111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2113 Type 321 2114 Length 4 + RHASH_len /4 2115 #K #K is the number of verified bits 2116 Reserved zero when sent, ignored when received 2117 Opaque copied unmodified from the received PUZZLE 2118 parameter 2119 Random #I random number of size RHASH_len bits 2120 Puzzle solution #J random number of size RHASH_len bits 2122 Random #I and Random #J are represented as n-bit unsigned integers 2123 (where n is RHASH_len), #K as an 8-bit unsigned integer, all in 2124 network byte order. 2126 The SOLUTION parameter contains a solution to a puzzle. It also 2127 echoes back the random difficulty #K, the Opaque field, and the 2128 puzzle integer #I. 2130 5.2.6. DH_GROUP_LIST 2131 0 1 2 3 2132 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 2133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2134 | Type | Length | 2135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2136 | DH GROUP ID #1| DH GROUP ID #2| DH GROUP ID #3| DH GROUP ID #4| 2137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2138 | DH GROUP ID #n| Padding | 2139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2141 Type 511 2142 Length number of DH Group IDs 2143 DH GROUP ID identifies a DH GROUP ID supported by the host. 2144 The list of IDs is ordered by preference of the 2145 host. The possible DH Group IDs are defined 2146 in the DIFFIE_HELLMAN parameter. Each DH Group ID 2147 is one octet long. 2149 The DH_GROUP_LIST parameter contains the list of supported DH Group 2150 IDs of a host. The Initiator sends the DH_GROUP_LIST in the I1 2151 packet, the Responder sends its own list in the signed part of the R1 2152 packet. The DH Group IDs in the DH_GROUP_LIST are listed in the 2153 order of their preference of the host sending the list. DH Group IDs 2154 that are listed first are preferred over the DH Group IDs listed 2155 later. The information in the DH_GROUP_LIST allows the Responder to 2156 select the DH group preferred by itself and supported by the 2157 Initiator. Based on the DH_GROUP_LIST in the R1 packet, the 2158 Initiator can determine if the Responder has selected the best 2159 possible choice based on the Initiator's and Responder's preferences. 2160 If the Responder's choice differs from the best choice, the Initiator 2161 can conclude that there was an attempted downgrade attack (see 2162 Section 4.1.7). 2164 When selecting the DH group for the DIFFIE_HELLMAN parameter in the 2165 R1 packet, the Responder MUST select the first DH Group ID in its 2166 DH_GROUP_LIST in the R1 packet that is compatible with one of the 2167 Suite IDs in the Initiator's DH_GROUP_LIST in the I1 packet. The 2168 Responder MUST NOT select any other DH Group ID that is contained in 2169 both lists because a downgrade attack cannot be detected then. 2171 In general, hosts SHOULD prefer stronger groups over weaker ones if 2172 the computation overhead is not prohibitively high for the intended 2173 application. 2175 5.2.7. DIFFIE_HELLMAN 2177 0 1 2 3 2178 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 2179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2180 | Type | Length | 2181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2182 | Group ID | Public Value Length | Public Value / 2183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2184 / | 2185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2186 / | Padding | 2187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2189 Type 513 2190 Length length in octets, excluding Type, Length, and 2191 Padding 2192 Group ID identifies values for p and g as well as the KDF 2193 Public Value length of the following Public Value in octets 2194 Length 2195 Public Value the sender's public Diffie-Hellman key 2197 A single DIFFIE_HELLMAN parameter may be included in selected HIP 2198 packets based on the DH Group ID selected (Section 5.2.6). The 2199 following Group IDs have been defined: 2201 Group KDF Value 2202 Reserved 0 2203 DEPRECATED 1 2204 DEPRECATED 2 2205 1536-bit MODP group [RFC3526] HKDF [RFC5869] 3 2206 3072-bit MODP group [RFC3526] HKDF [RFC5869] 4 2207 DEPRECATED 5 2208 DEPRECATED 6 2209 NIST P-256 [RFC5903] HKDF [RFC5869] 7 2210 NIST P-384 [RFC5903] HKDF [RFC5869] 8 2211 NIST P-521 [RFC5903] HKDF [RFC5869] 9 2212 SECP160R1 [SECG] HKDF [RFC5869] 10 2213 2048-bit MODP group [RFC3526] HKDF [RFC5869] 11 2215 The MODP Diffie-Hellman groups are defined in [RFC3526]. The ECDH 2216 groups 7 - 9 are defined in [RFC5903] and [RFC6090]. ECDH group 10 2217 is covered in Appendix D. Any ECDH used with HIP MUST have a co- 2218 factor of 1. 2220 The Group ID also defines the key derivation function that is to be 2221 used for deriving the symmetric keys for the HMAC and symmetric 2222 encryption from the keying material from the Diffie Hellman key 2223 exchange (see Section 6.5). 2225 A HIP implementation MUST implement Group ID 3. The 160-bit 2226 SECP160R1 group can be used when lower security is enough (e.g., web 2227 surfing) and when the equipment is not powerful enough (e.g., some 2228 PDAs). Implementations SHOULD implement Group IDs 4 and 8. 2230 To avoid unnecessary failures during the base exchange, the rest of 2231 the groups SHOULD be implemented in hosts where resources are 2232 adequate. 2234 5.2.8. HIP_CIPHER 2236 0 1 2 3 2237 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 2238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2239 | Type | Length | 2240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2241 | Cipher ID #1 | Cipher ID #2 | 2242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2243 | Cipher ID #n | Padding | 2244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2246 Type 579 2247 Length length in octets, excluding Type, Length, and 2248 Padding 2249 Cipher ID identifies the cipher algorithm to be used for 2250 encrypting the contents of the ENCRYPTED parameter 2252 The following Cipher IDs are defined: 2254 Suite ID Value 2256 RESERVED 0 2257 NULL-ENCRYPT 1 ([RFC2410]) 2258 AES-128-CBC 2 ([RFC3602]) 2259 RESERVED 3 (unused value) 2260 AES-256-CBC 4 ([RFC3602]) 2262 The sender of a HIP_CIPHER parameter MUST make sure that there are no 2263 more than six (6) Cipher IDs in one HIP_CIPHER parameter. 2264 Conversely, a recipient MUST be prepared to handle received transport 2265 parameters that contain more than six Cipher IDs by accepting the 2266 first six Cipher IDs and dropping the rest. The limited number of 2267 Cipher IDs sets the maximum size of the HIP_CIPHER parameter. As the 2268 default configuration, the HIP_CIPHER parameter MUST contain at least 2269 one of the mandatory Cipher IDs. There MAY be a configuration option 2270 that allows the administrator to override this default. 2272 The Responder lists supported and desired Cipher IDs in order of 2273 preference in the R1, up to the maximum of six Cipher IDs. The 2274 Initiator MUST choose only one of the corresponding Cipher IDs. This 2275 Cipher ID will be used for generating the ENCRYPTED parameter. 2277 Mandatory implementation: AES-128-CBC. Implementors SHOULD support 2278 NULL-ENCRYPT for testing/debugging purposes, but MUST NOT offer or 2279 accept this value unless explicitly configured for testing/debugging 2280 of the HIP protocol. 2282 5.2.9. HOST_ID 2284 0 1 2 3 2285 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 2286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2287 | Type | Length | 2288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2289 | HI Length |DI-type| DI Length | 2290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2291 | Algorithm | Host Identity / 2292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2293 / | Domain Identifier / 2294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2295 / | Padding | 2296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2298 Type 705 2299 Length length in octets, excluding Type, Length, and 2300 Padding 2301 HI Length length of the Host Identity in octets 2302 DI-type type of the following Domain Identifier field 2303 DI Length length of the Domain Identifier field in octets 2304 Algorithm index to the employed algorithm 2305 Host Identity actual Host Identity 2306 Domain Identifier the identifier of the sender 2308 The following DI-types have been defined: 2310 Type Value 2311 none included 0 2312 FQDN 1 2313 NAI 2 2315 FQDN Fully Qualified Domain Name, in binary format. 2316 NAI Network Access Identifier 2318 The format for the FQDN is defined in RFC 1035 [RFC1035] Section 3.1. 2319 The format for the NAI is defined in [RFC4282] 2321 A host MAY optionally associate the Host Identity with a single 2322 Domain Identifier in the HOST_ID parameter. If there is no Domain 2323 Identifier, i.e., the DI-type field is zero, the DI Length field is 2324 set to zero as well. 2326 The following HI Algorithms have been defined: 2328 Algorithm 2329 profiles Values 2331 RESERVED 0 2332 DSA 3 [FIPS186-3] (RECOMMENDED) 2333 RSA 5 [RFC3447] (REQUIRED) 2334 ECDSA 7 [RFC4754] (REQUIRED) 2335 ECDSA_LOW 9 [SECG] (RECOMMENDED) 2337 For DSA, RSA, and ECDSA key types, profiles containing at least 112 2338 bits of security strength (as defined by [NIST.800-131A.2011]) should 2339 be used. For RSA signature padding, the PSS method of padding 2340 [RFC3447] MUST be used. 2342 The Host Identity is derived from the DNSKEY format for RSA and DSA. 2343 For these, the Public Key field of the RDATA part from RFC 4034 2344 [RFC4034] is used. For ECC we distinguish two different profiles: 2345 ECDSA and ECDSA_LOW. ECC contains curves approved by NIST and 2346 defined in RFC 4754 [RFC4754]. ECDSA_LOW is defined for devices with 2347 low computational capabilities and uses shorter curves from SECG 2348 [SECG]. Any ECDSA used with HIP MUST have a co-factor of 1. 2350 For ECDSA and ECDSA_LOW Host Identities are represented by the 2351 following fields: 2353 0 1 2 3 2354 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 2355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2356 | ECC Curve | / 2357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2358 / Public Key | 2359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2361 ECC Curve Curve label 2362 Public Key Represented in Octet-string format 2363 [RFC6090] 2365 For hosts that implement ECDSA as algorithm the following ECC curves 2366 are required: 2368 Algorithm Curve Values 2370 ECDSA RESERVED 0 2371 ECDSA NIST P-256 1 [RFC4754] 2372 ECDSA NIST P-384 2 [RFC4754] 2374 For hosts that implement the ECDSA_LOW algorithm profile, the 2375 following curve is required: 2377 Algorithm Curve Values 2379 ECDSA_LOW RESERVED 0 2380 ECDSA_LOW SECP160R1 1 [SECG] 2382 5.2.10. HIT_SUITE_LIST 2384 The HIT_SUITE_LIST parameter contains a list of the supported HIT 2385 Suite IDs of the Responder. The Responder sends the HIT_SUITE_LIST 2386 in the signed part of the R1 packet. Based on the HIT_SUITE_LIST, 2387 the Initiator can determine which source HIT Suite IDs are supported 2388 by the Responder. 2390 0 1 2 3 2391 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 2392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2393 | Type | Length | 2394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2395 | ID #1 | ID #2 | ID #3 | ID #4 | 2396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2397 | ID #n | Padding | 2398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2400 Type 715 2401 Length number of HIT Suite IDs 2402 ID identifies a HIT Suite ID supported by the host. 2403 The list of IDs is ordered by preference of the 2404 host. Each HIT Suite ID is one octet long. The four 2405 higher-order bits of the ID field correspond to the 2406 HIT Suite ID in the ORCHID OGA field. The four 2407 lower-order bits are reserved and set to 0 and 2408 ignored by the receiver. 2410 The HIT Suite ID indexes a HIT Suite. HIT Suites are composed of 2411 signature algorithms as defined in Section 5.2.9 and hash functions. 2413 The ID field in the HIT_SUITE_LIST is defined as eight-bit field as 2414 opposed to the four-bit HIT Suite ID and OGA field in the ORCHID. 2415 This difference is a measure to accommodate larger HIT Suite IDs if 2416 the 16 available values prove insufficient. In that case, one of the 2417 16 values, zero, will be used to indicate that four additional bits 2418 of the ORCHID will be used to encode the HIT Suite ID. Hence, the 2419 current four-bit HIT Suite-IDs only use the four higher order bits in 2420 the ID field. Future documents may define the use of the four lower- 2421 order bits in the ID field. 2423 The following HIT Suites ID are defined: 2425 HIT Suite ID 2426 RESERVED 0 2427 RSA,DSA/SHA-256 1 (REQUIRED) 2428 ECDSA/SHA-384 2 (RECOMMENDED) 2429 ECDSA_LOW/SHA-1 3 (RECOMMENDED) 2431 5.2.11. TRANSPORT_FORMAT_LIST 2433 The TRANSPORT_FORMAT_LIST parameter contains a list of the supported 2434 HIP transport formats (TFs) of the Responder. The Responder sends 2435 the TRANSPORT_FORMAT_LIST in the signed part of the R1 packet. Based 2436 on the TRANSPORT_FORMAT_LIST, the Initiator chooses one suitable 2437 transport format and includes the respective HIP transport format 2438 parameter in its response packet. 2440 0 1 2 3 2441 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 2442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2443 | Type | Length | 2444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2445 | TF type #1 | TF type #2 / 2446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2447 / TF type #n | Padding | 2448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2450 Type 2049 2451 Length 2x number of TF types 2452 TF Type identifies a transport format (TF) type supported by 2453 the host. The TF type numbers correspond to the HIP 2454 parameter type numbers of the respective transport 2455 format 2456 parameters. The list of TF types is ordered by 2457 preference of the sender 2459 The TF type numbers index the respective HIP parameters for the 2460 transport formats in the type number range between 2050 to 4095. The 2461 parameters and their use are defined in separate documents. 2462 Currently, the only transport format defined is IPsec ESP 2463 [I-D.ietf-hip-rfc5202-bis]. 2465 For each listed TF type, the sender of the TRANSPORT_FORMAT_LIST 2466 parameter MUST include the respective transport format parameter in 2467 the HIP packet. The receiver MUST ignore the TF type in the 2468 TRANSPORT_FORMAT_LIST if no matching transport format parameter is 2469 present in the packet. 2471 5.2.12. HIP_MAC 2472 0 1 2 3 2473 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 2474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2475 | Type | Length | 2476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2477 | | 2478 | HMAC | 2479 / / 2480 / +-------------------------------+ 2481 | | Padding | 2482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2484 Type 61505 2485 Length length in octets, excluding Type, Length, and 2486 Padding 2487 HMAC HMAC computed over the HIP packet, excluding the 2488 HIP_MAC parameter and any following parameters, such 2489 as HIP_SIGNATURE, HIP_SIGNATURE_2, 2490 ECHO_REQUEST_UNSIGNED, or ECHO_RESPONSE_UNSIGNED. 2491 The checksum field MUST be set to zero and the HIP 2492 header length in the HIP common header MUST be 2493 calculated not to cover any excluded parameters 2494 when the HMAC is calculated. The size of the 2495 HMAC is the natural size of the hash computation 2496 output depending on the used hash function. 2498 The HMAC uses RHASH as hash algorithm. The calculation and 2499 verification process is presented in Section 6.4.1. 2501 5.2.13. HIP_MAC_2 2503 The HIP_MAC_2 is a MAC of the packet and the HI of the sender in the 2504 form of a HOST_ID parameter when that parameter is not actually 2505 included in the packet. The parameter structure is the same as in 2506 Section 5.2.12. The fields are: 2508 Type 61569 2509 Length length in octets, excluding Type, Length, and 2510 Padding 2511 HMAC HMAC computed over the HIP packet, excluding the 2512 HIP_MAC_2 parameter and any following parameters 2513 such as HIP_SIGNATURE, HIP_SIGNATURE_2, 2514 ECHO_REQUEST_UNSIGNED, or ECHO_RESPONSE_UNSIGNED, 2515 and including an additional sender's HOST_ID 2516 parameter during the HMAC calculation. The checksum 2517 field MUST be set to zero and the HIP header length 2518 in the HIP common header MUST be calculated not to 2519 cover any excluded parameters when the HMAC is 2520 calculated. The size of the HMAC is the natural 2521 size of the hash computation output depending on the 2522 used hash function. 2524 The HMAC uses RHASH as hash algorithm. The calculation and 2525 verification process is presented in Section 6.4.1. 2527 5.2.14. HIP_SIGNATURE 2529 0 1 2 3 2530 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 2531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2532 | Type | Length | 2533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2534 | SIG alg | Signature / 2535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2536 / | Padding | 2537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2539 Type 61697 2540 Length length in octets, excluding Type, Length, and 2541 Padding 2542 SIG alg signature algorithm 2543 Signature the signature is calculated over the HIP packet, 2544 excluding the HIP_SIGNATURE parameter and any 2545 parameters that follow the HIP_SIGNATURE parameter. 2546 When the signature is calculated the checksum field 2547 MUST be set to zero, and the HIP header length in 2548 the HIP common header MUST be calculated only up to 2549 the beginning of the HIP_SIGNATURE parameter. 2551 The signature algorithms are defined in Section 5.2.9. The signature 2552 in the Signature field is encoded using the method depending on the 2553 signature algorithm (e.g., according to [RFC3110] in case of RSA/SHA- 2554 1, according to [RFC5702] in case of RSA/SHA-256, according to 2556 [RFC2536] in case of DSA, or according to [RFC6090] in case of 2557 ECDSA). 2559 The HIP_SIGNATURE calculation and verification process are presented 2560 in Section 6.4.2. 2562 5.2.15. HIP_SIGNATURE_2 2564 The HIP_SIGNATURE_2 excludes the variable parameters in the R1 packet 2565 to allow R1 pre-creation. The parameter structure is the same as in 2566 Section 5.2.14. The fields are: 2568 Type 61633 2569 Length length in octets, excluding Type, Length, and 2570 Padding 2571 SIG alg signature algorithm 2572 Signature Within the R1 packet that contains the 2573 HIP_SIGNATURE_2 parameter, the Initiator's HIT, the 2574 checksum field, and the Opaque and Random #I fields 2575 in the PUZZLE parameter MUST be set to zero while 2576 computing the HIP_SIGNATURE_2 signature. Further, 2577 the HIP packet length in the HIP header MUST be 2578 adjusted as if the HIP_SIGNATURE_2 was not in the 2579 packet during the signature calculation, i.e., the 2580 HIP packet length points to the beginning of 2581 the HIP_SIGNATURE_2 parameter during signing and 2582 verification. 2584 Zeroing the Initiator's HIT makes it possible to create R1 packets 2585 beforehand, to minimize the effects of possible DoS attacks. Zeroing 2586 the Random #I and Opaque fields within the PUZZLE parameter allows 2587 these fields to be populated dynamically on precomputed R1s. 2589 Signature calculation and verification follows the process defined in 2590 Section 6.4.2. 2592 5.2.16. SEQ 2594 0 1 2 3 2595 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 2596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2597 | Type | Length | 2598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2599 | Update ID | 2600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2601 Type 385 2602 Length 8 2603 Update ID 32-bit sequence number 2605 The Update ID is an unsigned number in network byte order, 2606 initialized by a host to zero upon moving to ESTABLISHED state. The 2607 Update ID has scope within a single HIP association, and not across 2608 multiple associations or multiple hosts. The Update ID is 2609 incremented by one before each new UPDATE that is sent by the host; 2610 the first UPDATE packet originated by a host has an Update ID of 0. 2612 5.2.17. ACK 2614 0 1 2 3 2615 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 2616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2617 | Type | Length | 2618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2619 | peer Update ID 1 | 2620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2621 / peer Update ID n | 2622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2624 Type 449 2625 Length length in octets, excluding Type and Length 2626 peer Update ID 32-bit sequence number corresponding to the 2627 Update ID being ACKed. 2629 The ACK parameter includes one or more Update IDs that have been 2630 received from the peer. The number of peer Update IDs can be 2631 inferred from the length by dividing it by 4. 2633 5.2.18. ENCRYPTED 2634 0 1 2 3 2635 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 2636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2637 | Type | Length | 2638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2639 | Reserved | 2640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2641 | IV / 2642 / / 2643 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 2645 / Encrypted data / 2646 / / 2647 / +-------------------------------+ 2648 / | Padding | 2649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2651 Type 641 2652 Length length in octets, excluding Type, Length, and 2653 Padding 2654 Reserved zero when sent, ignored when received 2655 IV Initialization vector, if needed, otherwise 2656 nonexistent. The length of the IV is inferred from 2657 the HIP_CIPHER. 2658 Encrypted The data is encrypted using the encryption algorithm 2659 data defined in the HIP_CIPHER parameter. 2661 The ENCRYPTED parameter encapsulates other parameters, the encrypted 2662 data, which holds one or more HIP parameters in block encrypted form. 2664 Consequently, the first fields in the encapsulated parameter(s) are 2665 Type and Length of the first such parameter, allowing the contents to 2666 be easily parsed after decryption. 2668 The field labeled "Encrypted data" consists of the output of one or 2669 more HIP parameters concatenated together that have been passed 2670 through an encryption algorithm. Each of these inner parameters is 2671 padded according to the rules of Section 5.2.1 for padding individual 2672 parameters. As a result, the concatenated parameters will be a block 2673 of data that is 8-byte aligned. 2675 Some encryption algorithms require that the data to be encrypted must 2676 be a multiple of the cipher algorithm block size. In this case, the 2677 above block of data MUST include additional padding, as specified by 2678 the encryption algorithm. The size of the extra padding is selected 2679 so that the length of the unencrypted data block is a multiple of the 2680 cipher block size. The encryption algorithm may specify padding 2681 bytes other than zero; for example, AES [FIPS.197.2001] uses the 2682 PKCS5 padding scheme (see section 6.1.1 of [RFC2898]) where the 2683 remaining n bytes to fill the block each have the value of n. This 2684 yields an "unencrypted data" block that is transformed to an 2685 "encrypted data" block by the cipher suite. This extra padding added 2686 to the set of parameters to satisfy the cipher block alignment rules 2687 is not counted in HIP TLV length fields, and this extra padding 2688 should be removed by the cipher suite upon decryption. 2690 Note that the length of the cipher suite output may be smaller or 2691 larger than the length of the set of parameters to be encrypted, 2692 since the encryption process may compress the data or add additional 2693 padding to the data. 2695 Once this encryption process is completed, the Encrypted data field 2696 is ready for inclusion in the parameter. If necessary, additional 2697 Padding for 8-byte alignment is then added according to the rules of 2698 Section 5.2.1. 2700 5.2.19. NOTIFICATION 2702 The NOTIFICATION parameter is used to transmit informational data, 2703 such as error conditions and state transitions, to a HIP peer. A 2704 NOTIFICATION parameter may appear in NOTIFY packets. The use of the 2705 NOTIFICATION parameter in other packet types is for further study. 2707 0 1 2 3 2708 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 2709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2710 | Type | Length | 2711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2712 | Reserved | Notify Message Type | 2713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2714 | / 2715 / Notification Data / 2716 / +---------------+ 2717 / | Padding | 2718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2720 Type 832 2721 Length length in octets, excluding Type, Length, and 2722 Padding 2723 Reserved zero when sent, ignored when received 2724 Notify Message specifies the type of notification 2725 Type 2726 Notification informational or error data transmitted in addition 2727 Data to the Notify Message Type. Values for this field 2728 are type specific (see below). 2729 multiple of 8 bytes. 2731 Notification information can be error messages specifying why an HIP 2732 Security Association could not be established. It can also be status 2733 data that a HIP implementation wishes to communicate with a peer 2734 process. The table below lists the notification messages and their 2735 Notification Message Types. HIP packets MAY contain multiple 2736 NOTIFICATION parameters if several problems exist or several 2737 independent pieces of information must be transmitted. 2739 To avoid certain types of attacks, a Responder SHOULD avoid sending a 2740 NOTIFICATION to any host with which it has not successfully verified 2741 a puzzle solution. 2743 Notify Message Types in the range 0-16383 are intended for reporting 2744 errors and in the range 16384-65535 for other status information. An 2745 implementation that receives a NOTIFY packet with a Notify Message 2746 Type that indicates an error in response to a request packet (e.g., 2747 I1, I2, UPDATE) SHOULD assume that the corresponding request has 2748 failed entirely. Unrecognized error types MUST be ignored except 2749 that they SHOULD be logged. 2751 As currently defined, Notify Message Type values 1-10 are used for 2752 informing about errors in packet structures, values 11-20 for 2753 informing about problems in parameters. 2755 Notification Data in NOTIFICATION parameters where the Notify Message 2756 Type is in the status range MUST be ignored if not recognized. 2758 Notify Message Types - Errors Value 2759 ----------------------------- ----- 2761 UNSUPPORTED_CRITICAL_PARAMETER_TYPE 1 2763 Sent if the parameter type has the "critical" bit set and the 2764 parameter type is not recognized. Notification Data contains the 2765 two-octet parameter type. 2767 INVALID_SYNTAX 7 2769 Indicates that the HIP message received was invalid because some 2770 type, length, or value was out of range or because the request 2771 was otherwise malformed. To avoid a denial-of-service 2772 attack using forged messages, this status may only be returned 2773 for packets whose HIP_MAC (if present) and SIGNATURE have been 2774 verified. This status MUST be sent in response to any error not 2775 covered by one of the other status types, and SHOULD NOT contain 2776 details to avoid leaking information to someone probing a node. 2777 To aid debugging, more detailed error information SHOULD be 2778 written to a console or log. 2780 NO_DH_PROPOSAL_CHOSEN 14 2782 None of the proposed group IDs was acceptable. 2784 INVALID_DH_CHOSEN 15 2786 The DH Group ID field does not correspond to one offered 2787 by the Responder. 2789 NO_HIP_PROPOSAL_CHOSEN 16 2791 None of the proposed HIT Suites or HIP Encryption Algorithms was 2792 acceptable. 2794 INVALID_HIP_CIPHER_CHOSEN 17 2796 The HIP_CIPHER Crypto ID does not correspond to one offered by 2797 the Responder. 2799 UNSUPPORTED_HIT_SUITE 20 2801 Sent in response to an I1 or R1 packet for which the HIT suite 2802 is not supported. 2804 AUTHENTICATION_FAILED 24 2806 Sent in response to a HIP signature failure, except when 2807 the signature verification fails in a NOTIFY message. 2809 CHECKSUM_FAILED 26 2811 Sent in response to a HIP checksum failure. 2813 HIP_MAC_FAILED 28 2815 Sent in response to a HIP HMAC failure. 2817 ENCRYPTION_FAILED 32 2819 The Responder could not successfully decrypt the 2820 ENCRYPTED parameter. 2822 INVALID_HIT 40 2824 Sent in response to a failure to validate the peer's 2825 HIT from the corresponding HI. 2827 BLOCKED_BY_POLICY 42 2828 The Responder is unwilling to set up an association 2829 for some policy reason (e.g., received HIT is NULL 2830 and policy does not allow opportunistic mode). 2832 RESPONDER_BUSY_PLEASE_RETRY 44 2834 The Responder is unwilling to set up an association as it is 2835 suffering under some kind of overload and has chosen to shed load 2836 by rejecting the Initiator's request. The Initiator may retry; 2837 however, the Initiator MUST find another (different) puzzle 2838 solution for any such retries. Note that the Initiator may need 2839 to obtain a new puzzle with a new I1/R1 exchange. 2841 Notify Message Types - Status Value 2842 ----------------------------- ----- 2844 I2_ACKNOWLEDGEMENT 16384 2846 The Responder has an I2 packet from the Initiator but had to 2847 queue the I2 packet for processing. The puzzle was correctly 2848 solved and the Responder is willing to set up an association but 2849 currently has a number of I2 packets in the processing queue. 2850 The R2 packet is sent after the I2 packet was processed. 2852 5.2.20. ECHO_REQUEST_SIGNED 2854 0 1 2 3 2855 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 2856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2857 | Type | Length | 2858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2859 | Opaque data (variable length) | 2860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2862 Type 897 2863 Length length of the opaque data in octets 2864 Opaque data opaque data, supposed to be meaningful only to the 2865 node that sends ECHO_REQUEST_SIGNED and receives a 2866 corresponding ECHO_RESPONSE_SIGNED or 2867 ECHO_RESPONSE_UNSIGNED. 2869 The ECHO_REQUEST_SIGNED parameter contains an opaque blob of data 2870 that the sender wants to get echoed back in the corresponding reply 2871 packet. 2873 The ECHO_REQUEST_SIGNED and corresponding echo response parameters 2874 MAY be used for any purpose where a node wants to carry some state in 2875 a request packet and get it back in a response packet. The 2876 ECHO_REQUEST_SIGNED is covered by the HIP_MAC and SIGNATURE. A HIP 2877 packet can contain only one ECHO_REQUEST_SIGNED parameter and MAY 2878 contain multiple ECHO_REQUEST_UNSIGNED parameters. The 2879 ECHO_REQUEST_SIGNED parameter MUST be responded to with an 2880 ECHO_RESPONSE_SIGNED. 2882 5.2.21. ECHO_REQUEST_UNSIGNED 2884 0 1 2 3 2885 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 2886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2887 | Type | Length | 2888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2889 | Opaque data (variable length) | 2890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2892 Type 63661 2893 Length length of the opaque data in octets 2894 Opaque data opaque data, supposed to be meaningful only to the 2895 node that sends ECHO_REQUEST_UNSIGNED and receives a 2896 corresponding ECHO_RESPONSE_UNSIGNED. 2898 The ECHO_REQUEST_UNSIGNED parameter contains an opaque blob of data 2899 that the sender wants to get echoed back in the corresponding reply 2900 packet. 2902 The ECHO_REQUEST_UNSIGNED and corresponding echo response parameters 2903 MAY be used for any purpose where a node wants to carry some state in 2904 a request packet and get it back in a response packet. The 2905 ECHO_REQUEST_UNSIGNED is not covered by the HIP_MAC and SIGNATURE. A 2906 HIP packet can contain one or more ECHO_REQUEST_UNSIGNED parameters. 2907 It is possible that middleboxes add ECHO_REQUEST_UNSIGNED parameters 2908 in HIP packets passing by. The creator of the ECHO_REQUEST_UNSIGNED 2909 (end-host or middlebox) has to create the Opaque field so that it can 2910 later identify and remove the corresponding ECHO_RESPONSE_UNSIGNED 2911 parameter. 2913 The ECHO_REQUEST_UNSIGNED parameter MUST be responded to with an 2914 ECHO_RESPONSE_UNSIGNED parameter. 2916 5.2.22. ECHO_RESPONSE_SIGNED 2917 0 1 2 3 2918 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 2919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2920 | Type | Length | 2921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2922 | Opaque data (variable length) | 2923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2925 Type 961 2926 Length length of the opaque data in octets 2927 Opaque data opaque data, copied unmodified from the 2928 ECHO_REQUEST_SIGNED or ECHO_REQUEST_UNSIGNED 2929 parameter that triggered this response. 2931 The ECHO_RESPONSE_SIGNED parameter contains an opaque blob of data 2932 that the sender of the ECHO_REQUEST_SIGNED wants to get echoed back. 2933 The opaque data is copied unmodified from the ECHO_REQUEST_SIGNED 2934 parameter. 2936 The ECHO_REQUEST_SIGNED and ECHO_RESPONSE_SIGNED parameters MAY be 2937 used for any purpose where a node wants to carry some state in a 2938 request packet and get it back in a response packet. The 2939 ECHO_RESPONSE_SIGNED is covered by the HIP_MAC and SIGNATURE. 2941 5.2.23. ECHO_RESPONSE_UNSIGNED 2943 0 1 2 3 2944 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 2945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2946 | Type | Length | 2947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2948 | Opaque data (variable length) | 2949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2951 Type 63425 2952 Length length of the opaque data in octets 2953 Opaque data opaque data, copied unmodified from the 2954 ECHO_REQUEST_SIGNED or ECHO_REQUEST_UNSIGNED 2955 parameter that triggered this response. 2957 The ECHO_RESPONSE_UNSIGNED parameter contains an opaque blob of data 2958 that the sender of the ECHO_REQUEST_SIGNED or ECHO_REQUEST_UNSIGNED 2959 wants to get echoed back. The opaque data is copied unmodified from 2960 the corresponding echo request parameter. 2962 The echo request and ECHO_RESPONSE_UNSIGNED parameters MAY be used 2963 for any purpose where a node wants to carry some state in a request 2964 packet and get it back in a response packet. The 2965 ECHO_RESPONSE_UNSIGNED is not covered by the HIP_MAC and SIGNATURE. 2967 5.3. HIP Packets 2969 There are eight basic HIP packets (see Table 10). Four are for the 2970 HIP base exchange, one is for updating, one is for sending 2971 notifications, and two are for closing a HIP association. Support 2972 for NOTIFY packet type is optional, but support for all other HIP 2973 packet types listed below is mandatory. 2975 +------------------+------------------------------------------------+ 2976 | Packet type | Packet name | 2977 +------------------+------------------------------------------------+ 2978 | 1 | I1 - the HIP Initiator Packet | 2979 | | | 2980 | 2 | R1 - the HIP Responder Packet | 2981 | | | 2982 | 3 | I2 - the Second HIP Initiator Packet | 2983 | | | 2984 | 4 | R2 - the Second HIP Responder Packet | 2985 | | | 2986 | 16 | UPDATE - the HIP Update Packet | 2987 | | | 2988 | 17 | NOTIFY - the HIP Notify Packet | 2989 | | | 2990 | 18 | CLOSE - the HIP Association Closing Packet | 2991 | | | 2992 | 19 | CLOSE_ACK - the HIP Closing Acknowledgment | 2993 | | Packet | 2994 +------------------+------------------------------------------------+ 2996 Table 10: HIP packets and packet type values 2998 Packets consist of the fixed header as described in Section 5.1, 2999 followed by the parameters. The parameter part, in turn, consists of 3000 zero or more TLV-coded parameters. 3002 In addition to the base packets, other packet types may be defined 3003 later in separate specifications. For example, support for mobility 3004 and multi-homing is not included in this specification. 3006 See Notation (Section 2.2) for the notation used in the operations. 3008 In the future, an optional upper-layer payload MAY follow the HIP 3009 header. The Next Header field in the header indicates if there is 3010 additional data following the HIP header. The HIP packet, however, 3011 MUST NOT be fragmented into multiple extension headers by setting the 3012 Next Header field in a HIP header to the HIP protocol number. This 3013 limits the size of the possible additional data in the packet. 3015 5.3.1. I1 - the HIP Initiator Packet 3017 The HIP header values for the I1 packet: 3019 Header: 3020 Packet Type = 1 3021 SRC HIT = Initiator's HIT 3022 DST HIT = Responder's HIT, or NULL 3024 IP ( HIP ( DH_GROUP_LIST ) ) 3026 The I1 packet contains the fixed HIP header and the Initiator's 3027 DH_GROUP_LIST. 3029 Valid control bits: none 3031 The Initiator receives the Responder's HIT either from a DNS lookup 3032 of the Responder's FQDN (see 5205-bis), from some other repository, 3033 or from a local table. If the Initiator does not know the 3034 Responder's HIT, it may attempt to use opportunistic mode by using 3035 NULL (all zeros) as the Responder's HIT. See also "HIP Opportunistic 3036 Mode" (Section 4.1.8). 3038 Since the I1 packet is so easy to spoof even if it were signed, no 3039 attempt is made to add to its generation or processing cost. 3041 The Initiator includes a DH_GROUP_LIST parameter in the I1 packet to 3042 inform the Responder of its preferred DH Group IDs. Note that the 3043 DH_GROUP_LIST in the I1 packet is not protected by a signature. 3045 Implementations MUST be able to handle a storm of received I1 3046 packets, discarding those with common content that arrive within a 3047 small time delta. 3049 5.3.2. R1 - the HIP Responder Packet 3051 The HIP header values for the R1 packet: 3053 Header: 3054 Packet Type = 2 3055 SRC HIT = Responder's HIT 3056 DST HIT = Initiator's HIT 3058 IP ( HIP ( [ R1_COUNTER, ] 3059 PUZZLE, 3060 DIFFIE_HELLMAN, 3061 HIP_CIPHER, 3062 HOST_ID, 3063 HIT_SUITE_LIST, 3064 DH_GROUP_LIST, 3065 [ ECHO_REQUEST_SIGNED, ] 3066 TRANSPORT_FORMAT_LIST, 3067 HIP_SIGNATURE_2 ) 3068 <, ECHO_REQUEST_UNSIGNED >i) 3070 Valid control bits: A 3072 If the Responder's HI is an anonymous one, the A control MUST be set. 3074 The Initiator's HIT MUST match the one received in the I1 packet if 3075 the R1 is a response to an I1. If the Responder has multiple HIs, 3076 the Responder's HIT used MUST match Initiator's request. If the 3077 Initiator used opportunistic mode, the Responder may select freely 3078 among its HIs. See also "HIP Opportunistic Mode" (Section 4.1.8). 3080 The R1 packet generation counter is used to determine the currently 3081 valid generation of puzzles. The value is increased periodically, 3082 and it is RECOMMENDED that it is increased at least as often as 3083 solutions to old puzzles are no longer accepted. 3085 The Puzzle contains a Random #I and the difficulty #K. The 3086 difficulty #K indicates the number of lower-order bits, in the puzzle 3087 hash result, that must be zeros; see Section 4.1.2. The Random #I is 3088 not covered by the signature and must be zeroed during the signature 3089 calculation, allowing the sender to select and set the #I into a 3090 precomputed R1 packet just prior sending it to the peer. 3092 The Responder selects the Diffie-Hellman public value based on the 3093 Initiator's preference expressed in the DH_GROUP_LIST parameter in 3094 the I1 packet. The Responder sends back its own preference based on 3095 which it chose the DH public value as DH_GROUP_LIST. This allows the 3096 Initiator to determine whether its own DH_GROUP_LIST in the sent I1 3097 packet was manipulated by an attacker. 3099 The Diffie-Hellman public value is ephemeral, and values SHOULD NOT 3100 be reused across different HIP associations. Once the Responder has 3101 received a valid response to an R1 packet, that Diffie-Hellman value 3102 SHOULD be deprecated. It is possible that the Responder has sent the 3103 same Diffie-Hellman value to different hosts simultaneously in 3104 corresponding R1 packets and those responses should also be accepted. 3105 However, as a defense against I1 packet storms, an implementation MAY 3106 propose, and re-use unless avoidable, the same Diffie-Hellman value 3107 for a period of time, for example, 15 minutes. By using a small 3108 number of different puzzles for a given Diffie-Hellman value, the R1 3109 packets can be precomputed and delivered as quickly as I1 packets 3110 arrive. A scavenger process should clean up unused Diffie-Hellman 3111 values and puzzles. 3113 Re-using Diffie-Hellman public values opens up the potential security 3114 risk of more than one Initiator ending up with the same keying 3115 material (due to faulty random number generators). Also, more than 3116 one Initiator using the same Responder public key half may lead to 3117 potentially easier cryptographic attacks and to imperfect forward 3118 security. 3120 However, these risks involved in re-using the same public value are 3121 statistical; that is, the authors are not aware of any mechanism that 3122 would allow manipulation of the protocol so that the risk of the re- 3123 use of any given Responder Diffie-Hellman public key would differ 3124 from the base probability. Consequently, it is RECOMMENDED that 3125 Responders avoid re-using the same DH key with multiple Initiators, 3126 but because the risk is considered statistical and not known to be 3127 manipulable, the implementations MAY re-use a key in order to ease 3128 resource-constrained implementations and to increase the probability 3129 of successful communication with legitimate clients even under an I1 3130 packet storm. In particular, when it is too expensive to generate 3131 enough precomputed R1 packets to supply each potential Initiator with 3132 a different DH key, the Responder MAY send the same DH key to several 3133 Initiators, thereby creating the possibility of multiple legitimate 3134 Initiators ending up using the same Responder-side public key. 3135 However, as soon as the Responder knows that it will use a particular 3136 DH key, it SHOULD stop offering it. This design is aimed to allow 3137 resource-constrained Responders to offer services under I1 packet 3138 storms and to simultaneously make the probability of DH key re-use 3139 both statistical and as low as possible. 3141 If the Responder uses the same DH keypair for multiple handshakes, it 3142 must take care to avoid small subgroup attacks [RFC2785]. To avoid 3143 these attacks, when receiving the I2 message, the Responder SHOULD 3144 validate the Initiators DH public key as described in [RFC2785] 3145 Section 3.1. In case the validation fails, the Responder MUST NOT 3146 generate a DH shared key and MUST silently abort the HIP BEX. 3148 The HIP_CIPHER contains the encryption algorithms supported by the 3149 Responder to encrypt the contents of the ENCRYPTED parameter, in the 3150 order of preference. All implementations MUST support AES [RFC3602]. 3152 The HIT_SUITE_LIST parameter is an ordered list of the Responder's 3153 preferred and supported HIT Suites. The list allows the Initiator to 3154 determine whether its own source HIT matches any suite supported by 3155 the Responder. 3157 The ECHO_REQUEST_SIGNED and ECHO_REQUEST_UNSIGNED parameters contain 3158 data that the sender wants to receive unmodified in the corresponding 3159 response packet in the ECHO_RESPONSE_SIGNED or ECHO_RESPONSE_UNSIGNED 3160 parameter. The R1 packet may contain zero or more 3161 ECHO_REQUEST_UNSIGNED parameters as described in 3162 Section Section 5.2.21. 3164 The TRANSPORT_FORMAT_LIST parameter is an ordered list of the 3165 Responder's preferred and supported transport format types. The list 3166 allows the Initiator and the Responder to agree on a common type for 3167 payload protection. This parameter is described in Section 5.2.11. 3169 The signature is calculated over the whole HIP packet as described in 3170 Section 5.2.15. This allows the Responder to use precomputed R1s. 3171 The Initiator SHOULD validate this signature. It MUST check that the 3172 Responder's HI matches with the one expected, if any. 3174 5.3.3. I2 - the Second HIP Initiator Packet 3176 The HIP header values for the I2 packet: 3178 Header: 3179 Type = 3 3180 SRC HIT = Initiator's HIT 3181 DST HIT = Responder's HIT 3183 IP ( HIP ( [R1_COUNTER,] 3184 SOLUTION, 3185 DIFFIE_HELLMAN, 3186 HIP_CIPHER, 3187 ENCRYPTED { HOST_ID } or HOST_ID, 3188 [ ECHO_RESPONSE_SIGNED ,] 3189 TRANSPORT_FORMAT_LIST, 3190 HIP_MAC, 3191 HIP_SIGNATURE 3192 <, ECHO_RESPONSE_UNSIGNED>i ) ) 3194 Valid control bits: A 3195 The HITs used MUST match the ones used in the R1. 3197 If the Initiator's HI is an anonymous one, the A control bit MUST be 3198 set. 3200 If present in the I1 packet, the Initiator MUST include an unmodified 3201 copy of the R1_COUNTER parameter received in the corresponding R1 3202 packet into the I2 packet. 3204 The Solution contains the Random #I from R1 and the computed #J. The 3205 low-order #K bits of the RHASH(I | ... | J) MUST be zero. 3207 The Diffie-Hellman value is ephemeral. If precomputed, a scavenger 3208 process should clean up unused Diffie-Hellman values. The Responder 3209 MAY re-use Diffie-Hellman values under some conditions as specified 3210 in Section 5.3.2. 3212 The HIP_CIPHER contains the single encryption suite selected by the 3213 Initiator, that it uses to encrypt the ENCRYPTED parameters. The 3214 chosen cipher MUST correspond to one of the ciphers offered by the 3215 Responder in the R1. All implementations MUST support AES [RFC3602]. 3217 The Initiator's HI MAY be encrypted using the HIP_CIPHER encryption 3218 algorithm. The keying material is derived from the Diffie-Hellman 3219 exchanged as defined in Section 6.5. 3221 The ECHO_RESPONSE_SIGNED and ECHO_RESPONSE_UNSIGNED contain the 3222 unmodified Opaque data copied from the corresponding echo request 3223 parameter(s). 3225 The TRANSPORT_FORMAT_LIST contains the single transport format type 3226 selected by the Initiator. The chosen type MUST correspond to one of 3227 the types offered by the Responder in the R1. Currently, the only 3228 transport format defined is the ESP transport format 3229 ([I-D.ietf-hip-rfc5202-bis]). 3231 The HMAC value in the HIP_MAC parameter is calculated over the whole 3232 HIP packet, excluding any parameters after the HIP_MAC, as described 3233 in Section 6.4.1. The Responder MUST validate the HIP_MAC. 3235 The signature is calculated over the whole HIP packet, excluding any 3236 parameters after the HIP_SIGNATURE, as described in Section 5.2.14. 3237 The Responder MUST validate this signature. The Responder uses the 3238 HI in the packet or a HI acquired by some other means for verifying 3239 the signature. 3241 5.3.4. R2 - the Second HIP Responder Packet 3243 The HIP header values for the R2 packet: 3245 Header: 3246 Packet Type = 4 3247 SRC HIT = Responder's HIT 3248 DST HIT = Initiator's HIT 3250 IP ( HIP ( HIP_MAC_2, HIP_SIGNATURE ) ) 3252 Valid control bits: none 3254 The HIP_MAC_2 is calculated over the whole HIP packet, with 3255 Responder's HOST_ID parameter concatenated with the HIP packet. The 3256 HOST_ID parameter is removed after the HMAC calculation. The 3257 procedure is described in Section 6.4.1. 3259 The signature is calculated over the whole HIP packet. 3261 The Initiator MUST validate both the HIP_MAC and the signature. 3263 5.3.5. UPDATE - the HIP Update Packet 3265 The HIP header values for the UPDATE packet: 3267 Header: 3268 Packet Type = 16 3269 SRC HIT = Sender's HIT 3270 DST HIT = Recipient's HIT 3272 IP ( HIP ( [SEQ, ACK, ] HIP_MAC, HIP_SIGNATURE ) ) 3274 Valid control bits: None 3276 The UPDATE packet contains mandatory HIP_MAC and HIP_SIGNATURE 3277 parameters, and other optional parameters. 3279 The UPDATE packet contains zero or one SEQ parameter. The presence 3280 of a SEQ parameter indicates that the receiver MUST acknowledge the 3281 the UPDATE. An UPDATE that does not contain a SEQ but only an ACK 3282 parameter is simply an acknowledgment of a previous UPDATE and itself 3283 MUST NOT be acknowledged by a separate ACK parameter. Such UPDATE 3284 packets containing only an ACK parameter do not require processing in 3285 relative order to other UPDATE packets. An UPDATE packet without 3286 either a SEQ or an ACK parameter is invalid; such unacknowledged 3287 updates MUST instead use a NOTIFY packet. 3289 An UPDATE packet contains zero or one ACK parameters. The ACK 3290 parameter echoes the SEQ sequence number of the UPDATE packet being 3291 ACKed. A host MAY choose to acknowledge more than one UPDATE packet 3292 at a time; e.g., the ACK parameter may contain the last two SEQ 3293 values received, for resilience against packet loss. ACK values are 3294 not cumulative; each received unique SEQ value requires at least one 3295 corresponding ACK value in reply. Received ACK parameters that are 3296 redundant are ignored. Hosts MUST implement the processing of ACK 3297 parameters with multiple SEQ numbers even if they do not implement 3298 sending ACK parameters with multiple SEQ numbers. 3300 The UPDATE packet may contain both a SEQ and an ACK parameter. In 3301 this case, the ACK parameter is being piggybacked on an outgoing 3302 UPDATE. In general, UPDATEs carrying SEQ SHOULD be ACKed upon 3303 completion of the processing of the UPDATE. A host MAY choose to 3304 hold the UPDATE carrying an ACK parameter for a short period of time 3305 to allow for the possibility of piggybacking the ACK parameter, in a 3306 manner similar to TCP delayed acknowledgments. 3308 A sender MAY choose to forego reliable transmission of a particular 3309 UPDATE (e.g., it becomes overcome by events). The semantics are such 3310 that the receiver MUST acknowledge the UPDATE, but the sender MAY 3311 choose to not care about receiving the ACK parameter. 3313 UPDATEs MAY be retransmitted without incrementing SEQ. If the same 3314 subset of parameters is included in multiple UPDATEs with different 3315 SEQs, the host MUST ensure that the receiver's processing of the 3316 parameters multiple times will not result in a protocol error. 3318 5.3.6. NOTIFY - the HIP Notify Packet 3320 The NOTIFY packet MAY be used to provide information to a peer. 3321 Typically, NOTIFY is used to indicate some type of protocol error or 3322 negotiation failure. NOTIFY packets are unacknowledged. The 3323 receiver can handle the packet only as informational, and SHOULD NOT 3324 change its HIP state (see Section 4.4.2) based purely on a received 3325 NOTIFY packet. 3327 The HIP header values for the NOTIFY packet: 3329 Header: 3330 Packet Type = 17 3331 SRC HIT = Sender's HIT 3332 DST HIT = Recipient's HIT, or zero if unknown 3334 IP ( HIP (i, [HOST_ID, ] HIP_SIGNATURE) ) 3336 Valid control bits: None 3337 The NOTIFY packet is used to carry one or more NOTIFICATION 3338 parameters. 3340 5.3.7. CLOSE - the HIP Association Closing Packet 3342 The HIP header values for the CLOSE packet: 3344 Header: 3345 Packet Type = 18 3346 SRC HIT = Sender's HIT 3347 DST HIT = Recipient's HIT 3349 IP ( HIP ( ECHO_REQUEST_SIGNED, HIP_MAC, HIP_SIGNATURE ) ) 3351 Valid control bits: none 3353 The sender MUST include an ECHO_REQUEST_SIGNED used to validate 3354 CLOSE_ACK received in response, and both a HIP_MAC and a signature 3355 (calculated over the whole HIP packet). 3357 The receiver peer MUST reply with a CLOSE_ACK containing an 3358 ECHO_RESPONSE_SIGNED corresponding to the received 3359 ECHO_REQUEST_SIGNED. 3361 5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet 3363 The HIP header values for the CLOSE_ACK packet: 3365 Header: 3366 Packet Type = 19 3367 SRC HIT = Sender's HIT 3368 DST HIT = Recipient's HIT 3370 IP ( HIP ( ECHO_RESPONSE_SIGNED, HIP_MAC, HIP_SIGNATURE ) ) 3372 Valid control bits: none 3374 The sender MUST include both an HMAC and signature (calculated over 3375 the whole HIP packet). 3377 The receiver peer MUST validate the ECHO_RESPONSE_SIGNED and validate 3378 both the HIP_MAC and the signature if the receiver has state for a 3379 HIP association. 3381 5.4. ICMP Messages 3383 When a HIP implementation detects a problem with an incoming packet, 3384 and it either cannot determine the identity of the sender of the 3385 packet or does not have any existing HIP association with the sender 3386 of the packet, it MAY respond with an ICMP packet. Any such replies 3387 MUST be rate-limited as described in [RFC4443]. In most cases, the 3388 ICMP packet has the Parameter Problem type (12 for ICMPv4, 4 for 3389 ICMPv6), with the Pointer field pointing to the field that caused the 3390 ICMP message to be generated. 3392 5.4.1. Invalid Version 3394 If a HIP implementation receives a HIP packet that has an 3395 unrecognized HIP version number, it SHOULD respond, rate-limited, 3396 with an ICMP packet with type Parameter Problem, with the Pointer 3397 pointing to the Version/RES. byte in the HIP header. 3399 5.4.2. Other Problems with the HIP Header and Packet Structure 3401 If a HIP implementation receives a HIP packet that has other 3402 unrecoverable problems in the header or packet format, it MAY 3403 respond, rate-limited, with an ICMP packet with type Parameter 3404 Problem, the Pointer pointing to the field that failed to pass the 3405 format checks. However, an implementation MUST NOT send an ICMP 3406 message if the checksum fails; instead, it MUST silently drop the 3407 packet. 3409 5.4.3. Invalid Puzzle Solution 3411 If a HIP implementation receives an I2 packet that has an invalid 3412 puzzle solution, the behavior depends on the underlying version of 3413 IP. If IPv6 is used, the implementation SHOULD respond with an ICMP 3414 packet with type Parameter Problem, the Pointer pointing to the 3415 beginning of the Puzzle solution #J field in the SOLUTION payload in 3416 the HIP message. 3418 If IPv4 is used, the implementation MAY respond with an ICMP packet 3419 with the type Parameter Problem, copying enough of bytes from the I2 3420 message so that the SOLUTION parameter fits into the ICMP message, 3421 the Pointer pointing to the beginning of the Puzzle solution #J 3422 field, as in the IPv6 case. Note, however, that the resulting ICMPv4 3423 message exceeds the typical ICMPv4 message size as defined in 3424 [RFC0792]. 3426 5.4.4. Non-Existing HIP Association 3428 If a HIP implementation receives a CLOSE or UPDATE packet, or any 3429 other packet whose handling requires an existing association, that 3430 has either a Receiver or Sender HIT that does not match with any 3431 existing HIP association, the implementation MAY respond, rate- 3432 limited, with an ICMP packet with the type Parameter Problem. The 3433 Pointer of the ICMP Parameter Problem packet is set pointing to the 3434 beginning of the first HIT that does not match. 3436 A host MUST NOT reply with such an ICMP if it receives any of the 3437 following messages: I1, R2, I2, R2, and NOTIFY packet. When 3438 introducing new packet types, a specification SHOULD define the 3439 appropriate rules for sending or not sending this kind of ICMP reply. 3441 6. Packet Processing 3443 Each host is assumed to have a single HIP protocol implementation 3444 that manages the host's HIP associations and handles requests for new 3445 ones. Each HIP association is governed by a conceptual state 3446 machine, with states defined above in Section 4.4. The HIP 3447 implementation can simultaneously maintain HIP associations with more 3448 than one host. Furthermore, the HIP implementation may have more 3449 than one active HIP association with another host; in this case, HIP 3450 associations are distinguished by their respective HITs. It is not 3451 possible to have more than one HIP association between any given pair 3452 of HITs. Consequently, the only way for two hosts to have more than 3453 one parallel association is to use different HITs, at least at one 3454 end. 3456 The processing of packets depends on the state of the HIP 3457 association(s) with respect to the authenticated or apparent 3458 originator of the packet. A HIP implementation determines whether it 3459 has an active association with the originator of the packet based on 3460 the HITs. In the case of user data carried in a specific transport 3461 format, the transport format document specifies how the incoming 3462 packets are matched with the active associations. 3464 6.1. Processing Outgoing Application Data 3466 In a HIP host, an application can send application-level data using 3467 an identifier specified via the underlying API. The API can be a 3468 backwards-compatible API (see [RFC5338]), using identifiers that look 3469 similar to IP addresses, or a completely new API, providing enhanced 3470 services related to Host Identities. Depending on the HIP 3471 implementation, the identifier provided to the application may be 3472 different; for example, it can be a HIT or an IP address. 3474 The exact format and method for transferring the user data from the 3475 source HIP host to the destination HIP host is defined in the 3476 corresponding transport format document. The actual data is 3477 transferred in the network using the appropriate source and 3478 destination IP addresses. 3480 In this document, conceptual processing rules are defined only for 3481 the base case where both hosts have only single usable IP addresses; 3482 the multi-address multi-homing case is specified separately. 3484 The following conceptual algorithm describes the steps that are 3485 required for handling outgoing datagrams destined to a HIT. 3487 1. If the datagram has a specified source address, it MUST be a HIT. 3488 If it is not, the implementation MAY replace the source address 3489 with a HIT. Otherwise, it MUST drop the packet. 3491 2. If the datagram has an unspecified source address, the 3492 implementation MUST choose a suitable source HIT for the 3493 datagram. Selecting the source HIT is subject to local policy. 3495 3. If there is no active HIP association with the given HIT pair, one MUST be created by running the base 3497 exchange. While waiting for the base exchange to complete, the 3498 implementation SHOULD queue at least one user data packet per HIP 3499 association to be formed, and it MAY queue more than one. 3501 4. Once there is an active HIP association for the given HIT pair, the outgoing datagram is passed to 3503 transport handling. The possible transport formats are defined 3504 in separate documents, of which the ESP transport format for HIP 3505 is mandatory for all HIP implementations. 3507 5. Before sending the packet, the HITs in the datagram are replaced 3508 with suitable IP addresses. For IPv6, the rules defined in 3509 [RFC6724] SHOULD be followed. Note that this HIT-to-IP-address 3510 conversion step MAY also be performed at some other point in the 3511 stack, e.g., before wrapping the packet into the output format. 3513 6.2. Processing Incoming Application Data 3515 The following conceptual algorithm describes the incoming datagram 3516 handling when HITs are used at the receiving host as application- 3517 level identifiers. More detailed steps for processing packets are 3518 defined in corresponding transport format documents. 3520 1. The incoming datagram is mapped to an existing HIP association, 3521 typically using some information from the packet. For example, 3522 such mapping may be based on the ESP Security Parameter Index 3523 (SPI). 3525 2. The specific transport format is unwrapped, in a way depending on 3526 the transport format, yielding a packet that looks like a 3527 standard (unencrypted) IP packet. If possible, this step SHOULD 3528 also verify that the packet was indeed (once) sent by the remote 3529 HIP host, as identified by the HIP association. 3531 Depending on the used transport mode, the verification method can 3532 vary. While the HI (as well as HIT) is used as the higher-layer 3533 identifier, the verification method has to verify that the data 3534 packet was sent by the correct node identity and that the actual 3535 identity maps to this particular HIT. When using ESP transport 3536 format [I-D.ietf-hip-rfc5202-bis], the verification is done using 3537 the SPI value in the data packet to find the corresponding SA 3538 with associated HIT and key, and decrypting the packet with that 3539 associated key. 3541 3. The IP addresses in the datagram are replaced with the HITs 3542 associated with the HIP association. Note that this IP-address- 3543 to-HIT conversion step MAY also be performed at some other point 3544 in the stack. 3546 4. The datagram is delivered to the upper layer (e.g., UDP or TCP). 3547 When demultiplexing the datagram, the right upper-layer socket is 3548 selected based on the HITs. 3550 6.3. Solving the Puzzle 3552 This subsection describes the details for solving the puzzle. 3554 In the R1 packet, the values #I and #K are sent in network byte 3555 order. Similarly, in the I2 packet, the values #I and #J are sent in 3556 network byte order. The hash is created by concatenating, in network 3557 byte order, the following data, in the following order and using the 3558 RHASH algorithm: 3560 n-bit random value #I (where n is RHASH_len), in network byte 3561 order, as appearing in the R1 and I2 packets. 3563 128-bit Initiator's HIT, in network byte order, as appearing in 3564 the HIP Payload in the R1 and I2 packets. 3566 128-bit Responder's HIT, in network byte order, as appearing in 3567 the HIP Payload in the R1 and I2 packets. 3569 n-bit random value #J (where n is RHASH_len), in network byte 3570 order, as appearing in the I2 packet. 3572 In a valid response puzzle, the #K low-order bits of the resulting 3573 RHASH digest MUST be zero. 3575 Notes: 3577 i) The length of the data to be hashed is variable depending on 3578 the output length of the Responder's hash function RHASH. 3580 ii) All the data in the hash input MUST be in network byte order. 3582 iii) The order of the Initiator's and Responder's HITs are 3583 different in the R1 and I2 packets; see Section 5.1. Care must be 3584 taken to copy the values in the right order to the hash input. 3586 iv) For a puzzle #I, there may exist multiple valid puzzle 3587 solutions #J. 3589 The following procedure describes the processing steps involved, 3590 assuming that the Responder chooses to precompute the R1 packets: 3592 Precomputation by the Responder: 3593 Sets up the puzzle difficulty #K. 3594 Creates a signed R1 and caches it. 3596 Responder: 3597 Selects a suitable cached R1. 3598 Generates a random number #I. 3599 Sends #I and #K in an R1. 3600 Saves #I and #K for a Delta time. 3602 Initiator: 3603 Generates repeated attempts to solve the puzzle until a matching 3604 #J is found: 3605 Ltrunc( RHASH( #I | HIT-I | HIT-R | #J ), #K ) == 0 3606 Sends #I and #J in an I2. 3608 Responder: 3609 Verifies that the received #I is a saved one. 3610 Finds the right #K based on #I. 3611 Computes V := Ltrunc( RHASH( #I | HIT-I | HIT-R | #J ), #K ) 3612 Rejects if V != 0 3613 Accept if V == 0 3615 6.4. HIP_MAC and SIGNATURE Calculation and Verification 3617 The following subsections define the actions for processing HIP_MAC, 3618 HIP_MAC_2, HIP_SIGNATURE and HIP_SIGNATURE_2 parameters. The 3619 HIP_MAC_2 parameter is contained in the R2 packet. The 3620 HIP_SIGNATURE_2 parameter is contained in the R1 packet. The 3621 HIP_SIGNATURE and HIP_MAC parameter are contained in other HIP 3622 packets. 3624 6.4.1. HMAC Calculation 3626 The HMAC uses RHASH as underlying hash function. The type of RHASH 3627 depends on the HIT Suite of the Responder. Hence, HMAC-SHA-256 3628 [RFC4868] is used for HIT Suite RSA/DSA/SHA-256, HMAC-SHA-1 [RFC2404] 3629 is used for HIT Suite ECDSA_LOW/SHA-1, and HMAC-SHA-384 [RFC4868] for 3630 HIT Suite ECDSA/SHA-384. 3632 The following process applies both to the HIP_MAC and HIP_MAC_2 3633 parameters. When processing HIP_MAC_2, the difference is that the 3634 HIP_MAC calculation includes a pseudo HOST_ID field containing the 3635 Responder's information as sent in the R1 packet earlier. 3637 Both the Initiator and the Responder should take some care when 3638 verifying or calculating the HIP_MAC_2. Specifically, the Initiator 3639 has to preserve the HOST_ID exactly as it was received in the R1 3640 packet until it receives the HIP_MAC_2 in the R2 packet. 3642 The scope of the calculation for HIP_MAC is: 3644 HMAC: { HIP header | [ Parameters ] } 3646 where Parameters include all HIP parameters of the packet that is 3647 being calculated with Type values ranging from 1 to (HIP_MAC's Type 3648 value - 1) and exclude parameters with Type values greater or equal 3649 to HIP_MAC's Type value. 3651 During HIP_MAC calculation, the following applies: 3653 o In the HIP header, the Checksum field is set to zero. 3655 o In the HIP header, the Header Length field value is calculated to 3656 the beginning of the HIP_MAC parameter. 3658 Parameter order is described in Section 5.2.1. 3660 The scope of the calculation for HIP_MAC_2 is: 3662 HIP_MAC_2: { HIP header | [ Parameters ] | HOST_ID } 3664 where Parameters include all HIP parameters for the packet that is 3665 being calculated with Type values from 1 to (HIP_MAC_2's Type value - 3666 1) and exclude parameters with Type values greater or equal to 3667 HIP_MAC_2's Type value. 3669 During HIP_MAC_2 calculation, the following applies: 3671 o In the HIP header, the Checksum field is set to zero. 3673 o In the HIP header, the Header Length field value is calculated to 3674 the beginning of the HIP_MAC_2 parameter and increased by the 3675 length of the concatenated HOST_ID parameter length (including 3676 type and length fields). 3678 o HOST_ID parameter is exactly in the form it was received in the R1 3679 packet from the Responder. 3681 Parameter order is described in Section 5.2.1, except that the 3682 HOST_ID parameter in this calculation is added to the end. 3684 The HIP_MAC parameter is defined in Section 5.2.12 and the HIP_MAC_2 3685 parameter in Section 5.2.13. The HMAC calculation and verification 3686 process (the process applies both to HIP_MAC and HIP_MAC_2 except 3687 where HIP_MAC_2 is mentioned separately) is as follows: 3689 Packet sender: 3691 1. Create the HIP packet, without the HIP_MAC, HIP_SIGNATURE, 3692 HIP_SIGNATURE_2, or any other parameter with greater Type value 3693 than the HIP_MAC parameter has. 3695 2. In case of HIP_MAC_2 calculation, add a HOST_ID (Responder) 3696 parameter to the end of the packet. 3698 3. Calculate the Header Length field in the HIP header including the 3699 added HOST_ID parameter in case of HIP_MAC_2. 3701 4. Compute the HMAC using either HIP-gl or HIP-lg integrity key 3702 retrieved from KEYMAT as defined in Section 6.5. 3704 5. In case of HIP_MAC_2, remove the HOST_ID parameter from the 3705 packet. 3707 6. Add the HIP_MAC parameter to the packet and any parameter with 3708 greater Type value than the HIP_MAC's (HIP_MAC_2's) that may 3709 follow, including possible HIP_SIGNATURE or HIP_SIGNATURE_2 3710 parameters 3712 7. Recalculate the Length field in the HIP header. 3714 Packet receiver: 3716 1. Verify the HIP header Length field. 3718 2. Remove the HIP_MAC or HIP_MAC_2 parameter, as well as all other 3719 parameters that follow it with greater Type value including 3720 possible HIP_SIGNATURE or HIP_SIGNATURE_2 fields, saving the 3721 contents if they are needed later. 3723 3. In case of HIP_MAC_2, build and add a HOST_ID parameter (with 3724 Responder information) to the packet. The HOST_ID parameter 3725 should be identical to the one previously received from the 3726 Responder. 3728 4. Recalculate the HIP packet length in the HIP header and clear the 3729 Checksum field (set it to all zeros). In case of HIP_MAC_2, the 3730 length is calculated with the added HOST_ID parameter. 3732 5. Compute the HMAC using either HIP-gl or HIP-lg integrity key as 3733 defined in Section 6.5 and verify it against the received HMAC. 3735 6. Set Checksum and Header Length field in the HIP header to 3736 original values. Note that the checksum and length fields 3737 contain incorrect values after this step. 3739 7. In case of HIP_MAC_2, remove the HOST_ID parameter from the 3740 packet before further processing. 3742 6.4.2. Signature Calculation 3744 The following process applies both to the HIP_SIGNATURE and 3745 HIP_SIGNATURE_2 parameters. When processing the HIP_SIGNATURE_2, the 3746 only difference is that instead of the HIP_SIGNATURE parameter, the 3747 HIP_SIGNATURE_2 parameter is used, and the Initiator's HIT and PUZZLE 3748 Opaque and Random #I fields are cleared (set to all zeros) before 3749 computing the signature. The HIP_SIGNATURE parameter is defined in 3750 Section 5.2.14 and the HIP_SIGNATURE_2 parameter in Section 5.2.15. 3752 The scope of the calculation for HIP_SIGNATURE and HIP_SIGNATURE_2 3753 is: 3755 HIP_SIGNATURE: { HIP header | [ Parameters ] } 3757 where Parameters include all HIP parameters for the packet that is 3758 being calculated with Type values from 1 to (HIP_SIGNATURE's Type 3759 value - 1). 3761 During signature calculation, the following applies: 3763 o In the HIP header, the Checksum field is set to zero. 3765 o In the HIP header, the Header Length field value is calculated to 3766 the beginning of the HIP_SIGNATURE parameter. 3768 The parameter order is described in Section 5.2.1. 3770 HIP_SIGNATURE_2: { HIP header | [ Parameters ] } 3772 where Parameters include all HIP parameters for the packet that is 3773 being calculated with Type values ranging from 1 to 3774 (HIP_SIGNATURE_2's Type value - 1). 3776 During signature calculation, the following apply: 3778 o In the HIP header, the Initiator's HIT field and Checksum fields 3779 are set to zero. 3781 o In the HIP header, the Header Length field value is calculated to 3782 the beginning of the HIP_SIGNATURE_2 parameter. 3784 o PUZZLE parameter's Opaque and Random #I fields are set to zero. 3786 Parameter order is described in Section 5.2.1. 3788 The signature calculation and verification process (the process 3789 applies both to HIP_SIGNATURE and HIP_SIGNATURE_2 except in the case 3790 where HIP_SIGNATURE_2 is separately mentioned) is as follows: 3792 Packet sender: 3794 1. Create the HIP packet without the HIP_SIGNATURE parameter or any 3795 other parameters that follow the HIP_SIGNATURE parameter. 3797 2. Calculate the Length field and zero the Checksum field in the HIP 3798 header. In case of HIP_SIGNATURE_2, set Initiator's HIT field in 3799 the HIP header as well as PUZZLE parameter's Opaque and Random #I 3800 fields to zero. 3802 3. Compute the signature using the private key corresponding to the 3803 Host Identifier (public key). 3805 4. Add the HIP_SIGNATURE parameter to the packet. 3807 5. Add any parameters that follow the HIP_SIGNATURE parameter. 3809 6. Recalculate the Length field in the HIP header, and calculate the 3810 Checksum field. 3812 Packet receiver: 3814 1. Verify the HIP header Length field and checksum. 3816 2. Save the contents of the HIP_SIGNATURE parameter and any other 3817 parameters following the HIP_SIGNATURE parameter and remove them 3818 from the packet. 3820 3. Recalculate the HIP packet Length in the HIP header and clear the 3821 Checksum field (set it to all zeros). In case of 3822 HIP_SIGNATURE_2, set Initiator's HIT field in the HIP header as 3823 well as PUZZLE parameter's Opaque and Random #I fields to zero. 3825 4. Compute the signature and verify it against the received 3826 signature using the packet sender's Host Identity (public key). 3828 5. Restore the original packet by adding removed parameters (in step 3829 2) and resetting the values that were set to zero (in step 3). 3831 The verification can use either the HI received from a HIP packet, 3832 the HI from a DNS query, if the FQDN has been received in the HOST_ID 3833 packet or one received by some other means. 3835 6.5. HIP KEYMAT Generation 3837 HIP keying material is derived from the Diffie-Hellman session key, 3838 Kij, produced during the HIP base exchange (see Section 4.1.3). The 3839 Initiator has Kij during the creation of the I2 packet, and the 3840 Responder has Kij once it receives the I2 packet. This is why I2 can 3841 already contain encrypted information. 3843 The KEYMAT is derived by feeding Kij into the key derivation function 3844 defined by the DH Group ID. Currently the only key derivation 3845 function defined in this document is the Hash-based Key Derivation 3846 Function (HKDF) [RFC5869] using the RHASH hash function. Other 3847 documents may define new DH Group IDs and corresponding key 3848 distribution functions. 3850 In the following we provide the details for deriving the keying 3851 material using HKDF. 3853 where 3855 info = sort(HIT-I | HIT-R) 3856 salt = #I | #J 3858 Sort(HIT-I | HIT-R) is defined as the network byte order 3859 concatenation of the two HITs, with the smaller HIT preceding the 3860 larger HIT, resulting from the numeric comparison of the two HITs 3861 interpreted as positive (unsigned) 128-bit integers in network byte 3862 order. The #I and #J values are from the puzzle and its solution 3863 that were exchanged in R1 and I2 messages when this HIP association 3864 was set up. Both hosts have to store #I and #J values for the HIP 3865 association for future use. 3867 The initial keys are drawn sequentially in the order that is 3868 determined by the numeric comparison of the two HITs, with comparison 3869 method described in the previous paragraph. HOST_g denotes the host 3870 with the greater HIT value, and HOST_l the host with the lower HIT 3871 value. 3873 The drawing order for the four initial keys is as follows: 3875 HIP-gl encryption key for HOST_g's ENCRYPTED parameter 3877 HIP-gl integrity (HMAC) key for HOST_g's outgoing HIP packets 3879 HIP-lg encryption key for HOST_l's ENCRYPTED parameter 3881 HIP-lg integrity (HMAC) key for HOST_l's outgoing HIP packets 3883 The number of bits drawn for a given algorithm is the "natural" size 3884 of the keys. For the mandatory algorithms, the following sizes 3885 apply: 3887 AES 128 or 256 bits 3889 SHA-1 160 bits 3891 SHA-256 256 bits 3893 SHA-384 384 bits 3895 NULL 0 bits 3896 If other key sizes are used, they MUST be treated as different 3897 encryption algorithms and defined separately. 3899 6.6. Initiation of a HIP Base Exchange 3901 An implementation may originate a HIP base exchange to another host 3902 based on a local policy decision, usually triggered by an application 3903 datagram, in much the same way that an IPsec IKE key exchange can 3904 dynamically create a Security Association. Alternatively, a system 3905 may initiate a HIP exchange if it has rebooted or timed out, or 3906 otherwise lost its HIP state, as described in Section 4.5.4. 3908 The implementation prepares an I1 packet and sends it to the IP 3909 address that corresponds to the peer host. The IP address of the 3910 peer host may be obtained via conventional mechanisms, such as DNS 3911 lookup. The I1 packet contents are specified in Section 5.3.1. The 3912 selection of which source or destination Host Identity to use, if a 3913 Initiator or Responder has more than one to choose from, is typically 3914 a policy decision. 3916 The following steps define the conceptual processing rules for 3917 initiating a HIP base exchange: 3919 1. The Initiator receives one or more of the Responder's HITs and 3920 one or more addresses either from a DNS lookup of the Responder's 3921 FQDN, from some other repository, or from a local database. If 3922 the Initiator does not know the Responder's HIT, it may attempt 3923 opportunistic mode by using NULL (all zeros) as the Responder's 3924 HIT (see also "HIP Opportunistic Mode" (Section 4.1.8)). If the 3925 Initiator can choose from multiple Responder HITs, it selects a 3926 HIT for which the Initiator supports the HIT Suite. 3928 2. The Initiator sends an I1 packet to one of the Responder's 3929 addresses. The selection of which address to use is a local 3930 policy decision. 3932 3. The Initiator includes the DH_GROUP_LIST in the I1 packet. The 3933 selection and order of DH Group IDs in the DH_GROUP_LIST MUST be 3934 stored by the Initiator because this list is needed for later R1 3935 processing. In most cases, the preferences regarding the DH 3936 Groups will be static, so no per-association storage is 3937 necessary. 3939 4. Upon sending an I1 packet, the sender transitions to state 3940 I1-SENT, starts a timer for which the timeout value SHOULD be 3941 larger than the worst-case anticipated RTT. The sender SHOULD 3942 also increment the trial counter associated with the I1. 3944 5. Upon timeout, the sender SHOULD retransmit the I1 packet and 3945 restart the timer, up to a maximum of I1_RETRIES_MAX tries. 3947 6.6.1. Sending Multiple I1 Packets in Parallel 3949 For the sake of minimizing the association establishment latency, an 3950 implementation MAY send the same I1 packet to more than one of the 3951 Responder's addresses. However, it MUST NOT send to more than three 3952 (3) Responder addresses in parallel. Furthermore, upon timeout, the 3953 implementation MUST refrain from sending the same I1 packet to 3954 multiple addresses. That is, if it retries to initialize the 3955 connection after a timeout, it MUST NOT send the I1 packet to more 3956 than one destination address. These limitations are placed in order 3957 to avoid congestion of the network, and potential DoS attacks that 3958 might occur, e.g., because someone's claim to have hundreds or 3959 thousands of addresses could generate a huge number of I1 packets 3960 from the Initiator. 3962 As the Responder is not guaranteed to distinguish the duplicate I1 3963 packets it receives at several of its addresses (because it avoids 3964 storing states when it answers back an R1 packet), the Initiator may 3965 receive several duplicate R1 packets. 3967 The Initiator SHOULD then select the initial preferred destination 3968 address using the source address of the selected received R1, and use 3969 the preferred address as a source address for the I2 packet. 3970 Processing rules for received R1s are discussed in Section 6.8. 3972 6.6.2. Processing Incoming ICMP Protocol Unreachable Messages 3974 A host may receive an ICMP 'Destination Protocol Unreachable' message 3975 as a response to sending a HIP I1 packet. Such a packet may be an 3976 indication that the peer does not support HIP, or it may be an 3977 attempt to launch an attack by making the Initiator believe that the 3978 Responder does not support HIP. 3980 When a system receives an ICMP 'Destination Protocol Unreachable' 3981 message while it is waiting for an R1 packet, it MUST NOT terminate 3982 waiting. It MAY continue as if it had not received the ICMP message, 3983 and send a few more I1 packets. Alternatively, it MAY take the ICMP 3984 message as a hint that the peer most probably does not support HIP, 3985 and return to state UNASSOCIATED earlier than otherwise. However, at 3986 minimum, it MUST continue waiting for an R1 packet for a reasonable 3987 time before returning to UNASSOCIATED. 3989 6.7. Processing Incoming I1 Packets 3991 An implementation SHOULD reply to an I1 with an R1 packet, unless the 3992 implementation is unable or unwilling to set up a HIP association. 3993 If the implementation is unable to set up a HIP association, the host 3994 SHOULD send an ICMP Destination Protocol Unreachable, 3995 Administratively Prohibited, message to the I1 packet source IP 3996 address. If the implementation is unwilling to set up a HIP 3997 association, the host MAY ignore the I1 packet. This latter case may 3998 occur during a DoS attack such as an I1 packet flood. 4000 The implementation SHOULD be able to handle a storm of received I1 4001 packets, discarding those with common content that arrive within a 4002 small time delta. 4004 A spoofed I1 packet can result in an R1 attack on a system. An R1 4005 packet sender MUST have a mechanism to rate-limit R1 packets sent to 4006 an address. 4008 It is RECOMMENDED that the HIP state machine does not transition upon 4009 sending an R1 packet. 4011 The following steps define the conceptual processing rules for 4012 responding to an I1 packet: 4014 1. The Responder MUST check that the Responder's HIT in the received 4015 I1 packet is either one of its own HITs or NULL. Otherwise it 4016 must drop the packet. 4018 2. If the Responder is in ESTABLISHED state, the Responder MAY 4019 respond to this with an R1 packet, prepare to drop an existing 4020 HIP security association with the peer, and stay at ESTABLISHED 4021 state. 4023 3. If the Responder is in I1-SENT state, it MUST make a comparison 4024 between the sender's HIT and its own (i.e., the receiver's) HIT. 4025 If the sender's HIT is greater than its own HIT, it should drop 4026 the I1 packet and stay at I1-SENT. If the sender's HIT is 4027 smaller than its own HIT, it SHOULD send the R1 packet and stay 4028 at I1-SENT. The HIT comparison is performed as defined in 4029 Section 6.5. 4031 4. If the implementation chooses to respond to the I1 packet with an 4032 R1 packet, it creates a new R1 or selects a precomputed R1 4033 according to the format described in Section 5.3.2. It creates 4034 or chooses an R1 that contains its most preferred DH public value 4035 that is also contained in the DH_GROUP_LIST in the I1 packet. If 4036 no suitable DH Group ID was contained in the DH_GROUP_LIST in the 4037 I1 packet, it sends an R1 with any suitable DH public key. 4039 5. If the received Responder's HIT in the I1 is NULL, the Responder 4040 selects a HIT with a the same HIT Suite as the Initiator's HIT. 4041 If this HIT Suite is not supported by the Responder, it SHOULD 4042 select a REQUIRED HIT Suite from Section 5.2.10, which is 4043 currently RSA/DSA/SHA-256. Other than that, selecting the HIT is 4044 a local policy matter. 4046 6. The responder expresses its supported HIP transport formats in 4047 the TRANSPORT_FORMAT_LIST as described in Section 5.2.11. The 4048 Responder MUST at least provide one payload transport format 4049 type. 4051 7. The Responder sends the R1 packet to the source IP address of the 4052 I1 packet. 4054 6.7.1. R1 Management 4056 All compliant implementations MUST be able to produce R1 packets; 4057 even if a device is configured by policy to only initiate 4058 associations, it must be able to process I1s in case of recovery from 4059 loss of state or key exhaustion. An R1 packet MAY be precomputed. 4060 An R1 packet MAY be reused for time Delta T, which is implementation 4061 dependent, and SHOULD be deprecated and not used once a valid 4062 response I2 packet has been received from an Initiator. During an I1 4063 message storm, an R1 packet MAY be re-used beyond this limit. R1 4064 information MUST NOT be discarded until Delta S after T. Time S is 4065 the delay needed for the last I2 packet to arrive back to the 4066 Responder. 4068 Implementations that support multiple DH groups MAY pre-compute R1 4069 packets for each supported group so that incoming I1 packets with 4070 different DH Group IDs in the DH_GROUP_LIST can be served quickly. 4072 An implementation MAY keep state about received I1 packets and match 4073 the received I2 packets against the state, as discussed in 4074 Section 4.1.1. 4076 6.7.2. Handling Malformed Messages 4078 If an implementation receives a malformed I1 packet, it SHOULD NOT 4079 respond with a NOTIFY message, as such practice could open up a 4080 potential denial-of-service threat. Instead, it MAY respond with an 4081 ICMP packet, as defined in Section 5.4. 4083 6.8. Processing Incoming R1 Packets 4085 A system receiving an R1 packet MUST first check to see if it has 4086 sent an I1 packet to the originator of the R1 packet (i.e., it is in 4087 state I1-SENT). If so, it SHOULD process the R1 as described below, 4088 send an I2 packet, and transition to state I2-SENT, setting a timer 4089 to protect the I2 packet. If the system is in state I2-SENT, it MAY 4090 respond to the R1 packet if the R1 packet has a larger R1 generation 4091 counter; if so, it should drop its state due to processing the 4092 previous R1 packet and start over from state I1-SENT. If the system 4093 is in any other state with respect to that host, the system SHOULD 4094 silently drop the R1 packet. 4096 When sending multiple I1 packets, an Initiator SHOULD wait for a 4097 small amount of time after the first R1 reception to allow possibly 4098 multiple R1 packets to arrive, and it SHOULD respond to an R1 packet 4099 among the set with the largest R1 generation counter. 4101 The following steps define the conceptual processing rules for 4102 responding to an R1 packet: 4104 1. A system receiving an R1 MUST first check to see if it has sent 4105 an I1 packet to the originator of the R1 packet (i.e., it has a 4106 HIP association that is in state I1-SENT and that is associated 4107 with the HITs in the R1). Unless the I1 packet was sent in 4108 opportunistic mode (see Section 4.1.8), the IP addresses in the 4109 received R1 packet SHOULD be ignored by the R1 processing and, 4110 when looking up the right HIP association, the received R1 4111 packet SHOULD be matched against the associations using only the 4112 HITs. If a match exists, the system should process the R1 4113 packet as described below. 4115 2. Otherwise, if the system is in any other state than I1-SENT or 4116 I2-SENT with respect to the HITs included in the R1 packet, it 4117 SHOULD silently drop the R1 packet and remain in the current 4118 state. 4120 3. If the HIP association state is I1-SENT or I2-SENT, the received 4121 Initiator's HIT MUST correspond to the HIT used in the original 4122 I1. Also, the Responder's HIT MUST correspond to the one used 4123 in the I1, unless the I1 packet contained a NULL HIT. 4125 4. The system SHOULD validate the R1 signature before applying 4126 further packet processing, according to Section 5.2.15. 4128 5. If the HIP association state is I1-SENT, and multiple valid R1 4129 packets are present, the system MUST select from among the R1 4130 packets with the largest R1 generation counter. 4132 6. The system MUST check that the Initiator HIT Suite is contained 4133 in the HIT_SUITE_LIST parameter in the R1 packet (i.e., the 4134 Initiator's HIT Suite is supported by the Responder). If the 4135 HIT Suite is supported by the Responder, the system proceeds 4136 normally. Otherwise, the system MAY stay in state I1-sent and 4137 restart the BEX by sending a new I1 packet with an Initiator HIT 4138 that is supported by the Responder and hence is contained in the 4139 HIT_SUITE_LIST in the R1 packet. The system MAY abort the BEX 4140 if no suitable source HIT is available. The system SHOULD wait 4141 for an acceptable time span to allow further R1 packets with 4142 higher R1 generation counters or different HIT and HIT Suites to 4143 arrive before restarting or aborting the BEX. 4145 7. The system MUST check that the DH Group ID in the DIFFIE_HELLMAN 4146 parameter in the R1 matches the first DH Suite ID in the 4147 Responder's DH_GROUP_LIST in the R1 packet that was also 4148 contained in the Initiator's DH_GROUP_LIST in the I1 packet. If 4149 the DH Group ID of the DIFFIE_HELLMAN parameter does not express 4150 the Responder's best choice, the Initiator can conclude that the 4151 DH_GROUP_LIST in the I1 packet was adversely modified. In such 4152 case, the Initiator MAY send a new I1 packet, however, it SHOULD 4153 NOT change its preference in the DH_GROUP_LIST in the new I1 4154 packet. Alternatively, the Initiator MAY abort the HIP base 4155 exchange. 4157 8. If the HIP association state is I2-SENT, the system MAY re-enter 4158 state I1-SENT and process the received R1 packet if it has a 4159 larger R1 generation counter than the R1 packet responded to 4160 previously. 4162 9. The R1 packet may have the A bit set -- in this case, the system 4163 MAY choose to refuse it by dropping the R1 packet and returning 4164 to state UNASSOCIATED. The system SHOULD consider dropping the 4165 R1 packet only if it used a NULL HIT in I1 packet. If the A bit 4166 is set, the Responder's HIT is anonymous and SHOULD NOT be 4167 stored permanently. 4169 10. The system SHOULD attempt to validate the HIT against the 4170 received Host Identity by using the received Host Identity to 4171 construct a HIT and verify that it matches the Sender's HIT. 4173 11. The system MUST store the received R1 generation counter for 4174 future reference. 4176 12. The system attempts to solve the puzzle in the R1 packet. The 4177 system MUST terminate the search after exceeding the remaining 4178 lifetime of the puzzle. If the puzzle is not successfully 4179 solved, the implementation MAY either resend the I1 packet 4180 within the retry bounds or abandon the HIP base exchange. 4182 13. The system computes standard Diffie-Hellman keying material 4183 according to the public value and Group ID provided in the 4184 DIFFIE_HELLMAN parameter. The Diffie-Hellman keying material 4185 Kij is used for key extraction as specified in Section 6.5. 4187 14. The system selects the HIP_CIPHER ID from the choices presented 4188 in the R1 packet and uses the selected values subsequently when 4189 generating and using encryption keys, and when sending the I2 4190 packet. If the proposed alternatives are not acceptable to the 4191 system, it may either resend an I1 within the retry bounds or 4192 abandon the HIP base exchange. 4194 15. The system chooses one suitable transport format from the 4195 TRANSPORT_FORMAT_LIST and includes the respective transport 4196 format parameter in the subsequent I2 packet. 4198 16. The system initializes the remaining variables in the associated 4199 state, including Update ID counters. 4201 17. The system prepares and sends an I2 packet, as described in 4202 Section 5.3.3. 4204 18. The system SHOULD start a timer whose timeout value SHOULD be 4205 larger than the worst-case anticipated RTT, and MUST increment a 4206 trial counter associated with the I2 packet. The sender SHOULD 4207 retransmit the I2 packet upon a timeout and restart the timer, 4208 up to a maximum of I2_RETRIES_MAX tries. 4210 19. If the system is in state I1-SENT, it SHALL transition to state 4211 I2-SENT. If the system is in any other state, it remains in the 4212 current state. 4214 6.8.1. Handling of Malformed Messages 4216 If an implementation receives a malformed R1 message, it MUST 4217 silently drop the packet. Sending a NOTIFY or ICMP would not help, 4218 as the sender of the R1 packet typically doesn't have any state. An 4219 implementation SHOULD wait for some more time for a possibly well- 4220 formed R1, after which it MAY try again by sending a new I1 packet. 4222 6.9. Processing Incoming I2 Packets 4224 Upon receipt of an I2 packet, the system MAY perform initial checks 4225 to determine whether the I2 packet corresponds to a recent R1 packet 4226 that has been sent out, if the Responder keeps such state. For 4227 example, the sender could check whether the I2 packet is from an 4228 address or HIT for which the Responder has recently received an I1. 4229 The R1 packet may have had Opaque data included that was echoed back 4230 in the I2 packet. If the I2 packet is considered to be suspect, it 4231 MAY be silently discarded by the system. 4233 Otherwise, the HIP implementation SHOULD process the I2 packet. This 4234 includes validation of the puzzle solution, generating the Diffie- 4235 Hellman key, possibly decrypting the Initiator's Host Identity, 4236 verifying the signature, creating state, and finally sending an R2 4237 packet. 4239 The following steps define the conceptual processing rules for 4240 responding to an I2 packet: 4242 1. The system MAY perform checks to verify that the I2 packet 4243 corresponds to a recently sent R1 packet. Such checks are 4244 implementation dependent. See Appendix A for a description of 4245 an example implementation. 4247 2. The system MUST check that the Responder's HIT corresponds to 4248 one of its own HITs and MUST drop the packet otherwise. 4250 3. The system MUST further check that the Initiator's HIT Suite is 4251 supported. The Responder SHOULD silently drop I2 packets with 4252 unsupported Initiator HITs. 4254 4. If the system's state machine is in the R2-SENT state, the 4255 system MAY check if the newly received I2 packet is similar to 4256 the one that triggered moving to R2-SENT. If so, it MAY 4257 retransmit a previously sent R2 packet, reset the R2-SENT timer, 4258 and the state machine stays in R2-SENT. 4260 5. If the system's state machine is in the I2-SENT state, the 4261 system MUST make a comparison between its local and sender's 4262 HITs (similarly as in Section 6.5). If the local HIT is smaller 4263 than the sender's HIT, it should drop the I2 packet, use the 4264 peer Diffie-Hellman key and nonce #I from the R1 packet received 4265 earlier, and get the local Diffie-Hellman key and nonce #J from 4266 the I2 packet sent to the peer earlier. Otherwise, the system 4267 should process the received I2 packet and drop any previously 4268 derived Diffie-Hellman keying material Kij it might have formed 4269 upon sending the I2 packet previously. The peer Diffie-Hellman 4270 key and the nonce #J are taken from the just arrived I2 packet. 4271 The local Diffie-Hellman key and the nonce I are the ones that 4272 were sent earlier in the R1 packet. 4274 6. If the system's state machine is in the I1-SENT state, and the 4275 HITs in the I2 packet match those used in the previously sent I1 4276 packet, the system uses this received I2 packet as the basis for 4277 the HIP association it was trying to form, and stops 4278 retransmitting I1 packets (provided that the I2 packet passes 4279 the additional checks below). 4281 7. If the system's state machine is in any other state than 4282 R2-SENT, the system SHOULD check that the echoed R1 generation 4283 counter in the I2 packet is within the acceptable range if the 4284 counter is included. Implementations MUST accept puzzles from 4285 the current generation and MAY accept puzzles from earlier 4286 generations. If the generation counter in the newly received I2 4287 packet is outside the accepted range, the I2 packet is stale 4288 (and perhaps replayed) and SHOULD be dropped. 4290 8. The system MUST validate the solution to the puzzle by computing 4291 the hash described in Section 5.3.3 using the same RHASH 4292 algorithm. 4294 9. The I2 packet MUST have a single value in the HIP_CIPHER 4295 parameter, which MUST match one of the values offered to the 4296 Initiator in the R1 packet. 4298 10. The system must derive Diffie-Hellman keying material Kij based 4299 on the public value and Group ID in the DIFFIE_HELLMAN 4300 parameter. This key is used to derive the HIP association keys, 4301 as described in Section 6.5. If the Diffie-Hellman Group ID is 4302 unsupported, the I2 packet is silently dropped. 4304 11. The encrypted HOST_ID is decrypted by the Initiator's encryption 4305 key defined in Section 6.5. If the decrypted data is not a 4306 HOST_ID parameter, the I2 packet is silently dropped. 4308 12. The implementation SHOULD also verify that the Initiator's HIT 4309 in the I2 packet corresponds to the Host Identity sent in the I2 4310 packet. (Note: some middleboxes may not able to make this 4311 verification.) 4313 13. The system MUST process the TRANSPORT_FORMAT_LIST parameter. 4314 Other documents specifying transport formats (e.g. 4315 [I-D.ietf-hip-rfc5202-bis]) contain specifications for handling 4316 any specific transport selected. 4318 14. The system MUST verify the HIP_MAC according to the procedures 4319 in Section 5.2.12. 4321 15. The system MUST verify the HIP_SIGNATURE according to 4322 Section 5.2.14 and Section 5.3.3. 4324 16. If the checks above are valid, then the system proceeds with 4325 further I2 processing; otherwise, it discards the I2 and its 4326 state machine remains in the same state. 4328 17. The I2 packet may have the A bit set -- in this case, the system 4329 MAY choose to refuse it by dropping the I2 and the state machine 4330 returns to state UNASSOCIATED. If the A bit is set, the 4331 Initiator's HIT is anonymous and should not be stored 4332 permanently. 4334 18. The system initializes the remaining variables in the associated 4335 state, including Update ID counters. 4337 19. Upon successful processing of an I2 message when the system's 4338 state machine is in state UNASSOCIATED, I1-SENT, I2-SENT, or 4339 R2-SENT, an R2 packet is sent and the system's state machine 4340 transitions to state R2-SENT. 4342 20. Upon successful processing of an I2 packet when the system's 4343 state machine is in state ESTABLISHED, the old HIP association 4344 is dropped and a new one is installed, an R2 packet is sent, and 4345 the system's state machine transitions to R2-SENT. 4347 21. Upon the system's state machine transitioning to R2-SENT, the 4348 system starts a timer. The state machine transitions to 4349 ESTABLISHED if some data has been received on the incoming HIP 4350 association, or an UPDATE packet has been received (or some 4351 other packet that indicates that the peer system's state machine 4352 has moved to ESTABLISHED). If the timer expires (allowing for 4353 maximal amount of retransmissions of I2 packets), the state 4354 machine transitions to ESTABLISHED. 4356 6.9.1. Handling of Malformed Messages 4358 If an implementation receives a malformed I2 message, the behavior 4359 SHOULD depend on how many checks the message has already passed. If 4360 the puzzle solution in the message has already been checked, the 4361 implementation SHOULD report the error by responding with a NOTIFY 4362 packet. Otherwise, the implementation MAY respond with an ICMP 4363 message as defined in Section 5.4. 4365 6.10. Processing of Incoming R2 Packets 4367 An R2 packet received in states UNASSOCIATED, I1-SENT, or ESTABLISHED 4368 results in the R2 packet being dropped and the state machine staying 4369 in the same state. If an R2 packet is received in state I2-SENT, it 4370 MUST be processed. 4372 The following steps define the conceptual processing rules for an 4373 incoming R2 packet: 4375 1. If the system is in any other state than I2-SENT, the R2 packet 4376 is silently dropped. 4378 2. The system MUST verify that the HITs in use correspond to the 4379 HITs that were received in the R1 packet that caused the 4380 transition to the I1-SENT state. 4382 3. The system MUST verify the HIP_MAC_2 according to the procedures 4383 in Section 5.2.13. 4385 4. The system MUST verify the HIP signature according to the 4386 procedures in Section 5.2.14. 4388 5. If any of the checks above fail, there is a high probability of 4389 an ongoing man-in-the-middle or other security attack. The 4390 system SHOULD act accordingly, based on its local policy. 4392 6. Upon successful processing of the R2 packet, the state machine 4393 transitions to state ESTABLISHED. 4395 6.11. Sending UPDATE Packets 4397 A host sends an UPDATE packet when it intends to update some 4398 information related to a HIP association. There are a number of 4399 possible scenarios when this can occur, e.g., mobility management and 4400 rekeying of an existing ESP Security Association. The following 4401 paragraphs define the conceptual rules for sending an UPDATE packet 4402 to the peer. Additional steps can be defined in other documents 4403 where the UPDATE packet is used. 4405 The sequence of UPDATE messages is indicated by their SEQ parameter. 4406 Before sending an UPDATE message, the system first determines whether 4407 there are any outstanding UPDATE messages that may conflict with the 4408 new UPDATE message under consideration. When multiple UPDATEs are 4409 outstanding (not yet acknowledged), the sender must assume that such 4410 UPDATEs may be processed in an arbitrary order by the receiver. 4411 Therefore, any new UPDATEs that depend on a previous outstanding 4412 UPDATE being successfully received and acknowledged MUST be postponed 4413 until reception of the necessary ACK(s) occurs. One way to prevent 4414 any conflicts is to only allow one outstanding UPDATE at a time. 4415 However, allowing multiple UPDATEs may improve the performance of 4416 mobility and multihoming protocols. 4418 The following steps define the conceptual processing rules for 4419 sending UPDATE packets. 4421 1. The first UPDATE packet is sent with Update ID of zero. 4422 Otherwise, the system increments its own Update ID value by one 4423 before continuing the steps below. 4425 2. The system creates an UPDATE packet that contains a SEQ parameter 4426 with the current value of Update ID. The UPDATE packet MAY also 4427 include zero or more ACKs of the peer's Update ID(s) from 4428 previously received UPDATE SEQ parameter(s) 4430 3. The system sends the created UPDATE packet and starts an UPDATE 4431 timer. The default value for the timer is 2 * RTT estimate. If 4432 multiple UPDATEs are outstanding, multiple timers are in effect. 4434 4. If the UPDATE timer expires, the UPDATE is resent. The UPDATE 4435 can be resent UPDATE_RETRY_MAX times. The UPDATE timer SHOULD be 4436 exponentially backed off for subsequent retransmissions. If no 4437 acknowledgment is received from the peer after UPDATE_RETRY_MAX 4438 times, the HIP association is considered to be broken and the 4439 state machine SHOULD move from state ESTABLISHED to state CLOSING 4440 as depicted in Section 4.4.4. The UPDATE timer is cancelled upon 4441 receiving an ACK from the peer that acknowledges receipt of the 4442 UPDATE. 4444 6.12. Receiving UPDATE Packets 4446 When a system receives an UPDATE packet, its processing depends on 4447 the state of the HIP association and the presence and values of the 4448 SEQ and ACK parameters. Typically, an UPDATE message also carries 4449 optional parameters whose handling is defined in separate documents. 4451 For each association, a host stores the peer's next expected in- 4452 sequence Update ID ("peer Update ID"). Initially, this value is 4453 zero. Update ID comparisons of "less than" and "greater than" are 4454 performed with respect to a circular sequence number space. Hence, a 4455 wrap around after 2^32 updates has to be expected and MUST be handled 4456 accordingly. 4458 The sender MAY send multiple outstanding UPDATE messages. These 4459 messages are processed in the order in which they are received at the 4460 receiver (i.e., no re-sequencing is performed). When processing 4461 UPDATEs out-of-order, the receiver MUST keep track of which UPDATEs 4462 were previously processed, so that duplicates or retransmissions are 4463 ACKed and not reprocessed. A receiver MAY choose to define a receive 4464 window of Update IDs that it is willing to process at any given time, 4465 and discard received UPDATEs falling outside of that window. 4467 The following steps define the conceptual processing rules for 4468 receiving UPDATE packets. 4470 1. If there is no corresponding HIP association, the implementation 4471 MAY reply with an ICMP Parameter Problem, as specified in 4472 Section 5.4.4. 4474 2. If the association is in the ESTABLISHED state and the SEQ (but 4475 not ACK) parameter is present, the UPDATE is processed and 4476 replied to as described in Section 6.12.1. 4478 3. If the association is in the ESTABLISHED state and the ACK (but 4479 not SEQ) parameter is present, the UPDATE is processed as 4480 described in Section 6.12.2. 4482 4. If the association is in the ESTABLISHED state and there is both 4483 an ACK and SEQ in the UPDATE, the ACK is first processed as 4484 described in Section 6.12.2, and then the rest of the UPDATE is 4485 processed as described in Section 6.12.1. 4487 6.12.1. Handling a SEQ Parameter in a Received UPDATE Message 4489 The following steps define the conceptual processing rules for 4490 handling a SEQ parameter in a received UPDATE packet. 4492 1. If the Update ID in the received SEQ is not the next in the 4493 sequence of Update IDs and is greater than the receiver's window 4494 for new UPDATEs, the packet MUST be dropped. 4496 2. If the Update ID in the received SEQ corresponds to an UPDATE 4497 that has recently been processed, the packet is treated as a 4498 retransmission. The HIP_MAC verification (next step) MUST NOT be 4499 skipped. (A byte-by-byte comparison of the received and a stored 4500 packet would be acceptable, though.) It is recommended that a 4501 host caches UPDATE packets sent with ACKs to avoid the cost of 4502 generating a new ACK packet to respond to a replayed UPDATE. The 4503 system MUST acknowledge, again, such (apparent) UPDATE message 4504 retransmissions but SHOULD also consider rate-limiting such 4505 retransmission responses to guard against replay attacks. 4507 3. The system MUST verify the HIP_MAC in the UPDATE packet. If the 4508 verification fails, the packet MUST be dropped. 4510 4. The system MAY verify the SIGNATURE in the UPDATE packet. If the 4511 verification fails, the packet SHOULD be dropped and an error 4512 message logged. 4514 5. If a new SEQ parameter is being processed, the parameters in the 4515 UPDATE are then processed. The system MUST record the Update ID 4516 in the received SEQ parameter, for replay protection. 4518 6. An UPDATE acknowledgment packet with ACK parameter is prepared 4519 and sent to the peer. This ACK parameter MAY be included in a 4520 separate UPDATE or piggybacked in an UPDATE with SEQ parameter, 4521 as described in Section 5.3.5. The ACK parameter MAY acknowledge 4522 more than one of the peer's Update IDs. 4524 6.12.2. Handling an ACK Parameter in a Received UPDATE Packet 4526 The following steps define the conceptual processing rules for 4527 handling an ACK parameter in a received UPDATE packet. 4529 1. The sequence number reported in the ACK must match with an UPDATE 4530 packet sent earlier that has not already been acknowledged. If 4531 no match is found or if the ACK does not acknowledge a new 4532 UPDATE, the packet MUST either be dropped if no SEQ parameter is 4533 present, or the processing steps in Section 6.12.1 are followed. 4535 2. The system MUST verify the HIP_MAC in the UPDATE packet. If the 4536 verification fails, the packet MUST be dropped. 4538 3. The system MAY verify the SIGNATURE in the UPDATE packet. If the 4539 verification fails, the packet SHOULD be dropped and an error 4540 message logged. 4542 4. The corresponding UPDATE timer is stopped (see Section 6.11) so 4543 that the now acknowledged UPDATE is no longer retransmitted. If 4544 multiple UPDATEs are acknowledged, multiple timers are stopped. 4546 6.13. Processing of NOTIFY Packets 4548 Processing of NOTIFY packets is OPTIONAL. If processed, any errors 4549 in a received NOTIFICATION parameter SHOULD be logged. Received 4550 errors MUST be considered only as informational, and the receiver 4551 SHOULD NOT change its HIP state (see Section 4.4.2) purely based on 4552 the received NOTIFY message. 4554 6.14. Processing CLOSE Packets 4556 When the host receives a CLOSE message, it responds with a CLOSE_ACK 4557 message and moves to CLOSED state. (The authenticity of the CLOSE 4558 message is verified using both HIP_MAC and SIGNATURE). This 4559 processing applies whether or not the HIP association state is 4560 CLOSING in order to handle simultaneous CLOSE messages from both ends 4561 that cross in flight. 4563 The HIP association is not discarded before the host moves to the 4564 UNASSOCIATED state. 4566 Once the closing process has started, any new need to send data 4567 packets triggers creating and establishing of a new HIP association, 4568 starting with sending of an I1 packet. 4570 If there is no corresponding HIP association, the CLOSE packet is 4571 dropped. 4573 6.15. Processing CLOSE_ACK Packets 4575 When a host receives a CLOSE_ACK message, it verifies that it is in 4576 CLOSING or CLOSED state and that the CLOSE_ACK was in response to the 4577 CLOSE. A host can map CLOSE_ACK messages to CLOSE messages by 4578 comparing the value of ECHO_REQUEST_SIGNED (in the CLOSE packet) to 4579 the value of ECHO_RESPONSE_SIGNED (in the CLOSE_ACK packet). 4581 The CLOSE_ACK contains the HIP_MAC and the SIGNATURE parameters for 4582 verification. The state is discarded when the state changes to 4583 UNASSOCIATED and, after that, the host MAY respond with an ICMP 4584 Parameter Problem to an incoming CLOSE message (see Section 5.4.4). 4586 6.16. Handling State Loss 4588 In the case of a system crash and unanticipated state loss, the 4589 system SHOULD delete the corresponding HIP state, including the 4590 keying material. That is, the state SHOULD NOT be stored in long- 4591 term storage. If the implementation does drop the state (as 4592 RECOMMENDED), it MUST also drop the peer's R1 generation counter 4593 value, unless a local policy explicitly defines that the value of 4594 that particular host is stored. An implementation MUST NOT store a 4595 peer's R1 generation counters by default, but storing R1 generation 4596 counter values, if done, MUST be configured by explicit HITs. 4598 7. HIP Policies 4600 There are a number of variables that will influence the HIP base 4601 exchanges that each host must support. All HIP implementations MUST 4602 support more than one simultaneous HI, at least one of which SHOULD 4603 be reserved for anonymous usage. Although anonymous HIs will be 4604 rarely used as Responders' HIs, they will be common for Initiators. 4605 Support for more than two HIs is RECOMMENDED. 4607 Initiators MAY use a different HI for different Responders to provide 4608 basic privacy. Whether such private HIs are used repeatedly with the 4609 same Responder and how long these HIs are used is decided by local 4610 policy and depends on the privacy requirements of the Initiator. 4612 The value of #K used in the HIP R1 must be chosen with care. Too 4613 high numbers of #K will exclude clients with weak CPUs because these 4614 devices cannot solve the puzzle within reasonable time. #K should 4615 only be raised if a Responder is under high load, i.e., it cannot 4616 process all incoming HIP handshakes any more. If a responder is not 4617 under high load, K SHOULD be 0. 4619 Responders that only respond to selected Initiators require an ACL, 4620 representing for which hosts they accept HIP base exchanges, and the 4621 preferred transport format and local lifetimes. Wildcarding SHOULD 4622 be supported for such ACLs, and also for Responders that offer public 4623 or anonymous services. 4625 8. Security Considerations 4627 HIP is designed to provide secure authentication of hosts. HIP also 4628 attempts to limit the exposure of the host to various denial-of- 4629 service and man-in-the-middle (MitM) attacks. In doing so, HIP 4630 itself is subject to its own DoS and MitM attacks that potentially 4631 could be more damaging to a host's ability to conduct business as 4632 usual. 4634 Denial-of-service attacks often take advantage of asymmetries in the 4635 cost of an starting an association. One example of such asymmetry is 4636 the need of a Responder to store local state while a malicious 4637 Initiator can stay stateless. HIP makes no attempt to increase the 4638 cost of the start of state at the Initiator, but makes an effort to 4639 reduce the cost for the Responder. This is accomplished by having 4640 the Responder start the 3-way exchange instead of the Initiator, 4641 making the HIP protocol 4 packets long. In doing this, the first 4642 packet from the Responder, R1, becomes a 'stock' packet that the 4643 Responder MAY use many times, until some Initiator has provided a 4644 valid response to such an R1 packet. During an I1 packet storm, the 4645 host may reuse the same DH value also even if some Initiator has 4646 provided a valid response using that particular DH value. However, 4647 such behavior is discouraged and should be avoided. Using the same 4648 Diffie-Hellman values and random puzzle #I value has some risks. 4649 This risk needs to be balanced against a potential storm of HIP I1 4650 packets. 4652 This shifting of the start of state cost to the Initiator in creating 4653 the I2 HIP packet presents another DoS attack. The attacker can 4654 spoof the I1 packet and the Responder sends out the R1 HIP packet. 4655 This could conceivably tie up the 'Initiator' with evaluating the R1 4656 HIP packet, and creating the I2 packet. The defense against this 4657 attack is to simply ignore any R1 packet where a corresponding I1 4658 packet was not sent (as defined in Section 6.8 step 1). 4660 The R1 packet is considerably larger than the I1 packet. This 4661 asymmetry can be exploited in an reflection attack. A malicious 4662 attacker could spoof the IP address of a victim and send a flood of 4663 I1 messages to a powerful Responder. For each small I1 packet, the 4664 Responder would send a larger R1 packet to the victim. The 4665 difference in packet sizes can further amplify a flooding attack 4666 against the victim. To avoid such reflection attacks, the Responder 4667 SHOULD rate limit the sending of R1 packets in general or SHOULD rate 4668 limit the sending of R1 packets to a specific IP address. 4670 Floods of forged I2 packets form a second kind of DoS attack. Once 4671 the attacking Initiator has solved the puzzle, it can send packets 4672 with spoofed IP source addresses with either an invalid HIP signature 4673 or invalid encrypted HIP payload (in the ENCRYPTED parameter). This 4674 would take resources in the Responder's part to reach the point to 4675 discover that the I2 packet cannot be completely processed. The 4676 defense against this attack is after N bad I2 packets with the same 4677 puzzle solution, the Responder would discard any I2 packets that 4678 contain the given solution. This will shut down the attack. The 4679 attacker would have to request another R1 packet and use that to 4680 launch a new attack. The Responder could increase the value of #K 4681 while under attack. Keeping a list of solutions from malformed 4682 packets requires that the Responder keeps state for these malformed 4683 I2 packets. This state has to be kept until the R1 counter is 4684 increased. As malformed packets are generally filtered by their 4685 checksum before signature verification, only solutions in packets 4686 that are forged to pass the checksum and puzzle are put to the 4687 blacklist. In addition, a valid puzzle is required before a new list 4688 entry is created. Hence, attackers that intend to flood the 4689 blacklist must solve puzzles first. 4691 A third form of DoS attack is emulating the restart of state after a 4692 reboot of one of the peers. A restarting host would send an I1 4693 packet to the peers, which would respond with an R1 packet even if it 4694 were in the ESTABLISHED state. If the I1 packet were spoofed, the 4695 resulting R1 packet would be received unexpectedly by the spoofed 4696 host and would be dropped, as in the first case above. 4698 A fourth form of DoS attack is emulating closing of the HIP 4699 association. HIP relies on timers and a CLOSE/CLOSE_ACK handshake to 4700 explicitly signal the end of a HIP association. Because both CLOSE 4701 and CLOSE_ACK messages contain a HIP_MAC, an outsider cannot close a 4702 connection. The presence of an additional SIGNATURE allows 4703 middleboxes to inspect these messages and discard the associated 4704 state (for e.g., firewalling, SPI-based NATing, etc.). However, the 4705 optional behavior of replying to CLOSE with an ICMP Parameter Problem 4706 packet (as described in Section 5.4.4) might allow an attacker 4707 spoofing the source IP address to send CLOSE messages to launch 4708 reflection attacks. 4710 A fifth form of DoS attack is replaying R1s to cause the Initiator to 4711 solve stale puzzles and become out of synchronization with the 4712 Responder. The R1 generation counter is a monotonically increasing 4713 counter designed to protect against this attack, as described in 4714 Section 4.1.4. 4716 Man-in-the-middle attacks are difficult to defend against, without 4717 third-party authentication. A skillful MitM could easily handle all 4718 parts of HIP, but HIP indirectly provides the following protection 4719 from a MitM attack. If the Responder's HI is retrieved from a signed 4720 DNS zone, a certificate, or through some other secure means, the 4721 Initiator can use this to validate the R1 HIP packet. 4723 Likewise, if the Initiator's HI is in a secure DNS zone, a trusted 4724 certificate, or otherwise securely available, the Responder can 4725 retrieve the HI (after having got the I2 HIP packet) and verify that 4726 the HI indeed can be trusted. 4728 The HIP Opportunistic Mode concept has been introduced in this 4729 document, but this document does not specify what the semantics of 4730 such a connection setup are for applications. There are certain 4731 concerns with opportunistic mode, as discussed in Section 4.1.8. 4733 NOTIFY messages are used only for informational purposes and they are 4734 unacknowledged. A HIP implementation cannot rely solely on the 4735 information received in a NOTIFY message because the packet may have 4736 been replayed. An implementation SHOULD NOT change any state 4737 information purely based on a received NOTIFY message. 4739 Since not all hosts will ever support HIP, ICMP 'Destination Protocol 4740 Unreachable' messages are to be expected and may be used for a DoS 4741 attack. Against an Initiator, the attack would look like the 4742 Responder does not support HIP, but shortly after receiving the ICMP 4743 message, the Initiator would receive a valid R1 HIP packet. Thus, to 4744 protect from this attack, an Initiator SHOULD NOT react to an ICMP 4745 message until a reasonable delta time to get the real Responder's R1 4746 HIP packet. A similar attack against the Responder is more involved. 4747 Normally, if an I1 message received by a Responder was a bogus one 4748 sent by an attacker, the Responder may receive an ICMP message from 4749 the IP address the R1 message was sent to. However, a sophisticated 4750 attacker can try to take advantage of such a behavior and try to 4751 break up the HIP base exchange by sending such an ICMP message to the 4752 Responder before the Initiator has a chance to send a valid I2 4753 message. Hence, the Responder SHOULD NOT act on such an ICMP 4754 message. Especially, it SHOULD NOT remove any minimal state created 4755 when it sent the R1 HIP packet (if it did create one), but wait for 4756 either a valid I2 HIP packet or the natural timeout (that is, if R1 4757 packets are tracked at all). Likewise, the Initiator SHOULD ignore 4758 any ICMP message while waiting for an R2 HIP packet, and SHOULD 4759 delete any pending state only after a natural timeout. 4761 9. IANA Considerations 4763 IANA has reserved protocol number 139 for the Host Identity Protocol 4764 and included it in the "IPv6 Extension Header Types" registry 4765 [RFC7045] and the "Assigned Internet Protocol Numbers" registry. The 4766 reference in both of these registries should be updated from 4767 [RFC5201] to this specification. 4769 The reference to the 128-bit value under the CGA Message Type 4770 namespace [RFC3972] of "0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA" 4771 should be changed from [RFC5201] to this specification. 4773 The following changes to the "Host Identity Protocol (HIP) 4774 Parameters" registries are requested. In many cases, the changes 4775 required involve updating the reference from [RFC5201] to this 4776 specification, but there are some differences as outlined below. 4777 Allocation terminology is defined in [RFC5226]; any existing 4778 references to "IETF Consensus" can be replaced with "IETF Review" as 4779 per [RFC5226]. 4781 HIP Version 4783 This document adds the value "2" to the existing registry. The 4784 value of "1" should be left with a reference to [RFC5201]. 4786 Packet Type 4788 The 7-bit Packet Type field in a HIP protocol packet describes the 4789 type of a HIP protocol message. It is defined in Section 5.1. 4791 All existing values referring to [RFC5201] should be updated to 4792 refer to this specification. Other values should be left 4793 unchanged. 4795 HIT Suite ID 4797 This specification creates a new registry for "HIT Suite ID". 4798 This is different than the existing registry for "Suite ID" which 4799 can be left unmodified for version 1 of the protocol ([RFC5201]). 4800 The registry should be closed to new registrations. 4802 The four-bit HIT Suite ID uses the OGA field in the ORCHID to 4803 express the type of the HIT. This document defines three HIT 4804 Suites (see Appendix E). 4806 The HIT Suite ID is also carried in the four higher-order bits of 4807 the ID field in the HIT_SUITE_LIST parameter. The four lower- 4808 order bits are reserved for future extensions of the HIT Suite ID 4809 space beyond 16 values. 4811 For the time being, the HIT Suite uses only four bits because 4812 these bits have to be carried in the HIT. Using more bits for the 4813 HIT Suite ID reduces the cryptographic strength of the HIT. HIT 4814 Suite IDs must be allocated carefully to avoid namespace 4815 exhaustion. Moreover, deprecated IDs should be reused after an 4816 appropriate time span. If 16 Suite IDs prove insufficient and 4817 more HIT Suite IDs are needed concurrently, more bits can be used 4818 for the HIT Suite ID by using one HIT Suite ID (0) to indicate 4819 that more bits should be used. The HIT_SUITE_LIST parameter 4820 already supports 8-bit HIT Suite IDs, should longer IDs be needed. 4821 Possible extensions of the HIT Suite ID space to accommodate eight 4822 bits and new HIT Suite IDs are defined through IETF Review. 4824 Requests to register reused values should include a note that the 4825 value is being reused after a deprecation period, to ensure 4826 appropriate IETF review and approval. 4828 Parameter Type 4830 The 16-bit Type field in a HIP parameter describes the type of the 4831 parameter. It is defined in Section 5.2.1. The current values 4832 are defined in Sections 5.2.3 through 5.2.23. The existing 4833 registry for "Parameter Type" should be updated as follows. 4835 A new value (129) for R1_COUNTER should be introduced, with a 4836 reference to this specification, and the existing value (128) for 4837 R1_COUNTER left in place with a reference to [RFC5201]. This 4838 documents the change in value that has occurred in version 2 of 4839 this protocol. For clarity, we recommend that the name for the 4840 value 128 be changed from "R1_COUNTER" to "R1_Counter (v1 only)". 4842 A new value (579) for a new Parameter Type HIP_CIPHER should be 4843 added, with reference to this specification. This Parameter Type 4844 functionally replaces the HIP_TRANSFORM Parameter Type (value 577) 4845 which can be left in the table with existing reference to 4846 [RFC5201]. For clarity, we recommend that the name for the value 4847 577 be changed from "HIP_TRANSFORM" to "HIP_TRANSFORM (v1 only)". 4849 A new value (715) for a new Parameter Type HIT_SUITE_LIST should 4850 be added, with reference to this specification. 4852 A new value (2049) for a new Parameter Type TRANSPORT_FORMAT_LIST 4853 should be added, with reference to this specification. 4855 The name of the HMAC Parameter Type (value 61505) should be 4856 changed to HIP_MAC. The name of the HMAC_2 Parameter Type (value 4857 61569) should be changed to HIP_MAC_2. The reference should be 4858 changed to this specification. 4860 All other Parameter Types that reference [RFC5201] should be 4861 updated to refer to this specification, and Parameter Types that 4862 reference other RFCs should be unchanged. 4864 Regarding the range assignments, the Type codes 32768 through 4865 49151 (not 49141) should be Reserved for Private Use. Where the 4866 existing ranges state "First Come First Served with Specification 4867 Required", this should be changed to "Specification Required". 4869 The Type codes 32768 through 49151 are reserved for 4870 experimentation. Implementors SHOULD select types in a random 4871 fashion from this range, thereby reducing the probability of 4872 collisions. A method employing genuine randomness (such as 4873 flipping a coin) SHOULD be used. 4875 Group ID 4877 The eight-bit Group ID values appear in the DIFFIE_HELLMAN 4878 parameter and the DH_GROUP_LIST parameter and are defined in 4879 Section 5.2.7. This registry should be updated based on the new 4880 values specified in Section 5.2.7; values noted as being 4881 DEPRECATED can be left in the table with reference to [RFC5201]. 4882 New values are assigned through IETF Review. 4884 HIP Cipher ID 4885 The 16-bit Cipher ID values in a HIP_CIPHER parameter are defined 4886 in Section 5.2.8. This is a new registry. New values either from 4887 the reserved or unassigned space are assigned through IETF Review. 4889 DI-Type 4891 The four-bit DI-Type values in a HOST_ID parameter are defined in 4892 Section 5.2.9. New values are assigned through IETF Review. All 4893 existing values referring to [RFC5201] should be updated to refer 4894 to this specification. 4896 HI Algorithm 4898 The 16-bit Algorithm values in a HOST_ID parameter are defined in 4899 Section 5.2.9. This is a new registry. New values either from 4900 the reserved or unassigned space are assigned through IETF Review. 4902 ECC Curve Label 4904 When the HI Algorithm values in a HOST_ID parameter is defined to 4905 the values of either "ECDSA" or "ECDSA_LOW", a new registry is 4906 needed to maintain the values for the ECC Curve Label as defined 4907 in Section 5.2.9. This might be handled by specifying two 4908 algorithm-specific sub-registries named "ECDSA Curve Label" and 4909 "ECDSA_LOW Curve Label". New values are to be assigned through 4910 IETF Review. 4912 Notify Message Type 4914 The 16-bit Notify Message Type values in a NOTIFICATION parameter 4915 are defined in Section 5.2.19. 4917 Notify Message Type values 1-10 are used for informing about 4918 errors in packet structures, values 11-20 for informing about 4919 problems in parameters containing cryptographic related material, 4920 values 21-30 for informing about problems in authentication or 4921 packet integrity verification. Parameter numbers above 30 can be 4922 used for informing about other types of errors or events. 4924 The existing registration procedures should be updated as follows. 4925 The range from 1-50 can remain as "IETF Review". The range from 4926 51-8191 should be marked as "Specification Required". Values 4927 8192-16383 can remain as "Reserved for Private Use". Values 4928 16385-40959 should be marked as "Specification Required". Values 4929 40960-65535 can remain as "Reserved for Private Use". 4931 The following updates to the values should be made to the existing 4932 registry. All existing values referring to [RFC5201] should be 4933 updated to refer to this specification. 4935 INVALID_HIP_TRANSFORM_CHOSEN should be renamed to 4936 INVALID_HIP_CIPHER_CHOSEN with the same value (17). 4938 A new value of 20 for the type UNSUPPORTED_HIT_SUITE should be 4939 added. 4941 HMAC_FAILED should be renamed to HIP_MAC_FAILED with the same 4942 value (28). 4944 SERVER_BUSY_PLEASE_RETRY should be renamed to 4945 RESPONDER_BUSY_PLEASE_RETRY with the same value (44). 4947 10. Acknowledgments 4949 The drive to create HIP came to being after attending the MALLOC 4950 meeting at the 43rd IETF meeting. Baiju Patel and Hilarie Orman 4951 really gave the original author, Bob Moskowitz, the assist to get HIP 4952 beyond 5 paragraphs of ideas. It has matured considerably since the 4953 early versions thanks to extensive input from IETFers. Most 4954 importantly, its design goals are articulated and are different from 4955 other efforts in this direction. Particular mention goes to the 4956 members of the NameSpace Research Group of the IRTF. Noel Chiappa 4957 provided valuable input at early stages of discussions about 4958 identifier handling and Keith Moore the impetus to provide 4959 resolvability. Steve Deering provided encouragement to keep working, 4960 as a solid proposal can act as a proof of ideas for a research group. 4962 Many others contributed; extensive security tips were provided by 4963 Steve Bellovin. Rob Austein kept the DNS parts on track. Paul 4964 Kocher taught Bob Moskowitz how to make the puzzle exchange expensive 4965 for the Initiator to respond, but easy for the Responder to validate. 4966 Bill Sommerfeld supplied the Birthday concept, which later evolved 4967 into the R1 generation counter, to simplify reboot management. Erik 4968 Nordmark supplied the CLOSE-mechanism for closing connections. 4969 Rodney Thayer and Hugh Daniels provided extensive feedback. In the 4970 early times of this document, John Gilmore kept Bob Moskowitz 4971 challenged to provide something of value. 4973 During the later stages of this document, when the editing baton was 4974 transferred to Pekka Nikander, the input from the early implementors 4975 was invaluable. Without having actual implementations, this document 4976 would not be on the level it is now. 4978 In the usual IETF fashion, a large number of people have contributed 4979 to the actual text or ideas. The list of these people include Jeff 4980 Ahrenholz, Francis Dupont, Derek Fawcus, George Gross, Andrew 4981 McGregor, Julien Laganier, Miika Komu, Mika Kousa, Jan Melen, Henrik 4982 Petander, Michael Richardson, Rene Hummen, Tim Shepard, Jorma Wall, 4983 Xin Gu, and Jukka Ylitalo. Our apologies to anyone whose name is 4984 missing. 4986 Once the HIP Working Group was founded in early 2004, a number of 4987 changes were introduced through the working group process. Most 4988 notably, the original document was split in two, one containing the 4989 base exchange and the other one defining how to use ESP. Some 4990 modifications to the protocol proposed by Aura, et al., [AUR03] were 4991 added at a later stage. 4993 11. Changes from RFC 5201 4995 This section summarizes the changes made from [RFC5201]. 4997 11.1. Changes from draft-ietf-hip-rfc5201-bis-18 4999 o Correct documentation prefix in Appendix C from 2001:D88/32 to 5000 2001:DB8/32, and update IPv6 checksum 5002 o Correct documentation prefix reference from RFC 5747 to 5737 5004 o Clarified HIT generation in Appendix E 5006 11.2. Changes from draft-ietf-hip-rfc5201-bis-17 5008 o Update ORCHID reference to newly published RFC 7343 5010 o Update example checksum section to RFC 7343 HIT prefix of 5011 2001:20::/28, and fix incorrect Header Length fields 5013 o Update IANA considerations comment on legacy HIP_TRANSFORM 5014 parameter naming 5016 o Add 2048-bit MODP DHE group as Group ID value 11. 5018 11.3. Changes from draft-ietf-hip-rfc5201-bis-16 5020 o Clarify that receipt of user data in state CLOSING (Table 7) 5021 results in transition to I1-SENT 5023 o Add academic reference for the first mention of the RSA algorithm 5024 o As part of comment resolution on use of NULL encryption, note that 5025 use of a NULL HIP CIPHER is only to be used when debugging and 5026 testing the HIP protocol. This only pertains to the ENCRYPTED 5027 parameter, which is optional; in practice, if encryption is not 5028 desired, better to just not encrypt the Host ID. 5030 11.4. Changes from draft-ietf-hip-rfc5201-bis-15 5032 o Additional edits to IANA Considerations section based on initial 5033 IANA review. 5035 11.5. Changes from draft-ietf-hip-rfc5201-bis-14 5037 o Update source XML to comply with xmlrfcv2 version of the xml2rfc 5038 tool, resulting in a few table formatting changes. 5040 o Editorial and minor technical revisions based on IESG review. 5042 o Significant revisions to IANA Considerations section based on 5043 initial IANA review. 5045 11.6. Changes from draft-ietf-hip-rfc5201-bis-13 5047 o Update a few references and fix some editorial nits. 5049 11.7. Changes from draft-ietf-hip-rfc5201-bis-12 5051 o Fix I-D nits. 5053 11.8. Changes from draft-ietf-hip-rfc5201-bis-11 5055 o Specify that TRANSPORT_FORMAT_LIST is mandatory in R1 and I2; fix 5056 incorrect section reference. 5058 11.9. Changes from draft-ietf-hip-rfc5201-bis-10 5060 o Issue 39: Text clarifying R1 counter rollover and Initiator 5061 response to unexpected reset of the counter. 5063 11.10. Changes from draft-ietf-hip-rfc5201-bis-09 5065 o Editorial changes based on working group last call. 5067 11.11. Changes from draft-ietf-hip-rfc5201-bis-08 5069 o Issue 29: Use different RSA mode OEAP/PSS, elevate ECDSA to 5070 REQUIRED status 5072 o Issue 35: limiting ECC cofactor to 1 5074 o Changed text regarding issue 33 reusing DH values 5076 o Fix tracker issue 32 on Domain Identifier normative text 5078 11.12. Changes from draft-ietf-hip-rfc5201-bis-07 5080 o Removed lingering references to SHA-1 as the mandatory hash 5081 algorithm (which was changed to SHA-256 in the -02 draft version). 5083 o For parameter type number changes, changed "IETF Review" to "IETF 5084 Review or IESG Approval". 5086 o Updated Appendix C checksum examples to conform to HIPv2 packets. 5088 11.13. Changes from draft-ietf-hip-rfc5201-bis-06 5090 o Made echoing the R1_COUNTER in the I2 mandatory if the R1 contains 5091 an R1_COUNTER. This required to make the R1 counter a critical 5092 parameter. Hence, the parameter type number of the R1_COUNTER 5093 changed from 128 to 129. 5095 o Made KDF dependent on DH Group to enable negotiation of the KDF. 5097 11.14. Changes from draft-ietf-hip-rfc5201-bis-05 5099 o Changed type number of DH_GROUP_LIST from 2151 to 511 because it 5100 was in the number space that is reserved for the HIP transport 5101 mode negotiations. 5103 o Added transport form type list parameter. Transport forms are now 5104 negotiated with this list instead of by their order in the HIP 5105 packet. This allows to remove the exception of the transport 5106 format parameters that were ordered by their preference instead of 5107 by their type number. This should remove complexity from 5108 implementations. 5110 o Clarify that in HIP signature processing, the restored checksum 5111 and length fields have been rendered invalid by the previous 5112 steps. 5114 o Clarify behavior for when UPDATE does not contain SEQ or ACQ 5115 (disallow this). 5117 o For namespace changes, changed "IETF Review" to "IETF Review or 5118 IESG Approval". 5120 o Addressed IESG comment about ignoring packet IP addresses. 5122 o Permit using Anonymous HI control in packets other than R1/I2. 5124 o Fixed minor reference error (RFC2418, RFC2410). 5126 o Deleted comment that NULL-ENCRYPTION SHOULD NOT be configurable 5127 via the UI. 5129 o Editorial changes. 5131 11.15. Changes from draft-ietf-hip-rfc5201-bis-04 5133 o Clarifications of the Security Considerations section. One DoS 5134 defense mechanism was changed to be more effective and less prone 5135 to misuse. 5137 o Minor clarifications of the state machine. 5139 o Clarified text on HIP puzzle. 5141 o Added names and references for figures. 5143 o Extended the definitions section. 5145 o Added a reference to the HIP Version 1 certificate document. 5147 o Added Initiator, Responder, HIP association, and signed data to 5148 the definitions section. 5150 o Changed parameter figure for PUZZLE and SOLUTION to use 5151 RHASH_len/8 instead of n-byte. 5153 o Replaced occurrences of lowercase 'not' in SHOULD NOT. 5155 o Changed text to reflect the fact that several 5156 ECHO_REQUEST_UNSIGNED parameters may be present in an R1 and 5157 several ECHO_RESPONSE parameters may be present in an I2. 5159 o Added text on verifying the ECHO_RESPONSE_SIGNED parameter in 5160 CLOSE_ACK. 5162 o Changed wording from HMAC to HIP_MAC in Section 5.3.8. 5164 o Reflected fact that the UPDATE packet MAY include zero or more 5165 ACKs. 5167 o Added BEX to Definitions section. 5169 o Changed HIP_SIGNATURE algorithm field from 8 bit to 16 bit to 5170 achieve alignment with the HOST_ID parameters. 5172 o Fixed the wrong figures of the SEQ and ACK parameters. SEQ always 5173 contains ONE update ID. ACK may acknowledge SEVERAL update IDs. 5175 o Added wording that several NOTIFY parameters may be present in a 5176 HIP packet. 5178 o Changed wording for the ECHO_RESPONSE_SIGNED parameter. Also 5179 lifted the restriction that only one ECHO_RESPONSE_UNSIGNED 5180 parameter MUST be present in each HIP packet. This did contradict 5181 the definition of the ECHO_RESPONSE_UNSIGNED parameter. 5183 o Changed IETF Consensus to IETF Review or IESG Approval in IANA 5184 section. 5186 o Aligned use of I, J, and K. Now I is #I, J is #J and K is #K 5187 throughout the document. 5189 o Updated references. 5191 o Editorial changes. 5193 11.16. Changes from draft-ietf-hip-rfc5201-bis-03 5195 o Editorial changes to improve clarity and readability. 5197 o Removed obsoleted (not applicable) attack from security 5198 consideration section. 5200 o Added a requirement that hosts MUST support processing of ACK 5201 parameters with several SEQ numbers even when they do not support 5202 sending such parameters. 5204 o Removed note on memory bound puzzles. The use of memory bound 5205 puzzles was reconsidered but no convincing arguments for inclusion 5206 in this document have been made on the list. 5208 o Changed references to reference the new bis documents. 5210 o Specified the ECC curves and the hashes used for these. 5212 o Specified representation of ECC curves in the HI. 5214 o Added text on the dependency between RHASH and HMAC. 5216 o Rephrased part of the security considerations to make them 5217 clearer. 5219 o Clarified the use of HITs in opportunistic mode. 5221 o Clarified the difference between HIP_MAC and HIP_MAC_2 as well as 5222 between SIGNATURE and SIGNATURE_2. 5224 o Changed NOTIFY name for value 44 from SERVER_BUSY_PLEASE_RETRY to 5225 RESPONDER_BUSY_PLEASE_RETRY. 5227 o Mentioned that there are multiple valid puzzle solutions. 5229 11.17. Changes from draft-ietf-hip-rfc5201-bis-02 5231 o Added recommendation to not use puzzle #I twice for the same host 5232 to avoid identical key material. 5234 o Revised state machine and added missing event handling. 5236 o Added UNSUPPORTED_HIT_SUITE to NOTIFY to indicate unsupported HIT 5237 suites. 5239 o Revised parameter type numbers (corresponding to IANA allocations) 5240 and added missing "free for experimentation" range to the 5241 description. 5243 o Clarifying note on the use of the C bit in the parameter type 5244 numbers. 5246 11.18. Changes from draft-ietf-hip-rfc5201-bis-01 5248 o Changed RHASH-len to RHASH_len to avoid confusion in calculations 5249 (- could be minus) 5251 o Added RHASH_len to list of abbreviations 5253 o Fixed length of puzzle #I and #J to be 1*RHASH_len 5255 o Changed RHASH-len to RHASH_len to avoid confusion in calculations 5256 (- could be minus) 5258 o Added RHASH_len to list of abbreviations 5260 o Fixed length of puzzle #I and #J to be 1*RHASH_len 5262 o Included HIT_SUITEs. 5264 o Added DH negotiation to I1 and R1. 5266 o Added DH_LIST parameter. 5268 o Added text for DH Group negotiation. 5270 o Removed second DH public value from DH parameter. 5272 o Added ECC to HI generation. 5274 o Added Responder HIT selection to opportunistic mode. 5276 o Added ECDSA HI text and references (not complete yet). 5278 o Added separate section on aborting BEX. 5280 o Added separate section on downgrade attack prevention. 5282 o Added text about DH Group selection for use cases without I1. 5284 o Removed type range allocation for parameters related to HIP 5285 transform types. 5287 o New type range allocation for parameters that are only covered by 5288 a signature if a signature is present (Applies to DH_GROUP_LIST). 5290 o Renamed HIP_TRANSFORM to HIP_CIPHER and removed hashes from it - 5291 hashes are determined by RHASH. 5293 o The length of #I and #J for the puzzle now depends on RHASH. 5295 o New keymat generation. 5297 o Puzzle seed and solution now use RHASH and have variable length. 5299 o Moved timing definitions closer to state machine. 5301 o Simplified text regarding puzzle lifetime. 5303 o Clarified the description of the use of #I in the puzzle 5305 o Removed "Opportunistic mode" description from general definitions. 5307 o More consistency across the old RFC5201 text. Aligned 5308 capitalization and abbreviations. 5310 o Extended protocol overview to include restart option. 5312 o Extended state machine to include restart option because of 5313 unsupported Algorithms. 5315 o Replaced SHA-1 with SHA-256 for required implementation. 5317 o Added OGA list parameter (715) for detecting the Responder's set 5318 of OGAs. 5320 o Added Appendix on ORCHID use in HITs. 5322 o Added truncated SHA-256 option for HITs. 5324 o Added truncated SHA-1 option for HITs. 5326 o Added text about new ORCHID structure to HIT overview. 5328 o Moved Editor role to Robert Moskowitz. 5330 o Added SHA-256 to puzzle parameter. 5332 o Generalized LTRUNC to be hash-function agnostic. 5334 o Added text about RHASH depending on OGA. 5336 11.19. Changes from draft-ietf-hip-rfc5201-bis-00 5338 o Added reasoning why BIS document is needed. 5340 11.20. Contents of draft-ietf-hip-rfc5201-bis-00 5342 o RFC5201 was submitted as draft-RFC. 5344 12. References 5346 12.1. Normative References 5348 [FIPS.180-2.2002] 5349 National Institute of Standards and Technology, "Secure 5350 Hash Standard", FIPS PUB 180-2, August 2002, 5351 . 5354 [I-D.ietf-hip-rfc5202-bis] 5355 Jokela, P., Moskowitz, R., and J. Melen, "Using the 5356 Encapsulating Security Payload (ESP) Transport Format with 5357 the Host Identity Protocol (HIP)", draft-ietf-hip- 5358 rfc5202-bis-05 (work in progress), November 2013. 5360 [NIST.800-131A.2011] 5361 National Institute of Standards and Technology, 5362 "Transitions: Recommendation for Transitioning the Use of 5363 Cryptographic Algorithms and Key Lengths", NIST 800-131A, 5364 January 2011. 5366 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 5367 August 1980. 5369 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 5370 793, September 1981. 5372 [RFC1035] Mockapetris, P., "Domain names - implementation and 5373 specification", STD 13, RFC 1035, November 1987. 5375 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 5376 Requirement Levels", BCP 14, RFC 2119, March 1997. 5378 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within 5379 ESP and AH", RFC 2404, November 1998. 5381 [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and 5382 Its Use With IPsec", RFC 2410, November 1998. 5384 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 5385 (IPv6) Specification", RFC 2460, December 1998. 5387 [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System 5388 (DNS)", RFC 2536, March 1999. 5390 [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain 5391 Name System (DNS)", RFC 3110, May 2001. 5393 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 5394 Diffie-Hellman groups for Internet Key Exchange (IKE)", 5395 RFC 3526, May 2003. 5397 [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher 5398 Algorithm and Its Use with IPsec", RFC 3602, September 5399 2003. 5401 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 5402 RFC 3972, March 2005. 5404 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 5405 Rose, "Resource Records for the DNS Security Extensions", 5406 RFC 4034, March 2005. 5408 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 5409 Network Access Identifier", RFC 4282, December 2005. 5411 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 5412 Message Protocol (ICMPv6) for the Internet Protocol 5413 Version 6 (IPv6) Specification", RFC 4443, March 2006. 5415 [RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using 5416 the Elliptic Curve Digital Signature Algorithm (ECDSA)", 5417 RFC 4754, January 2007. 5419 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 5420 384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007. 5422 [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY 5423 and RRSIG Resource Records for DNSSEC", RFC 5702, October 5424 2009. 5426 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 5427 "Default Address Selection for Internet Protocol Version 6 5428 (IPv6)", RFC 6724, September 2012. 5430 [RFC7343] Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay 5431 Routable Cryptographic Hash Identifiers Version 2 5432 (ORCHIDv2)", RFC 7343, September 2014. 5434 12.2. Informative References 5436 [AUR03] Aura, T., Nagarajan, A., and A. Gurtov, "Analysis of the 5437 HIP Base Exchange Protocol", in Proceedings of 10th 5438 Australasian Conference on Information Security and 5439 Privacy, July 2003. 5441 [CRO03] Crosby, SA. and DS. Wallach, "Denial of Service via 5442 Algorithmic Complexity Attacks", in Proceedings of Usenix 5443 Security Symposium 2003, Washington, DC., August 2003. 5445 [DIF76] Diffie, W. and M. Hellman, "New Directions in 5446 Cryptography", IEEE Transactions on Information Theory 5447 vol. IT-22, number 6, pages 644-654, Nov 1976. 5449 [FIPS.197.2001] 5450 National Institute of Standards and Technology, "Advanced 5451 Encryption Standard (AES)", FIPS PUB 197, November 2001, 5452 . 5455 [FIPS186-3] 5456 U.S. Department of Commerce/National Institute of 5457 Standards and Technology, "FIPS PUB 186-3: Digital 5458 Signature Standard (DSS).", June 2009. 5460 [I-D.ietf-hip-rfc4423-bis] 5461 Moskowitz, R., "Host Identity Protocol Architecture", 5462 draft-ietf-hip-rfc4423-bis-05 (work in progress), 5463 September 2012. 5465 [I-D.ietf-hip-rfc5204-bis] 5466 Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 5467 Rendezvous Extension", draft-ietf-hip-rfc5204-bis-02 (work 5468 in progress), September 2012. 5470 [I-D.ietf-hip-rfc5205-bis] 5471 Laganier, J., "Host Identity Protocol (HIP) Domain Name 5472 System (DNS) Extension", draft-ietf-hip-rfc5205-bis-02 5473 (work in progress), September 2012. 5475 [I-D.ietf-hip-rfc5206-bis] 5476 Henderson, T., Vogt, C., and J. Arkko, "Host Mobility with 5477 the Host Identity Protocol", draft-ietf-hip-rfc5206-bis-06 5478 (work in progress), July 2013. 5480 [KAU03] Kaufman, C., Perlman, R., and B. Sommerfeld, "DoS 5481 protection for UDP-based protocols", ACM Conference on 5482 Computer and Communications Security , Oct 2003. 5484 [KRA03] Krawczyk, H., "SIGMA: The 'SIGn-and-MAc' Approach to 5485 Authenticated Diffie-Hellman and Its Use in the IKE- 5486 Protocols", in Proceedings of CRYPTO 2003, pages 400-425, 5487 August 2003. 5489 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 5490 RFC 792, September 1981. 5492 [RFC2785] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup" 5493 Attacks on the Diffie-Hellman Key Agreement Method for S/ 5494 MIME", RFC 2785, March 2000. 5496 [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography 5497 Specification Version 2.0", RFC 2898, September 2000. 5499 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 5500 Standards (PKCS) #1: RSA Cryptography Specifications 5501 Version 2.1", RFC 3447, February 2003. 5503 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 5504 Reserved for Documentation", RFC 3849, July 2004. 5506 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 5507 "Host Identity Protocol", RFC 5201, April 2008. 5509 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 5510 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 5511 May 2008. 5513 [RFC5338] Henderson, T., Nikander, P., and M. Komu, "Using the Host 5514 Identity Protocol with Legacy Applications", RFC 5338, 5515 September 2008. 5517 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 5518 Shim Protocol for IPv6", RFC 5533, June 2009. 5520 [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks 5521 Reserved for Documentation", RFC 5737, January 2010. 5523 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 5524 Key Derivation Function (HKDF)", RFC 5869, May 2010. 5526 [RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a 5527 Prime (ECP Groups) for IKE and IKEv2", RFC 5903, June 5528 2010. 5530 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 5531 "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5532 5996, September 2010. 5534 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 5535 Curve Cryptography Algorithms", RFC 6090, February 2011. 5537 [RFC6253] Heer, T. and S. Varjonen, "Host Identity Protocol 5538 Certificates", RFC 6253, May 2011. 5540 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 5541 of IPv6 Extension Headers", RFC 7045, December 2013. 5543 [RSA] Rivest, R., Shamir, A., and L. Adleman, "A Method for 5544 Obtaining Digital Signatures and Public-Key 5545 Cryptosystems", Communications of the ACM 21 (2), pp. 5546 120-126, February 1978. 5548 [SECG] SECG, "Recommended Elliptic Curve Domain Parameters", SEC 5549 2 , 2000, . 5551 Appendix A. Using Responder Puzzles 5553 As mentioned in Section 4.1.1, the Responder may delay state creation 5554 and still reject most spoofed I2 packets by using a number of pre- 5555 calculated R1 packets and a local selection function. This appendix 5556 defines one possible implementation in detail. The purpose of this 5557 appendix is to give the implementors an idea on how to implement the 5558 mechanism. If the implementation is based on this appendix, it MAY 5559 contain some local modification that makes an attacker's task harder. 5561 The Responder creates a secret value S, that it regenerates 5562 periodically. The Responder needs to remember the two latest values 5563 of S. Each time the S is regenerated, the R1 generation counter 5564 value is incremented by one. 5566 The Responder generates a pre-signed R1 packet. The signature for 5567 pre-generated R1s must be recalculated when the Diffie-Hellman key is 5568 recomputed or when the R1_COUNTER value changes due to S value 5569 regeneration. 5571 When the Initiator sends the I1 packet for initializing a connection, 5572 the Responder receives the HIT and IP address from the packet, and 5573 generates an #I value for the puzzle. The #I value is set to the 5574 pre-signed R1 packet. 5576 #I value calculation: 5577 #I = Ltrunc( RHASH ( S | HIT-I | HIT-R | IP-I | IP-R ), n) 5578 where n = RHASH_len 5580 The RHASH algorithm is the same that is used to generate the 5581 Responder's HIT value. 5583 From an incoming I2 packet, the Responder receives the required 5584 information to validate the puzzle: HITs, IP addresses, and the 5585 information of the used S value from the R1_COUNTER. Using these 5586 values, the Responder can regenerate the #I, and verify it against 5587 the #I received in the I2 packet. If the #I values match, it can 5588 verify the solution using #I, #J, and difficulty #K. If the #I 5589 values do not match, the I2 is dropped. 5591 puzzle_check: 5592 V := Ltrunc( RHASH( I2.I | I2.hit_i | I2.hit_r | I2.J ), #K ) 5593 if V != 0, drop the packet 5595 If the puzzle solution is correct, the #I and #J values are stored 5596 for later use. They are used as input material when keying material 5597 is generated. 5599 Keeping state about failed puzzle solutions depends on the 5600 implementation. Although it is possible for the Responder not to 5601 keep any state information, it still may do so to protect itself 5602 against certain attacks (see Section 4.1.1). 5604 Appendix B. Generating a Public Key Encoding from an HI 5606 The following pseudo-code illustrates the process to generate a 5607 public key encoding from an HI for both RSA and DSA. 5609 The symbol ":=" denotes assignment; the symbol "+=" denotes 5610 appending. The pseudo-function "encode_in_network_byte_order" takes 5611 two parameters, an integer (bignum) and a length in bytes, and 5612 returns the integer encoded into a byte string of the given length. 5614 switch ( HI.algorithm ) 5615 { 5617 case RSA: 5618 buffer := encode_in_network_byte_order ( HI.RSA.e_len, 5619 ( HI.RSA.e_len > 255 ) ? 3 : 1 ) 5620 buffer += encode_in_network_byte_order ( HI.RSA.e, HI.RSA.e_len ) 5621 buffer += encode_in_network_byte_order ( HI.RSA.n, HI.RSA.n_len ) 5622 break; 5624 case DSA: 5625 buffer := encode_in_network_byte_order ( HI.DSA.T , 1 ) 5626 buffer += encode_in_network_byte_order ( HI.DSA.Q , 20 ) 5627 buffer += encode_in_network_byte_order ( HI.DSA.P , 64 + 5628 8 * HI.DSA.T ) 5629 buffer += encode_in_network_byte_order ( HI.DSA.G , 64 + 5630 8 * HI.DSA.T ) 5631 buffer += encode_in_network_byte_order ( HI.DSA.Y , 64 + 5632 8 * HI.DSA.T ) 5633 break; 5635 } 5637 Appendix C. Example Checksums for HIP Packets 5639 The HIP checksum for HIP packets is specified in Section 5.1.1. 5640 Checksums for TCP and UDP packets running over HIP-enabled security 5641 associations are specified in Section 4.5.1. The examples below use 5642 [RFC3849] and [RFC5737] addresses, and HITs with the prefix of 5643 2001:20 followed by zeros, followed by a decimal 1 or 2, 5644 respectively. 5646 The following example is defined only for testing the checksum 5647 calculation. 5649 C.1. IPv6 HIP Example (I1 packet) 5651 Source Address: 2001:DB8::1 5652 Destination Address: 2001:DB8::2 5653 Upper-Layer Packet Length: 48 0x30 5654 Next Header: 139 0x8b 5655 Payload Protocol: 59 0x3b 5656 Header Length: 5 0x5 5657 Packet Type: 1 0x1 5658 Version: 2 0x2 5659 Reserved: 1 0x1 5660 Control: 0 0x0 5661 Checksum: 6750 0x1a5e 5662 Sender's HIT : 2001:20::1 5663 Receiver's HIT: 2001:20::2 5664 DH_GROUP_LIST type: 511 0x1ff 5665 DH_GROUP_LIST length: 3 0x3 5666 DH_GROUP_LIST group IDs: 3,4,8 5668 C.2. IPv4 HIP Packet (I1 packet) 5670 The IPv4 checksum value for the example I1 packet is shown below. 5672 Source Address: 192.0.2.1 5673 Destination Address: 192.0.2.2 5674 Upper-Layer Packet Length: 48 0x30 5675 Next Header: 139 0x8b 5676 Payload Protocol: 59 0x3b 5677 Header Length: 5 0x5 5678 Packet Type: 1 0x1 5679 Version: 2 0x2 5680 Reserved: 1 0x1 5681 Control: 0 0x0 5682 Checksum: 61902 0xf1ce 5683 Sender's HIT : 2001:20::1 5684 Receiver's HIT: 2001:20::2 5685 DH_GROUP_LIST type: 511 0x1ff 5686 DH_GROUP_LIST length: 3 0x3 5687 DH_GROUP_LIST group IDs: 3,4,8 5689 C.3. TCP Segment 5691 Regardless of whether IPv6 or IPv4 is used, the TCP and UDP sockets 5692 use the IPv6 pseudo-header format [RFC2460], with the HITs used in 5693 place of the IPv6 addresses. 5695 Sender's HIT: 2001:20::1 5696 Receiver's HIT: 2001:20::2 5697 Upper-Layer Packet Length: 20 0x14 5698 Next Header: 6 0x06 5699 Source port: 65500 0xffdc 5700 Destination port: 22 0x0016 5701 Sequence number: 1 0x00000001 5702 Acknowledgment number: 0 0x00000000 5703 Data offset: 5 0x5 5704 Flags: SYN 0x02 5705 Window size: 65535 0xffff 5706 Checksum: 28586 0x6faa 5707 Urgent pointer: 0 0x0000 5709 Appendix D. ECDH and ECDSA 160 Bit Groups 5711 The ECDH and ECDSA 160-bit group SECP160R1 is rated at 80 bits 5712 symmetric strength. Once this was considered appropriate for one 5713 year of security. Today these groups should be used only when the 5714 host is not powerful enough (e.g., some embedded devices) and when 5715 security requirements are low (e.g., long-term confidentiality is not 5716 required). 5718 Appendix E. HIT Suites and HIT Generation 5720 The HIT as an ORCHID [RFC7343] consists of three parts: A 28-bit 5721 prefix, a 4-bit encoding of the ORCHID generation algorithm (OGA) and 5722 a hash that includes the Host Identity and a context ID. The OGA is 5723 an index pointing to the specific algorithm by which the public key 5724 and the 96-bit hashed encoding is generated. The OGA is protocol 5725 specific and is to be interpreted as defined below for all protocols 5726 that use the same context ID as HIP. HIP groups sets of valid 5727 combinations of signature and hash algorithms into HIT Suites. These 5728 HIT suites are addressed by an index, which is transmitted in the OGA 5729 field of the ORCHID. 5731 The set of used HIT Suites will be extended to counter the progress 5732 in computation capabilities and vulnerabilities in the employed 5733 algorithms. The intended use of the HIT Suites is to introduce a new 5734 HIT Suite and phase out an old one before it becomes insecure. Since 5735 the 4-bit OGA field only permits 15 HIT Suites (the HIT Suite with ID 5736 0 is reserved) to be used in parallel, phased-out HIT Suites must be 5737 reused at some point. In such a case, there will be a rollover of 5738 the HIT Suite ID and the next newly introduced HIT Suite will start 5739 with a lower HIT Suite index than the previously introduced one. The 5740 rollover effectively deprecates the reused HIT Suite. For a smooth 5741 transition, the HIT Suite should be deprecated a considerable time 5742 before the HIT Suite index is reused. 5744 Since the number of HIT Suites is tightly limited to 16, the HIT 5745 Suites must be assigned carefully. Hence, sets of suitable 5746 algorithms are grouped in a HIT Suite. 5748 The HIT Suite of the Responder's HIT determines the RHASH and the 5749 hash function to be used for the HMAC in HIP packets as well as the 5750 signature algorithm family used for generating the HI. The list of 5751 HIT Suites is defined in Table 11. 5753 The following HIT Suites are defined for HIT generation. The input 5754 for each generation algorithm is the encoding of the HI as defined in 5755 Section 3.2. The output is 96 bits long and is directly used in the 5756 ORCHID. 5758 +-------+----------+--------------+------------+--------------------+ 5759 | Index | Hash | HMAC | Signature | Description | 5760 | | function | | algorithm | | 5761 | | | | family | | 5762 +-------+----------+--------------+------------+--------------------+ 5763 | 0 | | | | Reserved | 5764 | 1 | SHA-256 | HMAC-SHA-256 | RSA, DSA | RSA or DSA HI | 5765 | | | | | hashed with | 5766 | | | | | SHA-256, truncated | 5767 | | | | | to 96 bits | 5768 | 2 | SHA-384 | HMAC-SHA-384 | ECDSA | ECDSA HI hashed | 5769 | | | | | with SHA-384, | 5770 | | | | | truncated to 96 | 5771 | | | | | bits | 5772 | 3 | SHA-1 | HMAC-SHA-1 | ECDSA_LOW | ECDSA_LOW HI | 5773 | | | | | hashed with SHA-1, | 5774 | | | | | truncated to 96 | 5775 | | | | | bits | 5776 +-------+----------+--------------+------------+--------------------+ 5778 Table 11: HIT Suites 5780 The hash of the responder as defined in the HIT Suite determines the 5781 HMAC to be used for the HMAC parameter. The HMACs currently defined 5782 here are HMAC-SHA-256 [RFC4868], HMAC-SHA-384 [RFC4868], and HMAC- 5783 SHA-1 [RFC2404]. 5785 Authors' Addresses 5787 Robert Moskowitz (editor) 5788 Verizon Telcom and Business 5789 1000 Bent Creek Blvd, Suite 200 5790 Mechanicsburg, PA 5791 USA 5793 EMail: robert.moskowitz@verizonbusiness.com 5795 Tobias Heer 5796 Hirschmann Automation and Control 5797 Stuttgarter Strasse 45-51 5798 Neckartenzlingen 72654 5799 Germany 5801 EMail: tobias.heer@belden.com 5803 Petri Jokela 5804 Ericsson Research NomadicLab 5805 JORVAS FIN-02420 5806 FINLAND 5808 Phone: +358 9 299 1 5809 EMail: petri.jokela@nomadiclab.com 5811 Thomas R. Henderson 5812 University of Washington 5813 Campus Box 352500 5814 Seattle, WA 5815 USA 5817 EMail: tomhend@u.washington.edu