idnits 2.17.1 draft-ietf-hip-rfc5201-bis-18.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 4 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 2192 has weird spacing: '...c Value leng...' == Line 2194 has weird spacing: '...c Value the ...' == Line 2725 has weird spacing: '...ication info...' == Line 2863 has weird spacing: '...ue data opaqu...' == Line 2893 has weird spacing: '...ue data opaqu...' == (2 more instances...) -- The document date (September 22, 2014) is 3504 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 (==), 9 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-18 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-17 . . . . . . . 112 184 11.2. Changes from draft-ietf-hip-rfc5201-bis-16 . . . . . . . 112 185 11.3. Changes from draft-ietf-hip-rfc5201-bis-15 . . . . . . . 113 186 11.4. Changes from draft-ietf-hip-rfc5201-bis-14 . . . . . . . 113 187 11.5. Changes from draft-ietf-hip-rfc5201-bis-13 . . . . . . . 113 188 11.6. Changes from draft-ietf-hip-rfc5201-bis-12 . . . . . . . 113 189 11.7. Changes from draft-ietf-hip-rfc5201-bis-11 . . . . . . . 113 190 11.8. Changes from draft-ietf-hip-rfc5201-bis-10 . . . . . . . 113 191 11.9. Changes from draft-ietf-hip-rfc5201-bis-09 . . . . . . . 113 192 11.10. Changes from draft-ietf-hip-rfc5201-bis-08 . . . . . . . 113 193 11.11. Changes from draft-ietf-hip-rfc5201-bis-07 . . . . . . . 114 194 11.12. Changes from draft-ietf-hip-rfc5201-bis-06 . . . . . . . 114 195 11.13. Changes from draft-ietf-hip-rfc5201-bis-05 . . . . . . . 114 196 11.14. Changes from draft-ietf-hip-rfc5201-bis-04 . . . . . . . 115 197 11.15. Changes from draft-ietf-hip-rfc5201-bis-03 . . . . . . . 116 198 11.16. Changes from draft-ietf-hip-rfc5201-bis-02 . . . . . . . 117 199 11.17. Changes from draft-ietf-hip-rfc5201-bis-01 . . . . . . . 117 200 11.18. Changes from draft-ietf-hip-rfc5201-bis-00 . . . . . . . 119 201 11.19. Contents of draft-ietf-hip-rfc5201-bis-00 . . . . . . . 119 202 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 119 203 12.1. Normative References . . . . . . . . . . . . . . . . . . 119 204 12.2. Informative References . . . . . . . . . . . . . . . . . 121 205 Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 124 206 Appendix B. Generating a Public Key Encoding from an HI . . 125 207 Appendix C. Example Checksums for HIP Packets . . . . . . . . . 125 208 C.1. IPv6 HIP Example (I1 packet) . . . . . . . . . . . . . . 126 209 C.2. IPv4 HIP Packet (I1 packet) . . . . . . . . . . . . . . . 126 210 C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . . 127 211 Appendix D. ECDH and ECDSA 160 Bit Groups . . . . . . . . . . . 127 212 Appendix E. HIT Suites and HIT Generation . . . . . . . . . . . 127 214 1. Introduction 216 This document specifies the details of the Host Identity Protocol 217 (HIP). A high-level description of the protocol and the underlying 218 architectural thinking is available in the separate HIP architecture 219 description [I-D.ietf-hip-rfc4423-bis]. Briefly, the HIP 220 architecture proposes an alternative to the dual use of IP addresses 221 as "locators" (routing labels) and "identifiers" (endpoint, or host, 222 identifiers). In HIP, public cryptographic keys, of a public/private 223 key pair, are used as Host Identifiers, to which higher layer 224 protocols are bound instead of an IP address. By using public keys 225 (and their representations) as host identifiers, dynamic changes to 226 IP address sets can be directly authenticated between hosts, and if 227 desired, strong authentication between hosts at the TCP/IP stack 228 level can be obtained. 230 This memo specifies the base HIP protocol ("base exchange") used 231 between hosts to establish an IP-layer communications context, called 232 a HIP association, prior to communications. It also defines a packet 233 format and procedures for updating and terminating an active HIP 234 association. Other elements of the HIP architecture are specified in 235 other documents, such as: 237 o "Using the Encapsulating Security Payload (ESP) transport format 238 with the Host Identity Protocol (HIP)" [I-D.ietf-hip-rfc5202-bis]: 239 how to use the Encapsulating Security Payload (ESP) for integrity 240 protection and optional encryption 242 o "Host Mobility with the Host Identity Protocol" 243 [I-D.ietf-hip-rfc5206-bis]: how to support host mobility in HIP 245 o "Host Identity Protocol (HIP) Domain Name System (DNS) Extensions" 246 [I-D.ietf-hip-rfc5205-bis]: how to extend DNS to contain Host 247 Identity information 249 o "Host Identity Protocol (HIP) Rendezvous Extension" 250 [I-D.ietf-hip-rfc5204-bis]: using a rendezvous mechanism to 251 contact mobile HIP hosts 253 Since the HIP base exchange was first developed, there have been a 254 few advances in cryptography and attacks against cryptographic 255 systems. As a result, all cryptographic protocols need to be agile. 256 That is, it should be a part of the protocol to be able to switch 257 from one cryptographic primitive to another. It is important to 258 support a reasonable set of mainstream algorithms to cater for 259 different use cases and allow moving away from algorithms that are 260 later discovered to be vulnerable. This update to the base exchange 261 includes this needed cryptographic agility while addressing the 262 downgrade attacks that such flexibility introduces. In particular, 263 Elliptic Curve support by Elliptic Curve DSA (ECDSA) and Elliptic 264 Curve Diffie-Hellman (ECDH) and alternative hash functions have been 265 added. 267 1.1. A New Namespace and Identifiers 269 The Host Identity Protocol introduces a new namespace, the Host 270 Identity namespace. Some ramifications of this new namespace are 271 explained in the HIP architecture description 272 [I-D.ietf-hip-rfc4423-bis]. 274 There are two main representations of the Host Identity, the full 275 Host Identity (HI) and the Host Identity Tag (HIT). The HI is a 276 public key and directly represents the Identity of a host. Since 277 there are different public key algorithms that can be used with 278 different key lengths, the HI, as such, is unsuitable for use as a 279 packet identifier, or as an index into the various state-related 280 implementation structures needed to support HIP. Consequently, a 281 hash of the HI, the Host Identity Tag (HIT), is used as the 282 operational representation. The HIT is 128 bits long and is used in 283 the HIP headers and to index the corresponding state in the end 284 hosts. The HIT has an important security property in that it is 285 self-certifying (see Section 3). 287 1.2. The HIP Base Exchange (BEX) 289 The HIP base exchange is a two-party cryptographic protocol used to 290 establish communications context between hosts. The base exchange is 291 a SIGMA-compliant [KRA03] four-packet exchange. The first party is 292 called the Initiator and the second party the Responder. The 293 protocol exchanges Diffie-Hellman [DIF76] keys in the 2nd and 3rd 294 packets, and authenticates the parties in the 3rd and 4th packets. 295 The four-packet design helps to make HIP DoS resilient. It allows 296 the Responder to stay stateless until the IP address and the 297 cryptographic puzzle is verified. The Responder starts the puzzle 298 exchange in the 2nd packet, with the Initiator completing it in the 299 3rd packet before the Responder stores any state from the exchange. 301 The exchange can use the Diffie-Hellman output to encrypt the Host 302 Identity of the Initiator in the 3rd packet (although Aura, et al., 303 [AUR03] notes that such operation may interfere with packet- 304 inspecting middleboxes), or the Host Identity may instead be sent 305 unencrypted. The Responder's Host Identity is not protected. It 306 should be noted, however, that both the Initiator's and the 307 Responder's HITs are transported as such (in cleartext) in the 308 packets, allowing an eavesdropper with a priori knowledge about the 309 parties to identify them by their HITs. Hence, encrypting the HI of 310 any party does not provide privacy against such attacker. 312 Data packets start to flow after the 4th packet. The 3rd and 4th HIP 313 packets may carry a data payload in the future. However, the details 314 of this may be defined later. 316 An existing HIP association can be updated using the update mechanism 317 defined in this document, and when the association is no longer 318 needed, it can be closed using the defined closing mechanism. 320 Finally, HIP is designed as an end-to-end authentication and key 321 establishment protocol, to be used with Encapsulated Security Payload 322 (ESP) [I-D.ietf-hip-rfc5202-bis] and other end-to-end security 323 protocols. The base protocol does not cover all the fine-grained 324 policy control found in Internet Key Exchange (IKE) [RFC5996] that 325 allows IKE to support complex gateway policies. Thus, HIP is not a 326 complete replacement for IKE. 328 1.3. Memo Structure 330 The rest of this memo is structured as follows. Section 2 defines 331 the central keywords, notation, and terms used throughout the rest of 332 the document. Section 3 defines the structure of the Host Identity 333 and its various representations. Section 4 gives an overview of the 334 HIP base exchange protocol. Sections 5 and 6 define the detailed 335 packet formats and rules for packet processing. Finally, Sections 7, 336 8, and 9 discuss policy, security, and IANA considerations, 337 respectively. 339 2. Terms and Definitions 341 2.1. Requirements Terminology 343 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 344 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 345 document are to be interpreted as described in RFC 2119 [RFC2119]. 347 2.2. Notation 349 [x] indicates that x is optional. 351 {x} indicates that x is encrypted. 353 X(y) indicates that y is a parameter of X. 355 i indicates that x exists i times. 357 --> signifies "Initiator to Responder" communication (requests). 359 <-- signifies "Responder to Initiator" communication (replies). 361 | signifies concatenation of information (e.g., X | Y is the 362 concatenation of X with Y). 364 Ltrunc (H(x), K) denotes the lowest order #K bits of the result of 365 the hash function H on the input x. 367 2.3. Definitions 369 HIP base exchange (BEX): the handshake for establishing a new HIP 370 association. 372 Host Identity (HI): The public key of the signature algorithm that 373 represents the identity of the host. In HIP, a host proves its 374 identity by creating a signature with the private key belonging to 375 its HI (c.f. Section 3). 377 Host Identity Tag (HIT): A shorthand for the HI in IPv6 format. It 378 is generated by hashing the HI (c.f. Section 3.1). 380 HIT Suite: A HIT Suite groups all cryptographic algorithms that are 381 required to generate and use an HI and its HIT. In particular, 382 these algorithms are: 1) the public key signature algorithm and 2) 383 the hash function, 3) the truncation (c.f. Appendix E). 385 HIP association: The shared state between two peers after 386 completion of the BEX. 388 HIP packet: A control packet carrying a HIP packet header relating 389 to the establishment, maintenance, or termination of the HIP 390 association. 392 Initiator: The host that initiates the BEX. This role is typically 393 forgotten once the BEX is completed. 395 Responder: The host that responds to the Initiator in the BEX. 396 This role is typically forgotten once the BEX is completed. 398 Responder's HIT Hash Algorithm (RHASH): The Hash algorithm used for 399 various hash calculations in this document. The algorithm is the 400 same as is used to generate the Responder's HIT. The RHASH is the 401 hash function defined by the HIT Suite of the Responder's HIT 402 (c.f. Appendix E). 404 Length of the Responder's HIT Hash Algorithm (RHASH_len): The 405 natural output length of RHASH in bits. 407 Signed data: Data that is signed is protected by a digital 408 signature that was created by the sender of the data by using the 409 private key of its HI. 411 KDF: The Key Derivation Function (KDF) is used for deriving the 412 symmetric keys from the Diffie-Hellman key exchange. 414 KEYMAT: The keying material derived from the Diffie-Hellman key 415 exchange by using the KDF. Symmetric keys for encryption and 416 integrity protection of HIP packets and encrypted user data 417 packets are drawn from this keying material. 419 3. Host Identity (HI) and its Structure 421 In this section, the properties of the Host Identity and Host 422 Identity Tag are discussed, and the exact format for them is defined. 423 In HIP, the public key of an asymmetric key pair is used as the Host 424 Identity (HI). Correspondingly, the host itself is defined as the 425 entity that holds the private key of the key pair. See the HIP 426 architecture specification [I-D.ietf-hip-rfc4423-bis] for more 427 details on the difference between an identity and the corresponding 428 identifier. 430 HIP implementations MUST support the Rivest Shamir Adelman [RSA] 431 public key algorithm and the Elliptic Curve Digital Signature 432 Algorithm (ECDSA) for generating the HI as defined in Section 5.2.9. 433 Additional algorithms MAY be supported. 435 A hashed encoding of the HI, the Host Identity Tag (HIT), is used in 436 protocols to represent the Host Identity. The HIT is 128 bits long 437 and has the following three key properties: i) it is the same length 438 as an IPv6 address and can be used in fixed address-sized fields in 439 APIs and protocols, ii) it is self-certifying (i.e., given a HIT, it 440 is computationally hard to find a Host Identity key that matches the 441 HIT), and iii) the probability of a HIT collision between two hosts 442 is very low, hence, it is infeasible for an attacker to find a 443 collision with a HIT that is in use. For details on the security 444 properties of the HIT see [I-D.ietf-hip-rfc4423-bis]. 446 The structure of the HIT is defined in [RFC7343]. The HIT is an 447 Overlay Routable Cryptographic Hash Identifier (ORCHID) and consists 448 of three parts: first, an IANA assigned prefix to distinguish it from 449 other IPv6 addresses. Second, a four-bit encoding of the algorithms 450 that were used for generating the HI and the hashed representation of 451 HI. Third, a 96-bit hashed representation of the Host Identity. The 452 encoding of the ORCHID generation algorithm and the exact algorithm 453 for generating the hashed representation is specified in Appendix E. 455 Carrying HIs and HITs in the header of user data packets would 456 increase the overhead of packets. Thus, it is not expected that they 457 are carried in every packet, but other methods are used to map the 458 data packets to the corresponding HIs. In some cases, this makes it 459 possible to use HIP without any additional headers in the user data 460 packets. For example, if ESP is used to protect data traffic, the 461 Security Parameter Index (SPI) carried in the ESP header can be used 462 to map the encrypted data packet to the correct HIP association. 464 3.1. Host Identity Tag (HIT) 466 The Host Identity Tag is a 128-bit value -- a hashed encoding of the 467 Host Identifier. There are two advantages of using a hashed encoding 468 over the actual variable-sized Host Identity public key in protocols. 469 First, the fixed length of the HIT keeps packet sizes manageable and 470 eases protocol coding. Second, it presents a consistent format for 471 the protocol, independent of the underlying identity technology in 472 use. 474 RFC 7343 [RFC7343] specifies 128-bit hash-based identifiers, called 475 Overlay Routable Cryptographic Hash Identifiers, ORCHIDs. Their 476 prefix, allocated from the IPv6 address block, is defined in 477 [RFC7343]. The Host Identity Tag is one type of an ORCHID. 479 This document extends the original, experimental HIP specification 480 [RFC5201] with measures to support crypto agility. One of these 481 measures is to allow different hash functions for creating a HIT. 482 HIT Suites group the sets of algorithms that are required to generate 483 and use a particular HIT. The Suites are encoded in HIT Suite IDs. 484 These HIT Suite IDs are transmitted in the ORCHID Generation 485 Algorithm (OGA) field in the ORCHID. With the HIT Suite ID in the 486 OGA field, a host can tell from another host's HIT, whether it 487 supports the necessary hash and signature algorithms to establish a 488 HIP association with that host. 490 3.2. Generating a HIT from an HI 492 The HIT MUST be generated according to the ORCHID generation method 493 described in [RFC7343] using a context ID value of 0xF0EF F02F BFF4 494 3D0F E793 0C3C 6E61 74EA (this tag value has been generated randomly 495 by the editor of this specification), and an input that encodes the 496 Host Identity field (see Section 5.2.9) present in a HIP payload 497 packet. The set of hash function, signature algorithm, and the 498 algorithm used for generating the HIT from the HI depends on the HIT 499 Suite (see Appendix E) and is indicated by the four bits of the 500 ORCHID Generation Algorithm (OGA) field in the ORCHID. Currently, 501 truncated SHA-1, truncated SHA-384, and truncated SHA-256 502 [FIPS.180-2.2002] are defined as hashes for generating a HIT. 504 For identities that are either RSA, Digital Signature Algorithm (DSA) 505 [FIPS186-3], or Elliptic Curve DSA (ECDSA) public keys, the ORCHID 506 input consists of the public key encoding as specified for the Host 507 Identity field of the HOST_ID parameter (see Section 5.2.9). This 508 document defines four algorithm profiles: RSA, DSA, ECDSA, and 509 ECDSA_LOW. The ECDSA_LOW profile is meant for devices with low 510 computational capabilities. Hence, one of the following applies: 512 The RSA public key is encoded as defined in [RFC3110] Section 2, 513 taking the exponent length (e_len), exponent (e), and modulus (n) 514 fields concatenated. The length (n_len) of the modulus (n) can be 515 determined from the total HI Length and the preceding HI fields 516 including the exponent (e). Thus, the data that serves as input 517 for the HIT generation has the same length as the HI. The fields 518 MUST be encoded in network byte order, as defined in [RFC3110]. 520 The DSA public key is encoded as defined in [RFC2536] Section 2, 521 taking the fields T, Q, P, G, and Y, concatenated as input. Thus, 522 the data to be hashed is 1 + 20 + 3 * 64 + 3 * 8 * T octets long, 523 where T is the size parameter as defined in [RFC2536]. The size 524 parameter T, affecting the field lengths, MUST be selected as the 525 minimum value that is long enough to accommodate P, G, and Y. The 526 fields MUST be encoded in network byte order, as defined in 527 [RFC2536]. 529 The ECDSA public keys are encoded as defined in [RFC6090] 530 Section 4.2 and 6. 532 In Appendix B, the public key encoding process is illustrated using 533 pseudo-code. 535 4. Protocol Overview 537 This section is a simplified overview of the HIP protocol operation, 538 and does not contain all the details of the packet formats or the 539 packet processing steps. Sections 5 and 6 describe in more detail 540 the packet formats and packet processing steps, respectively, and are 541 normative in case of any conflicts with this section. 543 The protocol number 139 has been assigned by IANA to the Host 544 Identity Protocol. 546 The HIP payload (Section 5.1) header could be carried in every IP 547 datagram. However, since HIP headers are relatively large (40 548 bytes), it is desirable to 'compress' the HIP header so that the HIP 549 header only occurs in control packets used to establish or change HIP 550 association state. The actual method for header 'compression' and 551 for matching data packets with existing HIP associations (if any) is 552 defined in separate documents, describing transport formats and 553 methods. All HIP implementations MUST implement, at minimum, the ESP 554 transport format for HIP [I-D.ietf-hip-rfc5202-bis]. 556 4.1. Creating a HIP Association 558 By definition, the system initiating a HIP base exchange is the 559 Initiator, and the peer is the Responder. This distinction is 560 typically forgotten once the base exchange completes, and either 561 party can become the Initiator in future communications. 563 The HIP base exchange serves to manage the establishment of state 564 between an Initiator and a Responder. The first packet, I1, 565 initiates the exchange, and the last three packets, R1, I2, and R2, 566 constitute an authenticated Diffie-Hellman [DIF76] key exchange for 567 session-key generation. In the first two packets, the hosts agree on 568 a set of cryptographic identifiers and algorithms that are then used 569 in and after the exchange. During the Diffie-Hellman key exchange, a 570 piece of keying material is generated. The HIP association keys are 571 drawn from this keying material by using a Key Derivation Function 572 (KDF). If other cryptographic keys are needed, e.g., to be used with 573 ESP, they are expected to be drawn from the same keying material by 574 using the KDF. 576 The Initiator first sends a trigger packet, I1, to the Responder. 577 The packet contains the HIT of the Initiator and possibly the HIT of 578 the Responder, if it is known. Moreover, the I1 packet initializes 579 the negotiation of the Diffie-Hellman group that is used for 580 generating the keying material. Therefore, the I1 packet contains a 581 list of Diffie Hellman Group IDs supported by the Initiator. Note 582 that in some cases it may be possible to replace this trigger packet 583 by some other form of a trigger, in which case the protocol starts 584 with the Responder sending the R1 packet. In such cases, another 585 mechanism to convey the Initiator's supported DH Groups (e.g., by 586 using a default group) must be specified. 588 The second packet, R1, starts the actual authenticated Diffie-Hellman 589 exchange. It contains a puzzle -- a cryptographic challenge that the 590 Initiator must solve before continuing the exchange. The level of 591 difficulty of the puzzle can be adjusted based on level of trust with 592 the Initiator, current load, or other factors. In addition, the R1 593 contains the Responder's Diffie-Hellman parameter and lists of 594 cryptographic algorithms supported by the Responder. Based on these 595 lists, the Initiator can continue, abort, or restart the base 596 exchange with a different selection of cryptographic algorithms. 597 Also, the R1 packet contains a signature that covers selected parts 598 of the message. Some fields are left outside the signature to 599 support pre-created R1s. 601 In the I2 packet, the Initiator MUST display the solution to the 602 received puzzle. Without a correct solution, the I2 message is 603 discarded. The I2 packet also contains a Diffie-Hellman parameter 604 that carries needed information for the Responder. The I2 packet is 605 signed by the Initiator. 607 The R2 packet acknowledges the receipt of the I2 packet and completes 608 the base exchange. The packet is signed by the Responder. 610 The base exchange is illustrated below in Figure 1. The term "key" 611 refers to the Host Identity public key, and "sig" represents a 612 signature using such a key. The packets contain other parameters not 613 shown in this figure. 615 Initiator Responder 617 I1: DH list 618 --------------------------> 619 select precomputed R1 620 R1: puzzle, DH, key, sig 621 <------------------------- 622 check sig remain stateless 623 solve puzzle 624 I2: solution, DH, {key}, sig 625 --------------------------> 626 compute DH check puzzle 627 check sig 628 R2: sig 629 <-------------------------- 630 check sig compute DH 632 Figure 1 634 4.1.1. HIP Puzzle Mechanism 636 The purpose of the HIP puzzle mechanism is to protect the Responder 637 from a number of denial-of-service threats. It allows the Responder 638 to delay state creation until receiving the I2 packet. Furthermore, 639 the puzzle allows the Responder to use a fairly cheap calculation to 640 check that the Initiator is "sincere" in the sense that it has 641 churned enough CPU cycles in solving the puzzle. 643 The puzzle allows a Responder implementation to completely delay 644 association-specific state creation until a valid I2 packet is 645 received. An I2 packet without valid puzzle solution can be rejected 646 immediately once the Responder has checked the solution by computing 647 only one hash function before state is created and CPU-intensive 648 public-key signature verification and Diffie-Hellman key generation 649 are performed. By varying the difficulty of the puzzle, the 650 Responder can frustrate CPU or memory targeted DoS attacks. 652 The Responder can remain stateless and drop most spoofed I2 packets 653 because puzzle calculation is based on the Initiator's Host Identity 654 Tag. The idea is that the Responder has a (perhaps varying) number of 655 pre-calculated R1 packets, and it selects one of these based on the 656 information carried in the I1 packet. When the Responder then later 657 receives the I2 packet, it can verify that the puzzle has been solved 658 using the Initiator's HIT. This makes it impractical for the 659 attacker to first exchange one I1/R1 packet, and then generate a 660 large number of spoofed I2 packets that seemingly come from different 661 HITs. This method does not protect the Responder from an attacker 662 that uses fixed HITs, though. Against such an attacker, a viable 663 approach may be to create a piece of local state, and remember that 664 the puzzle check has previously failed. See Appendix A for one 665 possible implementation. Responder implementations SHOULD include 666 sufficient randomness in the puzzle values so that algorithmic 667 complexity attacks become impossible [CRO03]. 669 The Responder can set the puzzle difficulty for the Initiator, based 670 on its level of trust of the Initiator. Because the puzzle is not 671 included in the signature calculation, the Responder can use pre- 672 calculated R1 packets and include the puzzle just before sending the 673 R1 to the Initiator. The Responder SHOULD use heuristics to 674 determine when it is under a denial-of-service attack, and set the 675 puzzle difficulty value #K appropriately as explained later. 677 4.1.2. Puzzle Exchange 679 The Responder starts the puzzle exchange when it receives an I1 680 packet. The Responder supplies a random number #I, and requires the 681 Initiator to find a number J. To select a proper #J, the Initiator 682 must create the concatenation of #I, the HITs of the parties, and #J, 683 and calculate a hash over this concatenation using the RHASH 684 algorithm. The lowest order #K bits of the result MUST be zeros. 685 The value #K sets the difficulty of the puzzle. 687 To generate a proper number #J, the Initiator will have to generate a 688 number of Js until one produces the hash target of zeros. The 689 Initiator SHOULD give up after exceeding the puzzle Lifetime in the 690 PUZZLE parameter (as described in Section 5.2.4). The Responder 691 needs to re-create the concatenation of #I, the HITs, and the 692 provided #J, and compute the hash once to prove that the Initiator 693 completed its assigned task. 695 To prevent precomputation attacks, the Responder MUST select the 696 number #I in such a way that the Initiator cannot guess it. 697 Furthermore, the construction MUST allow the Responder to verify that 698 the value #I was indeed selected by it and not by the Initiator. See 699 Appendix A for an example on how to implement this. 701 Using the Opaque data field in the PUZZLE (see Section 5.2.4), in an 702 ECHO_REQUEST_SIGNED (see Section 5.2.20) or in an 703 ECHO_REQUEST_UNSIGNED parameter (see Section 5.2.21), the Responder 704 can include some data in R1 that the Initiator MUST copy unmodified 705 in the corresponding I2 packet. The Responder can use the opaque 706 data to transfer a piece of local state information to the Initiator 707 and back, for example to recognize that the I2 is a response to a 708 previously sent R1. The Responder can generate the Opaque data in 709 various ways; e.g., using encryption or hashing with some secret, the 710 sent #I, and possibly using other related data. With the same 711 secret, the received #I (from the I2 packet), and the other related 712 data (if any), the Responder can verify that it has itself sent the 713 #I to the Initiator. The Responder MUST periodically change such a 714 secret. 716 It is RECOMMENDED that the Responder generates new secrets for the 717 puzzle and new R1s once every few minutes. Furthermore, it is 718 RECOMMENDED that the Responder is able to verify valid puzzle 719 solution at least Lifetime seconds after the puzzle secret has been 720 deprecated. This time value guarantees that the puzzle is valid for 721 at least Lifetime and at most 2 * Lifetime seconds. This limits the 722 usability that an old, solved puzzle has to an attacker. Moreover, 723 it avoids problems with the validity of puzzles if the lifetime is 724 relatively short compared to the network delay and the time for 725 solving the puzzle. 727 The puzzle value #I and the solution #J are inputs for deriving the 728 keying material from the Diffie-Hellman key exchange (see 729 Section 6.5). Therefore, a Responder SHOULD NOT use the same puzzle 730 #I with the same DH keys for the same Initiator twice to ensure that 731 the derived keying material differs. Such uniqueness can be 732 achieved, for example, by using a counter as an additional input for 733 generating #I. This counter can be increased for each processed I1 734 packet. The state of the counter can be transmitted in the Opaque 735 data field in the PUZZLE (see Section 5.2.4), in an 736 ECHO_REQUEST_SIGNED (see Section 5.2.20) or in an 737 ECHO_REQUEST_UNSIGNED parameter (see Section 5.2.21) without the need 738 to establish state. 740 NOTE: The protocol developers explicitly considered whether R1 should 741 include a timestamp in order to protect the Initiator from replay 742 attacks. The decision was to NOT include a timestamp to avoid 743 problems with global time synchronization. 745 NOTE: The protocol developers explicitly considered whether a memory 746 bound function should be used for the puzzle instead of a CPU-bound 747 function. The decision was not to use memory-bound functions. 749 4.1.3. Authenticated Diffie-Hellman Protocol with DH Group Negotiation 751 The packets R1, I2, and R2 implement a standard authenticated Diffie- 752 Hellman exchange. The Responder sends one of its public Diffie- 753 Hellman keys and its public authentication key, i.e., its Host 754 Identity, in R1. The signature in the R1 packet allows the Initiator 755 to verify that the R1 has been once generated by the Responder. 756 However, since the R1 is precomputed and therefore does not cover 757 association-specific information in the I1 packet, it does not 758 protect from replay attacks. 760 Before the actual authenticated Diffie-Hellman exchange, the 761 Initiator expresses its preference regarding its choice of the DH 762 groups in the I1 packet. The preference is expressed as a sorted 763 list of DH Group IDs. The I1 packet is not protected by a signature. 764 Therefore, this list is sent in an unauthenticated way to avoid 765 costly computations for processing the I1 packet at the Responder 766 side. Based on the preferences of the Initiator, the Responder sends 767 an R1 packet containing its most suitable public DH value. The 768 Responder also attaches a list of its own preferences to the R1 to 769 convey the basis for the DH group selection to the Initiator. This 770 list is carried in the signed part of the R1 packet. If the choice 771 of the DH group value in the R1 does not match the preferences of the 772 Initiator and the Responder, the Initiator can detect that the list 773 of DH Group IDs in the I1 was manipulated (see below for details). 775 If none of the DH Group IDs in the I1 packet is supported by the 776 Responder, the Responder selects the DH Group most suitable for it 777 regardless of the Initiator's preference. It then sends the R1 778 containing this DH Group and its list of supported DH Group IDs to 779 the Initiator. 781 When the Initiator receives an R1, it receives one of the Responder's 782 public Diffie-Hellman values and the list of DH Group IDs supported 783 by the Responder. This list is covered by the signature in the R1 784 packet to avoid forgery. The Initiator compares the Group ID of the 785 public DH value in the R1 packet to the list of supported DH Group 786 IDs in the R1 packets and to its own preferences expressed in the 787 list of supported DH Group IDs. The Initiator continues the BEX only 788 if the Group ID of the public DH value of the Responder is the most 789 preferred of the IDs supported by both the Initiator and Responder. 790 Otherwise, the communication is subject of a downgrade attack and the 791 Initiator MUST either restart the base exchange with a new I1 packet 792 or abort the base exchange. If the Responder's choice of the DH 793 Group is not supported by the Initiator, the Initiator MAY abort the 794 handshake or send a new I1 packet with a different list of supported 795 DH Groups. However, the Initiator MUST verify the signature of the 796 R1 packet before restarting or aborting the handshake. It MUST 797 silently ignore the R1 packet if the signature is not valid. 799 If the preferences regarding the DH Group ID match, the Initiator 800 computes the Diffie-Hellman session key (Kij). The Initiator creates 801 a HIP association using keying material from the session key (see 802 Section 6.5), and may use the HIP association to encrypt its public 803 authentication key, i.e., the Host Identity. The resulting I2 packet 804 contains the Initiator's Diffie-Hellman key and its (optionally 805 encrypted) public authentication key. The signature of the I2 806 message covers all parameters of the signed parameter ranges (see 807 Section 5.2) in the packet without exceptions as in the R1. 809 The Responder extracts the Initiator's Diffie-Hellman public key from 810 the I2 packet, computes the Diffie-Hellman session key, creates a 811 corresponding HIP association, and decrypts the Initiator's public 812 authentication key. It can then verify the signature using the 813 authentication key. 815 The final message, R2, completes the BEX and protects the Initiator 816 against replay attacks because the Responder uses the shared key from 817 the Diffie-Hellman exchange to create an HMAC as well as uses the 818 private key of its Host Identity to sign the packet contents. 820 4.1.4. HIP Replay Protection 822 The HIP protocol includes the following mechanisms to protect against 823 malicious packet replays. Responders are protected against replays 824 of I1 packets by virtue of the stateless response to I1 packets with 825 pre-signed R1 messages. Initiators are protected against R1 replays 826 by a monotonically increasing "R1 generation counter" included in the 827 R1. Responders are protected against replays of forged I2 packets by 828 the puzzle mechanism (see Section 4.1.1 above), and optional use of 829 opaque data. Hosts are protected against replays of R2 packets and 830 UPDATEs by use of a less expensive HMAC verification preceding the 831 HIP signature verification. 833 The R1 generation counter is a monotonically increasing 64-bit 834 counter that may be initialized to any value. The scope of the 835 counter MAY be system-wide but there SHOULD be a separate counter for 836 each Host Identity, if there is more than one local host identity. 837 The value of this counter SHOULD be preserved across system reboots 838 and invocations of the HIP base exchange. This counter indicates the 839 current generation of puzzles. Implementations MUST accept puzzles 840 from the current generation and MAY accept puzzles from earlier 841 generations. A system's local counter MUST be incremented at least 842 as often as every time old R1s cease to be valid. The local counter 843 SHOULD never be decremented, otherwise the host exposes its peers to 844 the replay of previously generated, higher numbered R1s. 846 A host may receive more than one R1, either due to sending multiple 847 I1 packets (see Section 6.6.1) or due to a replay of an old R1. When 848 sending multiple I1 packets to the same host, an Initiator SHOULD 849 wait for a small amount of time (a reasonable time may be 2 * 850 expected RTT) after the first R1 reception to allow possibly multiple 851 R1s to arrive, and it SHOULD respond to an R1 among the set with the 852 largest R1 generation counter. If an Initiator is processing an R1 853 or has already sent an I2 packet (still waiting for the R2 packet) 854 and it receives another R1 with a larger R1 generation counter, it 855 MAY elect to restart R1 processing with the fresher R1, as if it were 856 the first R1 to arrive. 858 The R1 generation counter may roll over or may become reset. It is 859 important for an Initiator to be robust to the loss of state about 860 the R1 generation counter of a peer, or to a reset of the peer's 861 counter. It is recommended that, when choosing between multiple R1s, 862 the Initiator prefer to use the R1 that corresponds to the current R1 863 generation counter, but that if it is unable to make progress with 864 that R1, the Initiator may try the other R1s beginning with the R1 865 packet with the highest counter. 867 4.1.5. Refusing a HIP base exchange 869 A HIP-aware host may choose not to accept a HIP base exchange. If 870 the host's policy is to only be an Initiator, and policy allows the 871 establishment of a HIP association with the original Initiator, it 872 should begin its own HIP base exchange. A host MAY choose to have 873 such a policy since only the privacy of the Initiator's HI is 874 protected in the exchange. It should be noted that such behavior can 875 introduce the risk of a race condition if each host's policy is to 876 only be an Initiator, at which point the HIP base exchange will fail. 878 If the host's policy does not permit it to enter into a HIP exchange 879 with the Initiator, it should send an ICMP 'Destination Unreachable, 880 Administratively Prohibited' message. A more complex HIP packet is 881 not used here as it actually opens up more potential DoS attacks than 882 a simple ICMP message. A HIP NOTIFY message is not used because no 883 HIP association exists between the two hosts at that time. 885 4.1.6. Aborting a HIP base exchange 887 Two HIP hosts may encounter situations in which they cannot complete 888 a HIP base exchange because of insufficient support for cryptographic 889 algorithms, in particular the HIT Suites and DH Groups. After 890 receiving the R1 packet, the Initiator can determine whether the 891 Responder supports the required cryptographic operations to 892 successfully establish a HIP association. The Initiator can abort 893 the BEX silently after receiving an R1 packet that indicates an 894 unsupported set of algorithms. The specific conditions are described 895 below. 897 The R1 packet contains a signed list of HIT Suite IDs as supported by 898 the Responder. Therefore, the Initiator can determine whether its 899 source HIT is supported by the Responder. If the HIT Suite ID of the 900 Initiator's HIT is not contained in the list of HIT Suites in the R1, 901 the Initiator MAY abort the handshake silently or MAY restart the 902 handshake with a new I1 packet that contains a source HIT supported 903 by the Responder. 905 During the Handshake, the Initiator and the Responder agree on a 906 single DH Group. The Responder selects the DH Group and its DH 907 public value in the R1 based on the list of DH Suite IDs in the I1 908 packet. If the responder supports none of the DH Groups requested by 909 the Initiator, the Responder selects an arbitrary DH and replies with 910 an R1 containing its list of supported DH Group IDs. In such case, 911 the Initiator receives an R1 packet containing the DH public value 912 for an unrequested DH Group and also the Responder's DH Group list in 913 the signed part of the R1 packet. At this point, the Initiator MAY 914 abort the handshake or MAY restart the handshake by sending a new I1 915 packet containing a selection of DH Group IDs that is supported by 916 the Responder. 918 4.1.7. HIP Downgrade Protection 920 In a downgrade attack, an attacker attempts to unnoticeably 921 manipulate the packets of an Initiator and/or a Responder to 922 influence the result of the cryptographic negotiations in the BEX to 923 its favor. As a result, the victims select weaker cryptographic 924 algorithms than they would otherwise have selected without the 925 attacker's interference. Downgrade attacks can only be successful if 926 they remain un-detected by the victims and the victims falsely assume 927 a secure communication channel. 929 In HIP, almost all packet parameters related to cryptographic 930 negotiations are covered by signatures. These parameters cannot be 931 directly manipulated in a downgrade attack without invalidating the 932 signature. However, signed packets can be subject to replay attacks. 933 In such a replay attack, the attacker could use an old BEX packet 934 with an outdated and weak selection of cryptographic algorithms and 935 replay it instead of a more recent packet with a collection of 936 stronger cryptographic algorithms. Signed packets that could be 937 subject to this replay attack are the R1 and I2 packet. However, 938 replayed R1 and I2 packets cannot be used to successfully establish a 939 HIP BEX because these packets also contain the public DH values of 940 the Initiator and the Responder. Old DH values from replayed packets 941 lead to invalid keying material and mismatching shared secrets 942 because the attacker is unable to derive valid keying material from 943 the DH public keys in the R1 and cannot generate a valid HMAC and 944 signature for a replayed I2. 946 In contrast to the first version of HIP [RFC5201],the version 2 of 947 HIP defined in this document begins the negotiation of the DH Groups 948 already in the first BEX packet, the I1. The I1 packet is, by 949 intention, not protected by a signature to avoid CPU-intensive 950 cryptographic operations for processing floods of I1 packets targeted 951 at the Responder. Hence, the list of DH Group IDs in the I1 packet 952 is vulnerable to forgery and manipulation. To thwart an unnoticed 953 manipulation of the I1 packet, the Responder chooses the DH Group 954 deterministically and includes its own list of DH Group IDs in the 955 signed part of the R1 packet. The Initiator can detect an attempted 956 downgrade attack by comparing the list of DH Group IDs in the R1 957 packet to its own preferences in the I1 packet. If the choice of the 958 DH Group in the R1 packet does not equal to the best match of the two 959 lists (the highest priority DH ID of the Responder that is present in 960 the Initiator's DH list), the Initiator can conclude that its list in 961 the I1 packet was altered by an attacker. In this case, the 962 Initiator can restart or abort the BEX. As mentioned before, the 963 detection of the downgrade attack is sufficient to prevent it. 965 4.1.8. HIP Opportunistic Mode 967 It is possible to initiate a HIP BEX even if the Responder's HI (and 968 HIT) is unknown. In this case, the initial I1 packet contains all 969 zeros as the destination HIT. This kind of connection setup is 970 called opportunistic mode. 972 The Responder may have multiple HITs due to multiple supported HIT 973 Suites. Since the Responder's HIT Suite in the opportunistic mode is 974 not determined by the destination HIT of the I1 packet, the Responder 975 can freely select a HIT of any HIT Suite. The complete set of HIT 976 Suites supported by the Initiator is not known to the Responder. 977 Therefore, the Responder SHOULD select its HIT from the same HIT 978 Suite as the Initiator's HIT (indicated by the HIT suite information 979 in the OGA field of the Initiator's HIT) because this HIT Suite is 980 obviously supported by the Initiator. If the Responder selects a 981 different HIT that is not supported by the Initiator, the Initiator 982 MAY restart the BEX with an I1 packet with a source HIT that is 983 contained in the list of the Responder's HIT Suites in the R1 packet. 985 Note that the Initiator cannot verify the signature of the R1 packet 986 if the Responder's HIT Suite is not supported. Therefore, the 987 Initiator MUST treat R1 packets with unsupported Responder HITs as 988 potentially forged and MUST NOT use any parameters from the 989 unverified R1 besides the HIT Suite List. Moreover, an Initiator 990 that uses an unverified HIT Suite List from an R1 packet to determine 991 a possible source HIT MUST verify that the HIT_SUITE_LIST in the 992 first unverified R1 packet matches the HIT_SUITE_LIST in the second 993 R1 packet for which the Initiator supports the signature algorithm. 994 The Initiator MUST restart the BEX with a new I1 packet for which the 995 algorithm was mentioned in the verifiable R1 if the two lists do not 996 match. This procedure is necessary to mitigate downgrade attacks. 998 There are both security and API issues involved with the 999 opportunistic mode. These issues are described in the reminder of 1000 this section. 1002 Given that the Responder's HI is not known by the Initiator, there 1003 must be suitable API calls that allow the Initiator to request, 1004 directly or indirectly, that the underlying system initiates the HIP 1005 base exchange solely based on locators. The Responder's HI will be 1006 tentatively available in the R1 packet, and in an authenticated form 1007 once the R2 packet has been received and verified. Hence, the 1008 Responder's HIT could be communicated to the application via new API 1009 mechanisms. However, with a backwards-compatible API the application 1010 sees only the locators used for the initial contact. Depending on 1011 the desired semantics of the API, this can raise the following 1012 issues: 1014 o The actual locators may later change if an UPDATE message is used, 1015 even if from the API perspective the association still appears to 1016 be between two specific locators. However, the locator update is 1017 still secure and the association is still between the same nodes. 1019 o Different associations between the same two locators may result in 1020 connections to different nodes, if the implementation no longer 1021 remembers which identifier the peer had in an earlier association. 1022 This is possible when the peer's locator has changed for 1023 legitimate reasons or when an attacker pretends to be a node that 1024 has the peer's locator. Therefore, when using opportunistic mode, 1025 HIP implementations MUST NOT place any expectation that the peer's 1026 HI returned in the R1 message matches any HI previously seen from 1027 that address. 1029 If the HIP implementation and application do not have the same 1030 understanding of what constitutes an association, this may even 1031 happen within the same association. For instance, an 1032 implementation may not know when HIP state can be purged for UDP- 1033 based applications. 1035 In addition, the following security considerations apply. The 1036 generation counter mechanism will be less efficient in protecting 1037 against replays of the R1 packet, given that the Responder can choose 1038 a replay that uses an arbitrary HI, not just the one given in the I1 1039 packet. 1041 More importantly, the opportunistic exchange is vulnerable to man-in- 1042 the-middle attacks, because the Initiator does not have any public 1043 key information about the peer. To assess the impacts of this 1044 vulnerability, we compare it to vulnerabilities in current, non-HIP- 1045 capable communications. 1047 An attacker on the path between the two peers can insert itself as a 1048 man-in-the-middle by providing its own identifier to the Initiator 1049 and then initiating another HIP association towards the Responder. 1050 For this to be possible, the Initiator must employ opportunistic 1051 mode, and the Responder must be configured to accept a connection 1052 from any HIP-enabled node. 1054 An attacker outside the path will be unable to do so, given that it 1055 cannot respond to the messages in the base exchange. 1057 These security properties are characteristic also of communications 1058 in the current Internet. A client contacting a server without 1059 employing end-to-end security may find itself talking to the server 1060 via a man-in-the-middle, assuming again that the server is willing to 1061 talk to anyone. 1063 If end-to-end security is in place, then the worst that can happen in 1064 both the opportunistic HIP and non-HIP (normal IP) cases is denial- 1065 of-service; an entity on the path can disrupt communications, but 1066 will be unable to successfully insert itself as a man-in-the-middle. 1068 However, once the opportunistic exchange has successfully completed, 1069 HIP provides confidentiality and integrity protection for the 1070 communications, and can securely change the locators of the 1071 endpoints. 1073 As a result, opportunistic mode in HIP offers a "better than nothing" 1074 security model. Initially, a base exchange authenticated in the 1075 opportunistic mode involves a leap of faith subject to man-in-the- 1076 middle attacks, but subsequent datagrams related to the same HIP 1077 association cannot be compromised by a new man-in-the-middle attack, 1078 and further, if the man-in-the-middle moves away from the path of the 1079 active association, the attack would be exposed after the fact. 1080 Thus, it can be stated that opportunistic mode in HIP is at least as 1081 secure as unprotected IP-based communications. 1083 4.2. Updating a HIP Association 1085 A HIP association between two hosts may need to be updated over time. 1086 Examples include the need to rekey expiring security associations, 1087 add new security associations, or change IP addresses associated with 1088 hosts. The UPDATE packet is used for those and other similar 1089 purposes. This document only specifies the UPDATE packet format and 1090 basic processing rules, with mandatory parameters. The actual usage 1091 is defined in separate specifications. 1093 HIP provides a general purpose UPDATE packet, which can carry 1094 multiple HIP parameters, for updating the HIP state between two 1095 peers. The UPDATE mechanism has the following properties: 1097 UPDATE messages carry a monotonically increasing sequence number 1098 and are explicitly acknowledged by the peer. Lost UPDATEs or 1099 acknowledgments may be recovered via retransmission. Multiple 1100 UPDATE messages may be outstanding under certain circumstances. 1102 UPDATE is protected by both HIP_MAC and HIP_SIGNATURE parameters, 1103 since processing UPDATE signatures alone is a potential DoS attack 1104 against intermediate systems. 1106 UPDATE packets are explicitly acknowledged by the use of an 1107 acknowledgment parameter that echoes an individual sequence number 1108 received from the peer. A single UPDATE packet may contain both a 1109 sequence number and one or more acknowledgment numbers (i.e., 1110 piggybacked acknowledgment(s) for the peer's UPDATE). 1112 The UPDATE packet is defined in Section 5.3.5. 1114 4.3. Error Processing 1116 HIP error processing behavior depends on whether or not there exists 1117 an active HIP association. In general, if a HIP association exists 1118 between the sender and receiver of a packet causing an error 1119 condition, the receiver SHOULD respond with a NOTIFY packet. On the 1120 other hand, if there are no existing HIP associations between the 1121 sender and receiver, or the receiver cannot reasonably determine the 1122 identity of the sender, the receiver MAY respond with a suitable ICMP 1123 message; see Section 5.4 for more details. 1125 The HIP protocol and state machine are designed to recover from one 1126 of the parties crashing and losing its state. The following 1127 scenarios describe the main use cases covered by the design. 1129 No prior state between the two systems. 1131 The system with data to send is the Initiator. The process 1132 follows the standard four-packet base exchange, establishing 1133 the HIP association. 1135 The system with data to send has no state with the receiver, but 1136 the receiver has a residual HIP association. 1138 The system with data to send is the Initiator. The Initiator 1139 acts as in no prior state, sending an I1 packet and receiving 1140 an R1 packet. When the Responder receives a valid I2 packet, 1141 the old association is 'discovered' and deleted, and the new 1142 association is established. 1144 The system with data to send has a HIP association, but the 1145 receiver does not. 1147 The system sends data on the outbound user data security 1148 association. The receiver 'detects' the situation when it 1149 receives a user data packet that it cannot match to any HIP 1150 association. The receiving host MUST discard this packet. 1152 The receiving host SHOULD send an ICMP packet, with the type 1153 Parameter Problem, to inform the sender that the HIP 1154 association does not exist (see Section 5.4), and it MAY 1155 initiate a new HIP BEX. However, responding with these 1156 optional mechanisms is implementation or policy dependent. If 1157 the sending application doesn't expect a response, the system 1158 could possibly send a large number of packets in this state, so 1159 for this reason, the sending of one or more ICMP packets is 1160 RECOMMENDED. However, any such responses MUST be rate-limited 1161 to prevent abuse (see Section 5.4). 1163 4.4. HIP State Machine 1165 The HIP protocol itself has little state. In the HIP base exchange, 1166 there is an Initiator and a Responder. Once the security 1167 associations (SAs) are established, this distinction is lost. If the 1168 HIP state needs to be re-established, the controlling parameters are 1169 which peer still has state and which has a datagram to send to its 1170 peer. The following state machine attempts to capture these 1171 processes. 1173 The state machine is symmetric and is presented in a single system 1174 view, representing either an Initiator or a Responder. The state 1175 machine is not a full representation of the processing logic. 1176 Additional processing rules are presented in the packet definitions. 1177 Hence, both are needed to completely implement HIP. 1179 This document extends the state machine as defined in [RFC5201] and 1180 introduces a restart option to allow for the negotiation of 1181 cryptographic algorithms. The extension to the previous state 1182 machine in [RFC5201] is a transition from state I1-SENT to I1-SENT - 1183 the restart option. An Initiator is required to restart the HIP base 1184 exchange if the Responder does not support the HIT Suite of the 1185 Initiator. In this case, the Initiator restarts the HIP base 1186 exchange by sending a new I1 packet with a source HIT supported by 1187 the Responder. 1189 Implementors must understand that the state machine, as described 1190 here, is informational. Specific implementations are free to 1191 implement the actual processing logic differently. Section 6 1192 describes the packet processing rules in more detail. This state 1193 machine focuses on the HIP I1, R1, I2, and R2 packets only. New 1194 states and state transitions may be introduced by mechanisms in other 1195 specifications (such as mobility and multihoming). 1197 4.4.1. State Machine Terminology 1199 Unused Association Lifetime (UAL): Implementation-specific time for 1200 which, if no packet is sent or received for this time interval, a 1201 host MAY begin to tear down an active HIP association. 1203 Maximum Segment Lifetime (MSL): Maximum time that a HIP packet is 1204 expected to spend in the network. A default value of 2 minutes 1205 has been borrowed from [RFC0793] because it is a prevailing 1206 assumption for packet lifetimes. 1208 Exchange Complete (EC): Time that the host spends at the R2-SENT 1209 state before it moves to the ESTABLISHED state. The time is n * 1210 I2 retransmission timeout, where n is about I2_RETRIES_MAX. 1212 Receive ANYOTHER: Any received packet for which no state 1213 transitions or processing rules are defined for a given state. 1215 4.4.2. HIP States 1216 +---------------------+---------------------------------------------+ 1217 | State | Explanation | 1218 +---------------------+---------------------------------------------+ 1219 | UNASSOCIATED | State machine start | 1220 | | | 1221 | I1-SENT | Initiating base exchange | 1222 | | | 1223 | I2-SENT | Waiting to complete base exchange | 1224 | | | 1225 | R2-SENT | Waiting to complete base exchange | 1226 | | | 1227 | ESTABLISHED | HIP association established | 1228 | | | 1229 | CLOSING | HIP association closing, no data can be | 1230 | | sent | 1231 | | | 1232 | CLOSED | HIP association closed, no data can be sent | 1233 | | | 1234 | E-FAILED | HIP base exchange failed | 1235 +---------------------+---------------------------------------------+ 1237 Table 1: HIP States 1239 4.4.3. HIP State Processes 1240 System behavior in state UNASSOCIATED, Table 2. 1242 +----------------------------+--------------------------------------+ 1243 | Trigger | Action | 1244 +----------------------------+--------------------------------------+ 1245 | User data to send, | Send I1 and go to I1-SENT | 1246 | requiring a new HIP | | 1247 | association | | 1248 | | | 1249 | Receive I1 | Send R1 and stay at UNASSOCIATED | 1250 | | | 1251 | Receive I2, process | If successful, send R2 and go to | 1252 | | R2-SENT | 1253 | | | 1254 | | If fail, stay at UNASSOCIATED | 1255 | | | 1256 | Receive user data for an | Optionally send ICMP as defined in | 1257 | unknown HIP association | Section 5.4 and stay at UNASSOCIATED | 1258 | | | 1259 | Receive CLOSE | Optionally send ICMP Parameter | 1260 | | Problem and stay at UNASSOCIATED | 1261 | | | 1262 | Receive ANYOTHER | Drop and stay at UNASSOCIATED | 1263 +----------------------------+--------------------------------------+ 1265 Table 2: UNASSOCIATED - Start state 1267 System behavior in state I1-SENT, Table 3. 1269 +---------------------+---------------------------------------------+ 1270 | Trigger | Action | 1271 +---------------------+---------------------------------------------+ 1272 | Receive I1 from | If the local HIT is smaller than the peer | 1273 | Responder | HIT, drop I1 and stay at I1-SENT (see | 1274 | | Section 6.5 for HIT comparison) | 1275 | | | 1276 | | If the local HIT is greater than the peer | 1277 | | HIT, send R1 and stay at I1-SENT | 1278 | | | 1279 | Receive I2, process | If successful, send R2 and go to R2-SENT | 1280 | | | 1281 | | If fail, stay at I1-SENT | 1282 | | | 1283 | Receive R1, process | If the HIT Suite of the local HIT is not | 1284 | | supported by the peer, select supported | 1285 | | local HIT, send I1 and stay at I1-SENT | 1286 | | | 1287 | | If successful, send I2 and go to I2-SENT | 1288 | | | 1289 | | If fail, stay at I1-SENT | 1290 | | | 1291 | Receive ANYOTHER | Drop and stay at I1-SENT | 1292 | | | 1293 | Timeout | Increment trial counter | 1294 | | | 1295 | | If counter is less than I1_RETRIES_MAX, | 1296 | | send I1 and stay at I1-SENT | 1297 | | | 1298 | | If counter is greater than I1_RETRIES_MAX, | 1299 | | go to E-FAILED | 1300 +---------------------+---------------------------------------------+ 1302 Table 3: I1-SENT - Initiating the HIP base exchange 1304 System behavior in state I2-SENT, Table 4. 1306 +---------------------+---------------------------------------------+ 1307 | Trigger | Action | 1308 +---------------------+---------------------------------------------+ 1309 | Receive I1 | Send R1 and stay at I2-SENT | 1310 | | | 1311 | Receive R1, process | If successful, send I2 and stay at I2-SENT | 1312 | | | 1313 | | If fail, stay at I2-SENT | 1314 | | | 1315 | Receive I2, process | If successful and local HIT is smaller than | 1316 | | the peer HIT, drop I2 and stay at I2-SENT | 1317 | | | 1318 | | If successful and local HIT is greater than | 1319 | | the peer HIT, send R2 and go to R2-SENT | 1320 | | | 1321 | | If fail, stay at I2-SENT | 1322 | | | 1323 | Receive R2, process | If successful, go to ESTABLISHED | 1324 | | | 1325 | | If fail, stay at I2-SENT | 1326 | | | 1327 | Receive CLOSE, | If successful, send CLOSE_ACK and go to | 1328 | process | CLOSED | 1329 | | | 1330 | | If fail, stay at I2-SENT | 1331 | | | 1332 | Receive ANYOTHER | Drop and stay at I2-SENT | 1333 | | | 1334 | Timeout | Increment trial counter | 1335 | | | 1336 | | If counter is less than I2_RETRIES_MAX, | 1337 | | send I2 and stay at I2-SENT | 1338 | | | 1339 | | If counter is greater than I2_RETRIES_MAX, | 1340 | | go to E-FAILED | 1341 +---------------------+---------------------------------------------+ 1343 Table 4: I2-SENT - Waiting to finish the HIP base exchange 1345 System behavior in state R2-SENT, Table 5. 1347 +------------------------+------------------------------------------+ 1348 | Trigger | Action | 1349 +------------------------+------------------------------------------+ 1350 | Receive I1 | Send R1 and stay at R2-SENT | 1351 | | | 1352 | Receive I2, process | If successful, send R2 and stay at | 1353 | | R2-SENT | 1354 | | | 1355 | | If fail, stay at R2-SENT | 1356 | | | 1357 | Receive R1 | Drop and stay at R2-SENT | 1358 | | | 1359 | Receive R2 | Drop and stay at R2-SENT | 1360 | | | 1361 | Receive data or UPDATE | Move to ESTABLISHED | 1362 | | | 1363 | Exchange Complete | Move to ESTABLISHED | 1364 | Timeout | | 1365 | | | 1366 | Receive CLOSE, process | If successful, send CLOSE_ACK and go to | 1367 | | CLOSED | 1368 | | | 1369 | | If fail, stay at ESTABLISHED | 1370 | | | 1371 | Receive CLOSE_ACK | Drop and stay at R2-SENT | 1372 | | | 1373 | Receive NOTIFY | Process and stay at R2-SENT | 1374 +------------------------+------------------------------------------+ 1376 Table 5: R2-SENT - Waiting to finish HIP 1378 System behavior in state ESTABLISHED, Table 6. 1380 +---------------------+---------------------------------------------+ 1381 | Trigger | Action | 1382 +---------------------+---------------------------------------------+ 1383 | Receive I1 | Send R1 and stay at ESTABLISHED | 1384 | | | 1385 | Receive I2 | Process with puzzle and possible Opaque | 1386 | | data verification | 1387 | | | 1388 | | If successful, send R2, drop old HIP | 1389 | | association, establish a new HIP | 1390 | | association and go to R2-SENT | 1391 | | | 1392 | | If fail, stay at ESTABLISHED | 1393 | | | 1394 | Receive R1 | Drop and stay at ESTABLISHED | 1395 | | | 1396 | Receive R2 | Drop and stay at ESTABLISHED | 1397 | | | 1398 | Receive user data | Process and stay at ESTABLISHED | 1399 | for HIP association | | 1400 | | | 1401 | No packet | Send CLOSE and go to CLOSING | 1402 | sent/received | | 1403 | during UAL minutes | | 1404 | | | 1405 | Receive UPDATE | Process and stay at ESTABLISHED | 1406 | | | 1407 | Receive CLOSE, | If successful, send CLOSE_ACK and go to | 1408 | process | CLOSED | 1409 | | | 1410 | | If fail, stay at ESTABLISHED | 1411 | | | 1412 | Receive CLOSE_ACK | Drop and stay at ESTABLISHED | 1413 | | | 1414 | Receive NOTIFY | Process and stay at ESTABLISHED | 1415 +---------------------+---------------------------------------------+ 1417 Table 6: ESTABLISHED - HIP association established 1419 System behavior in state CLOSING, Table 7. 1421 +----------------------------+--------------------------------------+ 1422 | Trigger | Action | 1423 +----------------------------+--------------------------------------+ 1424 | User data to send, | Send I1 and go to I1-SENT | 1425 | requires the creation of | | 1426 | another incarnation of the | | 1427 | HIP association | | 1428 | | | 1429 | Receive I1 | Send R1 and stay at CLOSING | 1430 | | | 1431 | Receive I2, process | If successful, send R2 and go to | 1432 | | R2-SENT | 1433 | | | 1434 | | If fail, stay at CLOSING | 1435 | | | 1436 | Receive R1, process | If successful, send I2 and go to | 1437 | | I2-SENT | 1438 | | | 1439 | | If fail, stay at CLOSING | 1440 | | | 1441 | Receive CLOSE, process | If successful, send CLOSE_ACK, | 1442 | | discard state and go to CLOSED | 1443 | | | 1444 | | If fail, stay at CLOSING | 1445 | | | 1446 | Receive CLOSE_ACK, process | If successful, discard state and go | 1447 | | to UNASSOCIATED | 1448 | | | 1449 | | If fail, stay at CLOSING | 1450 | | | 1451 | Receive ANYOTHER | Drop and stay at CLOSING | 1452 | | | 1453 | Timeout | Increment timeout sum and reset | 1454 | | timer. If timeout sum is less than | 1455 | | UAL+MSL minutes, retransmit CLOSE | 1456 | | and stay at CLOSING | 1457 | | | 1458 | | If timeout sum is greater than | 1459 | | UAL+MSL minutes, go to UNASSOCIATED | 1460 +----------------------------+--------------------------------------+ 1462 Table 7: CLOSING - HIP association has not been used for UAL minutes 1463 System behavior in state CLOSED, Table 8. 1465 +----------------------------------------+--------------------------+ 1466 | Trigger | Action | 1467 +----------------------------------------+--------------------------+ 1468 | Datagram to send, requires the | Send I1, and stay at | 1469 | creation of another incarnation of the | CLOSED | 1470 | HIP association | | 1471 | | | 1472 | Receive I1 | Send R1 and stay at | 1473 | | CLOSED | 1474 | | | 1475 | Receive I2, process | If successful, send R2 | 1476 | | and go to R2-SENT | 1477 | | | 1478 | | If fail, stay at CLOSED | 1479 | | | 1480 | Receive R1, process | If successful, send I2 | 1481 | | and go to I2-SENT | 1482 | | | 1483 | | If fail, stay at CLOSED | 1484 | | | 1485 | Receive CLOSE, process | If successful, send | 1486 | | CLOSE_ACK, stay at | 1487 | | CLOSED | 1488 | | | 1489 | | If fail, stay at CLOSED | 1490 | | | 1491 | Receive CLOSE_ACK, process | If successful, discard | 1492 | | state and go to | 1493 | | UNASSOCIATED | 1494 | | | 1495 | | If fail, stay at CLOSED | 1496 | | | 1497 | Receive ANYOTHER | Drop and stay at CLOSED | 1498 | | | 1499 | Timeout (UAL+2MSL) | Discard state, and go to | 1500 | | UNASSOCIATED | 1501 +----------------------------------------+--------------------------+ 1503 Table 8: CLOSED - CLOSE_ACK sent, resending CLOSE_ACK if necessary 1505 System behavior in state E-FAILED, Table 9. 1507 +-------------------------+-----------------------------------------+ 1508 | Trigger | Action | 1509 +-------------------------+-----------------------------------------+ 1510 | Wait for | Go to UNASSOCIATED. Re-negotiation is | 1511 | implementation-specific | possible after moving to UNASSOCIATED | 1512 | time | state. | 1513 +-------------------------+-----------------------------------------+ 1515 Table 9: E-FAILED - HIP failed to establish association with peer 1517 4.4.4. Simplified HIP State Diagram 1519 The following diagram (Figure 2) shows the major state transitions. 1520 Transitions based on received packets implicitly assume that the 1521 packets are successfully authenticated or processed. 1523 +--+ +----------------------------+ 1524 recv I1, send R1 | | | | 1525 | v v | 1526 +--------------+ recv I2, send R2 | 1527 +----------------| UNASSOCIATED |----------------+ | 1528 datagram | +--+ +--------------+ | | 1529 to send, | | | Alg. not supported, | | 1530 send I1 | | | send I1 | | 1531 . v | v | | 1532 . +---------+ recv I2, send R2 | | 1533 +---->| I1-SENT |--------------------------------------+ | | 1534 | +---------+ +----------------------+ | | | 1535 | | recv R2, | recv I2, send R2 | | | | 1536 | v send I2 | v v v | 1537 | +---------+ | +---------+ | 1538 | +--->| I2-SENT |----------+ +--------------| R2-SENT |<---+ | 1539 | | +---------+ | +---------+ | | 1540 | | | |recv R2 | data or| | | 1541 | |recv R1, | | | EC timeout| | | 1542 | |send I2 +--|-----------------+ | receive I2,| | 1543 | | | | +-------------+ | send R2| | 1544 | | | +------>| ESTABLISHED |<----------+ | | 1545 | | | +-------------+ | | 1546 | | | | | | receive I2, send R2 | | 1547 | | +------------+ | +-------------------------------+ | 1548 | | | +-----------+ | | 1549 | | | no packet sent/received| +---+ | | 1550 | | | for UAL min, send CLOSE| | |timeout | | 1551 | | | v v |(UAL+MSL) | | 1552 | | | +---------+ |retransmit | | 1553 +--|----------|------------------------| CLOSING |-+CLOSE | | 1554 | | +---------+ | | 1555 | | | | | | | | 1556 +----------|-------------------------+ | | +----------------+ | 1557 | | +-----------+ +------------------|--+ 1558 | | |recv CLOSE, recv CLOSE_ACK | | 1559 | +-------------+ |send CLOSE_ACK or timeout | | 1560 | recv CLOSE, | | (UAL+MSL) | | 1561 | send CLOSE_ACK v v | | 1562 | +--------+ receive I2, send R2 | | 1563 +---------------------| CLOSED |------------------------------+ | 1564 +--------+ | 1565 ^ | | | 1566 recv CLOSE, send CLOSE_ACK| | | timeout (UAL+2MSL) | 1567 +-+ +------------------------------------+ 1569 Figure 2 1571 4.5. User Data Considerations 1573 4.5.1. TCP and UDP Pseudo-Header Computation for User Data 1575 When computing TCP and UDP checksums on user data packets that flow 1576 through sockets bound to HITs, the IPv6 pseudo-header format 1577 [RFC2460] MUST be used, even if the actual addresses in the header of 1578 the packet are IPv4 addresses. Additionally, the HITs MUST be used 1579 in place of the IPv6 addresses in the IPv6 pseudo-header. Note that 1580 the pseudo-header for actual HIP payloads is computed differently; 1581 see Section 5.1.1. 1583 4.5.2. Sending Data on HIP Packets 1585 Other documents may define how to include user data in various HIP 1586 packets. However, currently the HIP header is a terminal header, and 1587 not followed by any other headers. 1589 4.5.3. Transport Formats 1591 The actual data transmission format, used for user data after the HIP 1592 base exchange, is not defined in this document. Such transport 1593 formats and methods are described in separate specifications. All 1594 HIP implementations MUST implement, at minimum, the ESP transport 1595 format for HIP [I-D.ietf-hip-rfc5202-bis]. The transport format to 1596 be chosen is negotiated in the base exchange. The Responder 1597 expresses its preference of the transport format in the 1598 TRANSPORT_FORMAT_LIST in the R1 packet and the Initiator selects one 1599 transport format and adds the respective HIP parameter to the I2 1600 packet. 1602 4.5.4. Reboot, Timeout, and Restart of HIP 1604 Simulating a loss of state is a potential DoS attack. The following 1605 process has been crafted to manage state recovery without presenting 1606 a DoS opportunity. 1608 If a host reboots or the HIP association times out, it has lost its 1609 HIP state. If the host that lost state has a datagram to send to the 1610 peer, it simply restarts the HIP base exchange. After the base 1611 exchange has completed, the Initiator can create a new payload 1612 association and start sending data. The peer does not reset its 1613 state until it receives a valid I2 packet. 1615 If a system receives a user data packet that cannot be matched to any 1616 existing HIP association, it is possible that it has lost the state 1617 and its peer has not. It MAY send an ICMP packet with the Parameter 1618 Problem type, and with the pointer pointing to the referred HIP- 1619 related association information. Reacting to such traffic depends on 1620 the implementation and the environment where the implementation is 1621 used. 1623 If the host, that apparently has lost its state, decides to restart 1624 the HIP base exchange, it sends an I1 packet to the peer. After the 1625 base exchange has been completed successfully, the Initiator can 1626 create a new HIP association and the peer drops its old payload 1627 associations and creates a new one. 1629 4.6. Certificate Distribution 1631 This document does not define how to use certificates or how to 1632 transfer them between hosts. These functions are expected to be 1633 defined in a future specification as for HIP Version 1 [RFC6253]. A 1634 parameter type value, meant to be used for carrying certificates, is 1635 reserved, though: CERT, Type 768; see Section 5.2. 1637 5. Packet Formats 1639 5.1. Payload Format 1641 All HIP packets start with a fixed header. 1643 0 1 2 3 1644 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 1645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1646 | Next Header | Header Length |0| Packet Type |Version| RES.|1| 1647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1648 | Checksum | Controls | 1649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1650 | Sender's Host Identity Tag (HIT) | 1651 | | 1652 | | 1653 | | 1654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1655 | Receiver's Host Identity Tag (HIT) | 1656 | | 1657 | | 1658 | | 1659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1660 | | 1661 / HIP Parameters / 1662 / / 1663 | | 1664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1665 The HIP header is logically an IPv6 extension header. However, this 1666 document does not describe processing for Next Header values other 1667 than decimal 59, IPPROTO_NONE, the IPv6 'no next header' value. 1668 Future documents MAY define behavior for also other values. However, 1669 current implementations MUST ignore trailing data if an unimplemented 1670 Next Header value is received. 1672 The Header Length field contains the combined length of the HIP 1673 Header and HIP parameters in 8-byte units, excluding the first 8 1674 bytes. Since all HIP headers MUST contain the sender's and 1675 receiver's HIT fields, the minimum value for this field is 4, and 1676 conversely, the maximum length of the HIP Parameters field is 1677 (255*8)-32 = 2008 bytes (see Section 5.1.3 regarding HIP 1678 fragmentation). Note: this sets an additional limit for sizes of 1679 parameters included in the Parameters field, independent of the 1680 individual parameter maximum lengths. 1682 The Packet Type indicates the HIP packet type. The individual packet 1683 types are defined in the relevant sections. If a HIP host receives a 1684 HIP packet that contains an unrecognized packet type, it MUST drop 1685 the packet. 1687 The HIP Version field is four bits. The version defined in this 1688 document is 2. The version number is expected to be incremented only 1689 if there are incompatible changes to the protocol. Most extensions 1690 can be handled by defining new packet types, new parameter types, or 1691 new Controls (see Section 5.1.2) . 1693 The following three bits are reserved for future use. They MUST be 1694 zero when sent, and they MUST be ignored when handling a received 1695 packet. 1697 The two fixed bits in the header are reserved for SHIM6 compatibility 1698 [RFC5533], Section 5.3. For implementations adhering (only) to this 1699 specification, they MUST be set as shown when sending and MUST be 1700 ignored when receiving. This is to ensure optimal forward 1701 compatibility. Note that for implementations that implement other 1702 compatible specifications in addition to this specification, the 1703 corresponding rules may well be different. For example, an 1704 implementation that implements both this specification and the SHIM6 1705 protocol may need to check these bits in order to determine how to 1706 handle the packet. 1708 The HIT fields are always 128 bits (16 bytes) long. 1710 5.1.1. Checksum 1712 Since the checksum covers the source and destination addresses in the 1713 IP header, it MUST be recomputed on HIP-aware NAT devices. 1715 If IPv6 is used to carry the HIP packet, the pseudo-header [RFC2460] 1716 contains the source and destination IPv6 addresses, HIP packet length 1717 in the pseudo-header length field, a zero field, and the HIP protocol 1718 number (see Section 5.1) in the Next Header field. The length field 1719 is in bytes and can be calculated from the HIP header length field: 1721 (HIP Header Length + 1) * 8. 1723 In case of using IPv4, the IPv4 UDP pseudo-header format [RFC0768] is 1724 used. In the pseudo-header, the source and destination addresses are 1725 those used in the IP header, the zero field is obviously zero, the 1726 protocol is the HIP protocol number (see Section 4), and the length 1727 is calculated as in the IPv6 case. 1729 5.1.2. HIP Controls 1731 The HIP Controls field conveys information about the structure of the 1732 packet and capabilities of the host. 1734 The following fields have been defined: 1736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1737 | | | | | | | | | | | | | | | |A| 1738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1740 A - Anonymous: If this is set, the sender's HI in this packet is 1741 anonymous, i.e., one not listed in a directory. Anonymous HIs 1742 SHOULD NOT be stored. This control is set in packets using 1743 anonymous sender HIs. The peer receiving an anonymous HI in an R1 1744 or I2 may choose to refuse it. 1746 The rest of the fields are reserved for future use and MUST be set to 1747 zero in sent packets and MUST be ignored in received packets. 1749 5.1.3. HIP Fragmentation Support 1751 A HIP implementation MUST support IP fragmentation/reassembly. 1752 Fragment reassembly MUST be implemented in both IPv4 and IPv6, but 1753 fragment generation is REQUIRED to be implemented in IPv4 (IPv4 1754 stacks and networks will usually do this by default) and RECOMMENDED 1755 to be implemented in IPv6. In IPv6 networks, the minimum MTU is 1756 larger, 1280 bytes, than in IPv4 networks. The larger MTU size is 1757 usually sufficient for most HIP packets, and therefore fragment 1758 generation may not be needed. If it is expected that a host will 1759 send HIP packets that are larger than the minimum IPv6 MTU, the 1760 implementation MUST implement fragment generation even for IPv6. 1762 In IPv4 networks, HIP packets may encounter low MTUs along their 1763 routed path. Since basic HIP, as defined in this document, does not 1764 provide a mechanism to use multiple IP datagrams for a single HIP 1765 packet, support for path MTU discovery does not bring any value to 1766 HIP in IPv4 networks. HIP-aware NAT devices SHOULD perform IPv4 1767 reassembly/fragmentation for HIP packets. 1769 All HIP implementations have to be careful while employing a 1770 reassembly algorithm so that the algorithm is sufficiently resistant 1771 to DoS attacks. 1773 Certificate chains can cause the packet to be fragmented and 1774 fragmentation can open implementations to denial-of-service attacks 1775 [KAU03]. "Hash and URL" schemes as defined in [RFC6253] for HIP 1776 version 1 may be used to avoid fragmentation and mitigate resulting 1777 DoS attacks. 1779 5.2. HIP Parameters 1781 The HIP parameters carry information that is necessary for 1782 establishing and maintaining a HIP association. For example, the 1783 peer's public keys as well as the signaling for negotiating ciphers 1784 and payload handling are encapsulated in HIP parameters. Additional 1785 information, meaningful for end-hosts or middleboxes, may also be 1786 included in HIP parameters. The specification of the HIP parameters 1787 and their mapping to HIP packets and packet types is flexible to 1788 allow HIP extensions to define new parameters and new protocol 1789 behavior. 1791 In HIP packets, HIP parameters are ordered according to their numeric 1792 type number and encoded in TLV format. 1794 The following parameter types are currently defined. 1796 +------------------------+-------+-----------+----------------------+ 1797 | TLV | Type | Length | Data | 1798 +------------------------+-------+-----------+----------------------+ 1799 | R1_COUNTER | 129 | 12 | Puzzle generation | 1800 | | | | counter | 1801 | | | | | 1802 | PUZZLE | 257 | 12 | K and Random #I | 1803 | | | | | 1804 | SOLUTION | 321 | 20 | K, Random #I and | 1805 | | | | puzzle solution J | 1806 | | | | | 1807 | SEQ | 385 | 4 | UPDATE packet ID | 1808 | | | | number | 1809 | | | | | 1810 | ACK | 449 | variable | UPDATE packet ID | 1811 | | | | number | 1812 | | | | | 1813 | DH_GROUP_LIST | 511 | variable | Ordered list of DH | 1814 | | | | Group IDs supported | 1815 | | | | by a host | 1816 | | | | | 1817 | DIFFIE_HELLMAN | 513 | variable | public key | 1818 | | | | | 1819 | HIP_CIPHER | 579 | variable | List of HIP | 1820 | | | | encryption | 1821 | | | | algorithms | 1822 | | | | | 1823 | ENCRYPTED | 641 | variable | Encrypted part of a | 1824 | | | | HIP packet | 1825 | | | | | 1826 | HOST_ID | 705 | variable | Host Identity with | 1827 | | | | Fully-Qualified | 1828 | | | | Domain FQDN (Name) | 1829 | | | | or Network Access | 1830 | | | | Identifier (NAI) | 1831 | | | | | 1832 | HIT_SUITE_LIST | 715 | variable | Ordered list of the | 1833 | | | | HIT suites supported | 1834 | | | | by the Responder | 1835 | | | | | 1836 | CERT | 768 | variable | HI Certificate; used | 1837 | | | | to transfer | 1838 | | | | certificates. | 1839 | | | | Specified in a | 1840 | | | | separate docment. | 1841 | | | | | 1842 | NOTIFICATION | 832 | variable | Informational data | 1843 | | | | | 1844 | ECHO_REQUEST_SIGNED | 897 | variable | Opaque data to be | 1845 | | | | echoed back; signed | 1846 | | | | | 1847 | ECHO_RESPONSE_SIGNED | 961 | variable | Opaque data echoed | 1848 | | | | back by request; | 1849 | | | | signed | 1850 | | | | | 1851 | TRANSPORT_FORMAT_LIST | 2049 | Ordered | variable | 1852 | | | list of | | 1853 | | | preferred | | 1854 | | | HIP | | 1855 | | | transport | | 1856 | | | type | | 1857 | | | numbers | | 1858 | | | | | 1859 | HIP_MAC | 61505 | variable | HMAC-based message | 1860 | | | | authentication code, | 1861 | | | | with key material | 1862 | | | | from KEYMAT | 1863 | | | | | 1864 | HIP_MAC_2 | 61569 | variable | HMAC based message | 1865 | | | | authentication code, | 1866 | | | | with key material | 1867 | | | | from KEYMAT. Unlike | 1868 | | | | HIP_MAC, the HOST_ID | 1869 | | | | parameter is | 1870 | | | | included in | 1871 | | | | HIP_MAC_2 | 1872 | | | | calculation. | 1873 | | | | | 1874 | HIP_SIGNATURE_2 | 61633 | variable | Signature used in R1 | 1875 | | | | packet | 1876 | | | | | 1877 | HIP_SIGNATURE | 61697 | variable | Signature of the | 1878 | | | | packet | 1879 | | | | | 1880 | ECHO_REQUEST_UNSIGNED | 63661 | variable | Opaque data to be | 1881 | | | | echoed back; after | 1882 | | | | signature | 1883 | | | | | 1884 | ECHO_RESPONSE_UNSIGNED | 63425 | variable | Opaque data echoed | 1885 | | | | back by request; | 1886 | | | | after signature | 1887 +------------------------+-------+-----------+----------------------+ 1889 As the ordering (from lowest to highest) of HIP parameters is 1890 strictly enforced (see Section 5.2.1), the parameter type values for 1891 existing parameters have been spaced to allow for future protocol 1892 extensions. 1894 The following parameter type number ranges are defined. 1896 +---------------+---------------------------------------------------+ 1897 | Type Range | Purpose | 1898 +---------------+---------------------------------------------------+ 1899 | 0 - 1023 | Handshake | 1900 | | | 1901 | 1024 - 2047 | Reserved | 1902 | | | 1903 | 2048 - 4095 | Parameters related to HIP transport formats | 1904 | | | 1905 | 4096 - 8191 | Signed parameters allocated through specification | 1906 | | documents | 1907 | | | 1908 | 8192 - 32767 | Reserved | 1909 | | | 1910 | 32768 - 49151 | Free for experimentation. Signed parameters. | 1911 | | | 1912 | 49152 - 61439 | Reserved | 1913 | | | 1914 | 61440 - 62463 | Signatures and (signed) MACs | 1915 | | | 1916 | 62464 - 63487 | Parameters that are neither signed nor MACed | 1917 | | | 1918 | 63488 - 64511 | Rendezvous and relaying | 1919 | | | 1920 | 64512 - 65023 | Parameters that are neither signed nor MACed | 1921 | | | 1922 | 65024 - 65535 | Reserved | 1923 +---------------+---------------------------------------------------+ 1925 The process for defining new parameters is described in Section 5.2.2 1926 of this document. 1928 The range between 32768 (2^15) and 49151 (2^15 + 2^14) are free for 1929 experimentation. Types from this range SHOULD be selected in a 1930 random fashion to reduce the probability of collisions. 1932 5.2.1. TLV Format 1934 The TLV-encoded parameters are described in the following 1935 subsections. The type-field value also describes the order of these 1936 fields in the packet. The parameters MUST be included in the packet 1937 so that their types form an increasing order. If multiple parameters 1938 with the same type number are in one packet, the parameters with the 1939 same type MUST be consecutive in the packet. If the order does not 1940 follow this rule, the packet is considered to be malformed and it 1941 MUST be discarded. 1943 Parameters using type values from 2048 up to 4095 are related to 1944 transport formats. Currently, one transport format is defined: the 1945 ESP transport format [I-D.ietf-hip-rfc5202-bis]. 1947 All of the encoded TLV parameters have a length (that includes the 1948 Type and Length fields), which is a multiple of 8 bytes. When 1949 needed, padding MUST be added to the end of the parameter so that the 1950 total length is a multiple of 8 bytes. This rule ensures proper 1951 alignment of data. Any added padding bytes MUST be zeroed by the 1952 sender, and their values SHOULD NOT be checked by the receiver. 1954 The Length field indicates the length of the Contents field (in 1955 bytes). Consequently, the total length of the TLV parameter 1956 (including Type, Length, Contents, and Padding) is related to the 1957 Length field according to the following formula: 1959 Total Length = 11 + Length - (Length + 3) % 8; 1961 where % is the modulo operator 1963 0 1 2 3 1964 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 1965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1966 | Type |C| Length | 1967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1968 | | 1969 / Contents / 1970 / +-+-+-+-+-+-+-+-+ 1971 | | Padding | 1972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1974 Type Type code for the parameter. 16 bits long, C-bit 1975 being part of the Type code. 1976 C Critical. One if this parameter is critical, and 1977 MUST be recognized by the recipient, zero otherwise. 1978 The C bit is considered to be a part of the Type 1979 field. Consequently, critical parameters are always 1980 odd and non-critical ones have an even value. 1981 Length Length of the Contents, in bytes excluding Type, 1982 Length, and Padding. 1983 Contents Parameter specific, defined by Type 1984 Padding Padding, 0-7 bytes, added if needed 1986 Critical parameters (indicated by the odd type number) MUST be 1987 recognized by the recipient. If a recipient encounters a critical 1988 parameter that it does not recognize, it MUST NOT process the packet 1989 any further. It MAY send an ICMP or NOTIFY, as defined in 1990 Section 4.3. 1992 Non-critical parameters MAY be safely ignored. If a recipient 1993 encounters a non-critical parameter that it does not recognize, it 1994 SHOULD proceed as if the parameter was not present in the received 1995 packet. 1997 5.2.2. Defining New Parameters 1999 Future specifications may define new parameters as needed. When 2000 defining new parameters, care must be taken to ensure that the 2001 parameter type values are appropriate and leave suitable space for 2002 other future extensions. One must remember that the parameters MUST 2003 always be arranged in numerically increasing order by Type code, 2004 thereby limiting the order of parameters (see Section 5.2.1). 2006 The following rules MUST be followed when defining new parameters. 2008 1. The low-order bit C of the Type code is used to distinguish 2009 between critical and non-critical parameters. Hence, even 2010 parameter type numbers indicate non-critical parameters while odd 2011 parameter type numbers indicate critical parameters. 2013 2. A new parameter MAY be critical only if an old implementation 2014 that ignored it would cause security problems. In general, new 2015 parameters SHOULD be defined as non-critical, and expect a reply 2016 from the recipient. 2018 3. If a system implements a new critical parameter, it MUST provide 2019 the ability to set the associated feature off, such that the 2020 critical parameter is not sent at all. The configuration option 2021 MUST be well documented. Implementations operating in a mode 2022 adhering to this specification MUST disable the sending of new 2023 critical parameters by default. In other words, the management 2024 interface MUST allow vanilla standards-only mode as a default 2025 configuration setting, and MAY allow new critical payloads to be 2026 configured on (and off). 2028 4. See Section 9 for allocation rules regarding Type codes. 2030 5.2.3. R1_COUNTER 2031 0 1 2 3 2032 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 2033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2034 | Type | Length | 2035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2036 | Reserved, 4 bytes | 2037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2038 | R1 generation counter, 8 bytes | 2039 | | 2040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2042 Type 129 2043 Length 12 2044 R1 generation 2045 counter The current generation of valid puzzles 2047 The R1_COUNTER parameter contains a 64-bit unsigned integer in 2048 network-byte order, indicating the current generation of valid 2049 puzzles. The sender SHOULD increment this counter periodically. It 2050 is RECOMMENDED that the counter value is incremented at least as 2051 often as old PUZZLE values are deprecated so that SOLUTIONs to them 2052 are no longer accepted. 2054 Support for the R1_COUNTER parameter is mandatory although its 2055 inclusion in the R1 packet is optional. It SHOULD be included in the 2056 R1 (in which case, it is covered by the signature), and if present in 2057 the R1, it MUST be echoed (including the Reserved field verbatim) by 2058 the Initiator in the I2 packet. 2060 5.2.4. PUZZLE 2061 0 1 2 3 2062 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 2063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2064 | Type | Length | 2065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2066 | #K, 1 byte | Lifetime | Opaque, 2 bytes | 2067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2068 | Random #I, RHASH_len/8 bytes | 2069 / / 2070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2072 Type 257 2073 Length 4 + RHASH_len / 8 2074 #K #K is the number of verified bits 2075 Lifetime puzzle lifetime 2^(value-32) seconds 2076 Opaque data set by the Responder, indexing the puzzle 2077 Random #I random number of size RHASH_len bits 2079 Random #I is represented as a n-bit integer (where n is RHASH_len), 2080 #K and Lifetime as 8-bit integers, all in network byte order. 2082 The PUZZLE parameter contains the puzzle difficulty #K and a n-bit 2083 random integer #I. The Puzzle Lifetime indicates the time during 2084 which the puzzle solution is valid, and sets a time limit that should 2085 not be exceeded by the Initiator while it attempts to solve the 2086 puzzle. The lifetime is indicated as a power of 2 using the formula 2087 2^(Lifetime-32) seconds. A puzzle MAY be augmented with an 2088 ECHO_REQUEST_SIGNED or an ECHO_REQUEST_UNSIGNED parameter included in 2089 the R1; the contents of the echo request are then echoed back in the 2090 ECHO_RESPONSE_SIGNED or in the ECHO_RESPONSE_UNSIGNED parameter, 2091 allowing the Responder to use the included information as a part of 2092 its puzzle processing. 2094 The Opaque and Random #I field are not covered by the HIP_SIGNATURE_2 2095 parameter. 2097 5.2.5. SOLUTION 2098 0 1 2 3 2099 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 2100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2101 | Type | Length | 2102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2103 | #K, 1 byte | Reserved | Opaque, 2 bytes | 2104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2105 | Random #I, n bytes | 2106 / / 2107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2108 | Puzzle solution #J, RHASH_len/8 bytes | 2109 / / 2110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2112 Type 321 2113 Length 4 + RHASH_len /4 2114 #K #K is the number of verified bits 2115 Reserved zero when sent, ignored when received 2116 Opaque copied unmodified from the received PUZZLE 2117 parameter 2118 Random #I random number of size RHASH_len bits 2119 Puzzle solution #J random number of size RHASH_len bits 2121 Random #I and Random #J are represented as n-bit unsigned integers 2122 (where n is RHASH_len), #K as an 8-bit unsigned integer, all in 2123 network byte order. 2125 The SOLUTION parameter contains a solution to a puzzle. It also 2126 echoes back the random difficulty #K, the Opaque field, and the 2127 puzzle integer #I. 2129 5.2.6. DH_GROUP_LIST 2130 0 1 2 3 2131 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 2132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2133 | Type | Length | 2134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2135 | DH GROUP ID #1| DH GROUP ID #2| DH GROUP ID #3| DH GROUP ID #4| 2136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2137 | DH GROUP ID #n| Padding | 2138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2140 Type 511 2141 Length number of DH Group IDs 2142 DH GROUP ID identifies a DH GROUP ID supported by the host. 2143 The list of IDs is ordered by preference of the 2144 host. The possible DH Group IDs are defined 2145 in the DIFFIE_HELLMAN parameter. Each DH Group ID 2146 is one octet long. 2148 The DH_GROUP_LIST parameter contains the list of supported DH Group 2149 IDs of a host. The Initiator sends the DH_GROUP_LIST in the I1 2150 packet, the Responder sends its own list in the signed part of the R1 2151 packet. The DH Group IDs in the DH_GROUP_LIST are listed in the 2152 order of their preference of the host sending the list. DH Group IDs 2153 that are listed first are preferred over the DH Group IDs listed 2154 later. The information in the DH_GROUP_LIST allows the Responder to 2155 select the DH group preferred by itself and supported by the 2156 Initiator. Based on the DH_GROUP_LIST in the R1 packet, the 2157 Initiator can determine if the Responder has selected the best 2158 possible choice based on the Initiator's and Responder's preferences. 2159 If the Responder's choice differs from the best choice, the Initiator 2160 can conclude that there was an attempted downgrade attack (see 2161 Section 4.1.7). 2163 When selecting the DH group for the DIFFIE_HELLMAN parameter in the 2164 R1 packet, the Responder MUST select the first DH Group ID in its 2165 DH_GROUP_LIST in the R1 packet that is compatible with one of the 2166 Suite IDs in the Initiator's DH_GROUP_LIST in the I1 packet. The 2167 Responder MUST NOT select any other DH Group ID that is contained in 2168 both lists because a downgrade attack cannot be detected then. 2170 In general, hosts SHOULD prefer stronger groups over weaker ones if 2171 the computation overhead is not prohibitively high for the intended 2172 application. 2174 5.2.7. DIFFIE_HELLMAN 2176 0 1 2 3 2177 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 2178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2179 | Type | Length | 2180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2181 | Group ID | Public Value Length | Public Value / 2182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2183 / | 2184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2185 / | Padding | 2186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2188 Type 513 2189 Length length in octets, excluding Type, Length, and 2190 Padding 2191 Group ID identifies values for p and g as well as the KDF 2192 Public Value length of the following Public Value in octets 2193 Length 2194 Public Value the sender's public Diffie-Hellman key 2196 A single DIFFIE_HELLMAN parameter may be included in selected HIP 2197 packets based on the DH Group ID selected (Section 5.2.6). The 2198 following Group IDs have been defined: 2200 Group KDF Value 2201 Reserved 0 2202 DEPRECATED 1 2203 DEPRECATED 2 2204 1536-bit MODP group [RFC3526] HKDF [RFC5869] 3 2205 3072-bit MODP group [RFC3526] HKDF [RFC5869] 4 2206 DEPRECATED 5 2207 DEPRECATED 6 2208 NIST P-256 [RFC5903] HKDF [RFC5869] 7 2209 NIST P-384 [RFC5903] HKDF [RFC5869] 8 2210 NIST P-521 [RFC5903] HKDF [RFC5869] 9 2211 SECP160R1 [SECG] HKDF [RFC5869] 10 2212 2048-bit MODP group [RFC3526] HKDF [RFC5869] 11 2214 The MODP Diffie-Hellman groups are defined in [RFC3526]. The ECDH 2215 groups 7 - 9 are defined in [RFC5903] and [RFC6090]. ECDH group 10 2216 is covered in Appendix D. Any ECDH used with HIP MUST have a co- 2217 factor of 1. 2219 The Group ID also defines the key derivation function that is to be 2220 used for deriving the symmetric keys for the HMAC and symmetric 2221 encryption from the keying material from the Diffie Hellman key 2222 exchange (see Section 6.5). 2224 A HIP implementation MUST implement Group ID 3. The 160-bit 2225 SECP160R1 group can be used when lower security is enough (e.g., web 2226 surfing) and when the equipment is not powerful enough (e.g., some 2227 PDAs). Implementations SHOULD implement Group IDs 4 and 8. 2229 To avoid unnecessary failures during the base exchange, the rest of 2230 the groups SHOULD be implemented in hosts where resources are 2231 adequate. 2233 5.2.8. HIP_CIPHER 2235 0 1 2 3 2236 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 2237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2238 | Type | Length | 2239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2240 | Cipher ID #1 | Cipher ID #2 | 2241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2242 | Cipher ID #n | Padding | 2243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2245 Type 579 2246 Length length in octets, excluding Type, Length, and 2247 Padding 2248 Cipher ID identifies the cipher algorithm to be used for 2249 encrypting the contents of the ENCRYPTED parameter 2251 The following Cipher IDs are defined: 2253 Suite ID Value 2255 RESERVED 0 2256 NULL-ENCRYPT 1 ([RFC2410]) 2257 AES-128-CBC 2 ([RFC3602]) 2258 RESERVED 3 (unused value) 2259 AES-256-CBC 4 ([RFC3602]) 2261 The sender of a HIP_CIPHER parameter MUST make sure that there are no 2262 more than six (6) Cipher IDs in one HIP_CIPHER parameter. 2263 Conversely, a recipient MUST be prepared to handle received transport 2264 parameters that contain more than six Cipher IDs by accepting the 2265 first six Cipher IDs and dropping the rest. The limited number of 2266 Cipher IDs sets the maximum size of the HIP_CIPHER parameter. As the 2267 default configuration, the HIP_CIPHER parameter MUST contain at least 2268 one of the mandatory Cipher IDs. There MAY be a configuration option 2269 that allows the administrator to override this default. 2271 The Responder lists supported and desired Cipher IDs in order of 2272 preference in the R1, up to the maximum of six Cipher IDs. The 2273 Initiator MUST choose only one of the corresponding Cipher IDs. This 2274 Cipher ID will be used for generating the ENCRYPTED parameter. 2276 Mandatory implementation: AES-128-CBC. Implementors SHOULD support 2277 NULL-ENCRYPT for testing/debugging purposes, but MUST NOT offer or 2278 accept this value unless explicitly configured for testing/debugging 2279 of the HIP protocol. 2281 5.2.9. HOST_ID 2283 0 1 2 3 2284 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 2285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2286 | Type | Length | 2287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2288 | HI Length |DI-type| DI Length | 2289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2290 | Algorithm | Host Identity / 2291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2292 / | Domain Identifier / 2293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2294 / | Padding | 2295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2297 Type 705 2298 Length length in octets, excluding Type, Length, and 2299 Padding 2300 HI Length length of the Host Identity in octets 2301 DI-type type of the following Domain Identifier field 2302 DI Length length of the Domain Identifier field in octets 2303 Algorithm index to the employed algorithm 2304 Host Identity actual Host Identity 2305 Domain Identifier the identifier of the sender 2307 The following DI-types have been defined: 2309 Type Value 2310 none included 0 2311 FQDN 1 2312 NAI 2 2314 FQDN Fully Qualified Domain Name, in binary format. 2315 NAI Network Access Identifier 2317 The format for the FQDN is defined in RFC 1035 [RFC1035] Section 3.1. 2318 The format for the NAI is defined in [RFC4282] 2320 A host MAY optionally associate the Host Identity with a single 2321 Domain Identifier in the HOST_ID parameter. If there is no Domain 2322 Identifier, i.e., the DI-type field is zero, the DI Length field is 2323 set to zero as well. 2325 The following HI Algorithms have been defined: 2327 Algorithm 2328 profiles Values 2330 RESERVED 0 2331 DSA 3 [FIPS186-3] (RECOMMENDED) 2332 RSA 5 [RFC3447] (REQUIRED) 2333 ECDSA 7 [RFC4754] (REQUIRED) 2334 ECDSA_LOW 9 [SECG] (RECOMMENDED) 2336 For DSA, RSA, and ECDSA key types, profiles containing at least 112 2337 bits of security strength (as defined by [NIST.800-131A.2011]) should 2338 be used. For RSA signature padding, the PSS method of padding 2339 [RFC3447] MUST be used. 2341 The Host Identity is derived from the DNSKEY format for RSA and DSA. 2342 For these, the Public Key field of the RDATA part from RFC 4034 2343 [RFC4034] is used. For ECC we distinguish two different profiles: 2344 ECDSA and ECDSA_LOW. ECC contains curves approved by NIST and 2345 defined in RFC 4754 [RFC4754]. ECDSA_LOW is defined for devices with 2346 low computational capabilities and uses shorter curves from SECG 2347 [SECG]. Any ECDSA used with HIP MUST have a co-factor of 1. 2349 For ECDSA and ECDSA_LOW Host Identities are represented by the 2350 following fields: 2352 0 1 2 3 2353 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2355 | ECC Curve | / 2356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2357 / Public Key | 2358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2360 ECC Curve Curve label 2361 Public Key Represented in Octet-string format 2362 [RFC6090] 2364 For hosts that implement ECDSA as algorithm the following ECC curves 2365 are required: 2367 Algorithm Curve Values 2369 ECDSA RESERVED 0 2370 ECDSA NIST P-256 1 [RFC4754] 2371 ECDSA NIST P-384 2 [RFC4754] 2373 For hosts that implement the ECDSA_LOW algorithm profile, the 2374 following curve is required: 2376 Algorithm Curve Values 2378 ECDSA_LOW RESERVED 0 2379 ECDSA_LOW SECP160R1 1 [SECG] 2381 5.2.10. HIT_SUITE_LIST 2383 The HIT_SUITE_LIST parameter contains a list of the supported HIT 2384 Suite IDs of the Responder. The Responder sends the HIT_SUITE_LIST 2385 in the signed part of the R1 packet. Based on the HIT_SUITE_LIST, 2386 the Initiator can determine which source HIT Suite IDs are supported 2387 by the Responder. 2389 0 1 2 3 2390 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 2391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2392 | Type | Length | 2393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2394 | ID #1 | ID #2 | ID #3 | ID #4 | 2395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2396 | ID #n | Padding | 2397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2399 Type 715 2400 Length number of HIT Suite IDs 2401 ID identifies a HIT Suite ID supported by the host. 2402 The list of IDs is ordered by preference of the 2403 host. Each HIT Suite ID is one octet long. The four 2404 higher-order bits of the ID field correspond to the 2405 HIT Suite ID in the ORCHID OGA field. The four 2406 lower-order bits are reserved and set to 0 and 2407 ignored by the receiver. 2409 The HIT Suite ID indexes a HIT Suite. HIT Suites are composed of 2410 signature algorithms as defined in Section 5.2.9 and hash functions. 2412 The ID field in the HIT_SUITE_LIST is defined as eight-bit field as 2413 opposed to the four-bit HIT Suite ID and OGA field in the ORCHID. 2414 This difference is a measure to accommodate larger HIT Suite IDs if 2415 the 16 available values prove insufficient. In that case, one of the 2416 16 values, zero, will be used to indicate that four additional bits 2417 of the ORCHID will be used to encode the HIT Suite ID. Hence, the 2418 current four-bit HIT Suite-IDs only use the four higher order bits in 2419 the ID field. Future documents may define the use of the four lower- 2420 order bits in the ID field. 2422 The following HIT Suites ID are defined: 2424 HIT Suite ID 2425 RESERVED 0 2426 RSA,DSA/SHA-256 1 (REQUIRED) 2427 ECDSA/SHA-384 2 (RECOMMENDED) 2428 ECDSA_LOW/SHA-1 3 (RECOMMENDED) 2430 5.2.11. TRANSPORT_FORMAT_LIST 2432 The TRANSPORT_FORMAT_LIST parameter contains a list of the supported 2433 HIP transport formats (TFs) of the Responder. The Responder sends 2434 the TRANSPORT_FORMAT_LIST in the signed part of the R1 packet. Based 2435 on the TRANSPORT_FORMAT_LIST, the Initiator chooses one suitable 2436 transport format and includes the respective HIP transport format 2437 parameter in its response packet. 2439 0 1 2 3 2440 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 2441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2442 | Type | Length | 2443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2444 | TF type #1 | TF type #2 / 2445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2446 / TF type #n | Padding | 2447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2449 Type 2049 2450 Length 2x number of TF types 2451 TF Type identifies a transport format (TF) type supported by 2452 the host. The TF type numbers correspond to the HIP 2453 parameter type numbers of the respective transport 2454 format 2455 parameters. The list of TF types is ordered by 2456 preference of the sender 2458 The TF type numbers index the respective HIP parameters for the 2459 transport formats in the type number range between 2050 to 4095. The 2460 parameters and their use are defined in separate documents. 2461 Currently, the only transport format defined is IPsec ESP 2462 [I-D.ietf-hip-rfc5202-bis]. 2464 For each listed TF type, the sender of the TRANSPORT_FORMAT_LIST 2465 parameter MUST include the respective transport format parameter in 2466 the HIP packet. The receiver MUST ignore the TF type in the 2467 TRANSPORT_FORMAT_LIST if no matching transport format parameter is 2468 present in the packet. 2470 5.2.12. HIP_MAC 2471 0 1 2 3 2472 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 2473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2474 | Type | Length | 2475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2476 | | 2477 | HMAC | 2478 / / 2479 / +-------------------------------+ 2480 | | Padding | 2481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2483 Type 61505 2484 Length length in octets, excluding Type, Length, and 2485 Padding 2486 HMAC HMAC computed over the HIP packet, excluding the 2487 HIP_MAC parameter and any following parameters, such 2488 as HIP_SIGNATURE, HIP_SIGNATURE_2, 2489 ECHO_REQUEST_UNSIGNED, or ECHO_RESPONSE_UNSIGNED. 2490 The checksum field MUST be set to zero and the HIP 2491 header length in the HIP common header MUST be 2492 calculated not to cover any excluded parameters 2493 when the HMAC is calculated. The size of the 2494 HMAC is the natural size of the hash computation 2495 output depending on the used hash function. 2497 The HMAC uses RHASH as hash algorithm. The calculation and 2498 verification process is presented in Section 6.4.1. 2500 5.2.13. HIP_MAC_2 2502 The HIP_MAC_2 is a MAC of the packet and the HI of the sender in the 2503 form of a HOST_ID parameter when that parameter is not actually 2504 included in the packet. The parameter structure is the same as in 2505 Section 5.2.12. The fields are: 2507 Type 61569 2508 Length length in octets, excluding Type, Length, and 2509 Padding 2510 HMAC HMAC computed over the HIP packet, excluding the 2511 HIP_MAC_2 parameter and any following parameters 2512 such as HIP_SIGNATURE, HIP_SIGNATURE_2, 2513 ECHO_REQUEST_UNSIGNED, or ECHO_RESPONSE_UNSIGNED, 2514 and including an additional sender's HOST_ID 2515 parameter during the HMAC calculation. The checksum 2516 field MUST be set to zero and the HIP header length 2517 in the HIP common header MUST be calculated not to 2518 cover any excluded parameters when the HMAC is 2519 calculated. The size of the HMAC is the natural 2520 size of the hash computation output depending on the 2521 used hash function. 2523 The HMAC uses RHASH as hash algorithm. The calculation and 2524 verification process is presented in Section 6.4.1. 2526 5.2.14. HIP_SIGNATURE 2528 0 1 2 3 2529 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 2530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2531 | Type | Length | 2532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2533 | SIG alg | Signature / 2534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2535 / | Padding | 2536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2538 Type 61697 2539 Length length in octets, excluding Type, Length, and 2540 Padding 2541 SIG alg signature algorithm 2542 Signature the signature is calculated over the HIP packet, 2543 excluding the HIP_SIGNATURE parameter and any 2544 parameters that follow the HIP_SIGNATURE parameter. 2545 When the signature is calculated the checksum field 2546 MUST be set to zero, and the HIP header length in 2547 the HIP common header MUST be calculated only up to 2548 the beginning of the HIP_SIGNATURE parameter. 2550 The signature algorithms are defined in Section 5.2.9. The signature 2551 in the Signature field is encoded using the method depending on the 2552 signature algorithm (e.g., according to [RFC3110] in case of RSA/SHA- 2553 1, according to [RFC5702] in case of RSA/SHA-256, according to 2555 [RFC2536] in case of DSA, or according to [RFC6090] in case of 2556 ECDSA). 2558 The HIP_SIGNATURE calculation and verification process are presented 2559 in Section 6.4.2. 2561 5.2.15. HIP_SIGNATURE_2 2563 The HIP_SIGNATURE_2 excludes the variable parameters in the R1 packet 2564 to allow R1 pre-creation. The parameter structure is the same as in 2565 Section 5.2.14. The fields are: 2567 Type 61633 2568 Length length in octets, excluding Type, Length, and 2569 Padding 2570 SIG alg signature algorithm 2571 Signature Within the R1 packet that contains the 2572 HIP_SIGNATURE_2 parameter, the Initiator's HIT, the 2573 checksum field, and the Opaque and Random #I fields 2574 in the PUZZLE parameter MUST be set to zero while 2575 computing the HIP_SIGNATURE_2 signature. Further, 2576 the HIP packet length in the HIP header MUST be 2577 adjusted as if the HIP_SIGNATURE_2 was not in the 2578 packet during the signature calculation, i.e., the 2579 HIP packet length points to the beginning of 2580 the HIP_SIGNATURE_2 parameter during signing and 2581 verification. 2583 Zeroing the Initiator's HIT makes it possible to create R1 packets 2584 beforehand, to minimize the effects of possible DoS attacks. Zeroing 2585 the Random #I and Opaque fields within the PUZZLE parameter allows 2586 these fields to be populated dynamically on precomputed R1s. 2588 Signature calculation and verification follows the process defined in 2589 Section 6.4.2. 2591 5.2.16. SEQ 2593 0 1 2 3 2594 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 2595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2596 | Type | Length | 2597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2598 | Update ID | 2599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2600 Type 385 2601 Length 8 2602 Update ID 32-bit sequence number 2604 The Update ID is an unsigned number in network byte order, 2605 initialized by a host to zero upon moving to ESTABLISHED state. The 2606 Update ID has scope within a single HIP association, and not across 2607 multiple associations or multiple hosts. The Update ID is 2608 incremented by one before each new UPDATE that is sent by the host; 2609 the first UPDATE packet originated by a host has an Update ID of 0. 2611 5.2.17. ACK 2613 0 1 2 3 2614 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2616 | Type | Length | 2617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2618 | peer Update ID 1 | 2619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2620 / peer Update ID n | 2621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2623 Type 449 2624 Length length in octets, excluding Type and Length 2625 peer Update ID 32-bit sequence number corresponding to the 2626 Update ID being ACKed. 2628 The ACK parameter includes one or more Update IDs that have been 2629 received from the peer. The number of peer Update IDs can be 2630 inferred from the length by dividing it by 4. 2632 5.2.18. ENCRYPTED 2633 0 1 2 3 2634 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 2635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2636 | Type | Length | 2637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2638 | Reserved | 2639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2640 | IV / 2641 / / 2642 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 2644 / Encrypted data / 2645 / / 2646 / +-------------------------------+ 2647 / | Padding | 2648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2650 Type 641 2651 Length length in octets, excluding Type, Length, and 2652 Padding 2653 Reserved zero when sent, ignored when received 2654 IV Initialization vector, if needed, otherwise 2655 nonexistent. The length of the IV is inferred from 2656 the HIP_CIPHER. 2657 Encrypted The data is encrypted using the encryption algorithm 2658 data defined in the HIP_CIPHER parameter. 2660 The ENCRYPTED parameter encapsulates other parameters, the encrypted 2661 data, which holds one or more HIP parameters in block encrypted form. 2663 Consequently, the first fields in the encapsulated parameter(s) are 2664 Type and Length of the first such parameter, allowing the contents to 2665 be easily parsed after decryption. 2667 The field labeled "Encrypted data" consists of the output of one or 2668 more HIP parameters concatenated together that have been passed 2669 through an encryption algorithm. Each of these inner parameters is 2670 padded according to the rules of Section 5.2.1 for padding individual 2671 parameters. As a result, the concatenated parameters will be a block 2672 of data that is 8-byte aligned. 2674 Some encryption algorithms require that the data to be encrypted must 2675 be a multiple of the cipher algorithm block size. In this case, the 2676 above block of data MUST include additional padding, as specified by 2677 the encryption algorithm. The size of the extra padding is selected 2678 so that the length of the unencrypted data block is a multiple of the 2679 cipher block size. The encryption algorithm may specify padding 2680 bytes other than zero; for example, AES [FIPS.197.2001] uses the 2681 PKCS5 padding scheme (see section 6.1.1 of [RFC2898]) where the 2682 remaining n bytes to fill the block each have the value of n. This 2683 yields an "unencrypted data" block that is transformed to an 2684 "encrypted data" block by the cipher suite. This extra padding added 2685 to the set of parameters to satisfy the cipher block alignment rules 2686 is not counted in HIP TLV length fields, and this extra padding 2687 should be removed by the cipher suite upon decryption. 2689 Note that the length of the cipher suite output may be smaller or 2690 larger than the length of the set of parameters to be encrypted, 2691 since the encryption process may compress the data or add additional 2692 padding to the data. 2694 Once this encryption process is completed, the Encrypted data field 2695 is ready for inclusion in the parameter. If necessary, additional 2696 Padding for 8-byte alignment is then added according to the rules of 2697 Section 5.2.1. 2699 5.2.19. NOTIFICATION 2701 The NOTIFICATION parameter is used to transmit informational data, 2702 such as error conditions and state transitions, to a HIP peer. A 2703 NOTIFICATION parameter may appear in NOTIFY packets. The use of the 2704 NOTIFICATION parameter in other packet types is for further study. 2706 0 1 2 3 2707 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 2708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2709 | Type | Length | 2710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2711 | Reserved | Notify Message Type | 2712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2713 | / 2714 / Notification Data / 2715 / +---------------+ 2716 / | Padding | 2717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2719 Type 832 2720 Length length in octets, excluding Type, Length, and 2721 Padding 2722 Reserved zero when sent, ignored when received 2723 Notify Message specifies the type of notification 2724 Type 2725 Notification informational or error data transmitted in addition 2726 Data to the Notify Message Type. Values for this field 2727 are type specific (see below). 2728 multiple of 8 bytes. 2730 Notification information can be error messages specifying why an HIP 2731 Security Association could not be established. It can also be status 2732 data that a HIP implementation wishes to communicate with a peer 2733 process. The table below lists the notification messages and their 2734 Notification Message Types. HIP packets MAY contain multiple 2735 NOTIFICATION parameters if several problems exist or several 2736 independent pieces of information must be transmitted. 2738 To avoid certain types of attacks, a Responder SHOULD avoid sending a 2739 NOTIFICATION to any host with which it has not successfully verified 2740 a puzzle solution. 2742 Notify Message Types in the range 0-16383 are intended for reporting 2743 errors and in the range 16384-65535 for other status information. An 2744 implementation that receives a NOTIFY packet with a Notify Message 2745 Type that indicates an error in response to a request packet (e.g., 2746 I1, I2, UPDATE) SHOULD assume that the corresponding request has 2747 failed entirely. Unrecognized error types MUST be ignored except 2748 that they SHOULD be logged. 2750 As currently defined, Notify Message Type values 1-10 are used for 2751 informing about errors in packet structures, values 11-20 for 2752 informing about problems in parameters. 2754 Notification Data in NOTIFICATION parameters where the Notify Message 2755 Type is in the status range MUST be ignored if not recognized. 2757 Notify Message Types - Errors Value 2758 ----------------------------- ----- 2760 UNSUPPORTED_CRITICAL_PARAMETER_TYPE 1 2762 Sent if the parameter type has the "critical" bit set and the 2763 parameter type is not recognized. Notification Data contains the 2764 two-octet parameter type. 2766 INVALID_SYNTAX 7 2768 Indicates that the HIP message received was invalid because some 2769 type, length, or value was out of range or because the request 2770 was otherwise malformed. To avoid a denial-of-service 2771 attack using forged messages, this status may only be returned 2772 for packets whose HIP_MAC (if present) and SIGNATURE have been 2773 verified. This status MUST be sent in response to any error not 2774 covered by one of the other status types, and SHOULD NOT contain 2775 details to avoid leaking information to someone probing a node. 2776 To aid debugging, more detailed error information SHOULD be 2777 written to a console or log. 2779 NO_DH_PROPOSAL_CHOSEN 14 2781 None of the proposed group IDs was acceptable. 2783 INVALID_DH_CHOSEN 15 2785 The DH Group ID field does not correspond to one offered 2786 by the Responder. 2788 NO_HIP_PROPOSAL_CHOSEN 16 2790 None of the proposed HIT Suites or HIP Encryption Algorithms was 2791 acceptable. 2793 INVALID_HIP_CIPHER_CHOSEN 17 2795 The HIP_CIPHER Crypto ID does not correspond to one offered by 2796 the Responder. 2798 UNSUPPORTED_HIT_SUITE 20 2800 Sent in response to an I1 or R1 packet for which the HIT suite 2801 is not supported. 2803 AUTHENTICATION_FAILED 24 2805 Sent in response to a HIP signature failure, except when 2806 the signature verification fails in a NOTIFY message. 2808 CHECKSUM_FAILED 26 2810 Sent in response to a HIP checksum failure. 2812 HIP_MAC_FAILED 28 2814 Sent in response to a HIP HMAC failure. 2816 ENCRYPTION_FAILED 32 2818 The Responder could not successfully decrypt the 2819 ENCRYPTED parameter. 2821 INVALID_HIT 40 2823 Sent in response to a failure to validate the peer's 2824 HIT from the corresponding HI. 2826 BLOCKED_BY_POLICY 42 2827 The Responder is unwilling to set up an association 2828 for some policy reason (e.g., received HIT is NULL 2829 and policy does not allow opportunistic mode). 2831 RESPONDER_BUSY_PLEASE_RETRY 44 2833 The Responder is unwilling to set up an association as it is 2834 suffering under some kind of overload and has chosen to shed load 2835 by rejecting the Initiator's request. The Initiator may retry; 2836 however, the Initiator MUST find another (different) puzzle 2837 solution for any such retries. Note that the Initiator may need 2838 to obtain a new puzzle with a new I1/R1 exchange. 2840 Notify Message Types - Status Value 2841 ----------------------------- ----- 2843 I2_ACKNOWLEDGEMENT 16384 2845 The Responder has an I2 packet from the Initiator but had to 2846 queue the I2 packet for processing. The puzzle was correctly 2847 solved and the Responder is willing to set up an association but 2848 currently has a number of I2 packets in the processing queue. 2849 The R2 packet is sent after the I2 packet was processed. 2851 5.2.20. ECHO_REQUEST_SIGNED 2853 0 1 2 3 2854 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 2855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2856 | Type | Length | 2857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2858 | Opaque data (variable length) | 2859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2861 Type 897 2862 Length length of the opaque data in octets 2863 Opaque data opaque data, supposed to be meaningful only to the 2864 node that sends ECHO_REQUEST_SIGNED and receives a 2865 corresponding ECHO_RESPONSE_SIGNED or 2866 ECHO_RESPONSE_UNSIGNED. 2868 The ECHO_REQUEST_SIGNED parameter contains an opaque blob of data 2869 that the sender wants to get echoed back in the corresponding reply 2870 packet. 2872 The ECHO_REQUEST_SIGNED and corresponding echo response parameters 2873 MAY be used for any purpose where a node wants to carry some state in 2874 a request packet and get it back in a response packet. The 2875 ECHO_REQUEST_SIGNED is covered by the HIP_MAC and SIGNATURE. A HIP 2876 packet can contain only one ECHO_REQUEST_SIGNED parameter and MAY 2877 contain multiple ECHO_REQUEST_UNSIGNED parameters. The 2878 ECHO_REQUEST_SIGNED parameter MUST be responded to with an 2879 ECHO_RESPONSE_SIGNED. 2881 5.2.21. ECHO_REQUEST_UNSIGNED 2883 0 1 2 3 2884 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 2885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2886 | Type | Length | 2887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2888 | Opaque data (variable length) | 2889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2891 Type 63661 2892 Length length of the opaque data in octets 2893 Opaque data opaque data, supposed to be meaningful only to the 2894 node that sends ECHO_REQUEST_UNSIGNED and receives a 2895 corresponding ECHO_RESPONSE_UNSIGNED. 2897 The ECHO_REQUEST_UNSIGNED parameter contains an opaque blob of data 2898 that the sender wants to get echoed back in the corresponding reply 2899 packet. 2901 The ECHO_REQUEST_UNSIGNED and corresponding echo response parameters 2902 MAY be used for any purpose where a node wants to carry some state in 2903 a request packet and get it back in a response packet. The 2904 ECHO_REQUEST_UNSIGNED is not covered by the HIP_MAC and SIGNATURE. A 2905 HIP packet can contain one or more ECHO_REQUEST_UNSIGNED parameters. 2906 It is possible that middleboxes add ECHO_REQUEST_UNSIGNED parameters 2907 in HIP packets passing by. The creator of the ECHO_REQUEST_UNSIGNED 2908 (end-host or middlebox) has to create the Opaque field so that it can 2909 later identify and remove the corresponding ECHO_RESPONSE_UNSIGNED 2910 parameter. 2912 The ECHO_REQUEST_UNSIGNED parameter MUST be responded to with an 2913 ECHO_RESPONSE_UNSIGNED parameter. 2915 5.2.22. ECHO_RESPONSE_SIGNED 2916 0 1 2 3 2917 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 2918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2919 | Type | Length | 2920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2921 | Opaque data (variable length) | 2922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2924 Type 961 2925 Length length of the opaque data in octets 2926 Opaque data opaque data, copied unmodified from the 2927 ECHO_REQUEST_SIGNED or ECHO_REQUEST_UNSIGNED 2928 parameter that triggered this response. 2930 The ECHO_RESPONSE_SIGNED parameter contains an opaque blob of data 2931 that the sender of the ECHO_REQUEST_SIGNED wants to get echoed back. 2932 The opaque data is copied unmodified from the ECHO_REQUEST_SIGNED 2933 parameter. 2935 The ECHO_REQUEST_SIGNED and ECHO_RESPONSE_SIGNED parameters MAY be 2936 used for any purpose where a node wants to carry some state in a 2937 request packet and get it back in a response packet. The 2938 ECHO_RESPONSE_SIGNED is covered by the HIP_MAC and SIGNATURE. 2940 5.2.23. ECHO_RESPONSE_UNSIGNED 2942 0 1 2 3 2943 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 2944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2945 | Type | Length | 2946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2947 | Opaque data (variable length) | 2948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2950 Type 63425 2951 Length length of the opaque data in octets 2952 Opaque data opaque data, copied unmodified from the 2953 ECHO_REQUEST_SIGNED or ECHO_REQUEST_UNSIGNED 2954 parameter that triggered this response. 2956 The ECHO_RESPONSE_UNSIGNED parameter contains an opaque blob of data 2957 that the sender of the ECHO_REQUEST_SIGNED or ECHO_REQUEST_UNSIGNED 2958 wants to get echoed back. The opaque data is copied unmodified from 2959 the corresponding echo request parameter. 2961 The echo request and ECHO_RESPONSE_UNSIGNED parameters MAY be used 2962 for any purpose where a node wants to carry some state in a request 2963 packet and get it back in a response packet. The 2964 ECHO_RESPONSE_UNSIGNED is not covered by the HIP_MAC and SIGNATURE. 2966 5.3. HIP Packets 2968 There are eight basic HIP packets (see Table 10). Four are for the 2969 HIP base exchange, one is for updating, one is for sending 2970 notifications, and two are for closing a HIP association. Support 2971 for NOTIFY packet type is optional, but support for all other HIP 2972 packet types listed below is mandatory. 2974 +------------------+------------------------------------------------+ 2975 | Packet type | Packet name | 2976 +------------------+------------------------------------------------+ 2977 | 1 | I1 - the HIP Initiator Packet | 2978 | | | 2979 | 2 | R1 - the HIP Responder Packet | 2980 | | | 2981 | 3 | I2 - the Second HIP Initiator Packet | 2982 | | | 2983 | 4 | R2 - the Second HIP Responder Packet | 2984 | | | 2985 | 16 | UPDATE - the HIP Update Packet | 2986 | | | 2987 | 17 | NOTIFY - the HIP Notify Packet | 2988 | | | 2989 | 18 | CLOSE - the HIP Association Closing Packet | 2990 | | | 2991 | 19 | CLOSE_ACK - the HIP Closing Acknowledgment | 2992 | | Packet | 2993 +------------------+------------------------------------------------+ 2995 Table 10: HIP packets and packet type values 2997 Packets consist of the fixed header as described in Section 5.1, 2998 followed by the parameters. The parameter part, in turn, consists of 2999 zero or more TLV-coded parameters. 3001 In addition to the base packets, other packet types may be defined 3002 later in separate specifications. For example, support for mobility 3003 and multi-homing is not included in this specification. 3005 See Notation (Section 2.2) for the notation used in the operations. 3007 In the future, an optional upper-layer payload MAY follow the HIP 3008 header. The Next Header field in the header indicates if there is 3009 additional data following the HIP header. The HIP packet, however, 3010 MUST NOT be fragmented into multiple extension headers by setting the 3011 Next Header field in a HIP header to the HIP protocol number. This 3012 limits the size of the possible additional data in the packet. 3014 5.3.1. I1 - the HIP Initiator Packet 3016 The HIP header values for the I1 packet: 3018 Header: 3019 Packet Type = 1 3020 SRC HIT = Initiator's HIT 3021 DST HIT = Responder's HIT, or NULL 3023 IP ( HIP ( DH_GROUP_LIST ) ) 3025 The I1 packet contains the fixed HIP header and the Initiator's 3026 DH_GROUP_LIST. 3028 Valid control bits: none 3030 The Initiator receives the Responder's HIT either from a DNS lookup 3031 of the Responder's FQDN (see 5205-bis), from some other repository, 3032 or from a local table. If the Initiator does not know the 3033 Responder's HIT, it may attempt to use opportunistic mode by using 3034 NULL (all zeros) as the Responder's HIT. See also "HIP Opportunistic 3035 Mode" (Section 4.1.8). 3037 Since the I1 packet is so easy to spoof even if it were signed, no 3038 attempt is made to add to its generation or processing cost. 3040 The Initiator includes a DH_GROUP_LIST parameter in the I1 packet to 3041 inform the Responder of its preferred DH Group IDs. Note that the 3042 DH_GROUP_LIST in the I1 packet is not protected by a signature. 3044 Implementations MUST be able to handle a storm of received I1 3045 packets, discarding those with common content that arrive within a 3046 small time delta. 3048 5.3.2. R1 - the HIP Responder Packet 3050 The HIP header values for the R1 packet: 3052 Header: 3053 Packet Type = 2 3054 SRC HIT = Responder's HIT 3055 DST HIT = Initiator's HIT 3057 IP ( HIP ( [ R1_COUNTER, ] 3058 PUZZLE, 3059 DIFFIE_HELLMAN, 3060 HIP_CIPHER, 3061 HOST_ID, 3062 HIT_SUITE_LIST, 3063 DH_GROUP_LIST, 3064 [ ECHO_REQUEST_SIGNED, ] 3065 TRANSPORT_FORMAT_LIST, 3066 HIP_SIGNATURE_2 ) 3067 <, ECHO_REQUEST_UNSIGNED >i) 3069 Valid control bits: A 3071 If the Responder's HI is an anonymous one, the A control MUST be set. 3073 The Initiator's HIT MUST match the one received in the I1 packet if 3074 the R1 is a response to an I1. If the Responder has multiple HIs, 3075 the Responder's HIT used MUST match Initiator's request. If the 3076 Initiator used opportunistic mode, the Responder may select freely 3077 among its HIs. See also "HIP Opportunistic Mode" (Section 4.1.8). 3079 The R1 packet generation counter is used to determine the currently 3080 valid generation of puzzles. The value is increased periodically, 3081 and it is RECOMMENDED that it is increased at least as often as 3082 solutions to old puzzles are no longer accepted. 3084 The Puzzle contains a Random #I and the difficulty #K. The 3085 difficulty #K indicates the number of lower-order bits, in the puzzle 3086 hash result, that must be zeros; see Section 4.1.2. The Random #I is 3087 not covered by the signature and must be zeroed during the signature 3088 calculation, allowing the sender to select and set the #I into a 3089 precomputed R1 packet just prior sending it to the peer. 3091 The Responder selects the Diffie-Hellman public value based on the 3092 Initiator's preference expressed in the DH_GROUP_LIST parameter in 3093 the I1 packet. The Responder sends back its own preference based on 3094 which it chose the DH public value as DH_GROUP_LIST. This allows the 3095 Initiator to determine whether its own DH_GROUP_LIST in the sent I1 3096 packet was manipulated by an attacker. 3098 The Diffie-Hellman public value is ephemeral, and values SHOULD NOT 3099 be reused across different HIP associations. Once the Responder has 3100 received a valid response to an R1 packet, that Diffie-Hellman value 3101 SHOULD be deprecated. It is possible that the Responder has sent the 3102 same Diffie-Hellman value to different hosts simultaneously in 3103 corresponding R1 packets and those responses should also be accepted. 3104 However, as a defense against I1 packet storms, an implementation MAY 3105 propose, and re-use unless avoidable, the same Diffie-Hellman value 3106 for a period of time, for example, 15 minutes. By using a small 3107 number of different puzzles for a given Diffie-Hellman value, the R1 3108 packets can be precomputed and delivered as quickly as I1 packets 3109 arrive. A scavenger process should clean up unused Diffie-Hellman 3110 values and puzzles. 3112 Re-using Diffie-Hellman public values opens up the potential security 3113 risk of more than one Initiator ending up with the same keying 3114 material (due to faulty random number generators). Also, more than 3115 one Initiator using the same Responder public key half may lead to 3116 potentially easier cryptographic attacks and to imperfect forward 3117 security. 3119 However, these risks involved in re-using the same public value are 3120 statistical; that is, the authors are not aware of any mechanism that 3121 would allow manipulation of the protocol so that the risk of the re- 3122 use of any given Responder Diffie-Hellman public key would differ 3123 from the base probability. Consequently, it is RECOMMENDED that 3124 Responders avoid re-using the same DH key with multiple Initiators, 3125 but because the risk is considered statistical and not known to be 3126 manipulable, the implementations MAY re-use a key in order to ease 3127 resource-constrained implementations and to increase the probability 3128 of successful communication with legitimate clients even under an I1 3129 packet storm. In particular, when it is too expensive to generate 3130 enough precomputed R1 packets to supply each potential Initiator with 3131 a different DH key, the Responder MAY send the same DH key to several 3132 Initiators, thereby creating the possibility of multiple legitimate 3133 Initiators ending up using the same Responder-side public key. 3134 However, as soon as the Responder knows that it will use a particular 3135 DH key, it SHOULD stop offering it. This design is aimed to allow 3136 resource-constrained Responders to offer services under I1 packet 3137 storms and to simultaneously make the probability of DH key re-use 3138 both statistical and as low as possible. 3140 If the Responder uses the same DH keypair for multiple handshakes, it 3141 must take care to avoid small subgroup attacks [RFC2785]. To avoid 3142 these attacks, when receiving the I2 message, the Responder SHOULD 3143 validate the Initiators DH public key as described in [RFC2785] 3144 Section 3.1. In case the validation fails, the Responder MUST NOT 3145 generate a DH shared key and MUST silently abort the HIP BEX. 3147 The HIP_CIPHER contains the encryption algorithms supported by the 3148 Responder to encrypt the contents of the ENCRYPTED parameter, in the 3149 order of preference. All implementations MUST support AES [RFC3602]. 3151 The HIT_SUITE_LIST parameter is an ordered list of the Responder's 3152 preferred and supported HIT Suites. The list allows the Initiator to 3153 determine whether its own source HIT matches any suite supported by 3154 the Responder. 3156 The ECHO_REQUEST_SIGNED and ECHO_REQUEST_UNSIGNED parameters contain 3157 data that the sender wants to receive unmodified in the corresponding 3158 response packet in the ECHO_RESPONSE_SIGNED or ECHO_RESPONSE_UNSIGNED 3159 parameter. The R1 packet may contain zero or more 3160 ECHO_REQUEST_UNSIGNED parameters as described in 3161 Section Section 5.2.21. 3163 The TRANSPORT_FORMAT_LIST parameter is an ordered list of the 3164 Responder's preferred and supported transport format types. The list 3165 allows the Initiator and the Responder to agree on a common type for 3166 payload protection. This parameter is described in Section 5.2.11. 3168 The signature is calculated over the whole HIP packet as described in 3169 Section 5.2.15. This allows the Responder to use precomputed R1s. 3170 The Initiator SHOULD validate this signature. It MUST check that the 3171 Responder's HI matches with the one expected, if any. 3173 5.3.3. I2 - the Second HIP Initiator Packet 3175 The HIP header values for the I2 packet: 3177 Header: 3178 Type = 3 3179 SRC HIT = Initiator's HIT 3180 DST HIT = Responder's HIT 3182 IP ( HIP ( [R1_COUNTER,] 3183 SOLUTION, 3184 DIFFIE_HELLMAN, 3185 HIP_CIPHER, 3186 ENCRYPTED { HOST_ID } or HOST_ID, 3187 [ ECHO_RESPONSE_SIGNED ,] 3188 TRANSPORT_FORMAT_LIST, 3189 HIP_MAC, 3190 HIP_SIGNATURE 3191 <, ECHO_RESPONSE_UNSIGNED>i ) ) 3193 Valid control bits: A 3194 The HITs used MUST match the ones used in the R1. 3196 If the Initiator's HI is an anonymous one, the A control bit MUST be 3197 set. 3199 If present in the I1 packet, the Initiator MUST include an unmodified 3200 copy of the R1_COUNTER parameter received in the corresponding R1 3201 packet into the I2 packet. 3203 The Solution contains the Random #I from R1 and the computed #J. The 3204 low-order #K bits of the RHASH(I | ... | J) MUST be zero. 3206 The Diffie-Hellman value is ephemeral. If precomputed, a scavenger 3207 process should clean up unused Diffie-Hellman values. The Responder 3208 MAY re-use Diffie-Hellman values under some conditions as specified 3209 in Section 5.3.2. 3211 The HIP_CIPHER contains the single encryption suite selected by the 3212 Initiator, that it uses to encrypt the ENCRYPTED parameters. The 3213 chosen cipher MUST correspond to one of the ciphers offered by the 3214 Responder in the R1. All implementations MUST support AES [RFC3602]. 3216 The Initiator's HI MAY be encrypted using the HIP_CIPHER encryption 3217 algorithm. The keying material is derived from the Diffie-Hellman 3218 exchanged as defined in Section 6.5. 3220 The ECHO_RESPONSE_SIGNED and ECHO_RESPONSE_UNSIGNED contain the 3221 unmodified Opaque data copied from the corresponding echo request 3222 parameter(s). 3224 The TRANSPORT_FORMAT_LIST contains the single transport format type 3225 selected by the Initiator. The chosen type MUST correspond to one of 3226 the types offered by the Responder in the R1. Currently, the only 3227 transport format defined is the ESP transport format 3228 ([I-D.ietf-hip-rfc5202-bis]). 3230 The HMAC value in the HIP_MAC parameter is calculated over the whole 3231 HIP packet, excluding any parameters after the HIP_MAC, as described 3232 in Section 6.4.1. The Responder MUST validate the HIP_MAC. 3234 The signature is calculated over the whole HIP packet, excluding any 3235 parameters after the HIP_SIGNATURE, as described in Section 5.2.14. 3236 The Responder MUST validate this signature. The Responder uses the 3237 HI in the packet or a HI acquired by some other means for verifying 3238 the signature. 3240 5.3.4. R2 - the Second HIP Responder Packet 3242 The HIP header values for the R2 packet: 3244 Header: 3245 Packet Type = 4 3246 SRC HIT = Responder's HIT 3247 DST HIT = Initiator's HIT 3249 IP ( HIP ( HIP_MAC_2, HIP_SIGNATURE ) ) 3251 Valid control bits: none 3253 The HIP_MAC_2 is calculated over the whole HIP packet, with 3254 Responder's HOST_ID parameter concatenated with the HIP packet. The 3255 HOST_ID parameter is removed after the HMAC calculation. The 3256 procedure is described in Section 6.4.1. 3258 The signature is calculated over the whole HIP packet. 3260 The Initiator MUST validate both the HIP_MAC and the signature. 3262 5.3.5. UPDATE - the HIP Update Packet 3264 The HIP header values for the UPDATE packet: 3266 Header: 3267 Packet Type = 16 3268 SRC HIT = Sender's HIT 3269 DST HIT = Recipient's HIT 3271 IP ( HIP ( [SEQ, ACK, ] HIP_MAC, HIP_SIGNATURE ) ) 3273 Valid control bits: None 3275 The UPDATE packet contains mandatory HIP_MAC and HIP_SIGNATURE 3276 parameters, and other optional parameters. 3278 The UPDATE packet contains zero or one SEQ parameter. The presence 3279 of a SEQ parameter indicates that the receiver MUST acknowledge the 3280 the UPDATE. An UPDATE that does not contain a SEQ but only an ACK 3281 parameter is simply an acknowledgment of a previous UPDATE and itself 3282 MUST NOT be acknowledged by a separate ACK parameter. Such UPDATE 3283 packets containing only an ACK parameter do not require processing in 3284 relative order to other UPDATE packets. An UPDATE packet without 3285 either a SEQ or an ACK parameter is invalid; such unacknowledged 3286 updates MUST instead use a NOTIFY packet. 3288 An UPDATE packet contains zero or one ACK parameters. The ACK 3289 parameter echoes the SEQ sequence number of the UPDATE packet being 3290 ACKed. A host MAY choose to acknowledge more than one UPDATE packet 3291 at a time; e.g., the ACK parameter may contain the last two SEQ 3292 values received, for resilience against packet loss. ACK values are 3293 not cumulative; each received unique SEQ value requires at least one 3294 corresponding ACK value in reply. Received ACK parameters that are 3295 redundant are ignored. Hosts MUST implement the processing of ACK 3296 parameters with multiple SEQ numbers even if they do not implement 3297 sending ACK parameters with multiple SEQ numbers. 3299 The UPDATE packet may contain both a SEQ and an ACK parameter. In 3300 this case, the ACK parameter is being piggybacked on an outgoing 3301 UPDATE. In general, UPDATEs carrying SEQ SHOULD be ACKed upon 3302 completion of the processing of the UPDATE. A host MAY choose to 3303 hold the UPDATE carrying an ACK parameter for a short period of time 3304 to allow for the possibility of piggybacking the ACK parameter, in a 3305 manner similar to TCP delayed acknowledgments. 3307 A sender MAY choose to forego reliable transmission of a particular 3308 UPDATE (e.g., it becomes overcome by events). The semantics are such 3309 that the receiver MUST acknowledge the UPDATE, but the sender MAY 3310 choose to not care about receiving the ACK parameter. 3312 UPDATEs MAY be retransmitted without incrementing SEQ. If the same 3313 subset of parameters is included in multiple UPDATEs with different 3314 SEQs, the host MUST ensure that the receiver's processing of the 3315 parameters multiple times will not result in a protocol error. 3317 5.3.6. NOTIFY - the HIP Notify Packet 3319 The NOTIFY packet MAY be used to provide information to a peer. 3320 Typically, NOTIFY is used to indicate some type of protocol error or 3321 negotiation failure. NOTIFY packets are unacknowledged. The 3322 receiver can handle the packet only as informational, and SHOULD NOT 3323 change its HIP state (see Section 4.4.2) based purely on a received 3324 NOTIFY packet. 3326 The HIP header values for the NOTIFY packet: 3328 Header: 3329 Packet Type = 17 3330 SRC HIT = Sender's HIT 3331 DST HIT = Recipient's HIT, or zero if unknown 3333 IP ( HIP (i, [HOST_ID, ] HIP_SIGNATURE) ) 3335 Valid control bits: None 3336 The NOTIFY packet is used to carry one or more NOTIFICATION 3337 parameters. 3339 5.3.7. CLOSE - the HIP Association Closing Packet 3341 The HIP header values for the CLOSE packet: 3343 Header: 3344 Packet Type = 18 3345 SRC HIT = Sender's HIT 3346 DST HIT = Recipient's HIT 3348 IP ( HIP ( ECHO_REQUEST_SIGNED, HIP_MAC, HIP_SIGNATURE ) ) 3350 Valid control bits: none 3352 The sender MUST include an ECHO_REQUEST_SIGNED used to validate 3353 CLOSE_ACK received in response, and both a HIP_MAC and a signature 3354 (calculated over the whole HIP packet). 3356 The receiver peer MUST reply with a CLOSE_ACK containing an 3357 ECHO_RESPONSE_SIGNED corresponding to the received 3358 ECHO_REQUEST_SIGNED. 3360 5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet 3362 The HIP header values for the CLOSE_ACK packet: 3364 Header: 3365 Packet Type = 19 3366 SRC HIT = Sender's HIT 3367 DST HIT = Recipient's HIT 3369 IP ( HIP ( ECHO_RESPONSE_SIGNED, HIP_MAC, HIP_SIGNATURE ) ) 3371 Valid control bits: none 3373 The sender MUST include both an HMAC and signature (calculated over 3374 the whole HIP packet). 3376 The receiver peer MUST validate the ECHO_RESPONSE_SIGNED and validate 3377 both the HIP_MAC and the signature if the receiver has state for a 3378 HIP association. 3380 5.4. ICMP Messages 3382 When a HIP implementation detects a problem with an incoming packet, 3383 and it either cannot determine the identity of the sender of the 3384 packet or does not have any existing HIP association with the sender 3385 of the packet, it MAY respond with an ICMP packet. Any such replies 3386 MUST be rate-limited as described in [RFC4443]. In most cases, the 3387 ICMP packet has the Parameter Problem type (12 for ICMPv4, 4 for 3388 ICMPv6), with the Pointer field pointing to the field that caused the 3389 ICMP message to be generated. 3391 5.4.1. Invalid Version 3393 If a HIP implementation receives a HIP packet that has an 3394 unrecognized HIP version number, it SHOULD respond, rate-limited, 3395 with an ICMP packet with type Parameter Problem, with the Pointer 3396 pointing to the Version/RES. byte in the HIP header. 3398 5.4.2. Other Problems with the HIP Header and Packet Structure 3400 If a HIP implementation receives a HIP packet that has other 3401 unrecoverable problems in the header or packet format, it MAY 3402 respond, rate-limited, with an ICMP packet with type Parameter 3403 Problem, the Pointer pointing to the field that failed to pass the 3404 format checks. However, an implementation MUST NOT send an ICMP 3405 message if the checksum fails; instead, it MUST silently drop the 3406 packet. 3408 5.4.3. Invalid Puzzle Solution 3410 If a HIP implementation receives an I2 packet that has an invalid 3411 puzzle solution, the behavior depends on the underlying version of 3412 IP. If IPv6 is used, the implementation SHOULD respond with an ICMP 3413 packet with type Parameter Problem, the Pointer pointing to the 3414 beginning of the Puzzle solution #J field in the SOLUTION payload in 3415 the HIP message. 3417 If IPv4 is used, the implementation MAY respond with an ICMP packet 3418 with the type Parameter Problem, copying enough of bytes from the I2 3419 message so that the SOLUTION parameter fits into the ICMP message, 3420 the Pointer pointing to the beginning of the Puzzle solution #J 3421 field, as in the IPv6 case. Note, however, that the resulting ICMPv4 3422 message exceeds the typical ICMPv4 message size as defined in 3423 [RFC0792]. 3425 5.4.4. Non-Existing HIP Association 3427 If a HIP implementation receives a CLOSE or UPDATE packet, or any 3428 other packet whose handling requires an existing association, that 3429 has either a Receiver or Sender HIT that does not match with any 3430 existing HIP association, the implementation MAY respond, rate- 3431 limited, with an ICMP packet with the type Parameter Problem. The 3432 Pointer of the ICMP Parameter Problem packet is set pointing to the 3433 beginning of the first HIT that does not match. 3435 A host MUST NOT reply with such an ICMP if it receives any of the 3436 following messages: I1, R2, I2, R2, and NOTIFY packet. When 3437 introducing new packet types, a specification SHOULD define the 3438 appropriate rules for sending or not sending this kind of ICMP reply. 3440 6. Packet Processing 3442 Each host is assumed to have a single HIP protocol implementation 3443 that manages the host's HIP associations and handles requests for new 3444 ones. Each HIP association is governed by a conceptual state 3445 machine, with states defined above in Section 4.4. The HIP 3446 implementation can simultaneously maintain HIP associations with more 3447 than one host. Furthermore, the HIP implementation may have more 3448 than one active HIP association with another host; in this case, HIP 3449 associations are distinguished by their respective HITs. It is not 3450 possible to have more than one HIP association between any given pair 3451 of HITs. Consequently, the only way for two hosts to have more than 3452 one parallel association is to use different HITs, at least at one 3453 end. 3455 The processing of packets depends on the state of the HIP 3456 association(s) with respect to the authenticated or apparent 3457 originator of the packet. A HIP implementation determines whether it 3458 has an active association with the originator of the packet based on 3459 the HITs. In the case of user data carried in a specific transport 3460 format, the transport format document specifies how the incoming 3461 packets are matched with the active associations. 3463 6.1. Processing Outgoing Application Data 3465 In a HIP host, an application can send application-level data using 3466 an identifier specified via the underlying API. The API can be a 3467 backwards-compatible API (see [RFC5338]), using identifiers that look 3468 similar to IP addresses, or a completely new API, providing enhanced 3469 services related to Host Identities. Depending on the HIP 3470 implementation, the identifier provided to the application may be 3471 different; for example, it can be a HIT or an IP address. 3473 The exact format and method for transferring the user data from the 3474 source HIP host to the destination HIP host is defined in the 3475 corresponding transport format document. The actual data is 3476 transferred in the network using the appropriate source and 3477 destination IP addresses. 3479 In this document, conceptual processing rules are defined only for 3480 the base case where both hosts have only single usable IP addresses; 3481 the multi-address multi-homing case is specified separately. 3483 The following conceptual algorithm describes the steps that are 3484 required for handling outgoing datagrams destined to a HIT. 3486 1. If the datagram has a specified source address, it MUST be a HIT. 3487 If it is not, the implementation MAY replace the source address 3488 with a HIT. Otherwise, it MUST drop the packet. 3490 2. If the datagram has an unspecified source address, the 3491 implementation MUST choose a suitable source HIT for the 3492 datagram. Selecting the source HIT is subject to local policy. 3494 3. If there is no active HIP association with the given HIT pair, one MUST be created by running the base 3496 exchange. While waiting for the base exchange to complete, the 3497 implementation SHOULD queue at least one user data packet per HIP 3498 association to be formed, and it MAY queue more than one. 3500 4. Once there is an active HIP association for the given HIT pair, the outgoing datagram is passed to 3502 transport handling. The possible transport formats are defined 3503 in separate documents, of which the ESP transport format for HIP 3504 is mandatory for all HIP implementations. 3506 5. Before sending the packet, the HITs in the datagram are replaced 3507 with suitable IP addresses. For IPv6, the rules defined in 3508 [RFC6724] SHOULD be followed. Note that this HIT-to-IP-address 3509 conversion step MAY also be performed at some other point in the 3510 stack, e.g., before wrapping the packet into the output format. 3512 6.2. Processing Incoming Application Data 3514 The following conceptual algorithm describes the incoming datagram 3515 handling when HITs are used at the receiving host as application- 3516 level identifiers. More detailed steps for processing packets are 3517 defined in corresponding transport format documents. 3519 1. The incoming datagram is mapped to an existing HIP association, 3520 typically using some information from the packet. For example, 3521 such mapping may be based on the ESP Security Parameter Index 3522 (SPI). 3524 2. The specific transport format is unwrapped, in a way depending on 3525 the transport format, yielding a packet that looks like a 3526 standard (unencrypted) IP packet. If possible, this step SHOULD 3527 also verify that the packet was indeed (once) sent by the remote 3528 HIP host, as identified by the HIP association. 3530 Depending on the used transport mode, the verification method can 3531 vary. While the HI (as well as HIT) is used as the higher-layer 3532 identifier, the verification method has to verify that the data 3533 packet was sent by the correct node identity and that the actual 3534 identity maps to this particular HIT. When using ESP transport 3535 format [I-D.ietf-hip-rfc5202-bis], the verification is done using 3536 the SPI value in the data packet to find the corresponding SA 3537 with associated HIT and key, and decrypting the packet with that 3538 associated key. 3540 3. The IP addresses in the datagram are replaced with the HITs 3541 associated with the HIP association. Note that this IP-address- 3542 to-HIT conversion step MAY also be performed at some other point 3543 in the stack. 3545 4. The datagram is delivered to the upper layer (e.g., UDP or TCP). 3546 When demultiplexing the datagram, the right upper-layer socket is 3547 selected based on the HITs. 3549 6.3. Solving the Puzzle 3551 This subsection describes the details for solving the puzzle. 3553 In the R1 packet, the values #I and #K are sent in network byte 3554 order. Similarly, in the I2 packet, the values #I and #J are sent in 3555 network byte order. The hash is created by concatenating, in network 3556 byte order, the following data, in the following order and using the 3557 RHASH algorithm: 3559 n-bit random value #I (where n is RHASH_len), in network byte 3560 order, as appearing in the R1 and I2 packets. 3562 128-bit Initiator's HIT, in network byte order, as appearing in 3563 the HIP Payload in the R1 and I2 packets. 3565 128-bit Responder's HIT, in network byte order, as appearing in 3566 the HIP Payload in the R1 and I2 packets. 3568 n-bit random value #J (where n is RHASH_len), in network byte 3569 order, as appearing in the I2 packet. 3571 In a valid response puzzle, the #K low-order bits of the resulting 3572 RHASH digest MUST be zero. 3574 Notes: 3576 i) The length of the data to be hashed is variable depending on 3577 the output length of the Responder's hash function RHASH. 3579 ii) All the data in the hash input MUST be in network byte order. 3581 iii) The order of the Initiator's and Responder's HITs are 3582 different in the R1 and I2 packets; see Section 5.1. Care must be 3583 taken to copy the values in the right order to the hash input. 3585 iv) For a puzzle #I, there may exist multiple valid puzzle 3586 solutions #J. 3588 The following procedure describes the processing steps involved, 3589 assuming that the Responder chooses to precompute the R1 packets: 3591 Precomputation by the Responder: 3592 Sets up the puzzle difficulty #K. 3593 Creates a signed R1 and caches it. 3595 Responder: 3596 Selects a suitable cached R1. 3597 Generates a random number #I. 3598 Sends #I and #K in an R1. 3599 Saves #I and #K for a Delta time. 3601 Initiator: 3602 Generates repeated attempts to solve the puzzle until a matching 3603 #J is found: 3604 Ltrunc( RHASH( #I | HIT-I | HIT-R | #J ), #K ) == 0 3605 Sends #I and #J in an I2. 3607 Responder: 3608 Verifies that the received #I is a saved one. 3609 Finds the right #K based on #I. 3610 Computes V := Ltrunc( RHASH( #I | HIT-I | HIT-R | #J ), #K ) 3611 Rejects if V != 0 3612 Accept if V == 0 3614 6.4. HIP_MAC and SIGNATURE Calculation and Verification 3616 The following subsections define the actions for processing HIP_MAC, 3617 HIP_MAC_2, HIP_SIGNATURE and HIP_SIGNATURE_2 parameters. The 3618 HIP_MAC_2 parameter is contained in the R2 packet. The 3619 HIP_SIGNATURE_2 parameter is contained in the R1 packet. The 3620 HIP_SIGNATURE and HIP_MAC parameter are contained in other HIP 3621 packets. 3623 6.4.1. HMAC Calculation 3625 The HMAC uses RHASH as underlying hash function. The type of RHASH 3626 depends on the HIT Suite of the Responder. Hence, HMAC-SHA-256 3627 [RFC4868] is used for HIT Suite RSA/DSA/SHA-256, HMAC-SHA-1 [RFC2404] 3628 is used for HIT Suite ECDSA_LOW/SHA-1, and HMAC-SHA-384 [RFC4868] for 3629 HIT Suite ECDSA/SHA-384. 3631 The following process applies both to the HIP_MAC and HIP_MAC_2 3632 parameters. When processing HIP_MAC_2, the difference is that the 3633 HIP_MAC calculation includes a pseudo HOST_ID field containing the 3634 Responder's information as sent in the R1 packet earlier. 3636 Both the Initiator and the Responder should take some care when 3637 verifying or calculating the HIP_MAC_2. Specifically, the Initiator 3638 has to preserve the HOST_ID exactly as it was received in the R1 3639 packet until it receives the HIP_MAC_2 in the R2 packet. 3641 The scope of the calculation for HIP_MAC is: 3643 HMAC: { HIP header | [ Parameters ] } 3645 where Parameters include all HIP parameters of the packet that is 3646 being calculated with Type values ranging from 1 to (HIP_MAC's Type 3647 value - 1) and exclude parameters with Type values greater or equal 3648 to HIP_MAC's Type value. 3650 During HIP_MAC calculation, the following applies: 3652 o In the HIP header, the Checksum field is set to zero. 3654 o In the HIP header, the Header Length field value is calculated to 3655 the beginning of the HIP_MAC parameter. 3657 Parameter order is described in Section 5.2.1. 3659 The scope of the calculation for HIP_MAC_2 is: 3661 HIP_MAC_2: { HIP header | [ Parameters ] | HOST_ID } 3663 where Parameters include all HIP parameters for the packet that is 3664 being calculated with Type values from 1 to (HIP_MAC_2's Type value - 3665 1) and exclude parameters with Type values greater or equal to 3666 HIP_MAC_2's Type value. 3668 During HIP_MAC_2 calculation, the following applies: 3670 o In the HIP header, the Checksum field is set to zero. 3672 o In the HIP header, the Header Length field value is calculated to 3673 the beginning of the HIP_MAC_2 parameter and increased by the 3674 length of the concatenated HOST_ID parameter length (including 3675 type and length fields). 3677 o HOST_ID parameter is exactly in the form it was received in the R1 3678 packet from the Responder. 3680 Parameter order is described in Section 5.2.1, except that the 3681 HOST_ID parameter in this calculation is added to the end. 3683 The HIP_MAC parameter is defined in Section 5.2.12 and the HIP_MAC_2 3684 parameter in Section 5.2.13. The HMAC calculation and verification 3685 process (the process applies both to HIP_MAC and HIP_MAC_2 except 3686 where HIP_MAC_2 is mentioned separately) is as follows: 3688 Packet sender: 3690 1. Create the HIP packet, without the HIP_MAC, HIP_SIGNATURE, 3691 HIP_SIGNATURE_2, or any other parameter with greater Type value 3692 than the HIP_MAC parameter has. 3694 2. In case of HIP_MAC_2 calculation, add a HOST_ID (Responder) 3695 parameter to the end of the packet. 3697 3. Calculate the Header Length field in the HIP header including the 3698 added HOST_ID parameter in case of HIP_MAC_2. 3700 4. Compute the HMAC using either HIP-gl or HIP-lg integrity key 3701 retrieved from KEYMAT as defined in Section 6.5. 3703 5. In case of HIP_MAC_2, remove the HOST_ID parameter from the 3704 packet. 3706 6. Add the HIP_MAC parameter to the packet and any parameter with 3707 greater Type value than the HIP_MAC's (HIP_MAC_2's) that may 3708 follow, including possible HIP_SIGNATURE or HIP_SIGNATURE_2 3709 parameters 3711 7. Recalculate the Length field in the HIP header. 3713 Packet receiver: 3715 1. Verify the HIP header Length field. 3717 2. Remove the HIP_MAC or HIP_MAC_2 parameter, as well as all other 3718 parameters that follow it with greater Type value including 3719 possible HIP_SIGNATURE or HIP_SIGNATURE_2 fields, saving the 3720 contents if they are needed later. 3722 3. In case of HIP_MAC_2, build and add a HOST_ID parameter (with 3723 Responder information) to the packet. The HOST_ID parameter 3724 should be identical to the one previously received from the 3725 Responder. 3727 4. Recalculate the HIP packet length in the HIP header and clear the 3728 Checksum field (set it to all zeros). In case of HIP_MAC_2, the 3729 length is calculated with the added HOST_ID parameter. 3731 5. Compute the HMAC using either HIP-gl or HIP-lg integrity key as 3732 defined in Section 6.5 and verify it against the received HMAC. 3734 6. Set Checksum and Header Length field in the HIP header to 3735 original values. Note that the checksum and length fields 3736 contain incorrect values after this step. 3738 7. In case of HIP_MAC_2, remove the HOST_ID parameter from the 3739 packet before further processing. 3741 6.4.2. Signature Calculation 3743 The following process applies both to the HIP_SIGNATURE and 3744 HIP_SIGNATURE_2 parameters. When processing the HIP_SIGNATURE_2, the 3745 only difference is that instead of the HIP_SIGNATURE parameter, the 3746 HIP_SIGNATURE_2 parameter is used, and the Initiator's HIT and PUZZLE 3747 Opaque and Random #I fields are cleared (set to all zeros) before 3748 computing the signature. The HIP_SIGNATURE parameter is defined in 3749 Section 5.2.14 and the HIP_SIGNATURE_2 parameter in Section 5.2.15. 3751 The scope of the calculation for HIP_SIGNATURE and HIP_SIGNATURE_2 3752 is: 3754 HIP_SIGNATURE: { HIP header | [ Parameters ] } 3756 where Parameters include all HIP parameters for the packet that is 3757 being calculated with Type values from 1 to (HIP_SIGNATURE's Type 3758 value - 1). 3760 During signature calculation, the following applies: 3762 o In the HIP header, the Checksum field is set to zero. 3764 o In the HIP header, the Header Length field value is calculated to 3765 the beginning of the HIP_SIGNATURE parameter. 3767 The parameter order is described in Section 5.2.1. 3769 HIP_SIGNATURE_2: { HIP header | [ Parameters ] } 3771 where Parameters include all HIP parameters for the packet that is 3772 being calculated with Type values ranging from 1 to 3773 (HIP_SIGNATURE_2's Type value - 1). 3775 During signature calculation, the following apply: 3777 o In the HIP header, the Initiator's HIT field and Checksum fields 3778 are set to zero. 3780 o In the HIP header, the Header Length field value is calculated to 3781 the beginning of the HIP_SIGNATURE_2 parameter. 3783 o PUZZLE parameter's Opaque and Random #I fields are set to zero. 3785 Parameter order is described in Section 5.2.1. 3787 The signature calculation and verification process (the process 3788 applies both to HIP_SIGNATURE and HIP_SIGNATURE_2 except in the case 3789 where HIP_SIGNATURE_2 is separately mentioned) is as follows: 3791 Packet sender: 3793 1. Create the HIP packet without the HIP_SIGNATURE parameter or any 3794 other parameters that follow the HIP_SIGNATURE parameter. 3796 2. Calculate the Length field and zero the Checksum field in the HIP 3797 header. In case of HIP_SIGNATURE_2, set Initiator's HIT field in 3798 the HIP header as well as PUZZLE parameter's Opaque and Random #I 3799 fields to zero. 3801 3. Compute the signature using the private key corresponding to the 3802 Host Identifier (public key). 3804 4. Add the HIP_SIGNATURE parameter to the packet. 3806 5. Add any parameters that follow the HIP_SIGNATURE parameter. 3808 6. Recalculate the Length field in the HIP header, and calculate the 3809 Checksum field. 3811 Packet receiver: 3813 1. Verify the HIP header Length field and checksum. 3815 2. Save the contents of the HIP_SIGNATURE parameter and any other 3816 parameters following the HIP_SIGNATURE parameter and remove them 3817 from the packet. 3819 3. Recalculate the HIP packet Length in the HIP header and clear the 3820 Checksum field (set it to all zeros). In case of 3821 HIP_SIGNATURE_2, set Initiator's HIT field in the HIP header as 3822 well as PUZZLE parameter's Opaque and Random #I fields to zero. 3824 4. Compute the signature and verify it against the received 3825 signature using the packet sender's Host Identity (public key). 3827 5. Restore the original packet by adding removed parameters (in step 3828 2) and resetting the values that were set to zero (in step 3). 3830 The verification can use either the HI received from a HIP packet, 3831 the HI from a DNS query, if the FQDN has been received in the HOST_ID 3832 packet or one received by some other means. 3834 6.5. HIP KEYMAT Generation 3836 HIP keying material is derived from the Diffie-Hellman session key, 3837 Kij, produced during the HIP base exchange (see Section 4.1.3). The 3838 Initiator has Kij during the creation of the I2 packet, and the 3839 Responder has Kij once it receives the I2 packet. This is why I2 can 3840 already contain encrypted information. 3842 The KEYMAT is derived by feeding Kij into the key derivation function 3843 defined by the DH Group ID. Currently the only key derivation 3844 function defined in this document is the Hash-based Key Derivation 3845 Function (HKDF) [RFC5869] using the RHASH hash function. Other 3846 documents may define new DH Group IDs and corresponding key 3847 distribution functions. 3849 In the following we provide the details for deriving the keying 3850 material using HKDF. 3852 where 3854 info = sort(HIT-I | HIT-R) 3855 salt = #I | #J 3857 Sort(HIT-I | HIT-R) is defined as the network byte order 3858 concatenation of the two HITs, with the smaller HIT preceding the 3859 larger HIT, resulting from the numeric comparison of the two HITs 3860 interpreted as positive (unsigned) 128-bit integers in network byte 3861 order. The #I and #J values are from the puzzle and its solution 3862 that were exchanged in R1 and I2 messages when this HIP association 3863 was set up. Both hosts have to store #I and #J values for the HIP 3864 association for future use. 3866 The initial keys are drawn sequentially in the order that is 3867 determined by the numeric comparison of the two HITs, with comparison 3868 method described in the previous paragraph. HOST_g denotes the host 3869 with the greater HIT value, and HOST_l the host with the lower HIT 3870 value. 3872 The drawing order for the four initial keys is as follows: 3874 HIP-gl encryption key for HOST_g's ENCRYPTED parameter 3876 HIP-gl integrity (HMAC) key for HOST_g's outgoing HIP packets 3878 HIP-lg encryption key for HOST_l's ENCRYPTED parameter 3880 HIP-lg integrity (HMAC) key for HOST_l's outgoing HIP packets 3882 The number of bits drawn for a given algorithm is the "natural" size 3883 of the keys. For the mandatory algorithms, the following sizes 3884 apply: 3886 AES 128 or 256 bits 3888 SHA-1 160 bits 3890 SHA-256 256 bits 3892 SHA-384 384 bits 3894 NULL 0 bits 3895 If other key sizes are used, they MUST be treated as different 3896 encryption algorithms and defined separately. 3898 6.6. Initiation of a HIP Base Exchange 3900 An implementation may originate a HIP base exchange to another host 3901 based on a local policy decision, usually triggered by an application 3902 datagram, in much the same way that an IPsec IKE key exchange can 3903 dynamically create a Security Association. Alternatively, a system 3904 may initiate a HIP exchange if it has rebooted or timed out, or 3905 otherwise lost its HIP state, as described in Section 4.5.4. 3907 The implementation prepares an I1 packet and sends it to the IP 3908 address that corresponds to the peer host. The IP address of the 3909 peer host may be obtained via conventional mechanisms, such as DNS 3910 lookup. The I1 packet contents are specified in Section 5.3.1. The 3911 selection of which source or destination Host Identity to use, if a 3912 Initiator or Responder has more than one to choose from, is typically 3913 a policy decision. 3915 The following steps define the conceptual processing rules for 3916 initiating a HIP base exchange: 3918 1. The Initiator receives one or more of the Responder's HITs and 3919 one or more addresses either from a DNS lookup of the Responder's 3920 FQDN, from some other repository, or from a local database. If 3921 the Initiator does not know the Responder's HIT, it may attempt 3922 opportunistic mode by using NULL (all zeros) as the Responder's 3923 HIT (see also "HIP Opportunistic Mode" (Section 4.1.8)). If the 3924 Initiator can choose from multiple Responder HITs, it selects a 3925 HIT for which the Initiator supports the HIT Suite. 3927 2. The Initiator sends an I1 packet to one of the Responder's 3928 addresses. The selection of which address to use is a local 3929 policy decision. 3931 3. The Initiator includes the DH_GROUP_LIST in the I1 packet. The 3932 selection and order of DH Group IDs in the DH_GROUP_LIST MUST be 3933 stored by the Initiator because this list is needed for later R1 3934 processing. In most cases, the preferences regarding the DH 3935 Groups will be static, so no per-association storage is 3936 necessary. 3938 4. Upon sending an I1 packet, the sender transitions to state 3939 I1-SENT, starts a timer for which the timeout value SHOULD be 3940 larger than the worst-case anticipated RTT. The sender SHOULD 3941 also increment the trial counter associated with the I1. 3943 5. Upon timeout, the sender SHOULD retransmit the I1 packet and 3944 restart the timer, up to a maximum of I1_RETRIES_MAX tries. 3946 6.6.1. Sending Multiple I1 Packets in Parallel 3948 For the sake of minimizing the association establishment latency, an 3949 implementation MAY send the same I1 packet to more than one of the 3950 Responder's addresses. However, it MUST NOT send to more than three 3951 (3) Responder addresses in parallel. Furthermore, upon timeout, the 3952 implementation MUST refrain from sending the same I1 packet to 3953 multiple addresses. That is, if it retries to initialize the 3954 connection after a timeout, it MUST NOT send the I1 packet to more 3955 than one destination address. These limitations are placed in order 3956 to avoid congestion of the network, and potential DoS attacks that 3957 might occur, e.g., because someone's claim to have hundreds or 3958 thousands of addresses could generate a huge number of I1 packets 3959 from the Initiator. 3961 As the Responder is not guaranteed to distinguish the duplicate I1 3962 packets it receives at several of its addresses (because it avoids 3963 storing states when it answers back an R1 packet), the Initiator may 3964 receive several duplicate R1 packets. 3966 The Initiator SHOULD then select the initial preferred destination 3967 address using the source address of the selected received R1, and use 3968 the preferred address as a source address for the I2 packet. 3969 Processing rules for received R1s are discussed in Section 6.8. 3971 6.6.2. Processing Incoming ICMP Protocol Unreachable Messages 3973 A host may receive an ICMP 'Destination Protocol Unreachable' message 3974 as a response to sending a HIP I1 packet. Such a packet may be an 3975 indication that the peer does not support HIP, or it may be an 3976 attempt to launch an attack by making the Initiator believe that the 3977 Responder does not support HIP. 3979 When a system receives an ICMP 'Destination Protocol Unreachable' 3980 message while it is waiting for an R1 packet, it MUST NOT terminate 3981 waiting. It MAY continue as if it had not received the ICMP message, 3982 and send a few more I1 packets. Alternatively, it MAY take the ICMP 3983 message as a hint that the peer most probably does not support HIP, 3984 and return to state UNASSOCIATED earlier than otherwise. However, at 3985 minimum, it MUST continue waiting for an R1 packet for a reasonable 3986 time before returning to UNASSOCIATED. 3988 6.7. Processing Incoming I1 Packets 3990 An implementation SHOULD reply to an I1 with an R1 packet, unless the 3991 implementation is unable or unwilling to set up a HIP association. 3992 If the implementation is unable to set up a HIP association, the host 3993 SHOULD send an ICMP Destination Protocol Unreachable, 3994 Administratively Prohibited, message to the I1 packet source IP 3995 address. If the implementation is unwilling to set up a HIP 3996 association, the host MAY ignore the I1 packet. This latter case may 3997 occur during a DoS attack such as an I1 packet flood. 3999 The implementation SHOULD be able to handle a storm of received I1 4000 packets, discarding those with common content that arrive within a 4001 small time delta. 4003 A spoofed I1 packet can result in an R1 attack on a system. An R1 4004 packet sender MUST have a mechanism to rate-limit R1 packets sent to 4005 an address. 4007 It is RECOMMENDED that the HIP state machine does not transition upon 4008 sending an R1 packet. 4010 The following steps define the conceptual processing rules for 4011 responding to an I1 packet: 4013 1. The Responder MUST check that the Responder's HIT in the received 4014 I1 packet is either one of its own HITs or NULL. Otherwise it 4015 must drop the packet. 4017 2. If the Responder is in ESTABLISHED state, the Responder MAY 4018 respond to this with an R1 packet, prepare to drop an existing 4019 HIP security association with the peer, and stay at ESTABLISHED 4020 state. 4022 3. If the Responder is in I1-SENT state, it MUST make a comparison 4023 between the sender's HIT and its own (i.e., the receiver's) HIT. 4024 If the sender's HIT is greater than its own HIT, it should drop 4025 the I1 packet and stay at I1-SENT. If the sender's HIT is 4026 smaller than its own HIT, it SHOULD send the R1 packet and stay 4027 at I1-SENT. The HIT comparison is performed as defined in 4028 Section 6.5. 4030 4. If the implementation chooses to respond to the I1 packet with an 4031 R1 packet, it creates a new R1 or selects a precomputed R1 4032 according to the format described in Section 5.3.2. It creates 4033 or chooses an R1 that contains its most preferred DH public value 4034 that is also contained in the DH_GROUP_LIST in the I1 packet. If 4035 no suitable DH Group ID was contained in the DH_GROUP_LIST in the 4036 I1 packet, it sends an R1 with any suitable DH public key. 4038 5. If the received Responder's HIT in the I1 is NULL, the Responder 4039 selects a HIT with a the same HIT Suite as the Initiator's HIT. 4040 If this HIT Suite is not supported by the Responder, it SHOULD 4041 select a REQUIRED HIT Suite from Section 5.2.10, which is 4042 currently RSA/DSA/SHA-256. Other than that, selecting the HIT is 4043 a local policy matter. 4045 6. The responder expresses its supported HIP transport formats in 4046 the TRANSPORT_FORMAT_LIST as described in Section 5.2.11. The 4047 Responder MUST at least provide one payload transport format 4048 type. 4050 7. The Responder sends the R1 packet to the source IP address of the 4051 I1 packet. 4053 6.7.1. R1 Management 4055 All compliant implementations MUST be able to produce R1 packets; 4056 even if a device is configured by policy to only initiate 4057 associations, it must be able to process I1s in case of recovery from 4058 loss of state or key exhaustion. An R1 packet MAY be precomputed. 4059 An R1 packet MAY be reused for time Delta T, which is implementation 4060 dependent, and SHOULD be deprecated and not used once a valid 4061 response I2 packet has been received from an Initiator. During an I1 4062 message storm, an R1 packet MAY be re-used beyond this limit. R1 4063 information MUST NOT be discarded until Delta S after T. Time S is 4064 the delay needed for the last I2 packet to arrive back to the 4065 Responder. 4067 Implementations that support multiple DH groups MAY pre-compute R1 4068 packets for each supported group so that incoming I1 packets with 4069 different DH Group IDs in the DH_GROUP_LIST can be served quickly. 4071 An implementation MAY keep state about received I1 packets and match 4072 the received I2 packets against the state, as discussed in 4073 Section 4.1.1. 4075 6.7.2. Handling Malformed Messages 4077 If an implementation receives a malformed I1 packet, it SHOULD NOT 4078 respond with a NOTIFY message, as such practice could open up a 4079 potential denial-of-service threat. Instead, it MAY respond with an 4080 ICMP packet, as defined in Section 5.4. 4082 6.8. Processing Incoming R1 Packets 4084 A system receiving an R1 packet MUST first check to see if it has 4085 sent an I1 packet to the originator of the R1 packet (i.e., it is in 4086 state I1-SENT). If so, it SHOULD process the R1 as described below, 4087 send an I2 packet, and transition to state I2-SENT, setting a timer 4088 to protect the I2 packet. If the system is in state I2-SENT, it MAY 4089 respond to the R1 packet if the R1 packet has a larger R1 generation 4090 counter; if so, it should drop its state due to processing the 4091 previous R1 packet and start over from state I1-SENT. If the system 4092 is in any other state with respect to that host, the system SHOULD 4093 silently drop the R1 packet. 4095 When sending multiple I1 packets, an Initiator SHOULD wait for a 4096 small amount of time after the first R1 reception to allow possibly 4097 multiple R1 packets to arrive, and it SHOULD respond to an R1 packet 4098 among the set with the largest R1 generation counter. 4100 The following steps define the conceptual processing rules for 4101 responding to an R1 packet: 4103 1. A system receiving an R1 MUST first check to see if it has sent 4104 an I1 packet to the originator of the R1 packet (i.e., it has a 4105 HIP association that is in state I1-SENT and that is associated 4106 with the HITs in the R1). Unless the I1 packet was sent in 4107 opportunistic mode (see Section 4.1.8), the IP addresses in the 4108 received R1 packet SHOULD be ignored by the R1 processing and, 4109 when looking up the right HIP association, the received R1 4110 packet SHOULD be matched against the associations using only the 4111 HITs. If a match exists, the system should process the R1 4112 packet as described below. 4114 2. Otherwise, if the system is in any other state than I1-SENT or 4115 I2-SENT with respect to the HITs included in the R1 packet, it 4116 SHOULD silently drop the R1 packet and remain in the current 4117 state. 4119 3. If the HIP association state is I1-SENT or I2-SENT, the received 4120 Initiator's HIT MUST correspond to the HIT used in the original 4121 I1. Also, the Responder's HIT MUST correspond to the one used 4122 in the I1, unless the I1 packet contained a NULL HIT. 4124 4. The system SHOULD validate the R1 signature before applying 4125 further packet processing, according to Section 5.2.15. 4127 5. If the HIP association state is I1-SENT, and multiple valid R1 4128 packets are present, the system MUST select from among the R1 4129 packets with the largest R1 generation counter. 4131 6. The system MUST check that the Initiator HIT Suite is contained 4132 in the HIT_SUITE_LIST parameter in the R1 packet (i.e., the 4133 Initiator's HIT Suite is supported by the Responder). If the 4134 HIT Suite is supported by the Responder, the system proceeds 4135 normally. Otherwise, the system MAY stay in state I1-sent and 4136 restart the BEX by sending a new I1 packet with an Initiator HIT 4137 that is supported by the Responder and hence is contained in the 4138 HIT_SUITE_LIST in the R1 packet. The system MAY abort the BEX 4139 if no suitable source HIT is available. The system SHOULD wait 4140 for an acceptable time span to allow further R1 packets with 4141 higher R1 generation counters or different HIT and HIT Suites to 4142 arrive before restarting or aborting the BEX. 4144 7. The system MUST check that the DH Group ID in the DIFFIE_HELLMAN 4145 parameter in the R1 matches the first DH Suite ID in the 4146 Responder's DH_GROUP_LIST in the R1 packet that was also 4147 contained in the Initiator's DH_GROUP_LIST in the I1 packet. If 4148 the DH Group ID of the DIFFIE_HELLMAN parameter does not express 4149 the Responder's best choice, the Initiator can conclude that the 4150 DH_GROUP_LIST in the I1 packet was adversely modified. In such 4151 case, the Initiator MAY send a new I1 packet, however, it SHOULD 4152 NOT change its preference in the DH_GROUP_LIST in the new I1 4153 packet. Alternatively, the Initiator MAY abort the HIP base 4154 exchange. 4156 8. If the HIP association state is I2-SENT, the system MAY re-enter 4157 state I1-SENT and process the received R1 packet if it has a 4158 larger R1 generation counter than the R1 packet responded to 4159 previously. 4161 9. The R1 packet may have the A bit set -- in this case, the system 4162 MAY choose to refuse it by dropping the R1 packet and returning 4163 to state UNASSOCIATED. The system SHOULD consider dropping the 4164 R1 packet only if it used a NULL HIT in I1 packet. If the A bit 4165 is set, the Responder's HIT is anonymous and SHOULD NOT be 4166 stored permanently. 4168 10. The system SHOULD attempt to validate the HIT against the 4169 received Host Identity by using the received Host Identity to 4170 construct a HIT and verify that it matches the Sender's HIT. 4172 11. The system MUST store the received R1 generation counter for 4173 future reference. 4175 12. The system attempts to solve the puzzle in the R1 packet. The 4176 system MUST terminate the search after exceeding the remaining 4177 lifetime of the puzzle. If the puzzle is not successfully 4178 solved, the implementation MAY either resend the I1 packet 4179 within the retry bounds or abandon the HIP base exchange. 4181 13. The system computes standard Diffie-Hellman keying material 4182 according to the public value and Group ID provided in the 4183 DIFFIE_HELLMAN parameter. The Diffie-Hellman keying material 4184 Kij is used for key extraction as specified in Section 6.5. 4186 14. The system selects the HIP_CIPHER ID from the choices presented 4187 in the R1 packet and uses the selected values subsequently when 4188 generating and using encryption keys, and when sending the I2 4189 packet. If the proposed alternatives are not acceptable to the 4190 system, it may either resend an I1 within the retry bounds or 4191 abandon the HIP base exchange. 4193 15. The system chooses one suitable transport format from the 4194 TRANSPORT_FORMAT_LIST and includes the respective transport 4195 format parameter in the subsequent I2 packet. 4197 16. The system initializes the remaining variables in the associated 4198 state, including Update ID counters. 4200 17. The system prepares and sends an I2 packet, as described in 4201 Section 5.3.3. 4203 18. The system SHOULD start a timer whose timeout value SHOULD be 4204 larger than the worst-case anticipated RTT, and MUST increment a 4205 trial counter associated with the I2 packet. The sender SHOULD 4206 retransmit the I2 packet upon a timeout and restart the timer, 4207 up to a maximum of I2_RETRIES_MAX tries. 4209 19. If the system is in state I1-SENT, it SHALL transition to state 4210 I2-SENT. If the system is in any other state, it remains in the 4211 current state. 4213 6.8.1. Handling of Malformed Messages 4215 If an implementation receives a malformed R1 message, it MUST 4216 silently drop the packet. Sending a NOTIFY or ICMP would not help, 4217 as the sender of the R1 packet typically doesn't have any state. An 4218 implementation SHOULD wait for some more time for a possibly well- 4219 formed R1, after which it MAY try again by sending a new I1 packet. 4221 6.9. Processing Incoming I2 Packets 4223 Upon receipt of an I2 packet, the system MAY perform initial checks 4224 to determine whether the I2 packet corresponds to a recent R1 packet 4225 that has been sent out, if the Responder keeps such state. For 4226 example, the sender could check whether the I2 packet is from an 4227 address or HIT for which the Responder has recently received an I1. 4228 The R1 packet may have had Opaque data included that was echoed back 4229 in the I2 packet. If the I2 packet is considered to be suspect, it 4230 MAY be silently discarded by the system. 4232 Otherwise, the HIP implementation SHOULD process the I2 packet. This 4233 includes validation of the puzzle solution, generating the Diffie- 4234 Hellman key, possibly decrypting the Initiator's Host Identity, 4235 verifying the signature, creating state, and finally sending an R2 4236 packet. 4238 The following steps define the conceptual processing rules for 4239 responding to an I2 packet: 4241 1. The system MAY perform checks to verify that the I2 packet 4242 corresponds to a recently sent R1 packet. Such checks are 4243 implementation dependent. See Appendix A for a description of 4244 an example implementation. 4246 2. The system MUST check that the Responder's HIT corresponds to 4247 one of its own HITs and MUST drop the packet otherwise. 4249 3. The system MUST further check that the Initiator's HIT Suite is 4250 supported. The Responder SHOULD silently drop I2 packets with 4251 unsupported Initiator HITs. 4253 4. If the system's state machine is in the R2-SENT state, the 4254 system MAY check if the newly received I2 packet is similar to 4255 the one that triggered moving to R2-SENT. If so, it MAY 4256 retransmit a previously sent R2 packet, reset the R2-SENT timer, 4257 and the state machine stays in R2-SENT. 4259 5. If the system's state machine is in the I2-SENT state, the 4260 system MUST make a comparison between its local and sender's 4261 HITs (similarly as in Section 6.5). If the local HIT is smaller 4262 than the sender's HIT, it should drop the I2 packet, use the 4263 peer Diffie-Hellman key and nonce #I from the R1 packet received 4264 earlier, and get the local Diffie-Hellman key and nonce #J from 4265 the I2 packet sent to the peer earlier. Otherwise, the system 4266 should process the received I2 packet and drop any previously 4267 derived Diffie-Hellman keying material Kij it might have formed 4268 upon sending the I2 packet previously. The peer Diffie-Hellman 4269 key and the nonce #J are taken from the just arrived I2 packet. 4270 The local Diffie-Hellman key and the nonce I are the ones that 4271 were sent earlier in the R1 packet. 4273 6. If the system's state machine is in the I1-SENT state, and the 4274 HITs in the I2 packet match those used in the previously sent I1 4275 packet, the system uses this received I2 packet as the basis for 4276 the HIP association it was trying to form, and stops 4277 retransmitting I1 packets (provided that the I2 packet passes 4278 the additional checks below). 4280 7. If the system's state machine is in any other state than 4281 R2-SENT, the system SHOULD check that the echoed R1 generation 4282 counter in the I2 packet is within the acceptable range if the 4283 counter is included. Implementations MUST accept puzzles from 4284 the current generation and MAY accept puzzles from earlier 4285 generations. If the generation counter in the newly received I2 4286 packet is outside the accepted range, the I2 packet is stale 4287 (and perhaps replayed) and SHOULD be dropped. 4289 8. The system MUST validate the solution to the puzzle by computing 4290 the hash described in Section 5.3.3 using the same RHASH 4291 algorithm. 4293 9. The I2 packet MUST have a single value in the HIP_CIPHER 4294 parameter, which MUST match one of the values offered to the 4295 Initiator in the R1 packet. 4297 10. The system must derive Diffie-Hellman keying material Kij based 4298 on the public value and Group ID in the DIFFIE_HELLMAN 4299 parameter. This key is used to derive the HIP association keys, 4300 as described in Section 6.5. If the Diffie-Hellman Group ID is 4301 unsupported, the I2 packet is silently dropped. 4303 11. The encrypted HOST_ID is decrypted by the Initiator's encryption 4304 key defined in Section 6.5. If the decrypted data is not a 4305 HOST_ID parameter, the I2 packet is silently dropped. 4307 12. The implementation SHOULD also verify that the Initiator's HIT 4308 in the I2 packet corresponds to the Host Identity sent in the I2 4309 packet. (Note: some middleboxes may not able to make this 4310 verification.) 4312 13. The system MUST process the TRANSPORT_FORMAT_LIST parameter. 4313 Other documents specifying transport formats (e.g. 4314 [I-D.ietf-hip-rfc5202-bis]) contain specifications for handling 4315 any specific transport selected. 4317 14. The system MUST verify the HIP_MAC according to the procedures 4318 in Section 5.2.12. 4320 15. The system MUST verify the HIP_SIGNATURE according to 4321 Section 5.2.14 and Section 5.3.3. 4323 16. If the checks above are valid, then the system proceeds with 4324 further I2 processing; otherwise, it discards the I2 and its 4325 state machine remains in the same state. 4327 17. The I2 packet may have the A bit set -- in this case, the system 4328 MAY choose to refuse it by dropping the I2 and the state machine 4329 returns to state UNASSOCIATED. If the A bit is set, the 4330 Initiator's HIT is anonymous and should not be stored 4331 permanently. 4333 18. The system initializes the remaining variables in the associated 4334 state, including Update ID counters. 4336 19. Upon successful processing of an I2 message when the system's 4337 state machine is in state UNASSOCIATED, I1-SENT, I2-SENT, or 4338 R2-SENT, an R2 packet is sent and the system's state machine 4339 transitions to state R2-SENT. 4341 20. Upon successful processing of an I2 packet when the system's 4342 state machine is in state ESTABLISHED, the old HIP association 4343 is dropped and a new one is installed, an R2 packet is sent, and 4344 the system's state machine transitions to R2-SENT. 4346 21. Upon the system's state machine transitioning to R2-SENT, the 4347 system starts a timer. The state machine transitions to 4348 ESTABLISHED if some data has been received on the incoming HIP 4349 association, or an UPDATE packet has been received (or some 4350 other packet that indicates that the peer system's state machine 4351 has moved to ESTABLISHED). If the timer expires (allowing for 4352 maximal amount of retransmissions of I2 packets), the state 4353 machine transitions to ESTABLISHED. 4355 6.9.1. Handling of Malformed Messages 4357 If an implementation receives a malformed I2 message, the behavior 4358 SHOULD depend on how many checks the message has already passed. If 4359 the puzzle solution in the message has already been checked, the 4360 implementation SHOULD report the error by responding with a NOTIFY 4361 packet. Otherwise, the implementation MAY respond with an ICMP 4362 message as defined in Section 5.4. 4364 6.10. Processing of Incoming R2 Packets 4366 An R2 packet received in states UNASSOCIATED, I1-SENT, or ESTABLISHED 4367 results in the R2 packet being dropped and the state machine staying 4368 in the same state. If an R2 packet is received in state I2-SENT, it 4369 MUST be processed. 4371 The following steps define the conceptual processing rules for an 4372 incoming R2 packet: 4374 1. If the system is in any other state than I2-SENT, the R2 packet 4375 is silently dropped. 4377 2. The system MUST verify that the HITs in use correspond to the 4378 HITs that were received in the R1 packet that caused the 4379 transition to the I1-SENT state. 4381 3. The system MUST verify the HIP_MAC_2 according to the procedures 4382 in Section 5.2.13. 4384 4. The system MUST verify the HIP signature according to the 4385 procedures in Section 5.2.14. 4387 5. If any of the checks above fail, there is a high probability of 4388 an ongoing man-in-the-middle or other security attack. The 4389 system SHOULD act accordingly, based on its local policy. 4391 6. Upon successful processing of the R2 packet, the state machine 4392 transitions to state ESTABLISHED. 4394 6.11. Sending UPDATE Packets 4396 A host sends an UPDATE packet when it intends to update some 4397 information related to a HIP association. There are a number of 4398 possible scenarios when this can occur, e.g., mobility management and 4399 rekeying of an existing ESP Security Association. The following 4400 paragraphs define the conceptual rules for sending an UPDATE packet 4401 to the peer. Additional steps can be defined in other documents 4402 where the UPDATE packet is used. 4404 The sequence of UPDATE messages is indicated by their SEQ parameter. 4405 Before sending an UPDATE message, the system first determines whether 4406 there are any outstanding UPDATE messages that may conflict with the 4407 new UPDATE message under consideration. When multiple UPDATEs are 4408 outstanding (not yet acknowledged), the sender must assume that such 4409 UPDATEs may be processed in an arbitrary order by the receiver. 4410 Therefore, any new UPDATEs that depend on a previous outstanding 4411 UPDATE being successfully received and acknowledged MUST be postponed 4412 until reception of the necessary ACK(s) occurs. One way to prevent 4413 any conflicts is to only allow one outstanding UPDATE at a time. 4414 However, allowing multiple UPDATEs may improve the performance of 4415 mobility and multihoming protocols. 4417 The following steps define the conceptual processing rules for 4418 sending UPDATE packets. 4420 1. The first UPDATE packet is sent with Update ID of zero. 4421 Otherwise, the system increments its own Update ID value by one 4422 before continuing the steps below. 4424 2. The system creates an UPDATE packet that contains a SEQ parameter 4425 with the current value of Update ID. The UPDATE packet MAY also 4426 include zero or more ACKs of the peer's Update ID(s) from 4427 previously received UPDATE SEQ parameter(s) 4429 3. The system sends the created UPDATE packet and starts an UPDATE 4430 timer. The default value for the timer is 2 * RTT estimate. If 4431 multiple UPDATEs are outstanding, multiple timers are in effect. 4433 4. If the UPDATE timer expires, the UPDATE is resent. The UPDATE 4434 can be resent UPDATE_RETRY_MAX times. The UPDATE timer SHOULD be 4435 exponentially backed off for subsequent retransmissions. If no 4436 acknowledgment is received from the peer after UPDATE_RETRY_MAX 4437 times, the HIP association is considered to be broken and the 4438 state machine SHOULD move from state ESTABLISHED to state CLOSING 4439 as depicted in Section 4.4.4. The UPDATE timer is cancelled upon 4440 receiving an ACK from the peer that acknowledges receipt of the 4441 UPDATE. 4443 6.12. Receiving UPDATE Packets 4445 When a system receives an UPDATE packet, its processing depends on 4446 the state of the HIP association and the presence and values of the 4447 SEQ and ACK parameters. Typically, an UPDATE message also carries 4448 optional parameters whose handling is defined in separate documents. 4450 For each association, a host stores the peer's next expected in- 4451 sequence Update ID ("peer Update ID"). Initially, this value is 4452 zero. Update ID comparisons of "less than" and "greater than" are 4453 performed with respect to a circular sequence number space. Hence, a 4454 wrap around after 2^32 updates has to be expected and MUST be handled 4455 accordingly. 4457 The sender MAY send multiple outstanding UPDATE messages. These 4458 messages are processed in the order in which they are received at the 4459 receiver (i.e., no re-sequencing is performed). When processing 4460 UPDATEs out-of-order, the receiver MUST keep track of which UPDATEs 4461 were previously processed, so that duplicates or retransmissions are 4462 ACKed and not reprocessed. A receiver MAY choose to define a receive 4463 window of Update IDs that it is willing to process at any given time, 4464 and discard received UPDATEs falling outside of that window. 4466 The following steps define the conceptual processing rules for 4467 receiving UPDATE packets. 4469 1. If there is no corresponding HIP association, the implementation 4470 MAY reply with an ICMP Parameter Problem, as specified in 4471 Section 5.4.4. 4473 2. If the association is in the ESTABLISHED state and the SEQ (but 4474 not ACK) parameter is present, the UPDATE is processed and 4475 replied to as described in Section 6.12.1. 4477 3. If the association is in the ESTABLISHED state and the ACK (but 4478 not SEQ) parameter is present, the UPDATE is processed as 4479 described in Section 6.12.2. 4481 4. If the association is in the ESTABLISHED state and there is both 4482 an ACK and SEQ in the UPDATE, the ACK is first processed as 4483 described in Section 6.12.2, and then the rest of the UPDATE is 4484 processed as described in Section 6.12.1. 4486 6.12.1. Handling a SEQ Parameter in a Received UPDATE Message 4488 The following steps define the conceptual processing rules for 4489 handling a SEQ parameter in a received UPDATE packet. 4491 1. If the Update ID in the received SEQ is not the next in the 4492 sequence of Update IDs and is greater than the receiver's window 4493 for new UPDATEs, the packet MUST be dropped. 4495 2. If the Update ID in the received SEQ corresponds to an UPDATE 4496 that has recently been processed, the packet is treated as a 4497 retransmission. The HIP_MAC verification (next step) MUST NOT be 4498 skipped. (A byte-by-byte comparison of the received and a stored 4499 packet would be acceptable, though.) It is recommended that a 4500 host caches UPDATE packets sent with ACKs to avoid the cost of 4501 generating a new ACK packet to respond to a replayed UPDATE. The 4502 system MUST acknowledge, again, such (apparent) UPDATE message 4503 retransmissions but SHOULD also consider rate-limiting such 4504 retransmission responses to guard against replay attacks. 4506 3. The system MUST verify the HIP_MAC in the UPDATE packet. If the 4507 verification fails, the packet MUST be dropped. 4509 4. The system MAY verify the SIGNATURE in the UPDATE packet. If the 4510 verification fails, the packet SHOULD be dropped and an error 4511 message logged. 4513 5. If a new SEQ parameter is being processed, the parameters in the 4514 UPDATE are then processed. The system MUST record the Update ID 4515 in the received SEQ parameter, for replay protection. 4517 6. An UPDATE acknowledgment packet with ACK parameter is prepared 4518 and sent to the peer. This ACK parameter MAY be included in a 4519 separate UPDATE or piggybacked in an UPDATE with SEQ parameter, 4520 as described in Section 5.3.5. The ACK parameter MAY acknowledge 4521 more than one of the peer's Update IDs. 4523 6.12.2. Handling an ACK Parameter in a Received UPDATE Packet 4525 The following steps define the conceptual processing rules for 4526 handling an ACK parameter in a received UPDATE packet. 4528 1. The sequence number reported in the ACK must match with an UPDATE 4529 packet sent earlier that has not already been acknowledged. If 4530 no match is found or if the ACK does not acknowledge a new 4531 UPDATE, the packet MUST either be dropped if no SEQ parameter is 4532 present, or the processing steps in Section 6.12.1 are followed. 4534 2. The system MUST verify the HIP_MAC in the UPDATE packet. If the 4535 verification fails, the packet MUST be dropped. 4537 3. The system MAY verify the SIGNATURE in the UPDATE packet. If the 4538 verification fails, the packet SHOULD be dropped and an error 4539 message logged. 4541 4. The corresponding UPDATE timer is stopped (see Section 6.11) so 4542 that the now acknowledged UPDATE is no longer retransmitted. If 4543 multiple UPDATEs are acknowledged, multiple timers are stopped. 4545 6.13. Processing of NOTIFY Packets 4547 Processing of NOTIFY packets is OPTIONAL. If processed, any errors 4548 in a received NOTIFICATION parameter SHOULD be logged. Received 4549 errors MUST be considered only as informational, and the receiver 4550 SHOULD NOT change its HIP state (see Section 4.4.2) purely based on 4551 the received NOTIFY message. 4553 6.14. Processing CLOSE Packets 4555 When the host receives a CLOSE message, it responds with a CLOSE_ACK 4556 message and moves to CLOSED state. (The authenticity of the CLOSE 4557 message is verified using both HIP_MAC and SIGNATURE). This 4558 processing applies whether or not the HIP association state is 4559 CLOSING in order to handle simultaneous CLOSE messages from both ends 4560 that cross in flight. 4562 The HIP association is not discarded before the host moves to the 4563 UNASSOCIATED state. 4565 Once the closing process has started, any new need to send data 4566 packets triggers creating and establishing of a new HIP association, 4567 starting with sending of an I1 packet. 4569 If there is no corresponding HIP association, the CLOSE packet is 4570 dropped. 4572 6.15. Processing CLOSE_ACK Packets 4574 When a host receives a CLOSE_ACK message, it verifies that it is in 4575 CLOSING or CLOSED state and that the CLOSE_ACK was in response to the 4576 CLOSE. A host can map CLOSE_ACK messages to CLOSE messages by 4577 comparing the value of ECHO_REQUEST_SIGNED (in the CLOSE packet) to 4578 the value of ECHO_RESPONSE_SIGNED (in the CLOSE_ACK packet). 4580 The CLOSE_ACK contains the HIP_MAC and the SIGNATURE parameters for 4581 verification. The state is discarded when the state changes to 4582 UNASSOCIATED and, after that, the host MAY respond with an ICMP 4583 Parameter Problem to an incoming CLOSE message (see Section 5.4.4). 4585 6.16. Handling State Loss 4587 In the case of a system crash and unanticipated state loss, the 4588 system SHOULD delete the corresponding HIP state, including the 4589 keying material. That is, the state SHOULD NOT be stored in long- 4590 term storage. If the implementation does drop the state (as 4591 RECOMMENDED), it MUST also drop the peer's R1 generation counter 4592 value, unless a local policy explicitly defines that the value of 4593 that particular host is stored. An implementation MUST NOT store a 4594 peer's R1 generation counters by default, but storing R1 generation 4595 counter values, if done, MUST be configured by explicit HITs. 4597 7. HIP Policies 4599 There are a number of variables that will influence the HIP base 4600 exchanges that each host must support. All HIP implementations MUST 4601 support more than one simultaneous HI, at least one of which SHOULD 4602 be reserved for anonymous usage. Although anonymous HIs will be 4603 rarely used as Responders' HIs, they will be common for Initiators. 4604 Support for more than two HIs is RECOMMENDED. 4606 Initiators MAY use a different HI for different Responders to provide 4607 basic privacy. Whether such private HIs are used repeatedly with the 4608 same Responder and how long these HIs are used is decided by local 4609 policy and depends on the privacy requirements of the Initiator. 4611 The value of #K used in the HIP R1 must be chosen with care. Too 4612 high numbers of #K will exclude clients with weak CPUs because these 4613 devices cannot solve the puzzle within reasonable time. #K should 4614 only be raised if a Responder is under high load, i.e., it cannot 4615 process all incoming HIP handshakes any more. If a responder is not 4616 under high load, K SHOULD be 0. 4618 Responders that only respond to selected Initiators require an ACL, 4619 representing for which hosts they accept HIP base exchanges, and the 4620 preferred transport format and local lifetimes. Wildcarding SHOULD 4621 be supported for such ACLs, and also for Responders that offer public 4622 or anonymous services. 4624 8. Security Considerations 4626 HIP is designed to provide secure authentication of hosts. HIP also 4627 attempts to limit the exposure of the host to various denial-of- 4628 service and man-in-the-middle (MitM) attacks. In doing so, HIP 4629 itself is subject to its own DoS and MitM attacks that potentially 4630 could be more damaging to a host's ability to conduct business as 4631 usual. 4633 Denial-of-service attacks often take advantage of asymmetries in the 4634 cost of an starting an association. One example of such asymmetry is 4635 the need of a Responder to store local state while a malicious 4636 Initiator can stay stateless. HIP makes no attempt to increase the 4637 cost of the start of state at the Initiator, but makes an effort to 4638 reduce the cost for the Responder. This is accomplished by having 4639 the Responder start the 3-way exchange instead of the Initiator, 4640 making the HIP protocol 4 packets long. In doing this, the first 4641 packet from the Responder, R1, becomes a 'stock' packet that the 4642 Responder MAY use many times, until some Initiator has provided a 4643 valid response to such an R1 packet. During an I1 packet storm, the 4644 host may reuse the same DH value also even if some Initiator has 4645 provided a valid response using that particular DH value. However, 4646 such behavior is discouraged and should be avoided. Using the same 4647 Diffie-Hellman values and random puzzle #I value has some risks. 4648 This risk needs to be balanced against a potential storm of HIP I1 4649 packets. 4651 This shifting of the start of state cost to the Initiator in creating 4652 the I2 HIP packet presents another DoS attack. The attacker can 4653 spoof the I1 packet and the Responder sends out the R1 HIP packet. 4654 This could conceivably tie up the 'Initiator' with evaluating the R1 4655 HIP packet, and creating the I2 packet. The defense against this 4656 attack is to simply ignore any R1 packet where a corresponding I1 4657 packet was not sent (as defined in Section 6.8 step 1). 4659 The R1 packet is considerably larger than the I1 packet. This 4660 asymmetry can be exploited in an reflection attack. A malicious 4661 attacker could spoof the IP address of a victim and send a flood of 4662 I1 messages to a powerful Responder. For each small I1 packet, the 4663 Responder would send a larger R1 packet to the victim. The 4664 difference in packet sizes can further amplify a flooding attack 4665 against the victim. To avoid such reflection attacks, the Responder 4666 SHOULD rate limit the sending of R1 packets in general or SHOULD rate 4667 limit the sending of R1 packets to a specific IP address. 4669 Floods of forged I2 packets form a second kind of DoS attack. Once 4670 the attacking Initiator has solved the puzzle, it can send packets 4671 with spoofed IP source addresses with either an invalid HIP signature 4672 or invalid encrypted HIP payload (in the ENCRYPTED parameter). This 4673 would take resources in the Responder's part to reach the point to 4674 discover that the I2 packet cannot be completely processed. The 4675 defense against this attack is after N bad I2 packets with the same 4676 puzzle solution, the Responder would discard any I2 packets that 4677 contain the given solution. This will shut down the attack. The 4678 attacker would have to request another R1 packet and use that to 4679 launch a new attack. The Responder could increase the value of #K 4680 while under attack. Keeping a list of solutions from malformed 4681 packets requires that the Responder keeps state for these malformed 4682 I2 packets. This state has to be kept until the R1 counter is 4683 increased. As malformed packets are generally filtered by their 4684 checksum before signature verification, only solutions in packets 4685 that are forged to pass the checksum and puzzle are put to the 4686 blacklist. In addition, a valid puzzle is required before a new list 4687 entry is created. Hence, attackers that intend to flood the 4688 blacklist must solve puzzles first. 4690 A third form of DoS attack is emulating the restart of state after a 4691 reboot of one of the peers. A restarting host would send an I1 4692 packet to the peers, which would respond with an R1 packet even if it 4693 were in the ESTABLISHED state. If the I1 packet were spoofed, the 4694 resulting R1 packet would be received unexpectedly by the spoofed 4695 host and would be dropped, as in the first case above. 4697 A fourth form of DoS attack is emulating closing of the HIP 4698 association. HIP relies on timers and a CLOSE/CLOSE_ACK handshake to 4699 explicitly signal the end of a HIP association. Because both CLOSE 4700 and CLOSE_ACK messages contain a HIP_MAC, an outsider cannot close a 4701 connection. The presence of an additional SIGNATURE allows 4702 middleboxes to inspect these messages and discard the associated 4703 state (for e.g., firewalling, SPI-based NATing, etc.). However, the 4704 optional behavior of replying to CLOSE with an ICMP Parameter Problem 4705 packet (as described in Section 5.4.4) might allow an attacker 4706 spoofing the source IP address to send CLOSE messages to launch 4707 reflection attacks. 4709 A fifth form of DoS attack is replaying R1s to cause the Initiator to 4710 solve stale puzzles and become out of synchronization with the 4711 Responder. The R1 generation counter is a monotonically increasing 4712 counter designed to protect against this attack, as described in 4713 Section 4.1.4. 4715 Man-in-the-middle attacks are difficult to defend against, without 4716 third-party authentication. A skillful MitM could easily handle all 4717 parts of HIP, but HIP indirectly provides the following protection 4718 from a MitM attack. If the Responder's HI is retrieved from a signed 4719 DNS zone, a certificate, or through some other secure means, the 4720 Initiator can use this to validate the R1 HIP packet. 4722 Likewise, if the Initiator's HI is in a secure DNS zone, a trusted 4723 certificate, or otherwise securely available, the Responder can 4724 retrieve the HI (after having got the I2 HIP packet) and verify that 4725 the HI indeed can be trusted. 4727 The HIP Opportunistic Mode concept has been introduced in this 4728 document, but this document does not specify what the semantics of 4729 such a connection setup are for applications. There are certain 4730 concerns with opportunistic mode, as discussed in Section 4.1.8. 4732 NOTIFY messages are used only for informational purposes and they are 4733 unacknowledged. A HIP implementation cannot rely solely on the 4734 information received in a NOTIFY message because the packet may have 4735 been replayed. An implementation SHOULD NOT change any state 4736 information purely based on a received NOTIFY message. 4738 Since not all hosts will ever support HIP, ICMP 'Destination Protocol 4739 Unreachable' messages are to be expected and may be used for a DoS 4740 attack. Against an Initiator, the attack would look like the 4741 Responder does not support HIP, but shortly after receiving the ICMP 4742 message, the Initiator would receive a valid R1 HIP packet. Thus, to 4743 protect from this attack, an Initiator SHOULD NOT react to an ICMP 4744 message until a reasonable delta time to get the real Responder's R1 4745 HIP packet. A similar attack against the Responder is more involved. 4746 Normally, if an I1 message received by a Responder was a bogus one 4747 sent by an attacker, the Responder may receive an ICMP message from 4748 the IP address the R1 message was sent to. However, a sophisticated 4749 attacker can try to take advantage of such a behavior and try to 4750 break up the HIP base exchange by sending such an ICMP message to the 4751 Responder before the Initiator has a chance to send a valid I2 4752 message. Hence, the Responder SHOULD NOT act on such an ICMP 4753 message. Especially, it SHOULD NOT remove any minimal state created 4754 when it sent the R1 HIP packet (if it did create one), but wait for 4755 either a valid I2 HIP packet or the natural timeout (that is, if R1 4756 packets are tracked at all). Likewise, the Initiator SHOULD ignore 4757 any ICMP message while waiting for an R2 HIP packet, and SHOULD 4758 delete any pending state only after a natural timeout. 4760 9. IANA Considerations 4762 IANA has reserved protocol number 139 for the Host Identity Protocol 4763 and included it in the "IPv6 Extension Header Types" registry 4764 [RFC7045] and the "Assigned Internet Protocol Numbers" registry. The 4765 reference in both of these registries should be updated from 4766 [RFC5201] to this specification. 4768 The reference to the 128-bit value under the CGA Message Type 4769 namespace [RFC3972] of "0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA" 4770 should be changed from [RFC5201] to this specification. 4772 The following changes to the "Host Identity Protocol (HIP) 4773 Parameters" registries are requested. In many cases, the changes 4774 required involve updating the reference from [RFC5201] to this 4775 specification, but there are some differences as outlined below. 4776 Allocation terminology is defined in [RFC5226]; any existing 4777 references to "IETF Consensus" can be replaced with "IETF Review" as 4778 per [RFC5226]. 4780 HIP Version 4782 This document adds the value "2" to the existing registry. The 4783 value of "1" should be left with a reference to [RFC5201]. 4785 Packet Type 4787 The 7-bit Packet Type field in a HIP protocol packet describes the 4788 type of a HIP protocol message. It is defined in Section 5.1. 4790 All existing values referring to [RFC5201] should be updated to 4791 refer to this specification. Other values should be left 4792 unchanged. 4794 HIT Suite ID 4796 This specification creates a new registry for "HIT Suite ID". 4797 This is different than the existing registry for "Suite ID" which 4798 can be left unmodified for version 1 of the protocol ([RFC5201]). 4799 The registry should be closed to new registrations. 4801 The four-bit HIT Suite ID uses the OGA field in the ORCHID to 4802 express the type of the HIT. This document defines three HIT 4803 Suites (see Appendix E). 4805 The HIT Suite ID is also carried in the four higher-order bits of 4806 the ID field in the HIT_SUITE_LIST parameter. The four lower- 4807 order bits are reserved for future extensions of the HIT Suite ID 4808 space beyond 16 values. 4810 For the time being, the HIT Suite uses only four bits because 4811 these bits have to be carried in the HIT. Using more bits for the 4812 HIT Suite ID reduces the cryptographic strength of the HIT. HIT 4813 Suite IDs must be allocated carefully to avoid namespace 4814 exhaustion. Moreover, deprecated IDs should be reused after an 4815 appropriate time span. If 16 Suite IDs prove insufficient and 4816 more HIT Suite IDs are needed concurrently, more bits can be used 4817 for the HIT Suite ID by using one HIT Suite ID (0) to indicate 4818 that more bits should be used. The HIT_SUITE_LIST parameter 4819 already supports 8-bit HIT Suite IDs, should longer IDs be needed. 4820 Possible extensions of the HIT Suite ID space to accommodate eight 4821 bits and new HIT Suite IDs are defined through IETF Review. 4823 Requests to register reused values should include a note that the 4824 value is being reused after a deprecation period, to ensure 4825 appropriate IETF review and approval. 4827 Parameter Type 4829 The 16-bit Type field in a HIP parameter describes the type of the 4830 parameter. It is defined in Section 5.2.1. The current values 4831 are defined in Sections 5.2.3 through 5.2.23. The existing 4832 registry for "Parameter Type" should be updated as follows. 4834 A new value (129) for R1_COUNTER should be introduced, with a 4835 reference to this specification, and the existing value (128) for 4836 R1_COUNTER left in place with a reference to [RFC5201]. This 4837 documents the change in value that has occurred in version 2 of 4838 this protocol. For clarity, we recommend that the name for the 4839 value 128 be changed from "R1_COUNTER" to "R1_Counter (v1 only)". 4841 A new value (579) for a new Parameter Type HIP_CIPHER should be 4842 added, with reference to this specification. This Parameter Type 4843 functionally replaces the HIP_TRANSFORM Parameter Type (value 577) 4844 which can be left in the table with existing reference to 4845 [RFC5201]. For clarity, we recommend that the name for the value 4846 577 be changed from "HIP_TRANSFORM" to "HIP_TRANSFORM (v1 only)". 4848 A new value (715) for a new Parameter Type HIT_SUITE_LIST should 4849 be added, with reference to this specification. 4851 A new value (2049) for a new Parameter Type TRANSPORT_FORMAT_LIST 4852 should be added, with reference to this specification. 4854 The name of the HMAC Parameter Type (value 61505) should be 4855 changed to HIP_MAC. The name of the HMAC_2 Parameter Type (value 4856 61569) should be changed to HIP_MAC_2. The reference should be 4857 changed to this specification. 4859 All other Parameter Types that reference [RFC5201] should be 4860 updated to refer to this specification, and Parameter Types that 4861 reference other RFCs should be unchanged. 4863 Regarding the range assignments, the Type codes 32768 through 4864 49151 (not 49141) should be Reserved for Private Use. Where the 4865 existing ranges state "First Come First Served with Specification 4866 Required", this should be changed to "Specification Required". 4868 The Type codes 32768 through 49151 are reserved for 4869 experimentation. Implementors SHOULD select types in a random 4870 fashion from this range, thereby reducing the probability of 4871 collisions. A method employing genuine randomness (such as 4872 flipping a coin) SHOULD be used. 4874 Group ID 4876 The eight-bit Group ID values appear in the DIFFIE_HELLMAN 4877 parameter and the DH_GROUP_LIST parameter and are defined in 4878 Section 5.2.7. This registry should be updated based on the new 4879 values specified in Section 5.2.7; values noted as being 4880 DEPRECATED can be left in the table with reference to [RFC5201]. 4881 New values are assigned through IETF Review. 4883 HIP Cipher ID 4884 The 16-bit Cipher ID values in a HIP_CIPHER parameter are defined 4885 in Section 5.2.8. This is a new registry. New values either from 4886 the reserved or unassigned space are assigned through IETF Review. 4888 DI-Type 4890 The four-bit DI-Type values in a HOST_ID parameter are defined in 4891 Section 5.2.9. New values are assigned through IETF Review. All 4892 existing values referring to [RFC5201] should be updated to refer 4893 to this specification. 4895 HI Algorithm 4897 The 16-bit Algorithm values in a HOST_ID parameter are defined in 4898 Section 5.2.9. This is a new registry. New values either from 4899 the reserved or unassigned space are assigned through IETF Review. 4901 ECC Curve Label 4903 When the HI Algorithm values in a HOST_ID parameter is defined to 4904 the values of either "ECDSA" or "ECDSA_LOW", a new registry is 4905 needed to maintain the values for the ECC Curve Label as defined 4906 in Section 5.2.9. This might be handled by specifying two 4907 algorithm-specific sub-registries named "ECDSA Curve Label" and 4908 "ECDSA_LOW Curve Label". New values are to be assigned through 4909 IETF Review. 4911 Notify Message Type 4913 The 16-bit Notify Message Type values in a NOTIFICATION parameter 4914 are defined in Section 5.2.19. 4916 Notify Message Type values 1-10 are used for informing about 4917 errors in packet structures, values 11-20 for informing about 4918 problems in parameters containing cryptographic related material, 4919 values 21-30 for informing about problems in authentication or 4920 packet integrity verification. Parameter numbers above 30 can be 4921 used for informing about other types of errors or events. 4923 The existing registration procedures should be updated as follows. 4924 The range from 1-50 can remain as "IETF Review". The range from 4925 51-8191 should be marked as "Specification Required". Values 4926 8192-16383 can remain as "Reserved for Private Use". Values 4927 16385-40959 should be marked as "Specification Required". Values 4928 40960-65535 can remain as "Reserved for Private Use". 4930 The following updates to the values should be made to the existing 4931 registry. All existing values referring to [RFC5201] should be 4932 updated to refer to this specification. 4934 INVALID_HIP_TRANSFORM_CHOSEN should be renamed to 4935 INVALID_HIP_CIPHER_CHOSEN with the same value (17). 4937 A new value of 20 for the type UNSUPPORTED_HIT_SUITE should be 4938 added. 4940 HMAC_FAILED should be renamed to HIP_MAC_FAILED with the same 4941 value (28). 4943 SERVER_BUSY_PLEASE_RETRY should be renamed to 4944 RESPONDER_BUSY_PLEASE_RETRY with the same value (44). 4946 10. Acknowledgments 4948 The drive to create HIP came to being after attending the MALLOC 4949 meeting at the 43rd IETF meeting. Baiju Patel and Hilarie Orman 4950 really gave the original author, Bob Moskowitz, the assist to get HIP 4951 beyond 5 paragraphs of ideas. It has matured considerably since the 4952 early versions thanks to extensive input from IETFers. Most 4953 importantly, its design goals are articulated and are different from 4954 other efforts in this direction. Particular mention goes to the 4955 members of the NameSpace Research Group of the IRTF. Noel Chiappa 4956 provided valuable input at early stages of discussions about 4957 identifier handling and Keith Moore the impetus to provide 4958 resolvability. Steve Deering provided encouragement to keep working, 4959 as a solid proposal can act as a proof of ideas for a research group. 4961 Many others contributed; extensive security tips were provided by 4962 Steve Bellovin. Rob Austein kept the DNS parts on track. Paul 4963 Kocher taught Bob Moskowitz how to make the puzzle exchange expensive 4964 for the Initiator to respond, but easy for the Responder to validate. 4965 Bill Sommerfeld supplied the Birthday concept, which later evolved 4966 into the R1 generation counter, to simplify reboot management. Erik 4967 Nordmark supplied the CLOSE-mechanism for closing connections. 4968 Rodney Thayer and Hugh Daniels provided extensive feedback. In the 4969 early times of this document, John Gilmore kept Bob Moskowitz 4970 challenged to provide something of value. 4972 During the later stages of this document, when the editing baton was 4973 transferred to Pekka Nikander, the input from the early implementors 4974 was invaluable. Without having actual implementations, this document 4975 would not be on the level it is now. 4977 In the usual IETF fashion, a large number of people have contributed 4978 to the actual text or ideas. The list of these people include Jeff 4979 Ahrenholz, Francis Dupont, Derek Fawcus, George Gross, Andrew 4980 McGregor, Julien Laganier, Miika Komu, Mika Kousa, Jan Melen, Henrik 4981 Petander, Michael Richardson, Rene Hummen, Tim Shepard, Jorma Wall, 4982 Xin Gu, and Jukka Ylitalo. Our apologies to anyone whose name is 4983 missing. 4985 Once the HIP Working Group was founded in early 2004, a number of 4986 changes were introduced through the working group process. Most 4987 notably, the original document was split in two, one containing the 4988 base exchange and the other one defining how to use ESP. Some 4989 modifications to the protocol proposed by Aura, et al., [AUR03] were 4990 added at a later stage. 4992 11. Changes from RFC 5201 4994 This section summarizes the changes made from [RFC5201]. 4996 11.1. Changes from draft-ietf-hip-rfc5201-bis-17 4998 o Update ORCHID reference to newly published RFC 7343 5000 o Update example checksum section to RFC 7343 HIT prefix of 5001 2001:20::/28, and fix incorrect Header Length fields 5003 o Update IANA considerations comment on legacy HIP_TRANSFORM 5004 parameter naming 5006 o Add 2048-bit MODP DHE group as Group ID value 11. 5008 11.2. Changes from draft-ietf-hip-rfc5201-bis-16 5010 o Clarify that receipt of user data in state CLOSING (Table 7) 5011 results in transition to I1-SENT 5013 o Add academic reference for the first mention of the RSA algorithm 5015 o As part of comment resolution on use of NULL encryption, note that 5016 use of a NULL HIP CIPHER is only to be used when debugging and 5017 testing the HIP protocol. This only pertains to the ENCRYPTED 5018 parameter, which is optional; in practice, if encryption is not 5019 desired, better to just not encrypt the Host ID. 5021 11.3. Changes from draft-ietf-hip-rfc5201-bis-15 5023 o Additional edits to IANA Considerations section based on initial 5024 IANA review. 5026 11.4. Changes from draft-ietf-hip-rfc5201-bis-14 5028 o Update source XML to comply with xmlrfcv2 version of the xml2rfc 5029 tool, resulting in a few table formatting changes. 5031 o Editorial and minor technical revisions based on IESG review. 5033 o Significant revisions to IANA Considerations section based on 5034 initial IANA review. 5036 11.5. Changes from draft-ietf-hip-rfc5201-bis-13 5038 o Update a few references and fix some editorial nits. 5040 11.6. Changes from draft-ietf-hip-rfc5201-bis-12 5042 o Fix I-D nits. 5044 11.7. Changes from draft-ietf-hip-rfc5201-bis-11 5046 o Specify that TRANSPORT_FORMAT_LIST is mandatory in R1 and I2; fix 5047 incorrect section reference. 5049 11.8. Changes from draft-ietf-hip-rfc5201-bis-10 5051 o Issue 39: Text clarifying R1 counter rollover and Initiator 5052 response to unexpected reset of the counter. 5054 11.9. Changes from draft-ietf-hip-rfc5201-bis-09 5056 o Editorial changes based on working group last call. 5058 11.10. Changes from draft-ietf-hip-rfc5201-bis-08 5060 o Issue 29: Use different RSA mode OEAP/PSS, elevate ECDSA to 5061 REQUIRED status 5063 o Issue 35: limiting ECC cofactor to 1 5065 o Changed text regarding issue 33 reusing DH values 5067 o Fix tracker issue 32 on Domain Identifier normative text 5069 11.11. Changes from draft-ietf-hip-rfc5201-bis-07 5071 o Removed lingering references to SHA-1 as the mandatory hash 5072 algorithm (which was changed to SHA-256 in the -02 draft version). 5074 o For parameter type number changes, changed "IETF Review" to "IETF 5075 Review or IESG Approval". 5077 o Updated Appendix C checksum examples to conform to HIPv2 packets. 5079 11.12. Changes from draft-ietf-hip-rfc5201-bis-06 5081 o Made echoing the R1_COUNTER in the I2 mandatory if the R1 contains 5082 an R1_COUNTER. This required to make the R1 counter a critical 5083 parameter. Hence, the parameter type number of the R1_COUNTER 5084 changed from 128 to 129. 5086 o Made KDF dependent on DH Group to enable negotiation of the KDF. 5088 11.13. Changes from draft-ietf-hip-rfc5201-bis-05 5090 o Changed type number of DH_GROUP_LIST from 2151 to 511 because it 5091 was in the number space that is reserved for the HIP transport 5092 mode negotiations. 5094 o Added transport form type list parameter. Transport forms are now 5095 negotiated with this list instead of by their order in the HIP 5096 packet. This allows to remove the exception of the transport 5097 format parameters that were ordered by their preference instead of 5098 by their type number. This should remove complexity from 5099 implementations. 5101 o Clarify that in HIP signature processing, the restored checksum 5102 and length fields have been rendered invalid by the previous 5103 steps. 5105 o Clarify behavior for when UPDATE does not contain SEQ or ACQ 5106 (disallow this). 5108 o For namespace changes, changed "IETF Review" to "IETF Review or 5109 IESG Approval". 5111 o Addressed IESG comment about ignoring packet IP addresses. 5113 o Permit using Anonymous HI control in packets other than R1/I2. 5115 o Fixed minor reference error (RFC2418, RFC2410). 5117 o Deleted comment that NULL-ENCRYPTION SHOULD NOT be configurable 5118 via the UI. 5120 o Editorial changes. 5122 11.14. Changes from draft-ietf-hip-rfc5201-bis-04 5124 o Clarifications of the Security Considerations section. One DoS 5125 defense mechanism was changed to be more effective and less prone 5126 to misuse. 5128 o Minor clarifications of the state machine. 5130 o Clarified text on HIP puzzle. 5132 o Added names and references for figures. 5134 o Extended the definitions section. 5136 o Added a reference to the HIP Version 1 certificate document. 5138 o Added Initiator, Responder, HIP association, and signed data to 5139 the definitions section. 5141 o Changed parameter figure for PUZZLE and SOLUTION to use 5142 RHASH_len/8 instead of n-byte. 5144 o Replaced occurrences of lowercase 'not' in SHOULD NOT. 5146 o Changed text to reflect the fact that several 5147 ECHO_REQUEST_UNSIGNED parameters may be present in an R1 and 5148 several ECHO_RESPONSE parameters may be present in an I2. 5150 o Added text on verifying the ECHO_RESPONSE_SIGNED parameter in 5151 CLOSE_ACK. 5153 o Changed wording from HMAC to HIP_MAC in Section 5.3.8. 5155 o Reflected fact that the UPDATE packet MAY include zero or more 5156 ACKs. 5158 o Added BEX to Definitions section. 5160 o Changed HIP_SIGNATURE algorithm field from 8 bit to 16 bit to 5161 achieve alignment with the HOST_ID parameters. 5163 o Fixed the wrong figures of the SEQ and ACK parameters. SEQ always 5164 contains ONE update ID. ACK may acknowledge SEVERAL update IDs. 5166 o Added wording that several NOTIFY parameters may be present in a 5167 HIP packet. 5169 o Changed wording for the ECHO_RESPONSE_SIGNED parameter. Also 5170 lifted the restriction that only one ECHO_RESPONSE_UNSIGNED 5171 parameter MUST be present in each HIP packet. This did contradict 5172 the definition of the ECHO_RESPONSE_UNSIGNED parameter. 5174 o Changed IETF Consensus to IETF Review or IESG Approval in IANA 5175 section. 5177 o Aligned use of I, J, and K. Now I is #I, J is #J and K is #K 5178 throughout the document. 5180 o Updated references. 5182 o Editorial changes. 5184 11.15. Changes from draft-ietf-hip-rfc5201-bis-03 5186 o Editorial changes to improve clarity and readability. 5188 o Removed obsoleted (not applicable) attack from security 5189 consideration section. 5191 o Added a requirement that hosts MUST support processing of ACK 5192 parameters with several SEQ numbers even when they do not support 5193 sending such parameters. 5195 o Removed note on memory bound puzzles. The use of memory bound 5196 puzzles was reconsidered but no convincing arguments for inclusion 5197 in this document have been made on the list. 5199 o Changed references to reference the new bis documents. 5201 o Specified the ECC curves and the hashes used for these. 5203 o Specified representation of ECC curves in the HI. 5205 o Added text on the dependency between RHASH and HMAC. 5207 o Rephrased part of the security considerations to make them 5208 clearer. 5210 o Clarified the use of HITs in opportunistic mode. 5212 o Clarified the difference between HIP_MAC and HIP_MAC_2 as well as 5213 between SIGNATURE and SIGNATURE_2. 5215 o Changed NOTIFY name for value 44 from SERVER_BUSY_PLEASE_RETRY to 5216 RESPONDER_BUSY_PLEASE_RETRY. 5218 o Mentioned that there are multiple valid puzzle solutions. 5220 11.16. Changes from draft-ietf-hip-rfc5201-bis-02 5222 o Added recommendation to not use puzzle #I twice for the same host 5223 to avoid identical key material. 5225 o Revised state machine and added missing event handling. 5227 o Added UNSUPPORTED_HIT_SUITE to NOTIFY to indicate unsupported HIT 5228 suites. 5230 o Revised parameter type numbers (corresponding to IANA allocations) 5231 and added missing "free for experimentation" range to the 5232 description. 5234 o Clarifying note on the use of the C bit in the parameter type 5235 numbers. 5237 11.17. Changes from draft-ietf-hip-rfc5201-bis-01 5239 o Changed RHASH-len to RHASH_len to avoid confusion in calculations 5240 (- could be minus) 5242 o Added RHASH_len to list of abbreviations 5244 o Fixed length of puzzle #I and #J to be 1*RHASH_len 5246 o Changed RHASH-len to RHASH_len to avoid confusion in calculations 5247 (- could be minus) 5249 o Added RHASH_len to list of abbreviations 5251 o Fixed length of puzzle #I and #J to be 1*RHASH_len 5253 o Included HIT_SUITEs. 5255 o Added DH negotiation to I1 and R1. 5257 o Added DH_LIST parameter. 5259 o Added text for DH Group negotiation. 5261 o Removed second DH public value from DH parameter. 5263 o Added ECC to HI generation. 5265 o Added Responder HIT selection to opportunistic mode. 5267 o Added ECDSA HI text and references (not complete yet). 5269 o Added separate section on aborting BEX. 5271 o Added separate section on downgrade attack prevention. 5273 o Added text about DH Group selection for use cases without I1. 5275 o Removed type range allocation for parameters related to HIP 5276 transform types. 5278 o New type range allocation for parameters that are only covered by 5279 a signature if a signature is present (Applies to DH_GROUP_LIST). 5281 o Renamed HIP_TRANSFORM to HIP_CIPHER and removed hashes from it - 5282 hashes are determined by RHASH. 5284 o The length of #I and #J for the puzzle now depends on RHASH. 5286 o New keymat generation. 5288 o Puzzle seed and solution now use RHASH and have variable length. 5290 o Moved timing definitions closer to state machine. 5292 o Simplified text regarding puzzle lifetime. 5294 o Clarified the description of the use of #I in the puzzle 5296 o Removed "Opportunistic mode" description from general definitions. 5298 o More consistency across the old RFC5201 text. Aligned 5299 capitalization and abbreviations. 5301 o Extended protocol overview to include restart option. 5303 o Extended state machine to include restart option because of 5304 unsupported Algorithms. 5306 o Replaced SHA-1 with SHA-256 for required implementation. 5308 o Added OGA list parameter (715) for detecting the Responder's set 5309 of OGAs. 5311 o Added Appendix on ORCHID use in HITs. 5313 o Added truncated SHA-256 option for HITs. 5315 o Added truncated SHA-1 option for HITs. 5317 o Added text about new ORCHID structure to HIT overview. 5319 o Moved Editor role to Robert Moskowitz. 5321 o Added SHA-256 to puzzle parameter. 5323 o Generalized LTRUNC to be hash-function agnostic. 5325 o Added text about RHASH depending on OGA. 5327 11.18. Changes from draft-ietf-hip-rfc5201-bis-00 5329 o Added reasoning why BIS document is needed. 5331 11.19. Contents of draft-ietf-hip-rfc5201-bis-00 5333 o RFC5201 was submitted as draft-RFC. 5335 12. References 5337 12.1. Normative References 5339 [FIPS.180-2.2002] 5340 National Institute of Standards and Technology, "Secure 5341 Hash Standard", FIPS PUB 180-2, August 2002, 5342 . 5345 [I-D.ietf-hip-rfc5202-bis] 5346 Jokela, P., Moskowitz, R., and J. Melen, "Using the 5347 Encapsulating Security Payload (ESP) Transport Format with 5348 the Host Identity Protocol (HIP)", draft-ietf-hip- 5349 rfc5202-bis-05 (work in progress), November 2013. 5351 [NIST.800-131A.2011] 5352 National Institute of Standards and Technology, 5353 "Transitions: Recommendation for Transitioning the Use of 5354 Cryptographic Algorithms and Key Lengths", NIST 800-131A, 5355 January 2011. 5357 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 5358 August 1980. 5360 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 5361 793, September 1981. 5363 [RFC1035] Mockapetris, P., "Domain names - implementation and 5364 specification", STD 13, RFC 1035, November 1987. 5366 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 5367 Requirement Levels", BCP 14, RFC 2119, March 1997. 5369 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within 5370 ESP and AH", RFC 2404, November 1998. 5372 [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and 5373 Its Use With IPsec", RFC 2410, November 1998. 5375 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 5376 (IPv6) Specification", RFC 2460, December 1998. 5378 [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System 5379 (DNS)", RFC 2536, March 1999. 5381 [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain 5382 Name System (DNS)", RFC 3110, May 2001. 5384 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 5385 Diffie-Hellman groups for Internet Key Exchange (IKE)", 5386 RFC 3526, May 2003. 5388 [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher 5389 Algorithm and Its Use with IPsec", RFC 3602, September 5390 2003. 5392 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 5393 RFC 3972, March 2005. 5395 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 5396 Rose, "Resource Records for the DNS Security Extensions", 5397 RFC 4034, March 2005. 5399 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 5400 Network Access Identifier", RFC 4282, December 2005. 5402 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 5403 Message Protocol (ICMPv6) for the Internet Protocol 5404 Version 6 (IPv6) Specification", RFC 4443, March 2006. 5406 [RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using 5407 the Elliptic Curve Digital Signature Algorithm (ECDSA)", 5408 RFC 4754, January 2007. 5410 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 5411 384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007. 5413 [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY 5414 and RRSIG Resource Records for DNSSEC", RFC 5702, October 5415 2009. 5417 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 5418 "Default Address Selection for Internet Protocol Version 6 5419 (IPv6)", RFC 6724, September 2012. 5421 [RFC7343] Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay 5422 Routable Cryptographic Hash Identifiers Version 2 5423 (ORCHIDv2)", RFC 7343, September 2014. 5425 12.2. Informative References 5427 [AUR03] Aura, T., Nagarajan, A., and A. Gurtov, "Analysis of the 5428 HIP Base Exchange Protocol", in Proceedings of 10th 5429 Australasian Conference on Information Security and 5430 Privacy, July 2003. 5432 [CRO03] Crosby, SA. and DS. Wallach, "Denial of Service via 5433 Algorithmic Complexity Attacks", in Proceedings of Usenix 5434 Security Symposium 2003, Washington, DC., August 2003. 5436 [DIF76] Diffie, W. and M. Hellman, "New Directions in 5437 Cryptography", IEEE Transactions on Information Theory 5438 vol. IT-22, number 6, pages 644-654, Nov 1976. 5440 [FIPS.197.2001] 5441 National Institute of Standards and Technology, "Advanced 5442 Encryption Standard (AES)", FIPS PUB 197, November 2001, 5443 . 5446 [FIPS186-3] 5447 U.S. Department of Commerce/National Institute of 5448 Standards and Technology, "FIPS PUB 186-3: Digital 5449 Signature Standard (DSS).", June 2009. 5451 [I-D.ietf-hip-rfc4423-bis] 5452 Moskowitz, R., "Host Identity Protocol Architecture", 5453 draft-ietf-hip-rfc4423-bis-05 (work in progress), 5454 September 2012. 5456 [I-D.ietf-hip-rfc5204-bis] 5457 Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 5458 Rendezvous Extension", draft-ietf-hip-rfc5204-bis-02 (work 5459 in progress), September 2012. 5461 [I-D.ietf-hip-rfc5205-bis] 5462 Laganier, J., "Host Identity Protocol (HIP) Domain Name 5463 System (DNS) Extension", draft-ietf-hip-rfc5205-bis-02 5464 (work in progress), September 2012. 5466 [I-D.ietf-hip-rfc5206-bis] 5467 Henderson, T., Vogt, C., and J. Arkko, "Host Mobility with 5468 the Host Identity Protocol", draft-ietf-hip-rfc5206-bis-06 5469 (work in progress), July 2013. 5471 [KAU03] Kaufman, C., Perlman, R., and B. Sommerfeld, "DoS 5472 protection for UDP-based protocols", ACM Conference on 5473 Computer and Communications Security , Oct 2003. 5475 [KRA03] Krawczyk, H., "SIGMA: The 'SIGn-and-MAc' Approach to 5476 Authenticated Diffie-Hellman and Its Use in the IKE- 5477 Protocols", in Proceedings of CRYPTO 2003, pages 400-425, 5478 August 2003. 5480 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 5481 RFC 792, September 1981. 5483 [RFC2785] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup" 5484 Attacks on the Diffie-Hellman Key Agreement Method for S/ 5485 MIME", RFC 2785, March 2000. 5487 [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography 5488 Specification Version 2.0", RFC 2898, September 2000. 5490 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 5491 Standards (PKCS) #1: RSA Cryptography Specifications 5492 Version 2.1", RFC 3447, February 2003. 5494 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 5495 Reserved for Documentation", RFC 3849, July 2004. 5497 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 5498 "Host Identity Protocol", RFC 5201, April 2008. 5500 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 5501 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 5502 May 2008. 5504 [RFC5338] Henderson, T., Nikander, P., and M. Komu, "Using the Host 5505 Identity Protocol with Legacy Applications", RFC 5338, 5506 September 2008. 5508 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 5509 Shim Protocol for IPv6", RFC 5533, June 2009. 5511 [RFC5747] Wu, J., Cui, Y., Li, X., Xu, M., and C. Metz, "4over6 5512 Transit Solution Using IP Encapsulation and MP-BGP 5513 Extensions", RFC 5747, March 2010. 5515 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 5516 Key Derivation Function (HKDF)", RFC 5869, May 2010. 5518 [RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a 5519 Prime (ECP Groups) for IKE and IKEv2", RFC 5903, June 5520 2010. 5522 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 5523 "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5524 5996, September 2010. 5526 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 5527 Curve Cryptography Algorithms", RFC 6090, February 2011. 5529 [RFC6253] Heer, T. and S. Varjonen, "Host Identity Protocol 5530 Certificates", RFC 6253, May 2011. 5532 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 5533 of IPv6 Extension Headers", RFC 7045, December 2013. 5535 [RSA] Rivest, R., Shamir, A., and L. Adleman, "A Method for 5536 Obtaining Digital Signatures and Public-Key 5537 Cryptosystems", Communications of the ACM 21 (2), pp. 5538 120-126, February 1978. 5540 [SECG] SECG, "Recommended Elliptic Curve Domain Parameters", SEC 5541 2 , 2000, . 5543 Appendix A. Using Responder Puzzles 5545 As mentioned in Section 4.1.1, the Responder may delay state creation 5546 and still reject most spoofed I2 packets by using a number of pre- 5547 calculated R1 packets and a local selection function. This appendix 5548 defines one possible implementation in detail. The purpose of this 5549 appendix is to give the implementors an idea on how to implement the 5550 mechanism. If the implementation is based on this appendix, it MAY 5551 contain some local modification that makes an attacker's task harder. 5553 The Responder creates a secret value S, that it regenerates 5554 periodically. The Responder needs to remember the two latest values 5555 of S. Each time the S is regenerated, the R1 generation counter 5556 value is incremented by one. 5558 The Responder generates a pre-signed R1 packet. The signature for 5559 pre-generated R1s must be recalculated when the Diffie-Hellman key is 5560 recomputed or when the R1_COUNTER value changes due to S value 5561 regeneration. 5563 When the Initiator sends the I1 packet for initializing a connection, 5564 the Responder receives the HIT and IP address from the packet, and 5565 generates an #I value for the puzzle. The #I value is set to the 5566 pre-signed R1 packet. 5568 #I value calculation: 5569 #I = Ltrunc( RHASH ( S | HIT-I | HIT-R | IP-I | IP-R ), n) 5570 where n = RHASH_len 5572 The RHASH algorithm is the same that is used to generate the 5573 Responder's HIT value. 5575 From an incoming I2 packet, the Responder receives the required 5576 information to validate the puzzle: HITs, IP addresses, and the 5577 information of the used S value from the R1_COUNTER. Using these 5578 values, the Responder can regenerate the #I, and verify it against 5579 the #I received in the I2 packet. If the #I values match, it can 5580 verify the solution using #I, #J, and difficulty #K. If the #I 5581 values do not match, the I2 is dropped. 5583 puzzle_check: 5584 V := Ltrunc( RHASH( I2.I | I2.hit_i | I2.hit_r | I2.J ), #K ) 5585 if V != 0, drop the packet 5587 If the puzzle solution is correct, the #I and #J values are stored 5588 for later use. They are used as input material when keying material 5589 is generated. 5591 Keeping state about failed puzzle solutions depends on the 5592 implementation. Although it is possible for the Responder not to 5593 keep any state information, it still may do so to protect itself 5594 against certain attacks (see Section 4.1.1). 5596 Appendix B. Generating a Public Key Encoding from an HI 5598 The following pseudo-code illustrates the process to generate a 5599 public key encoding from an HI for both RSA and DSA. 5601 The symbol ":=" denotes assignment; the symbol "+=" denotes 5602 appending. The pseudo-function "encode_in_network_byte_order" takes 5603 two parameters, an integer (bignum) and a length in bytes, and 5604 returns the integer encoded into a byte string of the given length. 5606 switch ( HI.algorithm ) 5607 { 5609 case RSA: 5610 buffer := encode_in_network_byte_order ( HI.RSA.e_len, 5611 ( HI.RSA.e_len > 255 ) ? 3 : 1 ) 5612 buffer += encode_in_network_byte_order ( HI.RSA.e, HI.RSA.e_len ) 5613 buffer += encode_in_network_byte_order ( HI.RSA.n, HI.RSA.n_len ) 5614 break; 5616 case DSA: 5617 buffer := encode_in_network_byte_order ( HI.DSA.T , 1 ) 5618 buffer += encode_in_network_byte_order ( HI.DSA.Q , 20 ) 5619 buffer += encode_in_network_byte_order ( HI.DSA.P , 64 + 5620 8 * HI.DSA.T ) 5621 buffer += encode_in_network_byte_order ( HI.DSA.G , 64 + 5622 8 * HI.DSA.T ) 5623 buffer += encode_in_network_byte_order ( HI.DSA.Y , 64 + 5624 8 * HI.DSA.T ) 5625 break; 5627 } 5629 Appendix C. Example Checksums for HIP Packets 5631 The HIP checksum for HIP packets is specified in Section 5.1.1. 5632 Checksums for TCP and UDP packets running over HIP-enabled security 5633 associations are specified in Section 4.5.1. The examples below use 5634 [RFC3849] and [RFC5747] addresses, and HITs with the prefix of 5635 2001:20 followed by zeros, followed by a decimal 1 or 2, 5636 respectively. 5638 The following example is defined only for testing the checksum 5639 calculation. 5641 C.1. IPv6 HIP Example (I1 packet) 5643 Source Address: 2001:D88::1 5644 Destination Address: 2001:D88::2 5645 Upper-Layer Packet Length: 48 0x30 5646 Next Header: 139 0x8b 5647 Payload Protocol: 59 0x3b 5648 Header Length: 5 0x5 5649 Packet Type: 1 0x1 5650 Version: 2 0x2 5651 Reserved: 1 0x1 5652 Control: 0 0x0 5653 Checksum: 6846 0x1abe 5654 Sender's HIT : 2001:20::1 5655 Receiver's HIT: 2001:20::2 5656 DH_GROUP_LIST type: 511 0x1ff 5657 DH_GROUP_LIST length: 3 0x3 5658 DH_GROUP_LIST group IDs: 3,4,8 5660 C.2. IPv4 HIP Packet (I1 packet) 5662 The IPv4 checksum value for the example I1 packet is shown below. 5664 Source Address: 192.0.2.1 5665 Destination Address: 192.0.2.2 5666 Upper-Layer Packet Length: 48 0x30 5667 Next Header: 139 0x8b 5668 Payload Protocol: 59 0x3b 5669 Header Length: 5 0x5 5670 Packet Type: 1 0x1 5671 Version: 2 0x2 5672 Reserved: 1 0x1 5673 Control: 0 0x0 5674 Checksum: 61902 0xf1ce 5675 Sender's HIT : 2001:20::1 5676 Receiver's HIT: 2001:20::2 5677 DH_GROUP_LIST type: 511 0x1ff 5678 DH_GROUP_LIST length: 3 0x3 5679 DH_GROUP_LIST group IDs: 3,4,8 5681 C.3. TCP Segment 5683 Regardless of whether IPv6 or IPv4 is used, the TCP and UDP sockets 5684 use the IPv6 pseudo-header format [RFC2460], with the HITs used in 5685 place of the IPv6 addresses. 5687 Sender's HIT: 2001:20::1 5688 Receiver's HIT: 2001:20::2 5689 Upper-Layer Packet Length: 20 0x14 5690 Next Header: 6 0x06 5691 Source port: 65500 0xffdc 5692 Destination port: 22 0x0016 5693 Sequence number: 1 0x00000001 5694 Acknowledgment number: 0 0x00000000 5695 Data offset: 5 0x5 5696 Flags: SYN 0x02 5697 Window size: 65535 0xffff 5698 Checksum: 28586 0x6faa 5699 Urgent pointer: 0 0x0000 5701 Appendix D. ECDH and ECDSA 160 Bit Groups 5703 The ECDH and ECDSA 160-bit group SECP160R1 is rated at 80 bits 5704 symmetric strength. Once this was considered appropriate for one 5705 year of security. Today these groups should be used only when the 5706 host is not powerful enough (e.g., some embedded devices) and when 5707 security requirements are low (e.g., long-term confidentiality is not 5708 required). 5710 Appendix E. HIT Suites and HIT Generation 5712 The HIT as an ORCHID [RFC7343] consists of three parts: A 28-bit 5713 prefix, a 4-bit encoding of the ORCHID generation algorithm (OGA) and 5714 the representation of the public key. The OGA is an index pointing 5715 to the specific algorithm by which the public key and the 96-bit 5716 hashed encoding is generated. The OGA is protocol specific and is to 5717 be interpreted as defined below for all protocols that use the same 5718 context ID as HIP. HIP groups sets of valid combinations of 5719 signature and hash algorithms into HIT Suites. These HIT suites are 5720 addressed by an index, which is transmitted in the OGA field of the 5721 ORCHID. 5723 The set of used HIT Suites will be extended to counter the progress 5724 in computation capabilities and vulnerabilities in the employed 5725 algorithms. The intended use of the HIT Suites is to introduce a new 5726 HIT Suite and phase out an old one before it becomes insecure. Since 5727 the 4-bit OGA field only permits 15 HIT Suites (the HIT Suite with ID 5728 0 is reserved) to be used in parallel, phased-out HIT Suites must be 5729 reused at some point. In such a case, there will be a rollover of 5730 the HIT Suite ID and the next newly introduced HIT Suite will start 5731 with a lower HIT Suite index than the previously introduced one. The 5732 rollover effectively deprecates the reused HIT Suite. For a smooth 5733 transition, the HIT Suite should be deprecated a considerable time 5734 before the HIT Suite index is reused. 5736 Since the number of HIT Suites is tightly limited to 16, the HIT 5737 Suites must be assigned carefully. Hence, sets of suitable 5738 algorithms are grouped in a HIT Suite. 5740 The HIT Suite of the Responder's HIT determines the RHASH and the 5741 hash function to be used for the HMAC in HIP packets as well as the 5742 signature algorithm family used for generating the HI. The list of 5743 HIT Suites is defined in Table 11. 5745 The following HIT Suites are defined for HIT generation. The input 5746 for each generation algorithm is the encoding of the HI as defined in 5747 Section 3.2. The output is 96 bits long and is directly used in the 5748 ORCHID. 5750 +-------+----------+--------------+------------+--------------------+ 5751 | Index | Hash | HMAC | Signature | Description | 5752 | | function | | algorithm | | 5753 | | | | family | | 5754 +-------+----------+--------------+------------+--------------------+ 5755 | 0 | | | | Reserved | 5756 | 1 | SHA-256 | HMAC-SHA-256 | RSA, DSA | RSA or DSA HI | 5757 | | | | | hashed with | 5758 | | | | | SHA-256, truncated | 5759 | | | | | to 96 bits | 5760 | 2 | SHA-384 | HMAC-SHA-384 | ECDSA | ECDSA HI hashed | 5761 | | | | | with SHA-384, | 5762 | | | | | truncated to 96 | 5763 | | | | | bits | 5764 | 3 | SHA-1 | HMAC-SHA-1 | ECDSA_LOW | ECDSA_LOW HI | 5765 | | | | | hashed with SHA-1, | 5766 | | | | | truncated to 96 | 5767 | | | | | bits | 5768 +-------+----------+--------------+------------+--------------------+ 5770 Table 11: HIT Suites 5772 The hash of the responder as defined in the HIT Suite determines the 5773 HMAC to be used for the HMAC parameter. The HMACs currently defined 5774 here are HMAC-SHA-256 [RFC4868], HMAC-SHA-384 [RFC4868], and HMAC- 5775 SHA-1 [RFC2404]. 5777 Authors' Addresses 5779 Robert Moskowitz (editor) 5780 Verizon Telcom and Business 5781 1000 Bent Creek Blvd, Suite 200 5782 Mechanicsburg, PA 5783 USA 5785 EMail: robert.moskowitz@verizonbusiness.com 5787 Tobias Heer 5788 Hirschmann Automation and Control 5789 Stuttgarter Strasse 45-51 5790 Neckartenzlingen 72654 5791 Germany 5793 EMail: tobias.heer@belden.com 5795 Petri Jokela 5796 Ericsson Research NomadicLab 5797 JORVAS FIN-02420 5798 FINLAND 5800 Phone: +358 9 299 1 5801 EMail: petri.jokela@nomadiclab.com 5803 Thomas R. Henderson 5804 University of Washington 5805 Campus Box 352500 5806 Seattle, WA 5807 USA 5809 EMail: tomhend@u.washington.edu