idnits 2.17.1 draft-ietf-hip-rfc5201-bis-16.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. -- 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 2722 has weird spacing: '...ication info...' == Line 2860 has weird spacing: '...ue data opaqu...' == Line 2890 has weird spacing: '...ue data opaqu...' == (2 more instances...) -- The document date (August 11, 2014) is 3544 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-08) exists of draft-ietf-hip-rfc4843-bis-04 == 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 (~~), 14 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: February 12, 2015 P. Jokela 7 Ericsson Research NomadicLab 8 T. Henderson 9 University of Washington 10 August 11, 2014 12 Host Identity Protocol Version 2 (HIPv2) 13 draft-ietf-hip-rfc5201-bis-16 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 February 12, 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) . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . . 57 122 5.2.14. HIP_SIGNATURE . . . . . . . . . . . . . . . . . . . . 58 123 5.2.15. HIP_SIGNATURE_2 . . . . . . . . . . . . . . . . . . . 59 124 5.2.16. SEQ . . . . . . . . . . . . . . . . . . . . . . . . . 59 125 5.2.17. ACK . . . . . . . . . . . . . . . . . . . . . . . . . 60 126 5.2.18. ENCRYPTED . . . . . . . . . . . . . . . . . . . . . . 60 127 5.2.19. NOTIFICATION . . . . . . . . . . . . . . . . . . . . 62 128 5.2.20. ECHO_REQUEST_SIGNED . . . . . . . . . . . . . . . . . 65 129 5.2.21. ECHO_REQUEST_UNSIGNED . . . . . . . . . . . . . . . . 66 130 5.2.22. ECHO_RESPONSE_SIGNED . . . . . . . . . . . . . . . . 66 131 5.2.23. ECHO_RESPONSE_UNSIGNED . . . . . . . . . . . . . . . 67 132 5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 68 133 5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 69 134 5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 69 135 5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 72 136 5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 74 137 5.3.5. UPDATE - the HIP Update Packet . . . . . . . . . . . 74 138 5.3.6. NOTIFY - the HIP Notify Packet . . . . . . . . . . . 75 139 5.3.7. CLOSE - the HIP Association Closing Packet . . . . . 76 140 5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet . . 76 141 5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 77 142 5.4.1. Invalid Version . . . . . . . . . . . . . . . . . . . 77 143 5.4.2. Other Problems with the HIP Header and Packet 144 Structure . . . . . . . . . . . . . . . . . . . . . . 77 146 5.4.3. Invalid Puzzle Solution . . . . . . . . . . . . . . . 77 147 5.4.4. Non-Existing HIP Association . . . . . . . . . . . . 78 148 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 78 149 6.1. Processing Outgoing Application Data . . . . . . . . . . 78 150 6.2. Processing Incoming Application Data . . . . . . . . . . 79 151 6.3. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 80 152 6.4. HIP_MAC and SIGNATURE Calculation and Verification . . . 82 153 6.4.1. HMAC Calculation . . . . . . . . . . . . . . . . . . 82 154 6.4.2. Signature Calculation . . . . . . . . . . . . . . . . 84 155 6.5. HIP KEYMAT Generation . . . . . . . . . . . . . . . . . . 86 156 6.6. Initiation of a HIP Base Exchange . . . . . . . . . . . . 88 157 6.6.1. Sending Multiple I1 Packets in Parallel . . . . . . . 89 158 6.6.2. Processing Incoming ICMP Protocol Unreachable 159 Messages . . . . . . . . . . . . . . . . . . . . . . 89 160 6.7. Processing Incoming I1 Packets . . . . . . . . . . . . . 90 161 6.7.1. R1 Management . . . . . . . . . . . . . . . . . . . . 91 162 6.7.2. Handling Malformed Messages . . . . . . . . . . . . . 91 163 6.8. Processing Incoming R1 Packets . . . . . . . . . . . . . 92 164 6.8.1. Handling of Malformed Messages . . . . . . . . . . . 94 165 6.9. Processing Incoming I2 Packets . . . . . . . . . . . . . 94 166 6.9.1. Handling of Malformed Messages . . . . . . . . . . . 97 167 6.10. Processing of Incoming R2 Packets . . . . . . . . . . . . 98 168 6.11. Sending UPDATE Packets . . . . . . . . . . . . . . . . . 98 169 6.12. Receiving UPDATE Packets . . . . . . . . . . . . . . . . 99 170 6.12.1. Handling a SEQ Parameter in a Received UPDATE 171 Message . . . . . . . . . . . . . . . . . . . . . . 100 172 6.12.2. Handling an ACK Parameter in a Received UPDATE 173 Packet . . . . . . . . . . . . . . . . . . . . . . . 101 174 6.13. Processing of NOTIFY Packets . . . . . . . . . . . . . . 101 175 6.14. Processing CLOSE Packets . . . . . . . . . . . . . . . . 102 176 6.15. Processing CLOSE_ACK Packets . . . . . . . . . . . . . . 102 177 6.16. Handling State Loss . . . . . . . . . . . . . . . . . . . 102 178 7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 103 179 8. Security Considerations . . . . . . . . . . . . . . . . . . . 103 180 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 106 181 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 110 182 11. Changes from RFC 5201 . . . . . . . . . . . . . . . . . . . . 111 183 11.1. Changes from draft-ietf-hip-rfc5201-bis-15 . . . . . . . 111 184 11.2. Changes from draft-ietf-hip-rfc5201-bis-14 . . . . . . . 111 185 11.3. Changes from draft-ietf-hip-rfc5201-bis-13 . . . . . . . 111 186 11.4. Changes from draft-ietf-hip-rfc5201-bis-12 . . . . . . . 111 187 11.5. Changes from draft-ietf-hip-rfc5201-bis-11 . . . . . . . 111 188 11.6. Changes from draft-ietf-hip-rfc5201-bis-10 . . . . . . . 112 189 11.7. Changes from draft-ietf-hip-rfc5201-bis-09 . . . . . . . 112 190 11.8. Changes from draft-ietf-hip-rfc5201-bis-08 . . . . . . . 112 191 11.9. Changes from draft-ietf-hip-rfc5201-bis-07 . . . . . . . 112 192 11.10. Changes from draft-ietf-hip-rfc5201-bis-06 . . . . . . . 112 193 11.11. Changes from draft-ietf-hip-rfc5201-bis-05 . . . . . . . 112 194 11.12. Changes from draft-ietf-hip-rfc5201-bis-04 . . . . . . . 113 195 11.13. Changes from draft-ietf-hip-rfc5201-bis-03 . . . . . . . 114 196 11.14. Changes from draft-ietf-hip-rfc5201-bis-02 . . . . . . . 115 197 11.15. Changes from draft-ietf-hip-rfc5201-bis-01 . . . . . . . 115 198 11.16. Changes from draft-ietf-hip-rfc5201-bis-00 . . . . . . . 117 199 11.17. Contents of draft-ietf-hip-rfc5201-bis-00 . . . . . . . 117 200 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 117 201 12.1. Normative References . . . . . . . . . . . . . . . . . . 118 202 12.2. Informative References . . . . . . . . . . . . . . . . . 119 203 Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 123 204 Appendix B. Generating a Public Key Encoding from an HI . . 124 205 Appendix C. Example Checksums for HIP Packets . . . . . . . . . 124 206 C.1. IPv6 HIP Example (I1 packet) . . . . . . . . . . . . . . 125 207 C.2. IPv4 HIP Packet (I1 packet) . . . . . . . . . . . . . . . 125 208 C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . . 126 209 Appendix D. ECDH and ECDSA 160 Bit Groups . . . . . . . . . . . 126 210 Appendix E. HIT Suites and HIT Generation . . . . . . . . . . . 126 212 1. Introduction 214 This document specifies the details of the Host Identity Protocol 215 (HIP). A high-level description of the protocol and the underlying 216 architectural thinking is available in the separate HIP architecture 217 description [I-D.ietf-hip-rfc4423-bis]. Briefly, the HIP 218 architecture proposes an alternative to the dual use of IP addresses 219 as "locators" (routing labels) and "identifiers" (endpoint, or host, 220 identifiers). In HIP, public cryptographic keys, of a public/private 221 key pair, are used as Host Identifiers, to which higher layer 222 protocols are bound instead of an IP address. By using public keys 223 (and their representations) as host identifiers, dynamic changes to 224 IP address sets can be directly authenticated between hosts, and if 225 desired, strong authentication between hosts at the TCP/IP stack 226 level can be obtained. 228 This memo specifies the base HIP protocol ("base exchange") used 229 between hosts to establish an IP-layer communications context, called 230 a HIP association, prior to communications. It also defines a packet 231 format and procedures for updating and terminating an active HIP 232 association. Other elements of the HIP architecture are specified in 233 other documents, such as: 235 o "Using the Encapsulating Security Payload (ESP) transport format 236 with the Host Identity Protocol (HIP)" [I-D.ietf-hip-rfc5202-bis]: 237 how to use the Encapsulating Security Payload (ESP) for integrity 238 protection and optional encryption 240 o "Host Mobility with the Host Identity Protocol" 241 [I-D.ietf-hip-rfc5206-bis]: how to support host mobility in HIP 243 o "Host Identity Protocol (HIP) Domain Name System (DNS) Extensions" 244 [I-D.ietf-hip-rfc5205-bis]: how to extend DNS to contain Host 245 Identity information 247 o "Host Identity Protocol (HIP) Rendezvous Extension" 248 [I-D.ietf-hip-rfc5204-bis]: using a rendezvous mechanism to 249 contact mobile HIP hosts 251 Since the HIP base exchange was first developed, there have been a 252 few advances in cryptography and attacks against cryptographic 253 systems. As a result, all cryptographic protocols need to be agile. 254 That is, it should be a part of the protocol to be able to switch 255 from one cryptographic primitive to another. It is important to 256 support a reasonable set of mainstream algorithms to cater for 257 different use cases and allow moving away from algorithms that are 258 later discovered to be vulnerable. This update to the base exchange 259 includes this needed cryptographic agility while addressing the 260 downgrade attacks that such flexibility introduces. In particular, 261 Elliptic Curve support by Elliptic Curve DSA (ECDSA) and Elliptic 262 Curve Diffie-Hellman (ECDH) and alternative hash functions have been 263 added. 265 1.1. A New Namespace and Identifiers 267 The Host Identity Protocol introduces a new namespace, the Host 268 Identity namespace. Some ramifications of this new namespace are 269 explained in the HIP architecture description 270 [I-D.ietf-hip-rfc4423-bis]. 272 There are two main representations of the Host Identity, the full 273 Host Identity (HI) and the Host Identity Tag (HIT). The HI is a 274 public key and directly represents the Identity of a host. Since 275 there are different public key algorithms that can be used with 276 different key lengths, the HI, as such, is unsuitable for use as a 277 packet identifier, or as an index into the various state-related 278 implementation structures needed to support HIP. Consequently, a 279 hash of the HI, the Host Identity Tag (HIT), is used as the 280 operational representation. The HIT is 128 bits long and is used in 281 the HIP headers and to index the corresponding state in the end 282 hosts. The HIT has an important security property in that it is 283 self-certifying (see Section 3). 285 1.2. The HIP Base Exchange (BEX) 287 The HIP base exchange is a two-party cryptographic protocol used to 288 establish communications context between hosts. The base exchange is 289 a SIGMA-compliant [KRA03] four-packet exchange. The first party is 290 called the Initiator and the second party the Responder. The 291 protocol exchanges Diffie-Hellman [DIF76] keys in the 2nd and 3rd 292 packets, and authenticates the parties in the 3rd and 4th packets. 293 The four-packet design helps to make HIP DoS resilient. It allows 294 the Responder to stay stateless until the IP address and the 295 cryptographic puzzle is verified. The Responder starts the puzzle 296 exchange in the 2nd packet, with the Initiator completing it in the 297 3rd packet before the Responder stores any state from the exchange. 299 The exchange can use the Diffie-Hellman output to encrypt the Host 300 Identity of the Initiator in the 3rd packet (although Aura, et al., 301 [AUR03] notes that such operation may interfere with packet- 302 inspecting middleboxes), or the Host Identity may instead be sent 303 unencrypted. The Responder's Host Identity is not protected. It 304 should be noted, however, that both the Initiator's and the 305 Responder's HITs are transported as such (in cleartext) in the 306 packets, allowing an eavesdropper with a priori knowledge about the 307 parties to identify them by their HITs. Hence, encrypting the HI of 308 any party does not provide privacy against such attacker. 310 Data packets start to flow after the 4th packet. The 3rd and 4th HIP 311 packets may carry a data payload in the future. However, the details 312 of this may be defined later. 314 An existing HIP association can be updated using the update mechanism 315 defined in this document, and when the association is no longer 316 needed, it can be closed using the defined closing mechanism. 318 Finally, HIP is designed as an end-to-end authentication and key 319 establishment protocol, to be used with Encapsulated Security Payload 320 (ESP) [I-D.ietf-hip-rfc5202-bis] and other end-to-end security 321 protocols. The base protocol does not cover all the fine-grained 322 policy control found in Internet Key Exchange (IKE) [RFC5996] that 323 allows IKE to support complex gateway policies. Thus, HIP is not a 324 complete replacement for IKE. 326 1.3. Memo Structure 328 The rest of this memo is structured as follows. Section 2 defines 329 the central keywords, notation, and terms used throughout the rest of 330 the document. Section 3 defines the structure of the Host Identity 331 and its various representations. Section 4 gives an overview of the 332 HIP base exchange protocol. Sections 5 and 6 define the detailed 333 packet formats and rules for packet processing. Finally, Sections 7, 334 8, and 9 discuss policy, security, and IANA considerations, 335 respectively. 337 2. Terms and Definitions 339 2.1. Requirements Terminology 341 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 342 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 343 document are to be interpreted as described in RFC 2119 [RFC2119]. 345 2.2. Notation 347 [x] indicates that x is optional. 349 {x} indicates that x is encrypted. 351 X(y) indicates that y is a parameter of X. 353 i indicates that x exists i times. 355 --> signifies "Initiator to Responder" communication (requests). 357 <-- signifies "Responder to Initiator" communication (replies). 359 | signifies concatenation of information (e.g., X | Y is the 360 concatenation of X with Y). 362 Ltrunc (H(x), K) denotes the lowest order #K bits of the result of 363 the hash function H on the input x. 365 2.3. Definitions 367 HIP base exchange (BEX): the handshake for establishing a new HIP 368 association. 370 Host Identity (HI): The public key of the signature algorithm that 371 represents the identity of the host. In HIP, a host proves its 372 identity by creating a signature with the private key belonging to 373 its HI (c.f. Section 3). 375 Host Identity Tag (HIT): A shorthand for the HI in IPv6 format. It 376 is generated by hashing the HI (c.f. Section 3.1). 378 HIT Suite: A HIT Suite groups all cryptographic algorithms that are 379 required to generate and use an HI and its HIT. In particular, 380 these algorithms are: 1) the public key signature algorithm and 2) 381 the hash function, 3) the truncation (c.f. Appendix E). 383 HIP association: The shared state between two peers after 384 completion of the BEX. 386 HIP packet: A control packet carrying a HIP packet header relating 387 to the establishment, maintenance, or termination of the HIP 388 association. 390 Initiator: The host that initiates the BEX. This role is typically 391 forgotten once the BEX is completed. 393 Responder: The host that responds to the Initiator in the BEX. 394 This role is typically forgotten once the BEX is completed. 396 Responder's HIT Hash Algorithm (RHASH): The Hash algorithm used for 397 various hash calculations in this document. The algorithm is the 398 same as is used to generate the Responder's HIT. The RHASH is the 399 hash function defined by the HIT Suite of the Responder's HIT 400 (c.f. Appendix E). 402 Length of the Responder's HIT Hash Algorithm (RHASH_len): The 403 natural output length of RHASH in bits. 405 Signed data: Data that is signed is protected by a digital 406 signature that was created by the sender of the data by using the 407 private key of its HI. 409 KDF: The Key Derivation Function (KDF) is used for deriving the 410 symmetric keys from the Diffie-Hellman key exchange. 412 KEYMAT: The keying material derived from the Diffie-Hellman key 413 exchange by using the KDF. Symmetric keys for encryption and 414 integrity protection of HIP packets and encrypted user data 415 packets are drawn from this keying material. 417 3. Host Identity (HI) and its Structure 419 In this section, the properties of the Host Identity and Host 420 Identity Tag are discussed, and the exact format for them is defined. 421 In HIP, the public key of an asymmetric key pair is used as the Host 422 Identity (HI). Correspondingly, the host itself is defined as the 423 entity that holds the private key of the key pair. See the HIP 424 architecture specification [I-D.ietf-hip-rfc4423-bis] for more 425 details on the difference between an identity and the corresponding 426 identifier. 428 HIP implementations MUST support the Rivest Shamir Adelman (RSA) 429 [RFC3110] public key algorithm and the Elliptic Curve Digital 430 Signature Algorithm (ECDSA) for generating the HI as defined in 431 Section 5.2.9. Additional algorithms MAY be supported. 433 A hashed encoding of the HI, the Host Identity Tag (HIT), is used in 434 protocols to represent the Host Identity. The HIT is 128 bits long 435 and has the following three key properties: i) it is the same length 436 as an IPv6 address and can be used in fixed address-sized fields in 437 APIs and protocols, ii) it is self-certifying (i.e., given a HIT, it 438 is computationally hard to find a Host Identity key that matches the 439 HIT), and iii) the probability of a HIT collision between two hosts 440 is very low, hence, it is infeasible for an attacker to find a 441 collision with a HIT that is in use. For details on the security 442 properties of the HIT see [I-D.ietf-hip-rfc4423-bis]. 444 The structure of the HIT is defined in [I-D.ietf-hip-rfc4843-bis]. 445 The HIT is an Overlay Routable Cryptographic Hash Identifier (ORCHID) 446 and consists of three parts: first, an IANA assigned prefix to 447 distinguish it from other IPv6 addresses. Second, a four-bit 448 encoding of the algorithms that were used for generating the HI and 449 the hashed representation of HI. Third, a 96-bit hashed 450 representation of the Host Identity. The encoding of the ORCHID 451 generation algorithm and the exact algorithm for generating the 452 hashed representation is specified in Appendix E. 454 Carrying HIs and HITs in the header of user data packets would 455 increase the overhead of packets. Thus, it is not expected that they 456 are carried in every packet, but other methods are used to map the 457 data packets to the corresponding HIs. In some cases, this makes it 458 possible to use HIP without any additional headers in the user data 459 packets. For example, if ESP is used to protect data traffic, the 460 Security Parameter Index (SPI) carried in the ESP header can be used 461 to map the encrypted data packet to the correct HIP association. 463 3.1. Host Identity Tag (HIT) 465 The Host Identity Tag is a 128-bit value -- a hashed encoding of the 466 Host Identifier. There are two advantages of using a hashed encoding 467 over the actual variable-sized Host Identity public key in protocols. 468 First, the fixed length of the HIT keeps packet sizes manageable and 469 eases protocol coding. Second, it presents a consistent format for 470 the protocol, independent of the underlying identity technology in 471 use. 473 RFC 4843-bis [I-D.ietf-hip-rfc4843-bis] specifies 128-bit hash-based 474 identifiers, called Overlay Routable Cryptographic Hash Identifiers, 475 ORCHIDs. Their prefix, allocated from the IPv6 address block, is 476 defined in [I-D.ietf-hip-rfc4843-bis]. The Host Identity Tag is one 477 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 [I-D.ietf-hip-rfc4843-bis] using a context ID value of 494 0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA (this tag value has been 495 generated randomly by the editor of this specification), and an input 496 that encodes the Host Identity field (see Section 5.2.9) present in a 497 HIP payload packet. The set of hash function, signature algorithm, 498 and the algorithm used for generating the HIT from the HI depends on 499 the HIT Suite (see Appendix E) and is indicated by the four bits of 500 the ORCHID Generation Algorithm (OGA) field in the ORCHID. 501 Currently, 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 stay at CLOSING | 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 2213 The MODP Diffie-Hellman groups are defined in [RFC3526]. The ECDH 2214 groups 7 - 9 are defined in [RFC5903] and [RFC6090]. ECDH group 10 2215 is covered in Appendix D. Any ECDH used with HIP MUST have a co- 2216 factor of 1. 2218 The Group ID also defines the key derivation function that is to be 2219 used for deriving the symmetric keys for the HMAC and symmetric 2220 encryption from the keying material from the Diffie Hellman key 2221 exchange (see Section 6.5). 2223 A HIP implementation MUST implement Group ID 3. The 160-bit 2224 SECP160R1 group can be used when lower security is enough (e.g., web 2225 surfing) and when the equipment is not powerful enough (e.g., some 2226 PDAs). Implementations SHOULD implement Group IDs 4 and 8. 2228 To avoid unnecessary failures during the base exchange, the rest of 2229 the groups SHOULD be implemented in hosts where resources are 2230 adequate. 2232 5.2.8. HIP_CIPHER 2234 0 1 2 3 2235 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 2236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2237 | Type | Length | 2238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2239 | Cipher ID #1 | Cipher ID #2 | 2240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2241 | Cipher ID #n | Padding | 2242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2244 Type 579 2245 Length length in octets, excluding Type, Length, and 2246 Padding 2247 Cipher ID identifies the cipher algorithm to be used for 2248 encrypting the contents of the ENCRYPTED parameter 2250 The following Cipher IDs are defined: 2252 Suite ID Value 2254 RESERVED 0 2255 NULL-ENCRYPT 1 ([RFC2410]) 2256 AES-128-CBC 2 ([RFC3602]) 2257 DEPRECATED 3 2258 AES-256-CBC 4 ([RFC3602]) 2260 The sender of a HIP_CIPHER parameter MUST make sure that there are no 2261 more than six (6) Cipher IDs in one HIP_CIPHER parameter. 2262 Conversely, a recipient MUST be prepared to handle received transport 2263 parameters that contain more than six Cipher IDs by accepting the 2264 first six Cipher IDs and dropping the rest. The limited number of 2265 Cipher IDs sets the maximum size of the HIP_CIPHER parameter. As the 2266 default configuration, the HIP_CIPHER parameter MUST contain at least 2267 one of the mandatory Cipher IDs. There MAY be a configuration option 2268 that allows the administrator to override this default. 2270 The Responder lists supported and desired Cipher IDs in order of 2271 preference in the R1, up to the maximum of six Cipher IDs. The 2272 Initiator MUST choose only one of the corresponding Cipher IDs. This 2273 Cipher ID will be used for generating the ENCRYPTED parameter. 2275 Mandatory implementation: AES-128-CBC. NULL-ENCRYPTION [RFC2410] is 2276 included for testing purposes. 2278 5.2.9. HOST_ID 2280 0 1 2 3 2281 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 2282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2283 | Type | Length | 2284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2285 | HI Length |DI-type| DI Length | 2286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2287 | Algorithm | Host Identity / 2288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2289 / | Domain Identifier / 2290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2291 / | Padding | 2292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2294 Type 705 2295 Length length in octets, excluding Type, Length, and 2296 Padding 2297 HI Length length of the Host Identity in octets 2298 DI-type type of the following Domain Identifier field 2299 DI Length length of the Domain Identifier field in octets 2300 Algorithm index to the employed algorithm 2301 Host Identity actual Host Identity 2302 Domain Identifier the identifier of the sender 2304 The following DI-types have been defined: 2306 Type Value 2307 none included 0 2308 FQDN 1 2309 NAI 2 2311 FQDN Fully Qualified Domain Name, in binary format. 2312 NAI Network Access Identifier 2314 The format for the FQDN is defined in RFC 1035 [RFC1035] Section 3.1. 2315 The format for the NAI is defined in [RFC4282] 2316 A host MAY optionally associate the Host Identity with a single 2317 Domain Identifier in the HOST_ID parameter. If there is no Domain 2318 Identifier, i.e., the DI-type field is zero, the DI Length field is 2319 set to zero as well. 2321 The following HI Algorithms have been defined: 2323 Algorithm 2324 profiles Values 2326 RESERVED 0 2327 DSA 3 [FIPS186-3] (RECOMMENDED) 2328 RSA 5 [RFC3447] (REQUIRED) 2329 ECDSA 7 [RFC4754] (REQUIRED) 2330 ECDSA_LOW 9 [SECG] (RECOMMENDED) 2332 For DSA, RSA, and ECDSA key types, profiles containing at least 112 2333 bits of security strength (as defined by [NIST.800-131A.2011]) should 2334 be used. For RSA signature padding, the PSS method of padding 2335 [RFC3447] MUST be used. 2337 The Host Identity is derived from the DNSKEY format for RSA and DSA. 2338 For these, the Public Key field of the RDATA part from RFC 4034 2339 [RFC4034] is used. For ECC we distinguish two different profiles: 2340 ECDSA and ECDSA_LOW. ECC contains curves approved by NIST and 2341 defined in RFC 4754 [RFC4754]. ECDSA_LOW is defined for devices with 2342 low computational capabilities and uses shorter curves from SECG 2343 [SECG]. Any ECDSA used with HIP MUST have a co-factor of 1. 2345 For ECDSA and ECDSA_LOW Host Identities are represented by the 2346 following fields: 2348 0 1 2 3 2349 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 2350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2351 | ECC Curve | / 2352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2353 / Public Key | 2354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2356 ECC Curve Curve label 2357 Public Key Represented in Octet-string format 2358 [RFC6090] 2360 For hosts that implement ECDSA as algorithm the following ECC curves 2361 are required: 2363 Algorithm Curve Values 2365 ECDSA RESERVED 0 2366 ECDSA NIST P-256 1 [RFC4754] 2367 ECDSA NIST P-384 2 [RFC4754] 2369 For hosts that implement the ECDSA_LOW algorithm profile, the 2370 following curve is required: 2372 Algorithm Curve Values 2374 ECDSA_LOW RESERVED 0 2375 ECDSA_LOW SECP160R1 1 [SECG] 2377 5.2.10. HIT_SUITE_LIST 2379 The HIT_SUITE_LIST parameter contains a list of the supported HIT 2380 Suite IDs of the Responder. The Responder sends the HIT_SUITE_LIST 2381 in the signed part of the R1 packet. Based on the HIT_SUITE_LIST, 2382 the Initiator can determine which source HIT Suite IDs are supported 2383 by the Responder. 2385 0 1 2 3 2386 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 2387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2388 | Type | Length | 2389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2390 | ID #1 | ID #2 | ID #3 | ID #4 | 2391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2392 | ID #n | Padding | 2393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2395 Type 715 2396 Length number of HIT Suite IDs 2397 ID identifies a HIT Suite ID supported by the host. 2398 The list of IDs is ordered by preference of the 2399 host. Each HIT Suite ID is one octet long. The four 2400 higher-order bits of the ID field correspond to the 2401 HIT Suite ID in the ORCHID OGA field. The four 2402 lower-order bits are reserved and set to 0 and 2403 ignored by the receiver. 2405 The HIT Suite ID indexes a HIT Suite. HIT Suites are composed of 2406 signature algorithms as defined in Section 5.2.9 and hash functions. 2408 The ID field in the HIT_SUITE_LIST is defined as eight-bit field as 2409 opposed to the four-bit HIT Suite ID and OGA field in the ORCHID. 2410 This difference is a measure to accommodate larger HIT Suite IDs if 2411 the 16 available values prove insufficient. In that case, one of the 2412 16 values, zero, will be used to indicate that four additional bits 2413 of the ORCHID will be used to encode the HIT Suite ID. Hence, the 2414 current four-bit HIT Suite-IDs only use the four higher order bits in 2415 the ID field. Future documents may define the use of the four lower- 2416 order bits in the ID field. 2418 The following HIT Suites ID are defined: 2420 HIT Suite ID 2421 RESERVED 0 2422 RSA,DSA/SHA-256 1 (REQUIRED) 2423 ECDSA/SHA-384 2 (RECOMMENDED) 2424 ECDSA_LOW/SHA-1 3 (RECOMMENDED) 2426 5.2.11. TRANSPORT_FORMAT_LIST 2428 The TRANSPORT_FORMAT_LIST parameter contains a list of the supported 2429 HIP transport formats (TFs) of the Responder. The Responder sends 2430 the TRANSPORT_FORMAT_LIST in the signed part of the R1 packet. Based 2431 on the TRANSPORT_FORMAT_LIST, the Initiator chooses one suitable 2432 transport format and includes the respective HIP transport format 2433 parameter in its response packet. 2435 0 1 2 3 2436 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 2437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2438 | Type | Length | 2439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2440 | TF type #1 | TF type #2 / 2441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2442 / TF type #n | Padding | 2443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2445 Type 2049 2446 Length 2x number of TF types 2447 TF Type identifies a transport format (TF) type supported by 2448 the host. The TF type numbers correspond to the HIP 2449 parameter type numbers of the respective transport 2450 format 2451 parameters. The list of TF types is ordered by 2452 preference of the sender 2454 The TF type numbers index the respective HIP parameters for the 2455 transport formats in the type number range between 2050 to 4095. The 2456 parameters and their use are defined in separate documents. 2457 Currently, the only transport format defined is IPsec ESP 2458 [I-D.ietf-hip-rfc5202-bis]. 2460 For each listed TF type, the sender of the TRANSPORT_FORMAT_LIST 2461 parameter MUST include the respective transport format parameter in 2462 the HIP packet. The receiver MUST ignore the TF type in the 2463 TRANSPORT_FORMAT_LIST if no matching transport format parameter is 2464 present in the packet. 2466 5.2.12. HIP_MAC 2468 0 1 2 3 2469 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 2470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2471 | Type | Length | 2472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2473 | | 2474 | HMAC | 2475 / / 2476 / +-------------------------------+ 2477 | | Padding | 2478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2480 Type 61505 2481 Length length in octets, excluding Type, Length, and 2482 Padding 2483 HMAC HMAC computed over the HIP packet, excluding the 2484 HIP_MAC parameter and any following parameters, such 2485 as HIP_SIGNATURE, HIP_SIGNATURE_2, 2486 ECHO_REQUEST_UNSIGNED, or ECHO_RESPONSE_UNSIGNED. 2487 The checksum field MUST be set to zero and the HIP 2488 header length in the HIP common header MUST be 2489 calculated not to cover any excluded parameters 2490 when the HMAC is calculated. The size of the 2491 HMAC is the natural size of the hash computation 2492 output depending on the used hash function. 2494 The HMAC uses RHASH as hash algorithm. The calculation and 2495 verification process is presented in Section 6.4.1. 2497 5.2.13. HIP_MAC_2 2499 The HIP_MAC_2 is a MAC of the packet and the HI of the sender in the 2500 form of a HOST_ID parameter when that parameter is not actually 2501 included in the packet. The parameter structure is the same as in 2502 Section 5.2.12. The fields are: 2504 Type 61569 2505 Length length in octets, excluding Type, Length, and 2506 Padding 2507 HMAC HMAC computed over the HIP packet, excluding the 2508 HIP_MAC_2 parameter and any following parameters 2509 such as HIP_SIGNATURE, HIP_SIGNATURE_2, 2510 ECHO_REQUEST_UNSIGNED, or ECHO_RESPONSE_UNSIGNED, 2511 and including an additional sender's HOST_ID 2512 parameter during the HMAC calculation. The checksum 2513 field MUST be set to zero and the HIP header length 2514 in the HIP common header MUST be calculated not to 2515 cover any excluded parameters when the HMAC is 2516 calculated. The size of the HMAC is the natural 2517 size of the hash computation output depending on the 2518 used hash function. 2520 The HMAC uses RHASH as hash algorithm. The calculation and 2521 verification process is presented in Section 6.4.1. 2523 5.2.14. HIP_SIGNATURE 2525 0 1 2 3 2526 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 2527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2528 | Type | Length | 2529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2530 | SIG alg | Signature / 2531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2532 / | Padding | 2533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2535 Type 61697 2536 Length length in octets, excluding Type, Length, and 2537 Padding 2538 SIG alg signature algorithm 2539 Signature the signature is calculated over the HIP packet, 2540 excluding the HIP_SIGNATURE parameter and any 2541 parameters that follow the HIP_SIGNATURE parameter. 2542 When the signature is calculated the checksum field 2543 MUST be set to zero, and the HIP header length in 2544 the HIP common header MUST be calculated only up to 2545 the beginning of the HIP_SIGNATURE parameter. 2547 The signature algorithms are defined in Section 5.2.9. The signature 2548 in the Signature field is encoded using the method depending on the 2549 signature algorithm (e.g., according to [RFC3110] in case of RSA/SHA- 2550 1, according to [RFC5702] in case of RSA/SHA-256, according to 2552 [RFC2536] in case of DSA, or according to [RFC6090] in case of 2553 ECDSA). 2555 The HIP_SIGNATURE calculation and verification process are presented 2556 in Section 6.4.2. 2558 5.2.15. HIP_SIGNATURE_2 2560 The HIP_SIGNATURE_2 excludes the variable parameters in the R1 packet 2561 to allow R1 pre-creation. The parameter structure is the same as in 2562 Section 5.2.14. The fields are: 2564 Type 61633 2565 Length length in octets, excluding Type, Length, and 2566 Padding 2567 SIG alg signature algorithm 2568 Signature Within the R1 packet that contains the 2569 HIP_SIGNATURE_2 parameter, the Initiator's HIT, the 2570 checksum field, and the Opaque and Random #I fields 2571 in the PUZZLE parameter MUST be set to zero while 2572 computing the HIP_SIGNATURE_2 signature. Further, 2573 the HIP packet length in the HIP header MUST be 2574 adjusted as if the HIP_SIGNATURE_2 was not in the 2575 packet during the signature calculation, i.e., the 2576 HIP packet length points to the beginning of 2577 the HIP_SIGNATURE_2 parameter during signing and 2578 verification. 2580 Zeroing the Initiator's HIT makes it possible to create R1 packets 2581 beforehand, to minimize the effects of possible DoS attacks. Zeroing 2582 the Random #I and Opaque fields within the PUZZLE parameter allows 2583 these fields to be populated dynamically on precomputed R1s. 2585 Signature calculation and verification follows the process defined in 2586 Section 6.4.2. 2588 5.2.16. SEQ 2590 0 1 2 3 2591 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 2592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2593 | Type | Length | 2594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2595 | Update ID | 2596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2597 Type 385 2598 Length 8 2599 Update ID 32-bit sequence number 2601 The Update ID is an unsigned number in network byte order, 2602 initialized by a host to zero upon moving to ESTABLISHED state. The 2603 Update ID has scope within a single HIP association, and not across 2604 multiple associations or multiple hosts. The Update ID is 2605 incremented by one before each new UPDATE that is sent by the host; 2606 the first UPDATE packet originated by a host has an Update ID of 0. 2608 5.2.17. ACK 2610 0 1 2 3 2611 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 2612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2613 | Type | Length | 2614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2615 | peer Update ID 1 | 2616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2617 / peer Update ID n | 2618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2620 Type 449 2621 Length length in octets, excluding Type and Length 2622 peer Update ID 32-bit sequence number corresponding to the 2623 Update ID being ACKed. 2625 The ACK parameter includes one or more Update IDs that have been 2626 received from the peer. The number of peer Update IDs can be 2627 inferred from the length by dividing it by 4. 2629 5.2.18. ENCRYPTED 2630 0 1 2 3 2631 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 2632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2633 | Type | Length | 2634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2635 | Reserved | 2636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2637 | IV / 2638 / / 2639 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 2641 / Encrypted data / 2642 / / 2643 / +-------------------------------+ 2644 / | Padding | 2645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2647 Type 641 2648 Length length in octets, excluding Type, Length, and 2649 Padding 2650 Reserved zero when sent, ignored when received 2651 IV Initialization vector, if needed, otherwise 2652 nonexistent. The length of the IV is inferred from 2653 the HIP_CIPHER. 2654 Encrypted The data is encrypted using the encryption algorithm 2655 data defined in the HIP_CIPHER parameter. 2657 The ENCRYPTED parameter encapsulates other parameters, the encrypted 2658 data, which holds one or more HIP parameters in block encrypted form. 2660 Consequently, the first fields in the encapsulated parameter(s) are 2661 Type and Length of the first such parameter, allowing the contents to 2662 be easily parsed after decryption. 2664 The field labeled "Encrypted data" consists of the output of one or 2665 more HIP parameters concatenated together that have been passed 2666 through an encryption algorithm. Each of these inner parameters is 2667 padded according to the rules of Section 5.2.1 for padding individual 2668 parameters. As a result, the concatenated parameters will be a block 2669 of data that is 8-byte aligned. 2671 Some encryption algorithms require that the data to be encrypted must 2672 be a multiple of the cipher algorithm block size. In this case, the 2673 above block of data MUST include additional padding, as specified by 2674 the encryption algorithm. The size of the extra padding is selected 2675 so that the length of the unencrypted data block is a multiple of the 2676 cipher block size. The encryption algorithm may specify padding 2677 bytes other than zero; for example, AES [FIPS.197.2001] uses the 2678 PKCS5 padding scheme (see section 6.1.1 of [RFC2898]) where the 2679 remaining n bytes to fill the block each have the value of n. This 2680 yields an "unencrypted data" block that is transformed to an 2681 "encrypted data" block by the cipher suite. This extra padding added 2682 to the set of parameters to satisfy the cipher block alignment rules 2683 is not counted in HIP TLV length fields, and this extra padding 2684 should be removed by the cipher suite upon decryption. 2686 Note that the length of the cipher suite output may be smaller or 2687 larger than the length of the set of parameters to be encrypted, 2688 since the encryption process may compress the data or add additional 2689 padding to the data. 2691 Once this encryption process is completed, the Encrypted data field 2692 is ready for inclusion in the parameter. If necessary, additional 2693 Padding for 8-byte alignment is then added according to the rules of 2694 Section 5.2.1. 2696 5.2.19. NOTIFICATION 2698 The NOTIFICATION parameter is used to transmit informational data, 2699 such as error conditions and state transitions, to a HIP peer. A 2700 NOTIFICATION parameter may appear in NOTIFY packets. The use of the 2701 NOTIFICATION parameter in other packet types is for further study. 2703 0 1 2 3 2704 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 2705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2706 | Type | Length | 2707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2708 | Reserved | Notify Message Type | 2709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2710 | / 2711 / Notification Data / 2712 / +---------------+ 2713 / | Padding | 2714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2716 Type 832 2717 Length length in octets, excluding Type, Length, and 2718 Padding 2719 Reserved zero when sent, ignored when received 2720 Notify Message specifies the type of notification 2721 Type 2722 Notification informational or error data transmitted in addition 2723 Data to the Notify Message Type. Values for this field 2724 are type specific (see below). 2725 multiple of 8 bytes. 2727 Notification information can be error messages specifying why an HIP 2728 Security Association could not be established. It can also be status 2729 data that a HIP implementation wishes to communicate with a peer 2730 process. The table below lists the notification messages and their 2731 Notification Message Types. HIP packets MAY contain multiple 2732 NOTIFICATION parameters if several problems exist or several 2733 independent pieces of information must be transmitted. 2735 To avoid certain types of attacks, a Responder SHOULD avoid sending a 2736 NOTIFICATION to any host with which it has not successfully verified 2737 a puzzle solution. 2739 Notify Message Types in the range 0-16383 are intended for reporting 2740 errors and in the range 16384-65535 for other status information. An 2741 implementation that receives a NOTIFY packet with a Notify Message 2742 Type that indicates an error in response to a request packet (e.g., 2743 I1, I2, UPDATE) SHOULD assume that the corresponding request has 2744 failed entirely. Unrecognized error types MUST be ignored except 2745 that they SHOULD be logged. 2747 As currently defined, Notify Message Type values 1-10 are used for 2748 informing about errors in packet structures, values 11-20 for 2749 informing about problems in parameters. 2751 Notification Data in NOTIFICATION parameters where the Notify Message 2752 Type is in the status range MUST be ignored if not recognized. 2754 Notify Message Types - Errors Value 2755 ----------------------------- ----- 2757 UNSUPPORTED_CRITICAL_PARAMETER_TYPE 1 2759 Sent if the parameter type has the "critical" bit set and the 2760 parameter type is not recognized. Notification Data contains the 2761 two-octet parameter type. 2763 INVALID_SYNTAX 7 2765 Indicates that the HIP message received was invalid because some 2766 type, length, or value was out of range or because the request 2767 was otherwise malformed. To avoid a denial-of-service 2768 attack using forged messages, this status may only be returned 2769 for packets whose HIP_MAC (if present) and SIGNATURE have been 2770 verified. This status MUST be sent in response to any error not 2771 covered by one of the other status types, and SHOULD NOT contain 2772 details to avoid leaking information to someone probing a node. 2773 To aid debugging, more detailed error information SHOULD be 2774 written to a console or log. 2776 NO_DH_PROPOSAL_CHOSEN 14 2778 None of the proposed group IDs was acceptable. 2780 INVALID_DH_CHOSEN 15 2782 The DH Group ID field does not correspond to one offered 2783 by the Responder. 2785 NO_HIP_PROPOSAL_CHOSEN 16 2787 None of the proposed HIT Suites or HIP Encryption Algorithms was 2788 acceptable. 2790 INVALID_HIP_CIPHER_CHOSEN 17 2792 The HIP_CIPHER Crypto ID does not correspond to one offered by 2793 the Responder. 2795 UNSUPPORTED_HIT_SUITE 20 2797 Sent in response to an I1 or R1 packet for which the HIT suite 2798 is not supported. 2800 AUTHENTICATION_FAILED 24 2802 Sent in response to a HIP signature failure, except when 2803 the signature verification fails in a NOTIFY message. 2805 CHECKSUM_FAILED 26 2807 Sent in response to a HIP checksum failure. 2809 HIP_MAC_FAILED 28 2811 Sent in response to a HIP HMAC failure. 2813 ENCRYPTION_FAILED 32 2815 The Responder could not successfully decrypt the 2816 ENCRYPTED parameter. 2818 INVALID_HIT 40 2820 Sent in response to a failure to validate the peer's 2821 HIT from the corresponding HI. 2823 BLOCKED_BY_POLICY 42 2824 The Responder is unwilling to set up an association 2825 for some policy reason (e.g., received HIT is NULL 2826 and policy does not allow opportunistic mode). 2828 RESPONDER_BUSY_PLEASE_RETRY 44 2830 The Responder is unwilling to set up an association as it is 2831 suffering under some kind of overload and has chosen to shed load 2832 by rejecting the Initiator's request. The Initiator may retry; 2833 however, the Initiator MUST find another (different) puzzle 2834 solution for any such retries. Note that the Initiator may need 2835 to obtain a new puzzle with a new I1/R1 exchange. 2837 Notify Message Types - Status Value 2838 ----------------------------- ----- 2840 I2_ACKNOWLEDGEMENT 16384 2842 The Responder has an I2 packet from the Initiator but had to 2843 queue the I2 packet for processing. The puzzle was correctly 2844 solved and the Responder is willing to set up an association but 2845 currently has a number of I2 packets in the processing queue. 2846 The R2 packet is sent after the I2 packet was processed. 2848 5.2.20. ECHO_REQUEST_SIGNED 2850 0 1 2 3 2851 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 2852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2853 | Type | Length | 2854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2855 | Opaque data (variable length) | 2856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2858 Type 897 2859 Length length of the opaque data in octets 2860 Opaque data opaque data, supposed to be meaningful only to the 2861 node that sends ECHO_REQUEST_SIGNED and receives a 2862 corresponding ECHO_RESPONSE_SIGNED or 2863 ECHO_RESPONSE_UNSIGNED. 2865 The ECHO_REQUEST_SIGNED parameter contains an opaque blob of data 2866 that the sender wants to get echoed back in the corresponding reply 2867 packet. 2869 The ECHO_REQUEST_SIGNED and corresponding echo response parameters 2870 MAY be used for any purpose where a node wants to carry some state in 2871 a request packet and get it back in a response packet. The 2872 ECHO_REQUEST_SIGNED is covered by the HIP_MAC and SIGNATURE. A HIP 2873 packet can contain only one ECHO_REQUEST_SIGNED parameter and MAY 2874 contain multiple ECHO_REQUEST_UNSIGNED parameters. The 2875 ECHO_REQUEST_SIGNED parameter MUST be responded to with an 2876 ECHO_RESPONSE_SIGNED. 2878 5.2.21. ECHO_REQUEST_UNSIGNED 2880 0 1 2 3 2881 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 2882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2883 | Type | Length | 2884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2885 | Opaque data (variable length) | 2886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2888 Type 63661 2889 Length length of the opaque data in octets 2890 Opaque data opaque data, supposed to be meaningful only to the 2891 node that sends ECHO_REQUEST_UNSIGNED and receives a 2892 corresponding ECHO_RESPONSE_UNSIGNED. 2894 The ECHO_REQUEST_UNSIGNED parameter contains an opaque blob of data 2895 that the sender wants to get echoed back in the corresponding reply 2896 packet. 2898 The ECHO_REQUEST_UNSIGNED and corresponding echo response parameters 2899 MAY be used for any purpose where a node wants to carry some state in 2900 a request packet and get it back in a response packet. The 2901 ECHO_REQUEST_UNSIGNED is not covered by the HIP_MAC and SIGNATURE. A 2902 HIP packet can contain one or more ECHO_REQUEST_UNSIGNED parameters. 2903 It is possible that middleboxes add ECHO_REQUEST_UNSIGNED parameters 2904 in HIP packets passing by. The creator of the ECHO_REQUEST_UNSIGNED 2905 (end-host or middlebox) has to create the Opaque field so that it can 2906 later identify and remove the corresponding ECHO_RESPONSE_UNSIGNED 2907 parameter. 2909 The ECHO_REQUEST_UNSIGNED parameter MUST be responded to with an 2910 ECHO_RESPONSE_UNSIGNED parameter. 2912 5.2.22. ECHO_RESPONSE_SIGNED 2913 0 1 2 3 2914 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 2915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2916 | Type | Length | 2917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2918 | Opaque data (variable length) | 2919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2921 Type 961 2922 Length length of the opaque data in octets 2923 Opaque data opaque data, copied unmodified from the 2924 ECHO_REQUEST_SIGNED or ECHO_REQUEST_UNSIGNED 2925 parameter that triggered this response. 2927 The ECHO_RESPONSE_SIGNED parameter contains an opaque blob of data 2928 that the sender of the ECHO_REQUEST_SIGNED wants to get echoed back. 2929 The opaque data is copied unmodified from the ECHO_REQUEST_SIGNED 2930 parameter. 2932 The ECHO_REQUEST_SIGNED and ECHO_RESPONSE_SIGNED parameters MAY be 2933 used for any purpose where a node wants to carry some state in a 2934 request packet and get it back in a response packet. The 2935 ECHO_RESPONSE_SIGNED is covered by the HIP_MAC and SIGNATURE. 2937 5.2.23. ECHO_RESPONSE_UNSIGNED 2939 0 1 2 3 2940 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 2941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2942 | Type | Length | 2943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2944 | Opaque data (variable length) | 2945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2947 Type 63425 2948 Length length of the opaque data in octets 2949 Opaque data opaque data, copied unmodified from the 2950 ECHO_REQUEST_SIGNED or ECHO_REQUEST_UNSIGNED 2951 parameter that triggered this response. 2953 The ECHO_RESPONSE_UNSIGNED parameter contains an opaque blob of data 2954 that the sender of the ECHO_REQUEST_SIGNED or ECHO_REQUEST_UNSIGNED 2955 wants to get echoed back. The opaque data is copied unmodified from 2956 the corresponding echo request parameter. 2958 The echo request and ECHO_RESPONSE_UNSIGNED parameters MAY be used 2959 for any purpose where a node wants to carry some state in a request 2960 packet and get it back in a response packet. The 2961 ECHO_RESPONSE_UNSIGNED is not covered by the HIP_MAC and SIGNATURE. 2963 5.3. HIP Packets 2965 There are eight basic HIP packets (see Table 10). Four are for the 2966 HIP base exchange, one is for updating, one is for sending 2967 notifications, and two are for closing a HIP association. Support 2968 for NOTIFY packet type is optional, but support for all other HIP 2969 packet types listed below is mandatory. 2971 +------------------+------------------------------------------------+ 2972 | Packet type | Packet name | 2973 +------------------+------------------------------------------------+ 2974 | 1 | I1 - the HIP Initiator Packet | 2975 | | | 2976 | 2 | R1 - the HIP Responder Packet | 2977 | | | 2978 | 3 | I2 - the Second HIP Initiator Packet | 2979 | | | 2980 | 4 | R2 - the Second HIP Responder Packet | 2981 | | | 2982 | 16 | UPDATE - the HIP Update Packet | 2983 | | | 2984 | 17 | NOTIFY - the HIP Notify Packet | 2985 | | | 2986 | 18 | CLOSE - the HIP Association Closing Packet | 2987 | | | 2988 | 19 | CLOSE_ACK - the HIP Closing Acknowledgment | 2989 | | Packet | 2990 +------------------+------------------------------------------------+ 2992 Table 10: HIP packets and packet type values 2994 Packets consist of the fixed header as described in Section 5.1, 2995 followed by the parameters. The parameter part, in turn, consists of 2996 zero or more TLV-coded parameters. 2998 In addition to the base packets, other packet types may be defined 2999 later in separate specifications. For example, support for mobility 3000 and multi-homing is not included in this specification. 3002 See Notation (Section 2.2) for the notation used in the operations. 3004 In the future, an optional upper-layer payload MAY follow the HIP 3005 header. The Next Header field in the header indicates if there is 3006 additional data following the HIP header. The HIP packet, however, 3007 MUST NOT be fragmented into multiple extension headers by setting the 3008 Next Header field in a HIP header to the HIP protocol number. This 3009 limits the size of the possible additional data in the packet. 3011 5.3.1. I1 - the HIP Initiator Packet 3013 The HIP header values for the I1 packet: 3015 Header: 3016 Packet Type = 1 3017 SRC HIT = Initiator's HIT 3018 DST HIT = Responder's HIT, or NULL 3020 IP ( HIP ( DH_GROUP_LIST ) ) 3022 The I1 packet contains the fixed HIP header and the Initiator's 3023 DH_GROUP_LIST. 3025 Valid control bits: none 3027 The Initiator receives the Responder's HIT either from a DNS lookup 3028 of the Responder's FQDN (see 5205-bis), from some other repository, 3029 or from a local table. If the Initiator does not know the 3030 Responder's HIT, it may attempt to use opportunistic mode by using 3031 NULL (all zeros) as the Responder's HIT. See also "HIP Opportunistic 3032 Mode" (Section 4.1.8). 3034 Since the I1 packet is so easy to spoof even if it were signed, no 3035 attempt is made to add to its generation or processing cost. 3037 The Initiator includes a DH_GROUP_LIST parameter in the I1 packet to 3038 inform the Responder of its preferred DH Group IDs. Note that the 3039 DH_GROUP_LIST in the I1 packet is not protected by a signature. 3041 Implementations MUST be able to handle a storm of received I1 3042 packets, discarding those with common content that arrive within a 3043 small time delta. 3045 5.3.2. R1 - the HIP Responder Packet 3047 The HIP header values for the R1 packet: 3049 Header: 3050 Packet Type = 2 3051 SRC HIT = Responder's HIT 3052 DST HIT = Initiator's HIT 3054 IP ( HIP ( [ R1_COUNTER, ] 3055 PUZZLE, 3056 DIFFIE_HELLMAN, 3057 HIP_CIPHER, 3058 HOST_ID, 3059 HIT_SUITE_LIST, 3060 DH_GROUP_LIST, 3061 [ ECHO_REQUEST_SIGNED, ] 3062 TRANSPORT_FORMAT_LIST, 3063 HIP_SIGNATURE_2 ) 3064 <, ECHO_REQUEST_UNSIGNED >i) 3066 Valid control bits: A 3068 If the Responder's HI is an anonymous one, the A control MUST be set. 3070 The Initiator's HIT MUST match the one received in the I1 packet if 3071 the R1 is a response to an I1. If the Responder has multiple HIs, 3072 the Responder's HIT used MUST match Initiator's request. If the 3073 Initiator used opportunistic mode, the Responder may select freely 3074 among its HIs. See also "HIP Opportunistic Mode" (Section 4.1.8). 3076 The R1 packet generation counter is used to determine the currently 3077 valid generation of puzzles. The value is increased periodically, 3078 and it is RECOMMENDED that it is increased at least as often as 3079 solutions to old puzzles are no longer accepted. 3081 The Puzzle contains a Random #I and the difficulty #K. The 3082 difficulty #K indicates the number of lower-order bits, in the puzzle 3083 hash result, that must be zeros; see Section 4.1.2. The Random #I is 3084 not covered by the signature and must be zeroed during the signature 3085 calculation, allowing the sender to select and set the #I into a 3086 precomputed R1 packet just prior sending it to the peer. 3088 The Responder selects the Diffie-Hellman public value based on the 3089 Initiator's preference expressed in the DH_GROUP_LIST parameter in 3090 the I1 packet. The Responder sends back its own preference based on 3091 which it chose the DH public value as DH_GROUP_LIST. This allows the 3092 Initiator to determine whether its own DH_GROUP_LIST in the sent I1 3093 packet was manipulated by an attacker. 3095 The Diffie-Hellman public value is ephemeral, and values SHOULD NOT 3096 be reused across different HIP associations. Once the Responder has 3097 received a valid response to an R1 packet, that Diffie-Hellman value 3098 SHOULD be deprecated. It is possible that the Responder has sent the 3099 same Diffie-Hellman value to different hosts simultaneously in 3100 corresponding R1 packets and those responses should also be accepted. 3101 However, as a defense against I1 packet storms, an implementation MAY 3102 propose, and re-use unless avoidable, the same Diffie-Hellman value 3103 for a period of time, for example, 15 minutes. By using a small 3104 number of different puzzles for a given Diffie-Hellman value, the R1 3105 packets can be precomputed and delivered as quickly as I1 packets 3106 arrive. A scavenger process should clean up unused Diffie-Hellman 3107 values and puzzles. 3109 Re-using Diffie-Hellman public values opens up the potential security 3110 risk of more than one Initiator ending up with the same keying 3111 material (due to faulty random number generators). Also, more than 3112 one Initiator using the same Responder public key half may lead to 3113 potentially easier cryptographic attacks and to imperfect forward 3114 security. 3116 However, these risks involved in re-using the same public value are 3117 statistical; that is, the authors are not aware of any mechanism that 3118 would allow manipulation of the protocol so that the risk of the re- 3119 use of any given Responder Diffie-Hellman public key would differ 3120 from the base probability. Consequently, it is RECOMMENDED that 3121 Responders avoid re-using the same DH key with multiple Initiators, 3122 but because the risk is considered statistical and not known to be 3123 manipulable, the implementations MAY re-use a key in order to ease 3124 resource-constrained implementations and to increase the probability 3125 of successful communication with legitimate clients even under an I1 3126 packet storm. In particular, when it is too expensive to generate 3127 enough precomputed R1 packets to supply each potential Initiator with 3128 a different DH key, the Responder MAY send the same DH key to several 3129 Initiators, thereby creating the possibility of multiple legitimate 3130 Initiators ending up using the same Responder-side public key. 3131 However, as soon as the Responder knows that it will use a particular 3132 DH key, it SHOULD stop offering it. This design is aimed to allow 3133 resource-constrained Responders to offer services under I1 packet 3134 storms and to simultaneously make the probability of DH key re-use 3135 both statistical and as low as possible. 3137 If the Responder uses the same DH keypair for multiple handshakes, it 3138 must take care to avoid small subgroup attacks [RFC2785]. To avoid 3139 these attacks, when receiving the I2 message, the Responder SHOULD 3140 validate the Initiators DH public key as described in [RFC2785] 3141 Section 3.1. In case the validation fails, the Responder MUST NOT 3142 generate a DH shared key and MUST silently abort the HIP BEX. 3144 The HIP_CIPHER contains the encryption algorithms supported by the 3145 Responder to encrypt the contents of the ENCRYPTED parameter, in the 3146 order of preference. All implementations MUST support AES [RFC3602]. 3148 The HIT_SUITE_LIST parameter is an ordered list of the Responder's 3149 preferred and supported HIT Suites. The list allows the Initiator to 3150 determine whether its own source HIT matches any suite supported by 3151 the Responder. 3153 The ECHO_REQUEST_SIGNED and ECHO_REQUEST_UNSIGNED parameters contain 3154 data that the sender wants to receive unmodified in the corresponding 3155 response packet in the ECHO_RESPONSE_SIGNED or ECHO_RESPONSE_UNSIGNED 3156 parameter. The R1 packet may contain zero or more 3157 ECHO_REQUEST_UNSIGNED parameters as described in 3158 Section Section 5.2.21. 3160 The TRANSPORT_FORMAT_LIST parameter is an ordered list of the 3161 Responder's preferred and supported transport format types. The list 3162 allows the Initiator and the Responder to agree on a common type for 3163 payload protection. This parameter is described in Section 5.2.11. 3165 The signature is calculated over the whole HIP packet as described in 3166 Section 5.2.15. This allows the Responder to use precomputed R1s. 3167 The Initiator SHOULD validate this signature. It MUST check that the 3168 Responder's HI matches with the one expected, if any. 3170 5.3.3. I2 - the Second HIP Initiator Packet 3172 The HIP header values for the I2 packet: 3174 Header: 3175 Type = 3 3176 SRC HIT = Initiator's HIT 3177 DST HIT = Responder's HIT 3179 IP ( HIP ( [R1_COUNTER,] 3180 SOLUTION, 3181 DIFFIE_HELLMAN, 3182 HIP_CIPHER, 3183 ENCRYPTED { HOST_ID } or HOST_ID, 3184 [ ECHO_RESPONSE_SIGNED ,] 3185 TRANSPORT_FORMAT_LIST, 3186 HIP_MAC, 3187 HIP_SIGNATURE 3188 <, ECHO_RESPONSE_UNSIGNED>i ) ) 3190 Valid control bits: A 3191 The HITs used MUST match the ones used in the R1. 3193 If the Initiator's HI is an anonymous one, the A control bit MUST be 3194 set. 3196 If present in the I1 packet, the Initiator MUST include an unmodified 3197 copy of the R1_COUNTER parameter received in the corresponding R1 3198 packet into the I2 packet. 3200 The Solution contains the Random #I from R1 and the computed #J. The 3201 low-order #K bits of the RHASH(I | ... | J) MUST be zero. 3203 The Diffie-Hellman value is ephemeral. If precomputed, a scavenger 3204 process should clean up unused Diffie-Hellman values. The Responder 3205 MAY re-use Diffie-Hellman values under some conditions as specified 3206 in Section 5.3.2. 3208 The HIP_CIPHER contains the single encryption suite selected by the 3209 Initiator, that it uses to encrypt the ENCRYPTED parameters. The 3210 chosen cipher MUST correspond to one of the ciphers offered by the 3211 Responder in the R1. All implementations MUST support AES [RFC3602]. 3213 The Initiator's HI MAY be encrypted using the HIP_CIPHER encryption 3214 algorithm. The keying material is derived from the Diffie-Hellman 3215 exchanged as defined in Section 6.5. 3217 The ECHO_RESPONSE_SIGNED and ECHO_RESPONSE_UNSIGNED contain the 3218 unmodified Opaque data copied from the corresponding echo request 3219 parameter(s). 3221 The TRANSPORT_FORMAT_LIST contains the single transport format type 3222 selected by the Initiator. The chosen type MUST correspond to one of 3223 the types offered by the Responder in the R1. Currently, the only 3224 transport format defined is the ESP transport format 3225 ([I-D.ietf-hip-rfc5202-bis]). 3227 The HMAC value in the HIP_MAC parameter is calculated over the whole 3228 HIP packet, excluding any parameters after the HIP_MAC, as described 3229 in Section 6.4.1. The Responder MUST validate the HIP_MAC. 3231 The signature is calculated over the whole HIP packet, excluding any 3232 parameters after the HIP_SIGNATURE, as described in Section 5.2.14. 3233 The Responder MUST validate this signature. The Responder uses the 3234 HI in the packet or a HI acquired by some other means for verifying 3235 the signature. 3237 5.3.4. R2 - the Second HIP Responder Packet 3239 The HIP header values for the R2 packet: 3241 Header: 3242 Packet Type = 4 3243 SRC HIT = Responder's HIT 3244 DST HIT = Initiator's HIT 3246 IP ( HIP ( HIP_MAC_2, HIP_SIGNATURE ) ) 3248 Valid control bits: none 3250 The HIP_MAC_2 is calculated over the whole HIP packet, with 3251 Responder's HOST_ID parameter concatenated with the HIP packet. The 3252 HOST_ID parameter is removed after the HMAC calculation. The 3253 procedure is described in Section 6.4.1. 3255 The signature is calculated over the whole HIP packet. 3257 The Initiator MUST validate both the HIP_MAC and the signature. 3259 5.3.5. UPDATE - the HIP Update Packet 3261 The HIP header values for the UPDATE packet: 3263 Header: 3264 Packet Type = 16 3265 SRC HIT = Sender's HIT 3266 DST HIT = Recipient's HIT 3268 IP ( HIP ( [SEQ, ACK, ] HIP_MAC, HIP_SIGNATURE ) ) 3270 Valid control bits: None 3272 The UPDATE packet contains mandatory HIP_MAC and HIP_SIGNATURE 3273 parameters, and other optional parameters. 3275 The UPDATE packet contains zero or one SEQ parameter. The presence 3276 of a SEQ parameter indicates that the receiver MUST acknowledge the 3277 the UPDATE. An UPDATE that does not contain a SEQ but only an ACK 3278 parameter is simply an acknowledgment of a previous UPDATE and itself 3279 MUST NOT be acknowledged by a separate ACK parameter. Such UPDATE 3280 packets containing only an ACK parameter do not require processing in 3281 relative order to other UPDATE packets. An UPDATE packet without 3282 either a SEQ or an ACK parameter is invalid; such unacknowledged 3283 updates MUST instead use a NOTIFY packet. 3285 An UPDATE packet contains zero or one ACK parameters. The ACK 3286 parameter echoes the SEQ sequence number of the UPDATE packet being 3287 ACKed. A host MAY choose to acknowledge more than one UPDATE packet 3288 at a time; e.g., the ACK parameter may contain the last two SEQ 3289 values received, for resilience against packet loss. ACK values are 3290 not cumulative; each received unique SEQ value requires at least one 3291 corresponding ACK value in reply. Received ACK parameters that are 3292 redundant are ignored. Hosts MUST implement the processing of ACK 3293 parameters with multiple SEQ numbers even if they do not implement 3294 sending ACK parameters with multiple SEQ numbers. 3296 The UPDATE packet may contain both a SEQ and an ACK parameter. In 3297 this case, the ACK parameter is being piggybacked on an outgoing 3298 UPDATE. In general, UPDATEs carrying SEQ SHOULD be ACKed upon 3299 completion of the processing of the UPDATE. A host MAY choose to 3300 hold the UPDATE carrying an ACK parameter for a short period of time 3301 to allow for the possibility of piggybacking the ACK parameter, in a 3302 manner similar to TCP delayed acknowledgments. 3304 A sender MAY choose to forego reliable transmission of a particular 3305 UPDATE (e.g., it becomes overcome by events). The semantics are such 3306 that the receiver MUST acknowledge the UPDATE, but the sender MAY 3307 choose to not care about receiving the ACK parameter. 3309 UPDATEs MAY be retransmitted without incrementing SEQ. If the same 3310 subset of parameters is included in multiple UPDATEs with different 3311 SEQs, the host MUST ensure that the receiver's processing of the 3312 parameters multiple times will not result in a protocol error. 3314 5.3.6. NOTIFY - the HIP Notify Packet 3316 The NOTIFY packet MAY be used to provide information to a peer. 3317 Typically, NOTIFY is used to indicate some type of protocol error or 3318 negotiation failure. NOTIFY packets are unacknowledged. The 3319 receiver can handle the packet only as informational, and SHOULD NOT 3320 change its HIP state (see Section 4.4.2) based purely on a received 3321 NOTIFY packet. 3323 The HIP header values for the NOTIFY packet: 3325 Header: 3326 Packet Type = 17 3327 SRC HIT = Sender's HIT 3328 DST HIT = Recipient's HIT, or zero if unknown 3330 IP ( HIP (i, [HOST_ID, ] HIP_SIGNATURE) ) 3332 Valid control bits: None 3333 The NOTIFY packet is used to carry one or more NOTIFICATION 3334 parameters. 3336 5.3.7. CLOSE - the HIP Association Closing Packet 3338 The HIP header values for the CLOSE packet: 3340 Header: 3341 Packet Type = 18 3342 SRC HIT = Sender's HIT 3343 DST HIT = Recipient's HIT 3345 IP ( HIP ( ECHO_REQUEST_SIGNED, HIP_MAC, HIP_SIGNATURE ) ) 3347 Valid control bits: none 3349 The sender MUST include an ECHO_REQUEST_SIGNED used to validate 3350 CLOSE_ACK received in response, and both a HIP_MAC and a signature 3351 (calculated over the whole HIP packet). 3353 The receiver peer MUST reply with a CLOSE_ACK containing an 3354 ECHO_RESPONSE_SIGNED corresponding to the received 3355 ECHO_REQUEST_SIGNED. 3357 5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet 3359 The HIP header values for the CLOSE_ACK packet: 3361 Header: 3362 Packet Type = 19 3363 SRC HIT = Sender's HIT 3364 DST HIT = Recipient's HIT 3366 IP ( HIP ( ECHO_RESPONSE_SIGNED, HIP_MAC, HIP_SIGNATURE ) ) 3368 Valid control bits: none 3370 The sender MUST include both an HMAC and signature (calculated over 3371 the whole HIP packet). 3373 The receiver peer MUST validate the ECHO_RESPONSE_SIGNED and validate 3374 both the HIP_MAC and the signature if the receiver has state for a 3375 HIP association. 3377 5.4. ICMP Messages 3379 When a HIP implementation detects a problem with an incoming packet, 3380 and it either cannot determine the identity of the sender of the 3381 packet or does not have any existing HIP association with the sender 3382 of the packet, it MAY respond with an ICMP packet. Any such replies 3383 MUST be rate-limited as described in [RFC4443]. In most cases, the 3384 ICMP packet has the Parameter Problem type (12 for ICMPv4, 4 for 3385 ICMPv6), with the Pointer field pointing to the field that caused the 3386 ICMP message to be generated. 3388 5.4.1. Invalid Version 3390 If a HIP implementation receives a HIP packet that has an 3391 unrecognized HIP version number, it SHOULD respond, rate-limited, 3392 with an ICMP packet with type Parameter Problem, with the Pointer 3393 pointing to the Version/RES. byte in the HIP header. 3395 5.4.2. Other Problems with the HIP Header and Packet Structure 3397 If a HIP implementation receives a HIP packet that has other 3398 unrecoverable problems in the header or packet format, it MAY 3399 respond, rate-limited, with an ICMP packet with type Parameter 3400 Problem, the Pointer pointing to the field that failed to pass the 3401 format checks. However, an implementation MUST NOT send an ICMP 3402 message if the checksum fails; instead, it MUST silently drop the 3403 packet. 3405 5.4.3. Invalid Puzzle Solution 3407 If a HIP implementation receives an I2 packet that has an invalid 3408 puzzle solution, the behavior depends on the underlying version of 3409 IP. If IPv6 is used, the implementation SHOULD respond with an ICMP 3410 packet with type Parameter Problem, the Pointer pointing to the 3411 beginning of the Puzzle solution #J field in the SOLUTION payload in 3412 the HIP message. 3414 If IPv4 is used, the implementation MAY respond with an ICMP packet 3415 with the type Parameter Problem, copying enough of bytes from the I2 3416 message so that the SOLUTION parameter fits into the ICMP message, 3417 the Pointer pointing to the beginning of the Puzzle solution #J 3418 field, as in the IPv6 case. Note, however, that the resulting ICMPv4 3419 message exceeds the typical ICMPv4 message size as defined in 3420 [RFC0792]. 3422 5.4.4. Non-Existing HIP Association 3424 If a HIP implementation receives a CLOSE or UPDATE packet, or any 3425 other packet whose handling requires an existing association, that 3426 has either a Receiver or Sender HIT that does not match with any 3427 existing HIP association, the implementation MAY respond, rate- 3428 limited, with an ICMP packet with the type Parameter Problem. The 3429 Pointer of the ICMP Parameter Problem packet is set pointing to the 3430 beginning of the first HIT that does not match. 3432 A host MUST NOT reply with such an ICMP if it receives any of the 3433 following messages: I1, R2, I2, R2, and NOTIFY packet. When 3434 introducing new packet types, a specification SHOULD define the 3435 appropriate rules for sending or not sending this kind of ICMP reply. 3437 6. Packet Processing 3439 Each host is assumed to have a single HIP protocol implementation 3440 that manages the host's HIP associations and handles requests for new 3441 ones. Each HIP association is governed by a conceptual state 3442 machine, with states defined above in Section 4.4. The HIP 3443 implementation can simultaneously maintain HIP associations with more 3444 than one host. Furthermore, the HIP implementation may have more 3445 than one active HIP association with another host; in this case, HIP 3446 associations are distinguished by their respective HITs. It is not 3447 possible to have more than one HIP association between any given pair 3448 of HITs. Consequently, the only way for two hosts to have more than 3449 one parallel association is to use different HITs, at least at one 3450 end. 3452 The processing of packets depends on the state of the HIP 3453 association(s) with respect to the authenticated or apparent 3454 originator of the packet. A HIP implementation determines whether it 3455 has an active association with the originator of the packet based on 3456 the HITs. In the case of user data carried in a specific transport 3457 format, the transport format document specifies how the incoming 3458 packets are matched with the active associations. 3460 6.1. Processing Outgoing Application Data 3462 In a HIP host, an application can send application-level data using 3463 an identifier specified via the underlying API. The API can be a 3464 backwards-compatible API (see [RFC5338]), using identifiers that look 3465 similar to IP addresses, or a completely new API, providing enhanced 3466 services related to Host Identities. Depending on the HIP 3467 implementation, the identifier provided to the application may be 3468 different; for example, it can be a HIT or an IP address. 3470 The exact format and method for transferring the user data from the 3471 source HIP host to the destination HIP host is defined in the 3472 corresponding transport format document. The actual data is 3473 transferred in the network using the appropriate source and 3474 destination IP addresses. 3476 In this document, conceptual processing rules are defined only for 3477 the base case where both hosts have only single usable IP addresses; 3478 the multi-address multi-homing case is specified separately. 3480 The following conceptual algorithm describes the steps that are 3481 required for handling outgoing datagrams destined to a HIT. 3483 1. If the datagram has a specified source address, it MUST be a HIT. 3484 If it is not, the implementation MAY replace the source address 3485 with a HIT. Otherwise, it MUST drop the packet. 3487 2. If the datagram has an unspecified source address, the 3488 implementation MUST choose a suitable source HIT for the 3489 datagram. Selecting the source HIT is subject to local policy. 3491 3. If there is no active HIP association with the given HIT pair, one MUST be created by running the base 3493 exchange. While waiting for the base exchange to complete, the 3494 implementation SHOULD queue at least one user data packet per HIP 3495 association to be formed, and it MAY queue more than one. 3497 4. Once there is an active HIP association for the given HIT pair, the outgoing datagram is passed to 3499 transport handling. The possible transport formats are defined 3500 in separate documents, of which the ESP transport format for HIP 3501 is mandatory for all HIP implementations. 3503 5. Before sending the packet, the HITs in the datagram are replaced 3504 with suitable IP addresses. For IPv6, the rules defined in 3505 [RFC6724] SHOULD be followed. Note that this HIT-to-IP-address 3506 conversion step MAY also be performed at some other point in the 3507 stack, e.g., before wrapping the packet into the output format. 3509 6.2. Processing Incoming Application Data 3511 The following conceptual algorithm describes the incoming datagram 3512 handling when HITs are used at the receiving host as application- 3513 level identifiers. More detailed steps for processing packets are 3514 defined in corresponding transport format documents. 3516 1. The incoming datagram is mapped to an existing HIP association, 3517 typically using some information from the packet. For example, 3518 such mapping may be based on the ESP Security Parameter Index 3519 (SPI). 3521 2. The specific transport format is unwrapped, in a way depending on 3522 the transport format, yielding a packet that looks like a 3523 standard (unencrypted) IP packet. If possible, this step SHOULD 3524 also verify that the packet was indeed (once) sent by the remote 3525 HIP host, as identified by the HIP association. 3527 Depending on the used transport mode, the verification method can 3528 vary. While the HI (as well as HIT) is used as the higher-layer 3529 identifier, the verification method has to verify that the data 3530 packet was sent by the correct node identity and that the actual 3531 identity maps to this particular HIT. When using ESP transport 3532 format [I-D.ietf-hip-rfc5202-bis], the verification is done using 3533 the SPI value in the data packet to find the corresponding SA 3534 with associated HIT and key, and decrypting the packet with that 3535 associated key. 3537 3. The IP addresses in the datagram are replaced with the HITs 3538 associated with the HIP association. Note that this IP-address- 3539 to-HIT conversion step MAY also be performed at some other point 3540 in the stack. 3542 4. The datagram is delivered to the upper layer (e.g., UDP or TCP). 3543 When demultiplexing the datagram, the right upper-layer socket is 3544 selected based on the HITs. 3546 6.3. Solving the Puzzle 3548 This subsection describes the details for solving the puzzle. 3550 In the R1 packet, the values #I and #K are sent in network byte 3551 order. Similarly, in the I2 packet, the values #I and #J are sent in 3552 network byte order. The hash is created by concatenating, in network 3553 byte order, the following data, in the following order and using the 3554 RHASH algorithm: 3556 n-bit random value #I (where n is RHASH_len), in network byte 3557 order, as appearing in the R1 and I2 packets. 3559 128-bit Initiator's HIT, in network byte order, as appearing in 3560 the HIP Payload in the R1 and I2 packets. 3562 128-bit Responder's HIT, in network byte order, as appearing in 3563 the HIP Payload in the R1 and I2 packets. 3565 n-bit random value #J (where n is RHASH_len), in network byte 3566 order, as appearing in the I2 packet. 3568 In a valid response puzzle, the #K low-order bits of the resulting 3569 RHASH digest MUST be zero. 3571 Notes: 3573 i) The length of the data to be hashed is variable depending on 3574 the output length of the Responder's hash function RHASH. 3576 ii) All the data in the hash input MUST be in network byte order. 3578 iii) The order of the Initiator's and Responder's HITs are 3579 different in the R1 and I2 packets; see Section 5.1. Care must be 3580 taken to copy the values in the right order to the hash input. 3582 iv) For a puzzle #I, there may exist multiple valid puzzle 3583 solutions #J. 3585 The following procedure describes the processing steps involved, 3586 assuming that the Responder chooses to precompute the R1 packets: 3588 Precomputation by the Responder: 3589 Sets up the puzzle difficulty #K. 3590 Creates a signed R1 and caches it. 3592 Responder: 3593 Selects a suitable cached R1. 3594 Generates a random number #I. 3595 Sends #I and #K in an R1. 3596 Saves #I and #K for a Delta time. 3598 Initiator: 3599 Generates repeated attempts to solve the puzzle until a matching 3600 #J is found: 3601 Ltrunc( RHASH( #I | HIT-I | HIT-R | #J ), #K ) == 0 3602 Sends #I and #J in an I2. 3604 Responder: 3605 Verifies that the received #I is a saved one. 3606 Finds the right #K based on #I. 3607 Computes V := Ltrunc( RHASH( #I | HIT-I | HIT-R | #J ), #K ) 3608 Rejects if V != 0 3609 Accept if V == 0 3611 6.4. HIP_MAC and SIGNATURE Calculation and Verification 3613 The following subsections define the actions for processing HIP_MAC, 3614 HIP_MAC_2, HIP_SIGNATURE and HIP_SIGNATURE_2 parameters. The 3615 HIP_MAC_2 parameter is contained in the R2 packet. The 3616 HIP_SIGNATURE_2 parameter is contained in the R1 packet. The 3617 HIP_SIGNATURE and HIP_MAC parameter are contained in other HIP 3618 packets. 3620 6.4.1. HMAC Calculation 3622 The HMAC uses RHASH as underlying hash function. The type of RHASH 3623 depends on the HIT Suite of the Responder. Hence, HMAC-SHA-256 3624 [RFC4868] is used for HIT Suite RSA/DSA/SHA-256, HMAC-SHA-1 [RFC2404] 3625 is used for HIT Suite ECDSA_LOW/SHA-1, and HMAC-SHA-384 [RFC4868] for 3626 HIT Suite ECDSA/SHA-384. 3628 The following process applies both to the HIP_MAC and HIP_MAC_2 3629 parameters. When processing HIP_MAC_2, the difference is that the 3630 HIP_MAC calculation includes a pseudo HOST_ID field containing the 3631 Responder's information as sent in the R1 packet earlier. 3633 Both the Initiator and the Responder should take some care when 3634 verifying or calculating the HIP_MAC_2. Specifically, the Initiator 3635 has to preserve the HOST_ID exactly as it was received in the R1 3636 packet until it receives the HIP_MAC_2 in the R2 packet. 3638 The scope of the calculation for HIP_MAC is: 3640 HMAC: { HIP header | [ Parameters ] } 3642 where Parameters include all HIP parameters of the packet that is 3643 being calculated with Type values ranging from 1 to (HIP_MAC's Type 3644 value - 1) and exclude parameters with Type values greater or equal 3645 to HIP_MAC's Type value. 3647 During HIP_MAC calculation, the following applies: 3649 o In the HIP header, the Checksum field is set to zero. 3651 o In the HIP header, the Header Length field value is calculated to 3652 the beginning of the HIP_MAC parameter. 3654 Parameter order is described in Section 5.2.1. 3656 The scope of the calculation for HIP_MAC_2 is: 3658 HIP_MAC_2: { HIP header | [ Parameters ] | HOST_ID } 3660 where Parameters include all HIP parameters for the packet that is 3661 being calculated with Type values from 1 to (HIP_MAC_2's Type value - 3662 1) and exclude parameters with Type values greater or equal to 3663 HIP_MAC_2's Type value. 3665 During HIP_MAC_2 calculation, the following applies: 3667 o In the HIP header, the Checksum field is set to zero. 3669 o In the HIP header, the Header Length field value is calculated to 3670 the beginning of the HIP_MAC_2 parameter and increased by the 3671 length of the concatenated HOST_ID parameter length (including 3672 type and length fields). 3674 o HOST_ID parameter is exactly in the form it was received in the R1 3675 packet from the Responder. 3677 Parameter order is described in Section 5.2.1, except that the 3678 HOST_ID parameter in this calculation is added to the end. 3680 The HIP_MAC parameter is defined in Section 5.2.12 and the HIP_MAC_2 3681 parameter in Section 5.2.13. The HMAC calculation and verification 3682 process (the process applies both to HIP_MAC and HIP_MAC_2 except 3683 where HIP_MAC_2 is mentioned separately) is as follows: 3685 Packet sender: 3687 1. Create the HIP packet, without the HIP_MAC, HIP_SIGNATURE, 3688 HIP_SIGNATURE_2, or any other parameter with greater Type value 3689 than the HIP_MAC parameter has. 3691 2. In case of HIP_MAC_2 calculation, add a HOST_ID (Responder) 3692 parameter to the end of the packet. 3694 3. Calculate the Header Length field in the HIP header including the 3695 added HOST_ID parameter in case of HIP_MAC_2. 3697 4. Compute the HMAC using either HIP-gl or HIP-lg integrity key 3698 retrieved from KEYMAT as defined in Section 6.5. 3700 5. In case of HIP_MAC_2, remove the HOST_ID parameter from the 3701 packet. 3703 6. Add the HIP_MAC parameter to the packet and any parameter with 3704 greater Type value than the HIP_MAC's (HIP_MAC_2's) that may 3705 follow, including possible HIP_SIGNATURE or HIP_SIGNATURE_2 3706 parameters 3708 7. Recalculate the Length field in the HIP header. 3710 Packet receiver: 3712 1. Verify the HIP header Length field. 3714 2. Remove the HIP_MAC or HIP_MAC_2 parameter, as well as all other 3715 parameters that follow it with greater Type value including 3716 possible HIP_SIGNATURE or HIP_SIGNATURE_2 fields, saving the 3717 contents if they are needed later. 3719 3. In case of HIP_MAC_2, build and add a HOST_ID parameter (with 3720 Responder information) to the packet. The HOST_ID parameter 3721 should be identical to the one previously received from the 3722 Responder. 3724 4. Recalculate the HIP packet length in the HIP header and clear the 3725 Checksum field (set it to all zeros). In case of HIP_MAC_2, the 3726 length is calculated with the added HOST_ID parameter. 3728 5. Compute the HMAC using either HIP-gl or HIP-lg integrity key as 3729 defined in Section 6.5 and verify it against the received HMAC. 3731 6. Set Checksum and Header Length field in the HIP header to 3732 original values. Note that the checksum and length fields 3733 contain incorrect values after this step. 3735 7. In case of HIP_MAC_2, remove the HOST_ID parameter from the 3736 packet before further processing. 3738 6.4.2. Signature Calculation 3740 The following process applies both to the HIP_SIGNATURE and 3741 HIP_SIGNATURE_2 parameters. When processing the HIP_SIGNATURE_2, the 3742 only difference is that instead of the HIP_SIGNATURE parameter, the 3743 HIP_SIGNATURE_2 parameter is used, and the Initiator's HIT and PUZZLE 3744 Opaque and Random #I fields are cleared (set to all zeros) before 3745 computing the signature. The HIP_SIGNATURE parameter is defined in 3746 Section 5.2.14 and the HIP_SIGNATURE_2 parameter in Section 5.2.15. 3748 The scope of the calculation for HIP_SIGNATURE and HIP_SIGNATURE_2 3749 is: 3751 HIP_SIGNATURE: { HIP header | [ Parameters ] } 3753 where Parameters include all HIP parameters for the packet that is 3754 being calculated with Type values from 1 to (HIP_SIGNATURE's Type 3755 value - 1). 3757 During signature calculation, the following applies: 3759 o In the HIP header, the Checksum field is set to zero. 3761 o In the HIP header, the Header Length field value is calculated to 3762 the beginning of the HIP_SIGNATURE parameter. 3764 The parameter order is described in Section 5.2.1. 3766 HIP_SIGNATURE_2: { HIP header | [ Parameters ] } 3768 where Parameters include all HIP parameters for the packet that is 3769 being calculated with Type values ranging from 1 to 3770 (HIP_SIGNATURE_2's Type value - 1). 3772 During signature calculation, the following apply: 3774 o In the HIP header, the Initiator's HIT field and Checksum fields 3775 are set to zero. 3777 o In the HIP header, the Header Length field value is calculated to 3778 the beginning of the HIP_SIGNATURE_2 parameter. 3780 o PUZZLE parameter's Opaque and Random #I fields are set to zero. 3782 Parameter order is described in Section 5.2.1. 3784 The signature calculation and verification process (the process 3785 applies both to HIP_SIGNATURE and HIP_SIGNATURE_2 except in the case 3786 where HIP_SIGNATURE_2 is separately mentioned) is as follows: 3788 Packet sender: 3790 1. Create the HIP packet without the HIP_SIGNATURE parameter or any 3791 other parameters that follow the HIP_SIGNATURE parameter. 3793 2. Calculate the Length field and zero the Checksum field in the HIP 3794 header. In case of HIP_SIGNATURE_2, set Initiator's HIT field in 3795 the HIP header as well as PUZZLE parameter's Opaque and Random #I 3796 fields to zero. 3798 3. Compute the signature using the private key corresponding to the 3799 Host Identifier (public key). 3801 4. Add the HIP_SIGNATURE parameter to the packet. 3803 5. Add any parameters that follow the HIP_SIGNATURE parameter. 3805 6. Recalculate the Length field in the HIP header, and calculate the 3806 Checksum field. 3808 Packet receiver: 3810 1. Verify the HIP header Length field and checksum. 3812 2. Save the contents of the HIP_SIGNATURE parameter and any other 3813 parameters following the HIP_SIGNATURE parameter and remove them 3814 from the packet. 3816 3. Recalculate the HIP packet Length in the HIP header and clear the 3817 Checksum field (set it to all zeros). In case of 3818 HIP_SIGNATURE_2, set Initiator's HIT field in the HIP header as 3819 well as PUZZLE parameter's Opaque and Random #I fields to zero. 3821 4. Compute the signature and verify it against the received 3822 signature using the packet sender's Host Identity (public key). 3824 5. Restore the original packet by adding removed parameters (in step 3825 2) and resetting the values that were set to zero (in step 3). 3827 The verification can use either the HI received from a HIP packet, 3828 the HI from a DNS query, if the FQDN has been received in the HOST_ID 3829 packet or one received by some other means. 3831 6.5. HIP KEYMAT Generation 3833 HIP keying material is derived from the Diffie-Hellman session key, 3834 Kij, produced during the HIP base exchange (see Section 4.1.3). The 3835 Initiator has Kij during the creation of the I2 packet, and the 3836 Responder has Kij once it receives the I2 packet. This is why I2 can 3837 already contain encrypted information. 3839 The KEYMAT is derived by feeding Kij into the key derivation function 3840 defined by the DH Group ID. Currently the only key derivation 3841 function defined in this document is the Hash-based Key Derivation 3842 Function (HKDF) [RFC5869] using the RHASH hash function. Other 3843 documents may define new DH Group IDs and corresponding key 3844 distribution functions. 3846 In the following we provide the details for deriving the keying 3847 material using HKDF. 3849 where 3851 info = sort(HIT-I | HIT-R) 3852 salt = #I | #J 3854 Sort(HIT-I | HIT-R) is defined as the network byte order 3855 concatenation of the two HITs, with the smaller HIT preceding the 3856 larger HIT, resulting from the numeric comparison of the two HITs 3857 interpreted as positive (unsigned) 128-bit integers in network byte 3858 order. The #I and #J values are from the puzzle and its solution 3859 that were exchanged in R1 and I2 messages when this HIP association 3860 was set up. Both hosts have to store #I and #J values for the HIP 3861 association for future use. 3863 The initial keys are drawn sequentially in the order that is 3864 determined by the numeric comparison of the two HITs, with comparison 3865 method described in the previous paragraph. HOST_g denotes the host 3866 with the greater HIT value, and HOST_l the host with the lower HIT 3867 value. 3869 The drawing order for the four initial keys is as follows: 3871 HIP-gl encryption key for HOST_g's ENCRYPTED parameter 3873 HIP-gl integrity (HMAC) key for HOST_g's outgoing HIP packets 3875 HIP-lg encryption key for HOST_l's ENCRYPTED parameter 3877 HIP-lg integrity (HMAC) key for HOST_l's outgoing HIP packets 3879 The number of bits drawn for a given algorithm is the "natural" size 3880 of the keys. For the mandatory algorithms, the following sizes 3881 apply: 3883 AES 128 or 256 bits 3885 SHA-1 160 bits 3887 SHA-256 256 bits 3889 SHA-384 384 bits 3891 NULL 0 bits 3892 If other key sizes are used, they MUST be treated as different 3893 encryption algorithms and defined separately. 3895 6.6. Initiation of a HIP Base Exchange 3897 An implementation may originate a HIP base exchange to another host 3898 based on a local policy decision, usually triggered by an application 3899 datagram, in much the same way that an IPsec IKE key exchange can 3900 dynamically create a Security Association. Alternatively, a system 3901 may initiate a HIP exchange if it has rebooted or timed out, or 3902 otherwise lost its HIP state, as described in Section 4.5.4. 3904 The implementation prepares an I1 packet and sends it to the IP 3905 address that corresponds to the peer host. The IP address of the 3906 peer host may be obtained via conventional mechanisms, such as DNS 3907 lookup. The I1 packet contents are specified in Section 5.3.1. The 3908 selection of which source or destination Host Identity to use, if a 3909 Initiator or Responder has more than one to choose from, is typically 3910 a policy decision. 3912 The following steps define the conceptual processing rules for 3913 initiating a HIP base exchange: 3915 1. The Initiator receives one or more of the Responder's HITs and 3916 one or more addresses either from a DNS lookup of the Responder's 3917 FQDN, from some other repository, or from a local database. If 3918 the Initiator does not know the Responder's HIT, it may attempt 3919 opportunistic mode by using NULL (all zeros) as the Responder's 3920 HIT (see also "HIP Opportunistic Mode" (Section 4.1.8)). If the 3921 Initiator can choose from multiple Responder HITs, it selects a 3922 HIT for which the Initiator supports the HIT Suite. 3924 2. The Initiator sends an I1 packet to one of the Responder's 3925 addresses. The selection of which address to use is a local 3926 policy decision. 3928 3. The Initiator includes the DH_GROUP_LIST in the I1 packet. The 3929 selection and order of DH Group IDs in the DH_GROUP_LIST MUST be 3930 stored by the Initiator because this list is needed for later R1 3931 processing. In most cases, the preferences regarding the DH 3932 Groups will be static, so no per-association storage is 3933 necessary. 3935 4. Upon sending an I1 packet, the sender transitions to state 3936 I1-SENT, starts a timer for which the timeout value SHOULD be 3937 larger than the worst-case anticipated RTT. The sender SHOULD 3938 also increment the trial counter associated with the I1. 3940 5. Upon timeout, the sender SHOULD retransmit the I1 packet and 3941 restart the timer, up to a maximum of I1_RETRIES_MAX tries. 3943 6.6.1. Sending Multiple I1 Packets in Parallel 3945 For the sake of minimizing the association establishment latency, an 3946 implementation MAY send the same I1 packet to more than one of the 3947 Responder's addresses. However, it MUST NOT send to more than three 3948 (3) Responder addresses in parallel. Furthermore, upon timeout, the 3949 implementation MUST refrain from sending the same I1 packet to 3950 multiple addresses. That is, if it retries to initialize the 3951 connection after a timeout, it MUST NOT send the I1 packet to more 3952 than one destination address. These limitations are placed in order 3953 to avoid congestion of the network, and potential DoS attacks that 3954 might occur, e.g., because someone's claim to have hundreds or 3955 thousands of addresses could generate a huge number of I1 packets 3956 from the Initiator. 3958 As the Responder is not guaranteed to distinguish the duplicate I1 3959 packets it receives at several of its addresses (because it avoids 3960 storing states when it answers back an R1 packet), the Initiator may 3961 receive several duplicate R1 packets. 3963 The Initiator SHOULD then select the initial preferred destination 3964 address using the source address of the selected received R1, and use 3965 the preferred address as a source address for the I2 packet. 3966 Processing rules for received R1s are discussed in Section 6.8. 3968 6.6.2. Processing Incoming ICMP Protocol Unreachable Messages 3970 A host may receive an ICMP 'Destination Protocol Unreachable' message 3971 as a response to sending a HIP I1 packet. Such a packet may be an 3972 indication that the peer does not support HIP, or it may be an 3973 attempt to launch an attack by making the Initiator believe that the 3974 Responder does not support HIP. 3976 When a system receives an ICMP 'Destination Protocol Unreachable' 3977 message while it is waiting for an R1 packet, it MUST NOT terminate 3978 waiting. It MAY continue as if it had not received the ICMP message, 3979 and send a few more I1 packets. Alternatively, it MAY take the ICMP 3980 message as a hint that the peer most probably does not support HIP, 3981 and return to state UNASSOCIATED earlier than otherwise. However, at 3982 minimum, it MUST continue waiting for an R1 packet for a reasonable 3983 time before returning to UNASSOCIATED. 3985 6.7. Processing Incoming I1 Packets 3987 An implementation SHOULD reply to an I1 with an R1 packet, unless the 3988 implementation is unable or unwilling to set up a HIP association. 3989 If the implementation is unable to set up a HIP association, the host 3990 SHOULD send an ICMP Destination Protocol Unreachable, 3991 Administratively Prohibited, message to the I1 packet source IP 3992 address. If the implementation is unwilling to set up a HIP 3993 association, the host MAY ignore the I1 packet. This latter case may 3994 occur during a DoS attack such as an I1 packet flood. 3996 The implementation SHOULD be able to handle a storm of received I1 3997 packets, discarding those with common content that arrive within a 3998 small time delta. 4000 A spoofed I1 packet can result in an R1 attack on a system. An R1 4001 packet sender MUST have a mechanism to rate-limit R1 packets sent to 4002 an address. 4004 It is RECOMMENDED that the HIP state machine does not transition upon 4005 sending an R1 packet. 4007 The following steps define the conceptual processing rules for 4008 responding to an I1 packet: 4010 1. The Responder MUST check that the Responder's HIT in the received 4011 I1 packet is either one of its own HITs or NULL. Otherwise it 4012 must drop the packet. 4014 2. If the Responder is in ESTABLISHED state, the Responder MAY 4015 respond to this with an R1 packet, prepare to drop an existing 4016 HIP security association with the peer, and stay at ESTABLISHED 4017 state. 4019 3. If the Responder is in I1-SENT state, it MUST make a comparison 4020 between the sender's HIT and its own (i.e., the receiver's) HIT. 4021 If the sender's HIT is greater than its own HIT, it should drop 4022 the I1 packet and stay at I1-SENT. If the sender's HIT is 4023 smaller than its own HIT, it SHOULD send the R1 packet and stay 4024 at I1-SENT. The HIT comparison is performed as defined in 4025 Section 6.5. 4027 4. If the implementation chooses to respond to the I1 packet with an 4028 R1 packet, it creates a new R1 or selects a precomputed R1 4029 according to the format described in Section 5.3.2. It creates 4030 or chooses an R1 that contains its most preferred DH public value 4031 that is also contained in the DH_GROUP_LIST in the I1 packet. If 4032 no suitable DH Group ID was contained in the DH_GROUP_LIST in the 4033 I1 packet, it sends an R1 with any suitable DH public key. 4035 5. If the received Responder's HIT in the I1 is NULL, the Responder 4036 selects a HIT with a the same HIT Suite as the Initiator's HIT. 4037 If this HIT Suite is not supported by the Responder, it SHOULD 4038 select a REQUIRED HIT Suite from Section 5.2.10, which is 4039 currently RSA/DSA/SHA-256. Other than that, selecting the HIT is 4040 a local policy matter. 4042 6. The responder expresses its supported HIP transport formats in 4043 the TRANSPORT_FORMAT_LIST as described in Section 5.2.11. The 4044 Responder MUST at least provide one payload transport format 4045 type. 4047 7. The Responder sends the R1 packet to the source IP address of the 4048 I1 packet. 4050 6.7.1. R1 Management 4052 All compliant implementations MUST be able to produce R1 packets; 4053 even if a device is configured by policy to only initiate 4054 associations, it must be able to process I1s in case of recovery from 4055 loss of state or key exhaustion. An R1 packet MAY be precomputed. 4056 An R1 packet MAY be reused for time Delta T, which is implementation 4057 dependent, and SHOULD be deprecated and not used once a valid 4058 response I2 packet has been received from an Initiator. During an I1 4059 message storm, an R1 packet MAY be re-used beyond this limit. R1 4060 information MUST NOT be discarded until Delta S after T. Time S is 4061 the delay needed for the last I2 packet to arrive back to the 4062 Responder. 4064 Implementations that support multiple DH groups MAY pre-compute R1 4065 packets for each supported group so that incoming I1 packets with 4066 different DH Group IDs in the DH_GROUP_LIST can be served quickly. 4068 An implementation MAY keep state about received I1 packets and match 4069 the received I2 packets against the state, as discussed in 4070 Section 4.1.1. 4072 6.7.2. Handling Malformed Messages 4074 If an implementation receives a malformed I1 packet, it SHOULD NOT 4075 respond with a NOTIFY message, as such practice could open up a 4076 potential denial-of-service threat. Instead, it MAY respond with an 4077 ICMP packet, as defined in Section 5.4. 4079 6.8. Processing Incoming R1 Packets 4081 A system receiving an R1 packet MUST first check to see if it has 4082 sent an I1 packet to the originator of the R1 packet (i.e., it is in 4083 state I1-SENT). If so, it SHOULD process the R1 as described below, 4084 send an I2 packet, and transition to state I2-SENT, setting a timer 4085 to protect the I2 packet. If the system is in state I2-SENT, it MAY 4086 respond to the R1 packet if the R1 packet has a larger R1 generation 4087 counter; if so, it should drop its state due to processing the 4088 previous R1 packet and start over from state I1-SENT. If the system 4089 is in any other state with respect to that host, the system SHOULD 4090 silently drop the R1 packet. 4092 When sending multiple I1 packets, an Initiator SHOULD wait for a 4093 small amount of time after the first R1 reception to allow possibly 4094 multiple R1 packets to arrive, and it SHOULD respond to an R1 packet 4095 among the set with the largest R1 generation counter. 4097 The following steps define the conceptual processing rules for 4098 responding to an R1 packet: 4100 1. A system receiving an R1 MUST first check to see if it has sent 4101 an I1 packet to the originator of the R1 packet (i.e., it has a 4102 HIP association that is in state I1-SENT and that is associated 4103 with the HITs in the R1). Unless the I1 packet was sent in 4104 opportunistic mode (see Section 4.1.8), the IP addresses in the 4105 received R1 packet SHOULD be ignored by the R1 processing and, 4106 when looking up the right HIP association, the received R1 4107 packet SHOULD be matched against the associations using only the 4108 HITs. If a match exists, the system should process the R1 4109 packet as described below. 4111 2. Otherwise, if the system is in any other state than I1-SENT or 4112 I2-SENT with respect to the HITs included in the R1 packet, it 4113 SHOULD silently drop the R1 packet and remain in the current 4114 state. 4116 3. If the HIP association state is I1-SENT or I2-SENT, the received 4117 Initiator's HIT MUST correspond to the HIT used in the original 4118 I1. Also, the Responder's HIT MUST correspond to the one used 4119 in the I1, unless the I1 packet contained a NULL HIT. 4121 4. The system SHOULD validate the R1 signature before applying 4122 further packet processing, according to Section 5.2.15. 4124 5. If the HIP association state is I1-SENT, and multiple valid R1 4125 packets are present, the system MUST select from among the R1 4126 packets with the largest R1 generation counter. 4128 6. The system MUST check that the Initiator HIT Suite is contained 4129 in the HIT_SUITE_LIST parameter in the R1 packet (i.e., the 4130 Initiator's HIT Suite is supported by the Responder). If the 4131 HIT Suite is supported by the Responder, the system proceeds 4132 normally. Otherwise, the system MAY stay in state I1-sent and 4133 restart the BEX by sending a new I1 packet with an Initiator HIT 4134 that is supported by the Responder and hence is contained in the 4135 HIT_SUITE_LIST in the R1 packet. The system MAY abort the BEX 4136 if no suitable source HIT is available. The system SHOULD wait 4137 for an acceptable time span to allow further R1 packets with 4138 higher R1 generation counters or different HIT and HIT Suites to 4139 arrive before restarting or aborting the BEX. 4141 7. The system MUST check that the DH Group ID in the DIFFIE_HELLMAN 4142 parameter in the R1 matches the first DH Suite ID in the 4143 Responder's DH_GROUP_LIST in the R1 packet that was also 4144 contained in the Initiator's DH_GROUP_LIST in the I1 packet. If 4145 the DH Group ID of the DIFFIE_HELLMAN parameter does not express 4146 the Responder's best choice, the Initiator can conclude that the 4147 DH_GROUP_LIST in the I1 packet was adversely modified. In such 4148 case, the Initiator MAY send a new I1 packet, however, it SHOULD 4149 NOT change its preference in the DH_GROUP_LIST in the new I1 4150 packet. Alternatively, the Initiator MAY abort the HIP base 4151 exchange. 4153 8. If the HIP association state is I2-SENT, the system MAY re-enter 4154 state I1-SENT and process the received R1 packet if it has a 4155 larger R1 generation counter than the R1 packet responded to 4156 previously. 4158 9. The R1 packet may have the A bit set -- in this case, the system 4159 MAY choose to refuse it by dropping the R1 packet and returning 4160 to state UNASSOCIATED. The system SHOULD consider dropping the 4161 R1 packet only if it used a NULL HIT in I1 packet. If the A bit 4162 is set, the Responder's HIT is anonymous and SHOULD NOT be 4163 stored permanently. 4165 10. The system SHOULD attempt to validate the HIT against the 4166 received Host Identity by using the received Host Identity to 4167 construct a HIT and verify that it matches the Sender's HIT. 4169 11. The system MUST store the received R1 generation counter for 4170 future reference. 4172 12. The system attempts to solve the puzzle in the R1 packet. The 4173 system MUST terminate the search after exceeding the remaining 4174 lifetime of the puzzle. If the puzzle is not successfully 4175 solved, the implementation MAY either resend the I1 packet 4176 within the retry bounds or abandon the HIP base exchange. 4178 13. The system computes standard Diffie-Hellman keying material 4179 according to the public value and Group ID provided in the 4180 DIFFIE_HELLMAN parameter. The Diffie-Hellman keying material 4181 Kij is used for key extraction as specified in Section 6.5. 4183 14. The system selects the HIP_CIPHER ID from the choices presented 4184 in the R1 packet and uses the selected values subsequently when 4185 generating and using encryption keys, and when sending the I2 4186 packet. If the proposed alternatives are not acceptable to the 4187 system, it may either resend an I1 within the retry bounds or 4188 abandon the HIP base exchange. 4190 15. The system chooses one suitable transport format from the 4191 TRANSPORT_FORMAT_LIST and includes the respective transport 4192 format parameter in the subsequent I2 packet. 4194 16. The system initializes the remaining variables in the associated 4195 state, including Update ID counters. 4197 17. The system prepares and sends an I2 packet, as described in 4198 Section 5.3.3. 4200 18. The system SHOULD start a timer whose timeout value SHOULD be 4201 larger than the worst-case anticipated RTT, and MUST increment a 4202 trial counter associated with the I2 packet. The sender SHOULD 4203 retransmit the I2 packet upon a timeout and restart the timer, 4204 up to a maximum of I2_RETRIES_MAX tries. 4206 19. If the system is in state I1-SENT, it SHALL transition to state 4207 I2-SENT. If the system is in any other state, it remains in the 4208 current state. 4210 6.8.1. Handling of Malformed Messages 4212 If an implementation receives a malformed R1 message, it MUST 4213 silently drop the packet. Sending a NOTIFY or ICMP would not help, 4214 as the sender of the R1 packet typically doesn't have any state. An 4215 implementation SHOULD wait for some more time for a possibly well- 4216 formed R1, after which it MAY try again by sending a new I1 packet. 4218 6.9. Processing Incoming I2 Packets 4220 Upon receipt of an I2 packet, the system MAY perform initial checks 4221 to determine whether the I2 packet corresponds to a recent R1 packet 4222 that has been sent out, if the Responder keeps such state. For 4223 example, the sender could check whether the I2 packet is from an 4224 address or HIT for which the Responder has recently received an I1. 4225 The R1 packet may have had Opaque data included that was echoed back 4226 in the I2 packet. If the I2 packet is considered to be suspect, it 4227 MAY be silently discarded by the system. 4229 Otherwise, the HIP implementation SHOULD process the I2 packet. This 4230 includes validation of the puzzle solution, generating the Diffie- 4231 Hellman key, possibly decrypting the Initiator's Host Identity, 4232 verifying the signature, creating state, and finally sending an R2 4233 packet. 4235 The following steps define the conceptual processing rules for 4236 responding to an I2 packet: 4238 1. The system MAY perform checks to verify that the I2 packet 4239 corresponds to a recently sent R1 packet. Such checks are 4240 implementation dependent. See Appendix A for a description of 4241 an example implementation. 4243 2. The system MUST check that the Responder's HIT corresponds to 4244 one of its own HITs and MUST drop the packet otherwise. 4246 3. The system MUST further check that the Initiator's HIT Suite is 4247 supported. The Responder SHOULD silently drop I2 packets with 4248 unsupported Initiator HITs. 4250 4. If the system's state machine is in the R2-SENT state, the 4251 system MAY check if the newly received I2 packet is similar to 4252 the one that triggered moving to R2-SENT. If so, it MAY 4253 retransmit a previously sent R2 packet, reset the R2-SENT timer, 4254 and the state machine stays in R2-SENT. 4256 5. If the system's state machine is in the I2-SENT state, the 4257 system MUST make a comparison between its local and sender's 4258 HITs (similarly as in Section 6.5). If the local HIT is smaller 4259 than the sender's HIT, it should drop the I2 packet, use the 4260 peer Diffie-Hellman key and nonce #I from the R1 packet received 4261 earlier, and get the local Diffie-Hellman key and nonce #J from 4262 the I2 packet sent to the peer earlier. Otherwise, the system 4263 should process the received I2 packet and drop any previously 4264 derived Diffie-Hellman keying material Kij it might have formed 4265 upon sending the I2 packet previously. The peer Diffie-Hellman 4266 key and the nonce #J are taken from the just arrived I2 packet. 4267 The local Diffie-Hellman key and the nonce I are the ones that 4268 were sent earlier in the R1 packet. 4270 6. If the system's state machine is in the I1-SENT state, and the 4271 HITs in the I2 packet match those used in the previously sent I1 4272 packet, the system uses this received I2 packet as the basis for 4273 the HIP association it was trying to form, and stops 4274 retransmitting I1 packets (provided that the I2 packet passes 4275 the additional checks below). 4277 7. If the system's state machine is in any other state than 4278 R2-SENT, the system SHOULD check that the echoed R1 generation 4279 counter in the I2 packet is within the acceptable range if the 4280 counter is included. Implementations MUST accept puzzles from 4281 the current generation and MAY accept puzzles from earlier 4282 generations. If the generation counter in the newly received I2 4283 packet is outside the accepted range, the I2 packet is stale 4284 (and perhaps replayed) and SHOULD be dropped. 4286 8. The system MUST validate the solution to the puzzle by computing 4287 the hash described in Section 5.3.3 using the same RHASH 4288 algorithm. 4290 9. The I2 packet MUST have a single value in the HIP_CIPHER 4291 parameter, which MUST match one of the values offered to the 4292 Initiator in the R1 packet. 4294 10. The system must derive Diffie-Hellman keying material Kij based 4295 on the public value and Group ID in the DIFFIE_HELLMAN 4296 parameter. This key is used to derive the HIP association keys, 4297 as described in Section 6.5. If the Diffie-Hellman Group ID is 4298 unsupported, the I2 packet is silently dropped. 4300 11. The encrypted HOST_ID is decrypted by the Initiator's encryption 4301 key defined in Section 6.5. If the decrypted data is not a 4302 HOST_ID parameter, the I2 packet is silently dropped. 4304 12. The implementation SHOULD also verify that the Initiator's HIT 4305 in the I2 packet corresponds to the Host Identity sent in the I2 4306 packet. (Note: some middleboxes may not able to make this 4307 verification.) 4309 13. The system MUST process the TRANSPORT_FORMAT_LIST parameter. 4310 Other documents specifying transport formats (e.g. 4311 [I-D.ietf-hip-rfc5202-bis]) contain specifications for handling 4312 any specific transport selected. 4314 14. The system MUST verify the HIP_MAC according to the procedures 4315 in Section 5.2.12. 4317 15. The system MUST verify the HIP_SIGNATURE according to 4318 Section 5.2.14 and Section 5.3.3. 4320 16. If the checks above are valid, then the system proceeds with 4321 further I2 processing; otherwise, it discards the I2 and its 4322 state machine remains in the same state. 4324 17. The I2 packet may have the A bit set -- in this case, the system 4325 MAY choose to refuse it by dropping the I2 and the state machine 4326 returns to state UNASSOCIATED. If the A bit is set, the 4327 Initiator's HIT is anonymous and should not be stored 4328 permanently. 4330 18. The system initializes the remaining variables in the associated 4331 state, including Update ID counters. 4333 19. Upon successful processing of an I2 message when the system's 4334 state machine is in state UNASSOCIATED, I1-SENT, I2-SENT, or 4335 R2-SENT, an R2 packet is sent and the system's state machine 4336 transitions to state R2-SENT. 4338 20. Upon successful processing of an I2 packet when the system's 4339 state machine is in state ESTABLISHED, the old HIP association 4340 is dropped and a new one is installed, an R2 packet is sent, and 4341 the system's state machine transitions to R2-SENT. 4343 21. Upon the system's state machine transitioning to R2-SENT, the 4344 system starts a timer. The state machine transitions to 4345 ESTABLISHED if some data has been received on the incoming HIP 4346 association, or an UPDATE packet has been received (or some 4347 other packet that indicates that the peer system's state machine 4348 has moved to ESTABLISHED). If the timer expires (allowing for 4349 maximal amount of retransmissions of I2 packets), the state 4350 machine transitions to ESTABLISHED. 4352 6.9.1. Handling of Malformed Messages 4354 If an implementation receives a malformed I2 message, the behavior 4355 SHOULD depend on how many checks the message has already passed. If 4356 the puzzle solution in the message has already been checked, the 4357 implementation SHOULD report the error by responding with a NOTIFY 4358 packet. Otherwise, the implementation MAY respond with an ICMP 4359 message as defined in Section 5.4. 4361 6.10. Processing of Incoming R2 Packets 4363 An R2 packet received in states UNASSOCIATED, I1-SENT, or ESTABLISHED 4364 results in the R2 packet being dropped and the state machine staying 4365 in the same state. If an R2 packet is received in state I2-SENT, it 4366 MUST be processed. 4368 The following steps define the conceptual processing rules for an 4369 incoming R2 packet: 4371 1. If the system is in any other state than I2-SENT, the R2 packet 4372 is silently dropped. 4374 2. The system MUST verify that the HITs in use correspond to the 4375 HITs that were received in the R1 packet that caused the 4376 transition to the I1-SENT state. 4378 3. The system MUST verify the HIP_MAC_2 according to the procedures 4379 in Section 5.2.13. 4381 4. The system MUST verify the HIP signature according to the 4382 procedures in Section 5.2.14. 4384 5. If any of the checks above fail, there is a high probability of 4385 an ongoing man-in-the-middle or other security attack. The 4386 system SHOULD act accordingly, based on its local policy. 4388 6. Upon successful processing of the R2 packet, the state machine 4389 transitions to state ESTABLISHED. 4391 6.11. Sending UPDATE Packets 4393 A host sends an UPDATE packet when it intends to update some 4394 information related to a HIP association. There are a number of 4395 possible scenarios when this can occur, e.g., mobility management and 4396 rekeying of an existing ESP Security Association. The following 4397 paragraphs define the conceptual rules for sending an UPDATE packet 4398 to the peer. Additional steps can be defined in other documents 4399 where the UPDATE packet is used. 4401 The sequence of UPDATE messages is indicated by their SEQ parameter. 4402 Before sending an UPDATE message, the system first determines whether 4403 there are any outstanding UPDATE messages that may conflict with the 4404 new UPDATE message under consideration. When multiple UPDATEs are 4405 outstanding (not yet acknowledged), the sender must assume that such 4406 UPDATEs may be processed in an arbitrary order by the receiver. 4407 Therefore, any new UPDATEs that depend on a previous outstanding 4408 UPDATE being successfully received and acknowledged MUST be postponed 4409 until reception of the necessary ACK(s) occurs. One way to prevent 4410 any conflicts is to only allow one outstanding UPDATE at a time. 4411 However, allowing multiple UPDATEs may improve the performance of 4412 mobility and multihoming protocols. 4414 The following steps define the conceptual processing rules for 4415 sending UPDATE packets. 4417 1. The first UPDATE packet is sent with Update ID of zero. 4418 Otherwise, the system increments its own Update ID value by one 4419 before continuing the steps below. 4421 2. The system creates an UPDATE packet that contains a SEQ parameter 4422 with the current value of Update ID. The UPDATE packet MAY also 4423 include zero or more ACKs of the peer's Update ID(s) from 4424 previously received UPDATE SEQ parameter(s) 4426 3. The system sends the created UPDATE packet and starts an UPDATE 4427 timer. The default value for the timer is 2 * RTT estimate. If 4428 multiple UPDATEs are outstanding, multiple timers are in effect. 4430 4. If the UPDATE timer expires, the UPDATE is resent. The UPDATE 4431 can be resent UPDATE_RETRY_MAX times. The UPDATE timer SHOULD be 4432 exponentially backed off for subsequent retransmissions. If no 4433 acknowledgment is received from the peer after UPDATE_RETRY_MAX 4434 times, the HIP association is considered to be broken and the 4435 state machine SHOULD move from state ESTABLISHED to state CLOSING 4436 as depicted in Section 4.4.4. The UPDATE timer is cancelled upon 4437 receiving an ACK from the peer that acknowledges receipt of the 4438 UPDATE. 4440 6.12. Receiving UPDATE Packets 4442 When a system receives an UPDATE packet, its processing depends on 4443 the state of the HIP association and the presence and values of the 4444 SEQ and ACK parameters. Typically, an UPDATE message also carries 4445 optional parameters whose handling is defined in separate documents. 4447 For each association, a host stores the peer's next expected in- 4448 sequence Update ID ("peer Update ID"). Initially, this value is 4449 zero. Update ID comparisons of "less than" and "greater than" are 4450 performed with respect to a circular sequence number space. Hence, a 4451 wrap around after 2^32 updates has to be expected and MUST be handled 4452 accordingly. 4454 The sender MAY send multiple outstanding UPDATE messages. These 4455 messages are processed in the order in which they are received at the 4456 receiver (i.e., no re-sequencing is performed). When processing 4457 UPDATEs out-of-order, the receiver MUST keep track of which UPDATEs 4458 were previously processed, so that duplicates or retransmissions are 4459 ACKed and not reprocessed. A receiver MAY choose to define a receive 4460 window of Update IDs that it is willing to process at any given time, 4461 and discard received UPDATEs falling outside of that window. 4463 The following steps define the conceptual processing rules for 4464 receiving UPDATE packets. 4466 1. If there is no corresponding HIP association, the implementation 4467 MAY reply with an ICMP Parameter Problem, as specified in 4468 Section 5.4.4. 4470 2. If the association is in the ESTABLISHED state and the SEQ (but 4471 not ACK) parameter is present, the UPDATE is processed and 4472 replied to as described in Section 6.12.1. 4474 3. If the association is in the ESTABLISHED state and the ACK (but 4475 not SEQ) parameter is present, the UPDATE is processed as 4476 described in Section 6.12.2. 4478 4. If the association is in the ESTABLISHED state and there is both 4479 an ACK and SEQ in the UPDATE, the ACK is first processed as 4480 described in Section 6.12.2, and then the rest of the UPDATE is 4481 processed as described in Section 6.12.1. 4483 6.12.1. Handling a SEQ Parameter in a Received UPDATE Message 4485 The following steps define the conceptual processing rules for 4486 handling a SEQ parameter in a received UPDATE packet. 4488 1. If the Update ID in the received SEQ is not the next in the 4489 sequence of Update IDs and is greater than the receiver's window 4490 for new UPDATEs, the packet MUST be dropped. 4492 2. If the Update ID in the received SEQ corresponds to an UPDATE 4493 that has recently been processed, the packet is treated as a 4494 retransmission. The HIP_MAC verification (next step) MUST NOT be 4495 skipped. (A byte-by-byte comparison of the received and a stored 4496 packet would be acceptable, though.) It is recommended that a 4497 host caches UPDATE packets sent with ACKs to avoid the cost of 4498 generating a new ACK packet to respond to a replayed UPDATE. The 4499 system MUST acknowledge, again, such (apparent) UPDATE message 4500 retransmissions but SHOULD also consider rate-limiting such 4501 retransmission responses to guard against replay attacks. 4503 3. The system MUST verify the HIP_MAC in the UPDATE packet. If the 4504 verification fails, the packet MUST be dropped. 4506 4. The system MAY verify the SIGNATURE in the UPDATE packet. If the 4507 verification fails, the packet SHOULD be dropped and an error 4508 message logged. 4510 5. If a new SEQ parameter is being processed, the parameters in the 4511 UPDATE are then processed. The system MUST record the Update ID 4512 in the received SEQ parameter, for replay protection. 4514 6. An UPDATE acknowledgment packet with ACK parameter is prepared 4515 and sent to the peer. This ACK parameter MAY be included in a 4516 separate UPDATE or piggybacked in an UPDATE with SEQ parameter, 4517 as described in Section 5.3.5. The ACK parameter MAY acknowledge 4518 more than one of the peer's Update IDs. 4520 6.12.2. Handling an ACK Parameter in a Received UPDATE Packet 4522 The following steps define the conceptual processing rules for 4523 handling an ACK parameter in a received UPDATE packet. 4525 1. The sequence number reported in the ACK must match with an UPDATE 4526 packet sent earlier that has not already been acknowledged. If 4527 no match is found or if the ACK does not acknowledge a new 4528 UPDATE, the packet MUST either be dropped if no SEQ parameter is 4529 present, or the processing steps in Section 6.12.1 are followed. 4531 2. The system MUST verify the HIP_MAC in the UPDATE packet. If the 4532 verification fails, the packet MUST be dropped. 4534 3. The system MAY verify the SIGNATURE in the UPDATE packet. If the 4535 verification fails, the packet SHOULD be dropped and an error 4536 message logged. 4538 4. The corresponding UPDATE timer is stopped (see Section 6.11) so 4539 that the now acknowledged UPDATE is no longer retransmitted. If 4540 multiple UPDATEs are acknowledged, multiple timers are stopped. 4542 6.13. Processing of NOTIFY Packets 4544 Processing of NOTIFY packets is OPTIONAL. If processed, any errors 4545 in a received NOTIFICATION parameter SHOULD be logged. Received 4546 errors MUST be considered only as informational, and the receiver 4547 SHOULD NOT change its HIP state (see Section 4.4.2) purely based on 4548 the received NOTIFY message. 4550 6.14. Processing CLOSE Packets 4552 When the host receives a CLOSE message, it responds with a CLOSE_ACK 4553 message and moves to CLOSED state. (The authenticity of the CLOSE 4554 message is verified using both HIP_MAC and SIGNATURE). This 4555 processing applies whether or not the HIP association state is 4556 CLOSING in order to handle simultaneous CLOSE messages from both ends 4557 that cross in flight. 4559 The HIP association is not discarded before the host moves to the 4560 UNASSOCIATED state. 4562 Once the closing process has started, any new need to send data 4563 packets triggers creating and establishing of a new HIP association, 4564 starting with sending of an I1 packet. 4566 If there is no corresponding HIP association, the CLOSE packet is 4567 dropped. 4569 6.15. Processing CLOSE_ACK Packets 4571 When a host receives a CLOSE_ACK message, it verifies that it is in 4572 CLOSING or CLOSED state and that the CLOSE_ACK was in response to the 4573 CLOSE. A host can map CLOSE_ACK messages to CLOSE messages by 4574 comparing the value of ECHO_REQUEST_SIGNED (in the CLOSE packet) to 4575 the value of ECHO_RESPONSE_SIGNED (in the CLOSE_ACK packet). 4577 The CLOSE_ACK contains the HIP_MAC and the SIGNATURE parameters for 4578 verification. The state is discarded when the state changes to 4579 UNASSOCIATED and, after that, the host MAY respond with an ICMP 4580 Parameter Problem to an incoming CLOSE message (see Section 5.4.4). 4582 6.16. Handling State Loss 4584 In the case of a system crash and unanticipated state loss, the 4585 system SHOULD delete the corresponding HIP state, including the 4586 keying material. That is, the state SHOULD NOT be stored in long- 4587 term storage. If the implementation does drop the state (as 4588 RECOMMENDED), it MUST also drop the peer's R1 generation counter 4589 value, unless a local policy explicitly defines that the value of 4590 that particular host is stored. An implementation MUST NOT store a 4591 peer's R1 generation counters by default, but storing R1 generation 4592 counter values, if done, MUST be configured by explicit HITs. 4594 7. HIP Policies 4596 There are a number of variables that will influence the HIP base 4597 exchanges that each host must support. All HIP implementations MUST 4598 support more than one simultaneous HI, at least one of which SHOULD 4599 be reserved for anonymous usage. Although anonymous HIs will be 4600 rarely used as Responders' HIs, they will be common for Initiators. 4601 Support for more than two HIs is RECOMMENDED. 4603 Initiators MAY use a different HI for different Responders to provide 4604 basic privacy. Whether such private HIs are used repeatedly with the 4605 same Responder and how long these HIs are used is decided by local 4606 policy and depends on the privacy requirements of the Initiator. 4608 The value of #K used in the HIP R1 must be chosen with care. Too 4609 high numbers of #K will exclude clients with weak CPUs because these 4610 devices cannot solve the puzzle within reasonable time. #K should 4611 only be raised if a Responder is under high load, i.e., it cannot 4612 process all incoming HIP handshakes any more. If a responder is not 4613 under high load, K SHOULD be 0. 4615 Responders that only respond to selected Initiators require an ACL, 4616 representing for which hosts they accept HIP base exchanges, and the 4617 preferred transport format and local lifetimes. Wildcarding SHOULD 4618 be supported for such ACLs, and also for Responders that offer public 4619 or anonymous services. 4621 8. Security Considerations 4623 HIP is designed to provide secure authentication of hosts. HIP also 4624 attempts to limit the exposure of the host to various denial-of- 4625 service and man-in-the-middle (MitM) attacks. In doing so, HIP 4626 itself is subject to its own DoS and MitM attacks that potentially 4627 could be more damaging to a host's ability to conduct business as 4628 usual. 4630 Denial-of-service attacks often take advantage of asymmetries in the 4631 cost of an starting an association. One example of such asymmetry is 4632 the need of a Responder to store local state while a malicious 4633 Initiator can stay stateless. HIP makes no attempt to increase the 4634 cost of the start of state at the Initiator, but makes an effort to 4635 reduce the cost for the Responder. This is accomplished by having 4636 the Responder start the 3-way exchange instead of the Initiator, 4637 making the HIP protocol 4 packets long. In doing this, the first 4638 packet from the Responder, R1, becomes a 'stock' packet that the 4639 Responder MAY use many times, until some Initiator has provided a 4640 valid response to such an R1 packet. During an I1 packet storm, the 4641 host may reuse the same DH value also even if some Initiator has 4642 provided a valid response using that particular DH value. However, 4643 such behavior is discouraged and should be avoided. Using the same 4644 Diffie-Hellman values and random puzzle #I value has some risks. 4645 This risk needs to be balanced against a potential storm of HIP I1 4646 packets. 4648 This shifting of the start of state cost to the Initiator in creating 4649 the I2 HIP packet presents another DoS attack. The attacker can 4650 spoof the I1 packet and the Responder sends out the R1 HIP packet. 4651 This could conceivably tie up the 'Initiator' with evaluating the R1 4652 HIP packet, and creating the I2 packet. The defense against this 4653 attack is to simply ignore any R1 packet where a corresponding I1 4654 packet was not sent (as defined in Section 6.8 step 1). 4656 The R1 packet is considerably larger than the I1 packet. This 4657 asymmetry can be exploited in an reflection attack. A malicious 4658 attacker could spoof the IP address of a victim and send a flood of 4659 I1 messages to a powerful Responder. For each small I1 packet, the 4660 Responder would send a larger R1 packet to the victim. The 4661 difference in packet sizes can further amplify a flooding attack 4662 against the victim. To avoid such reflection attacks, the Responder 4663 SHOULD rate limit the sending of R1 packets in general or SHOULD rate 4664 limit the sending of R1 packets to a specific IP address. 4666 Floods of forged I2 packets form a second kind of DoS attack. Once 4667 the attacking Initiator has solved the puzzle, it can send packets 4668 with spoofed IP source addresses with either an invalid HIP signature 4669 or invalid encrypted HIP payload (in the ENCRYPTED parameter). This 4670 would take resources in the Responder's part to reach the point to 4671 discover that the I2 packet cannot be completely processed. The 4672 defense against this attack is after N bad I2 packets with the same 4673 puzzle solution, the Responder would discard any I2 packets that 4674 contain the given solution. This will shut down the attack. The 4675 attacker would have to request another R1 packet and use that to 4676 launch a new attack. The Responder could increase the value of #K 4677 while under attack. Keeping a list of solutions from malformed 4678 packets requires that the Responder keeps state for these malformed 4679 I2 packets. This state has to be kept until the R1 counter is 4680 increased. As malformed packets are generally filtered by their 4681 checksum before signature verification, only solutions in packets 4682 that are forged to pass the checksum and puzzle are put to the 4683 blacklist. In addition, a valid puzzle is required before a new list 4684 entry is created. Hence, attackers that intend to flood the 4685 blacklist must solve puzzles first. 4687 A third form of DoS attack is emulating the restart of state after a 4688 reboot of one of the peers. A restarting host would send an I1 4689 packet to the peers, which would respond with an R1 packet even if it 4690 were in the ESTABLISHED state. If the I1 packet were spoofed, the 4691 resulting R1 packet would be received unexpectedly by the spoofed 4692 host and would be dropped, as in the first case above. 4694 A fourth form of DoS attack is emulating closing of the HIP 4695 association. HIP relies on timers and a CLOSE/CLOSE_ACK handshake to 4696 explicitly signal the end of a HIP association. Because both CLOSE 4697 and CLOSE_ACK messages contain a HIP_MAC, an outsider cannot close a 4698 connection. The presence of an additional SIGNATURE allows 4699 middleboxes to inspect these messages and discard the associated 4700 state (for e.g., firewalling, SPI-based NATing, etc.). However, the 4701 optional behavior of replying to CLOSE with an ICMP Parameter Problem 4702 packet (as described in Section 5.4.4) might allow an attacker 4703 spoofing the source IP address to send CLOSE messages to launch 4704 reflection attacks. 4706 A fifth form of DoS attack is replaying R1s to cause the Initiator to 4707 solve stale puzzles and become out of synchronization with the 4708 Responder. The R1 generation counter is a monotonically increasing 4709 counter designed to protect against this attack, as described in 4710 Section 4.1.4. 4712 Man-in-the-middle attacks are difficult to defend against, without 4713 third-party authentication. A skillful MitM could easily handle all 4714 parts of HIP, but HIP indirectly provides the following protection 4715 from a MitM attack. If the Responder's HI is retrieved from a signed 4716 DNS zone, a certificate, or through some other secure means, the 4717 Initiator can use this to validate the R1 HIP packet. 4719 Likewise, if the Initiator's HI is in a secure DNS zone, a trusted 4720 certificate, or otherwise securely available, the Responder can 4721 retrieve the HI (after having got the I2 HIP packet) and verify that 4722 the HI indeed can be trusted. 4724 The HIP Opportunistic Mode concept has been introduced in this 4725 document, but this document does not specify what the semantics of 4726 such a connection setup are for applications. There are certain 4727 concerns with opportunistic mode, as discussed in Section 4.1.8. 4729 NOTIFY messages are used only for informational purposes and they are 4730 unacknowledged. A HIP implementation cannot rely solely on the 4731 information received in a NOTIFY message because the packet may have 4732 been replayed. An implementation SHOULD NOT change any state 4733 information purely based on a received NOTIFY message. 4735 Since not all hosts will ever support HIP, ICMP 'Destination Protocol 4736 Unreachable' messages are to be expected and may be used for a DoS 4737 attack. Against an Initiator, the attack would look like the 4738 Responder does not support HIP, but shortly after receiving the ICMP 4739 message, the Initiator would receive a valid R1 HIP packet. Thus, to 4740 protect from this attack, an Initiator SHOULD NOT react to an ICMP 4741 message until a reasonable delta time to get the real Responder's R1 4742 HIP packet. A similar attack against the Responder is more involved. 4743 Normally, if an I1 message received by a Responder was a bogus one 4744 sent by an attacker, the Responder may receive an ICMP message from 4745 the IP address the R1 message was sent to. However, a sophisticated 4746 attacker can try to take advantage of such a behavior and try to 4747 break up the HIP base exchange by sending such an ICMP message to the 4748 Responder before the Initiator has a chance to send a valid I2 4749 message. Hence, the Responder SHOULD NOT act on such an ICMP 4750 message. Especially, it SHOULD NOT remove any minimal state created 4751 when it sent the R1 HIP packet (if it did create one), but wait for 4752 either a valid I2 HIP packet or the natural timeout (that is, if R1 4753 packets are tracked at all). Likewise, the Initiator SHOULD ignore 4754 any ICMP message while waiting for an R2 HIP packet, and SHOULD 4755 delete any pending state only after a natural timeout. 4757 9. IANA Considerations 4759 IANA has reserved protocol number 139 for the Host Identity Protocol 4760 and included it in the "IPv6 Extension Header Types" registry 4761 [RFC7045] and the "Assigned Internet Protocol Numbers" registry. The 4762 reference in both of these registries should be updated from 4763 [RFC5201] to this specification. 4765 The reference to the 128-bit value under the CGA Message Type 4766 namespace [RFC3972] of "0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA" 4767 should be changed from [RFC5201] to this specification. 4769 The following changes to the "Host Identity Protocol (HIP) 4770 Parameters" registries are requested. In many cases, the changes 4771 required involve updating the reference from [RFC5201] to this 4772 specification, but there are some differences as outlined below. 4773 Allocation terminology is defined in [RFC5226]; any existing 4774 references to "IETF Consensus" can be replaced with "IETF Review" as 4775 per [RFC5226]. 4777 HIP Version 4779 This document adds the value "2" to the existing registry. The 4780 value of "1" should be left with a reference to [RFC5201]. 4782 Packet Type 4784 The 7-bit Packet Type field in a HIP protocol packet describes the 4785 type of a HIP protocol message. It is defined in Section 5.1. 4787 All existing values referring to [RFC5201] should be updated to 4788 refer to this specification. Other values should be left 4789 unchanged. 4791 HIT Suite ID 4793 This specification creates a new registry for "HIT Suite ID". 4794 This is different than the existing registry for "Suite ID" which 4795 can be left unmodified for version 1 of the protocol ([RFC5201]). 4796 The registry should be closed to new registrations. 4798 The four-bit HIT Suite ID uses the OGA field in the ORCHID to 4799 express the type of the HIT. This document defines three HIT 4800 Suites (see Appendix E). 4802 The HIT Suite ID is also carried in the four higher-order bits of 4803 the ID field in the HIT_SUITE_LIST parameter. The four lower- 4804 order bits are reserved for future extensions of the HIT Suite ID 4805 space beyond 16 values. 4807 For the time being, the HIT Suite uses only four bits because 4808 these bits have to be carried in the HIT. Using more bits for the 4809 HIT Suite ID reduces the cryptographic strength of the HIT. HIT 4810 Suite IDs must be allocated carefully to avoid namespace 4811 exhaustion. Moreover, deprecated IDs should be reused after an 4812 appropriate time span. If 16 Suite IDs prove insufficient and 4813 more HIT Suite IDs are needed concurrently, more bits can be used 4814 for the HIT Suite ID by using one HIT Suite ID (0) to indicate 4815 that more bits should be used. The HIT_SUITE_LIST parameter 4816 already supports 8-bit HIT Suite IDs, should longer IDs be needed. 4817 Possible extensions of the HIT Suite ID space to accommodate eight 4818 bits and new HIT Suite IDs are defined through IETF Review. 4820 Requests to register reused values should include a note that the 4821 value is being reused after a deprecation period, to ensure 4822 appropriate IETF review and approval. 4824 Parameter Type 4826 The 16-bit Type field in a HIP parameter describes the type of the 4827 parameter. It is defined in Section 5.2.1. The current values 4828 are defined in Sections 5.2.3 through 5.2.23. The existing 4829 registry for "Parameter Type" should be updated as follows. 4831 A new value (129) for R1_COUNTER should be introduced, with a 4832 reference to this specification, and the existing value (128) for 4833 R1_COUNTER left in place with a reference to [RFC5201]. This 4834 documents the change in value that has occurred in version 2 of 4835 this protocol. For clarity, we recommend that the name for the 4836 value 128 be changed from "R1_COUNTER" to "R1_Counter (v1 only)". 4838 A new value (579) for a new Parameter Type HIP_CIPHER should be 4839 added, with reference to this specification. This Parameter Type 4840 functionally replaces the HIP_TRANSFORM Parameter Type (value 577) 4841 which can be left in the table with existing reference to 4842 [RFC5201]. 4844 A new value (715) for a new Parameter Type HIT_SUITE_LIST should 4845 be added, with reference to this specification. 4847 A new value (2049) for a new Parameter Type TRANSPORT_FORMAT_LIST 4848 should be added, with reference to this specification. 4850 The name of the HMAC Parameter Type (value 61505) should be 4851 changed to HIP_MAC. The name of the HMAC_2 Parameter Type (value 4852 61569) should be changed to HIP_MAC_2. The reference should be 4853 changed to this specification. 4855 All other Parameter Types that reference [RFC5201] should be 4856 updated to refer to this specification, and Parameter Types that 4857 reference other RFCs should be unchanged. 4859 Regarding the range assignments, the Type codes 32768 through 4860 49151 (not 49141) should be Reserved for Private Use. Where the 4861 existing ranges state "First Come First Served with Specification 4862 Required", this should be changed to "Specification Required". 4864 The Type codes 32768 through 49151 are reserved for 4865 experimentation. Implementors SHOULD select types in a random 4866 fashion from this range, thereby reducing the probability of 4867 collisions. A method employing genuine randomness (such as 4868 flipping a coin) SHOULD be used. 4870 Group ID 4872 The eight-bit Group ID values appear in the DIFFIE_HELLMAN 4873 parameter and the DH_GROUP_LIST parameter and are defined in 4874 Section 5.2.7. This registry should be updated based on the new 4875 values specified in Section 5.2.7; values noted as being 4876 DEPRECATED can be left in the table with reference to [RFC5201]. 4877 New values are assigned through IETF Review. 4879 HIP Cipher ID 4880 The 16-bit Cipher ID values in a HIP_CIPHER parameter are defined 4881 in Section 5.2.8. This is a new registry. New values either from 4882 the reserved or unassigned space are assigned through IETF Review. 4884 DI-Type 4886 The four-bit DI-Type values in a HOST_ID parameter are defined in 4887 Section 5.2.9. New values are assigned through IETF Review. All 4888 existing values referring to [RFC5201] should be updated to refer 4889 to this specification. 4891 HI Algorithm 4893 The 16-bit Algorithm values in a HOST_ID parameter are defined in 4894 Section 5.2.9. This is a new registry. New values either from 4895 the reserved or unassigned space are assigned through IETF Review. 4897 ECC Curve Label 4899 When the HI Algorithm values in a HOST_ID parameter is defined to 4900 the values of either "ECDSA" or "ECDSA_LOW", a new registry is 4901 needed to maintain the values for the ECC Curve Label as defined 4902 in Section 5.2.9. This might be handled by specifying two 4903 algorithm-specific sub-registries named "ECDSA Curve Label" and 4904 "ECDSA_LOW Curve Label". New values are to be assigned through 4905 IETF Review. 4907 Notify Message Type 4909 The 16-bit Notify Message Type values in a NOTIFICATION parameter 4910 are defined in Section 5.2.19. 4912 Notify Message Type values 1-10 are used for informing about 4913 errors in packet structures, values 11-20 for informing about 4914 problems in parameters containing cryptographic related material, 4915 values 21-30 for informing about problems in authentication or 4916 packet integrity verification. Parameter numbers above 30 can be 4917 used for informing about other types of errors or events. 4919 The existing registration procedures should be updated as follows. 4920 The range from 1-50 can remain as "IETF Review". The range from 4921 51-8191 should be marked as "Specification Required". Values 4922 8192-16383 can remain as "Reserved for Private Use". Values 4923 16385-40959 should be marked as "Specification Required". Values 4924 40960-65535 can remain as "Reserved for Private Use". 4926 The following updates to the values should be made to the existing 4927 registry. All existing values referring to [RFC5201] should be 4928 updated to refer to this specification. 4930 INVALID_HIP_TRANSFORM_CHOSEN should be renamed to 4931 INVALID_HIP_CIPHER_CHOSEN with the same value (17). 4933 A new value of 20 for the type UNSUPPORTED_HIT_SUITE should be 4934 added. 4936 HMAC_FAILED should be renamed to HIP_MAC_FAILED with the same 4937 value (28). 4939 SERVER_BUSY_PLEASE_RETRY should be renamed to 4940 RESPONDER_BUSY_PLEASE_RETRY with the same value (44). 4942 10. Acknowledgments 4944 The drive to create HIP came to being after attending the MALLOC 4945 meeting at the 43rd IETF meeting. Baiju Patel and Hilarie Orman 4946 really gave the original author, Bob Moskowitz, the assist to get HIP 4947 beyond 5 paragraphs of ideas. It has matured considerably since the 4948 early versions thanks to extensive input from IETFers. Most 4949 importantly, its design goals are articulated and are different from 4950 other efforts in this direction. Particular mention goes to the 4951 members of the NameSpace Research Group of the IRTF. Noel Chiappa 4952 provided valuable input at early stages of discussions about 4953 identifier handling and Keith Moore the impetus to provide 4954 resolvability. Steve Deering provided encouragement to keep working, 4955 as a solid proposal can act as a proof of ideas for a research group. 4957 Many others contributed; extensive security tips were provided by 4958 Steve Bellovin. Rob Austein kept the DNS parts on track. Paul 4959 Kocher taught Bob Moskowitz how to make the puzzle exchange expensive 4960 for the Initiator to respond, but easy for the Responder to validate. 4961 Bill Sommerfeld supplied the Birthday concept, which later evolved 4962 into the R1 generation counter, to simplify reboot management. Erik 4963 Nordmark supplied the CLOSE-mechanism for closing connections. 4964 Rodney Thayer and Hugh Daniels provided extensive feedback. In the 4965 early times of this document, John Gilmore kept Bob Moskowitz 4966 challenged to provide something of value. 4968 During the later stages of this document, when the editing baton was 4969 transferred to Pekka Nikander, the input from the early implementors 4970 was invaluable. Without having actual implementations, this document 4971 would not be on the level it is now. 4973 In the usual IETF fashion, a large number of people have contributed 4974 to the actual text or ideas. The list of these people include Jeff 4975 Ahrenholz, Francis Dupont, Derek Fawcus, George Gross, Andrew 4976 McGregor, Julien Laganier, Miika Komu, Mika Kousa, Jan Melen, Henrik 4977 Petander, Michael Richardson, Rene Hummen, Tim Shepard, Jorma Wall, 4978 Xin Gu, and Jukka Ylitalo. Our apologies to anyone whose name is 4979 missing. 4981 Once the HIP Working Group was founded in early 2004, a number of 4982 changes were introduced through the working group process. Most 4983 notably, the original document was split in two, one containing the 4984 base exchange and the other one defining how to use ESP. Some 4985 modifications to the protocol proposed by Aura, et al., [AUR03] were 4986 added at a later stage. 4988 11. Changes from RFC 5201 4990 This section summarizes the changes made from [RFC5201]. 4992 11.1. Changes from draft-ietf-hip-rfc5201-bis-15 4994 o Additional edits to IANA Considerations section based on initial 4995 IANA review. 4997 11.2. Changes from draft-ietf-hip-rfc5201-bis-14 4999 o Update source XML to comply with xmlrfcv2 version of the xml2rfc 5000 tool, resulting in a few table formatting changes. 5002 o Editorial and minor technical revisions based on IESG review. 5004 o Significant revisions to IANA Considerations section based on 5005 initial IANA review. 5007 11.3. Changes from draft-ietf-hip-rfc5201-bis-13 5009 o Update a few references and fix some editorial nits. 5011 11.4. Changes from draft-ietf-hip-rfc5201-bis-12 5013 o Fix I-D nits. 5015 11.5. Changes from draft-ietf-hip-rfc5201-bis-11 5017 o Specify that TRANSPORT_FORMAT_LIST is mandatory in R1 and I2; fix 5018 incorrect section reference. 5020 11.6. Changes from draft-ietf-hip-rfc5201-bis-10 5022 o Issue 39: Text clarifying R1 counter rollover and Initiator 5023 response to unexpected reset of the counter. 5025 11.7. Changes from draft-ietf-hip-rfc5201-bis-09 5027 o Editorial changes based on working group last call. 5029 11.8. Changes from draft-ietf-hip-rfc5201-bis-08 5031 o Issue 29: Use different RSA mode OEAP/PSS, elevate ECDSA to 5032 REQUIRED status 5034 o Issue 35: limiting ECC cofactor to 1 5036 o Changed text regarding issue 33 reusing DH values 5038 o Fix tracker issue 32 on Domain Identifier normative text 5040 11.9. Changes from draft-ietf-hip-rfc5201-bis-07 5042 o Removed lingering references to SHA-1 as the mandatory hash 5043 algorithm (which was changed to SHA-256 in the -02 draft version). 5045 o For parameter type number changes, changed "IETF Review" to "IETF 5046 Review or IESG Approval". 5048 o Updated Appendix C checksum examples to conform to HIPv2 packets. 5050 11.10. Changes from draft-ietf-hip-rfc5201-bis-06 5052 o Made echoing the R1_COUNTER in the I2 mandatory if the R1 contains 5053 an R1_COUNTER. This required to make the R1 counter a critical 5054 parameter. Hence, the parameter type number of the R1_COUNTER 5055 changed from 128 to 129. 5057 o Made KDF dependent on DH Group to enable negotiation of the KDF. 5059 11.11. Changes from draft-ietf-hip-rfc5201-bis-05 5061 o Changed type number of DH_GROUP_LIST from 2151 to 511 because it 5062 was in the number space that is reserved for the HIP transport 5063 mode negotiations. 5065 o Added transport form type list parameter. Transport forms are now 5066 negotiated with this list instead of by their order in the HIP 5067 packet. This allows to remove the exception of the transport 5068 format parameters that were ordered by their preference instead of 5069 by their type number. This should remove complexity from 5070 implementations. 5072 o Clarify that in HIP signature processing, the restored checksum 5073 and length fields have been rendered invalid by the previous 5074 steps. 5076 o Clarify behavior for when UPDATE does not contain SEQ or ACQ 5077 (disallow this). 5079 o For namespace changes, changed "IETF Review" to "IETF Review or 5080 IESG Approval". 5082 o Addressed IESG comment about ignoring packet IP addresses. 5084 o Permit using Anonymous HI control in packets other than R1/I2. 5086 o Fixed minor reference error (RFC2418, RFC2410). 5088 o Deleted comment that NULL-ENCRYPTION SHOULD NOT be configurable 5089 via the UI. 5091 o Editorial changes. 5093 11.12. Changes from draft-ietf-hip-rfc5201-bis-04 5095 o Clarifications of the Security Considerations section. One DoS 5096 defense mechanism was changed to be more effective and less prone 5097 to misuse. 5099 o Minor clarifications of the state machine. 5101 o Clarified text on HIP puzzle. 5103 o Added names and references for figures. 5105 o Extended the definitions section. 5107 o Added a reference to the HIP Version 1 certificate document. 5109 o Added Initiator, Responder, HIP association, and signed data to 5110 the definitions section. 5112 o Changed parameter figure for PUZZLE and SOLUTION to use 5113 RHASH_len/8 instead of n-byte. 5115 o Replaced occurrences of lowercase 'not' in SHOULD NOT. 5117 o Changed text to reflect the fact that several 5118 ECHO_REQUEST_UNSIGNED parameters may be present in an R1 and 5119 several ECHO_RESPONSE parameters may be present in an I2. 5121 o Added text on verifying the ECHO_RESPONSE_SIGNED parameter in 5122 CLOSE_ACK. 5124 o Changed wording from HMAC to HIP_MAC in Section 5.3.8. 5126 o Reflected fact that the UPDATE packet MAY include zero or more 5127 ACKs. 5129 o Added BEX to Definitions section. 5131 o Changed HIP_SIGNATURE algorithm field from 8 bit to 16 bit to 5132 achieve alignment with the HOST_ID parameters. 5134 o Fixed the wrong figures of the SEQ and ACK parameters. SEQ always 5135 contains ONE update ID. ACK may acknowledge SEVERAL update IDs. 5137 o Added wording that several NOTIFY parameters may be present in a 5138 HIP packet. 5140 o Changed wording for the ECHO_RESPONSE_SIGNED parameter. Also 5141 lifted the restriction that only one ECHO_RESPONSE_UNSIGNED 5142 parameter MUST be present in each HIP packet. This did contradict 5143 the definition of the ECHO_RESPONSE_UNSIGNED parameter. 5145 o Changed IETF Consensus to IETF Review or IESG Approval in IANA 5146 section. 5148 o Aligned use of I, J, and K. Now I is #I, J is #J and K is #K 5149 throughout the document. 5151 o Updated references. 5153 o Editorial changes. 5155 11.13. Changes from draft-ietf-hip-rfc5201-bis-03 5157 o Editorial changes to improve clarity and readability. 5159 o Removed obsoleted (not applicable) attack from security 5160 consideration section. 5162 o Added a requirement that hosts MUST support processing of ACK 5163 parameters with several SEQ numbers even when they do not support 5164 sending such parameters. 5166 o Removed note on memory bound puzzles. The use of memory bound 5167 puzzles was reconsidered but no convincing arguments for inclusion 5168 in this document have been made on the list. 5170 o Changed references to reference the new bis documents. 5172 o Specified the ECC curves and the hashes used for these. 5174 o Specified representation of ECC curves in the HI. 5176 o Added text on the dependency between RHASH and HMAC. 5178 o Rephrased part of the security considerations to make them 5179 clearer. 5181 o Clarified the use of HITs in opportunistic mode. 5183 o Clarified the difference between HIP_MAC and HIP_MAC_2 as well as 5184 between SIGNATURE and SIGNATURE_2. 5186 o Changed NOTIFY name for value 44 from SERVER_BUSY_PLEASE_RETRY to 5187 RESPONDER_BUSY_PLEASE_RETRY. 5189 o Mentioned that there are multiple valid puzzle solutions. 5191 11.14. Changes from draft-ietf-hip-rfc5201-bis-02 5193 o Added recommendation to not use puzzle #I twice for the same host 5194 to avoid identical key material. 5196 o Revised state machine and added missing event handling. 5198 o Added UNSUPPORTED_HIT_SUITE to NOTIFY to indicate unsupported HIT 5199 suites. 5201 o Revised parameter type numbers (corresponding to IANA allocations) 5202 and added missing "free for experimentation" range to the 5203 description. 5205 o Clarifying note on the use of the C bit in the parameter type 5206 numbers. 5208 11.15. Changes from draft-ietf-hip-rfc5201-bis-01 5210 o Changed RHASH-len to RHASH_len to avoid confusion in calculations 5211 (- could be minus) 5213 o Added RHASH_len to list of abbreviations 5214 o Fixed length of puzzle #I and #J to be 1*RHASH_len 5216 o Changed RHASH-len to RHASH_len to avoid confusion in calculations 5217 (- could be minus) 5219 o Added RHASH_len to list of abbreviations 5221 o Fixed length of puzzle #I and #J to be 1*RHASH_len 5223 o Included HIT_SUITEs. 5225 o Added DH negotiation to I1 and R1. 5227 o Added DH_LIST parameter. 5229 o Added text for DH Group negotiation. 5231 o Removed second DH public value from DH parameter. 5233 o Added ECC to HI generation. 5235 o Added Responder HIT selection to opportunistic mode. 5237 o Added ECDSA HI text and references (not complete yet). 5239 o Added separate section on aborting BEX. 5241 o Added separate section on downgrade attack prevention. 5243 o Added text about DH Group selection for use cases without I1. 5245 o Removed type range allocation for parameters related to HIP 5246 transform types. 5248 o New type range allocation for parameters that are only covered by 5249 a signature if a signature is present (Applies to DH_GROUP_LIST). 5251 o Renamed HIP_TRANSFORM to HIP_CIPHER and removed hashes from it - 5252 hashes are determined by RHASH. 5254 o The length of #I and #J for the puzzle now depends on RHASH. 5256 o New keymat generation. 5258 o Puzzle seed and solution now use RHASH and have variable length. 5260 o Moved timing definitions closer to state machine. 5262 o Simplified text regarding puzzle lifetime. 5264 o Clarified the description of the use of #I in the puzzle 5266 o Removed "Opportunistic mode" description from general definitions. 5268 o More consistency across the old RFC5201 text. Aligned 5269 capitalization and abbreviations. 5271 o Extended protocol overview to include restart option. 5273 o Extended state machine to include restart option because of 5274 unsupported Algorithms. 5276 o Replaced SHA-1 with SHA-256 for required implementation. 5278 o Added OGA list parameter (715) for detecting the Responder's set 5279 of OGAs. 5281 o Added Appendix on ORCHID use in HITs. 5283 o Added truncated SHA-256 option for HITs. 5285 o Added truncated SHA-1 option for HITs. 5287 o Added text about new ORCHID structure to HIT overview. 5289 o Moved Editor role to Robert Moskowitz. 5291 o Added SHA-256 to puzzle parameter. 5293 o Generalized LTRUNC to be hash-function agnostic. 5295 o Added text about RHASH depending on OGA. 5297 11.16. Changes from draft-ietf-hip-rfc5201-bis-00 5299 o Added reasoning why BIS document is needed. 5301 11.17. Contents of draft-ietf-hip-rfc5201-bis-00 5303 o RFC5201 was submitted as draft-RFC. 5305 12. References 5306 12.1. Normative References 5308 [FIPS.180-2.2002] 5309 National Institute of Standards and Technology, "Secure 5310 Hash Standard", FIPS PUB 180-2, August 2002, 5311 . 5314 [I-D.ietf-hip-rfc4843-bis] 5315 Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay 5316 Routable Cryptographic Hash Identifiers Version 2 5317 (ORCHIDv2)", draft-ietf-hip-rfc4843-bis-04 (work in 5318 progress), May 2013. 5320 [I-D.ietf-hip-rfc5202-bis] 5321 Jokela, P., Moskowitz, R., and J. Melen, "Using the 5322 Encapsulating Security Payload (ESP) Transport Format with 5323 the Host Identity Protocol (HIP)", draft-ietf-hip- 5324 rfc5202-bis-05 (work in progress), November 2013. 5326 [NIST.800-131A.2011] 5327 National Institute of Standards and Technology, 5328 "Transitions: Recommendation for Transitioning the Use of 5329 Cryptographic Algorithms and Key Lengths", NIST 800-131A, 5330 January 2011. 5332 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 5333 August 1980. 5335 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 5336 793, September 1981. 5338 [RFC1035] Mockapetris, P., "Domain names - implementation and 5339 specification", STD 13, RFC 1035, November 1987. 5341 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 5342 Requirement Levels", BCP 14, RFC 2119, March 1997. 5344 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within 5345 ESP and AH", RFC 2404, November 1998. 5347 [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and 5348 Its Use With IPsec", RFC 2410, November 1998. 5350 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 5351 (IPv6) Specification", RFC 2460, December 1998. 5353 [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System 5354 (DNS)", RFC 2536, March 1999. 5356 [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain 5357 Name System (DNS)", RFC 3110, May 2001. 5359 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 5360 Diffie-Hellman groups for Internet Key Exchange (IKE)", 5361 RFC 3526, May 2003. 5363 [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher 5364 Algorithm and Its Use with IPsec", RFC 3602, September 5365 2003. 5367 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 5368 RFC 3972, March 2005. 5370 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 5371 Rose, "Resource Records for the DNS Security Extensions", 5372 RFC 4034, March 2005. 5374 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 5375 Network Access Identifier", RFC 4282, December 2005. 5377 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 5378 Message Protocol (ICMPv6) for the Internet Protocol 5379 Version 6 (IPv6) Specification", RFC 4443, March 2006. 5381 [RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using 5382 the Elliptic Curve Digital Signature Algorithm (ECDSA)", 5383 RFC 4754, January 2007. 5385 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 5386 384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007. 5388 [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY 5389 and RRSIG Resource Records for DNSSEC", RFC 5702, October 5390 2009. 5392 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 5393 "Default Address Selection for Internet Protocol Version 6 5394 (IPv6)", RFC 6724, September 2012. 5396 12.2. Informative References 5398 [AUR03] Aura, T., Nagarajan, A., and A. Gurtov, "Analysis of the 5399 HIP Base Exchange Protocol", in Proceedings of 10th 5400 Australasian Conference on Information Security and 5401 Privacy, July 2003. 5403 [CRO03] Crosby, SA. and DS. Wallach, "Denial of Service via 5404 Algorithmic Complexity Attacks", in Proceedings of Usenix 5405 Security Symposium 2003, Washington, DC., August 2003. 5407 [DIF76] Diffie, W. and M. Hellman, "New Directions in 5408 Cryptography", IEEE Transactions on Information Theory 5409 vol. IT-22, number 6, pages 644-654, Nov 1976. 5411 [FIPS.197.2001] 5412 National Institute of Standards and Technology, "Advanced 5413 Encryption Standard (AES)", FIPS PUB 197, November 2001, 5414 . 5417 [FIPS186-3] 5418 U.S. Department of Commerce/National Institute of 5419 Standards and Technology, "FIPS PUB 186-3: Digital 5420 Signature Standard (DSS).", June 2009. 5422 [I-D.ietf-hip-rfc4423-bis] 5423 Moskowitz, R., "Host Identity Protocol Architecture", 5424 draft-ietf-hip-rfc4423-bis-05 (work in progress), 5425 September 2012. 5427 [I-D.ietf-hip-rfc5204-bis] 5428 Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 5429 Rendezvous Extension", draft-ietf-hip-rfc5204-bis-02 (work 5430 in progress), September 2012. 5432 [I-D.ietf-hip-rfc5205-bis] 5433 Laganier, J., "Host Identity Protocol (HIP) Domain Name 5434 System (DNS) Extension", draft-ietf-hip-rfc5205-bis-02 5435 (work in progress), September 2012. 5437 [I-D.ietf-hip-rfc5206-bis] 5438 Henderson, T., Vogt, C., and J. Arkko, "Host Mobility with 5439 the Host Identity Protocol", draft-ietf-hip-rfc5206-bis-06 5440 (work in progress), July 2013. 5442 [KAU03] Kaufman, C., Perlman, R., and B. Sommerfeld, "DoS 5443 protection for UDP-based protocols", ACM Conference on 5444 Computer and Communications Security , Oct 2003. 5446 [KRA03] Krawczyk, H., "SIGMA: The 'SIGn-and-MAc' Approach to 5447 Authenticated Diffie-Hellman and Its Use in the IKE- 5448 Protocols", in Proceedings of CRYPTO 2003, pages 400-425, 5449 August 2003. 5451 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 5452 RFC 792, September 1981. 5454 [RFC2785] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup" 5455 Attacks on the Diffie-Hellman Key Agreement Method for S/ 5456 MIME", RFC 2785, March 2000. 5458 [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography 5459 Specification Version 2.0", RFC 2898, September 2000. 5461 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 5462 Standards (PKCS) #1: RSA Cryptography Specifications 5463 Version 2.1", RFC 3447, February 2003. 5465 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 5466 Reserved for Documentation", RFC 3849, July 2004. 5468 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 5469 "Host Identity Protocol", RFC 5201, April 2008. 5471 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 5472 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 5473 May 2008. 5475 [RFC5338] Henderson, T., Nikander, P., and M. Komu, "Using the Host 5476 Identity Protocol with Legacy Applications", RFC 5338, 5477 September 2008. 5479 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 5480 Shim Protocol for IPv6", RFC 5533, June 2009. 5482 [RFC5747] Wu, J., Cui, Y., Li, X., Xu, M., and C. Metz, "4over6 5483 Transit Solution Using IP Encapsulation and MP-BGP 5484 Extensions", RFC 5747, March 2010. 5486 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 5487 Key Derivation Function (HKDF)", RFC 5869, May 2010. 5489 [RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a 5490 Prime (ECP Groups) for IKE and IKEv2", RFC 5903, June 5491 2010. 5493 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 5494 "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5495 5996, September 2010. 5497 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 5498 Curve Cryptography Algorithms", RFC 6090, February 2011. 5500 [RFC6253] Heer, T. and S. Varjonen, "Host Identity Protocol 5501 Certificates", RFC 6253, May 2011. 5503 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 5504 of IPv6 Extension Headers", RFC 7045, December 2013. 5506 [SECG] SECG, "Recommended Elliptic Curve Domain Parameters", SEC 5507 2 , 2000, . 5509 Appendix A. Using Responder Puzzles 5511 As mentioned in Section 4.1.1, the Responder may delay state creation 5512 and still reject most spoofed I2 packets by using a number of pre- 5513 calculated R1 packets and a local selection function. This appendix 5514 defines one possible implementation in detail. The purpose of this 5515 appendix is to give the implementors an idea on how to implement the 5516 mechanism. If the implementation is based on this appendix, it MAY 5517 contain some local modification that makes an attacker's task harder. 5519 The Responder creates a secret value S, that it regenerates 5520 periodically. The Responder needs to remember the two latest values 5521 of S. Each time the S is regenerated, the R1 generation counter 5522 value is incremented by one. 5524 The Responder generates a pre-signed R1 packet. The signature for 5525 pre-generated R1s must be recalculated when the Diffie-Hellman key is 5526 recomputed or when the R1_COUNTER value changes due to S value 5527 regeneration. 5529 When the Initiator sends the I1 packet for initializing a connection, 5530 the Responder receives the HIT and IP address from the packet, and 5531 generates an #I value for the puzzle. The #I value is set to the 5532 pre-signed R1 packet. 5534 #I value calculation: 5535 #I = Ltrunc( RHASH ( S | HIT-I | HIT-R | IP-I | IP-R ), n) 5536 where n = RHASH_len 5538 The RHASH algorithm is the same that is used to generate the 5539 Responder's HIT value. 5541 From an incoming I2 packet, the Responder receives the required 5542 information to validate the puzzle: HITs, IP addresses, and the 5543 information of the used S value from the R1_COUNTER. Using these 5544 values, the Responder can regenerate the #I, and verify it against 5545 the #I received in the I2 packet. If the #I values match, it can 5546 verify the solution using #I, #J, and difficulty #K. If the #I 5547 values do not match, the I2 is dropped. 5549 puzzle_check: 5550 V := Ltrunc( RHASH( I2.I | I2.hit_i | I2.hit_r | I2.J ), #K ) 5551 if V != 0, drop the packet 5553 If the puzzle solution is correct, the #I and #J values are stored 5554 for later use. They are used as input material when keying material 5555 is generated. 5557 Keeping state about failed puzzle solutions depends on the 5558 implementation. Although it is possible for the Responder not to 5559 keep any state information, it still may do so to protect itself 5560 against certain attacks (see Section 4.1.1). 5562 Appendix B. Generating a Public Key Encoding from an HI 5564 The following pseudo-code illustrates the process to generate a 5565 public key encoding from an HI for both RSA and DSA. 5567 The symbol ":=" denotes assignment; the symbol "+=" denotes 5568 appending. The pseudo-function "encode_in_network_byte_order" takes 5569 two parameters, an integer (bignum) and a length in bytes, and 5570 returns the integer encoded into a byte string of the given length. 5572 switch ( HI.algorithm ) 5573 { 5575 case RSA: 5576 buffer := encode_in_network_byte_order ( HI.RSA.e_len, 5577 ( HI.RSA.e_len > 255 ) ? 3 : 1 ) 5578 buffer += encode_in_network_byte_order ( HI.RSA.e, HI.RSA.e_len ) 5579 buffer += encode_in_network_byte_order ( HI.RSA.n, HI.RSA.n_len ) 5580 break; 5582 case DSA: 5583 buffer := encode_in_network_byte_order ( HI.DSA.T , 1 ) 5584 buffer += encode_in_network_byte_order ( HI.DSA.Q , 20 ) 5585 buffer += encode_in_network_byte_order ( HI.DSA.P , 64 + 5586 8 * HI.DSA.T ) 5587 buffer += encode_in_network_byte_order ( HI.DSA.G , 64 + 5588 8 * HI.DSA.T ) 5589 buffer += encode_in_network_byte_order ( HI.DSA.Y , 64 + 5590 8 * HI.DSA.T ) 5591 break; 5593 } 5595 Appendix C. Example Checksums for HIP Packets 5597 The HIP checksum for HIP packets is specified in Section 5.1.1. 5598 Checksums for TCP and UDP packets running over HIP-enabled security 5599 associations are specified in Section 3.5. The examples below use 5600 [RFC3849] and [RFC5747] addresses, and HITs with the prefix of 5601 2001:10 followed by zeros, followed by a decimal 1 or 2, 5602 respectively. 5604 The following example is defined only for testing the checksum 5605 calculation. 5607 C.1. IPv6 HIP Example (I1 packet) 5609 Source Address: 2001:D88::1 5610 Destination Address: 2001:D88::2 5611 Upper-Layer Packet Length: 48 0x30 5612 Next Header: 139 0x8b 5613 Payload Protocol: 59 0x3b 5614 Header Length: 4 0x4 5615 Packet Type: 1 0x1 5616 Version: 2 0x2 5617 Reserved: 1 0x1 5618 Control: 0 0x0 5619 Checksum: 6878 0x1ade 5620 Sender's HIT : 2001:10::1 5621 Receiver's HIT: 2001:10::2 5622 DH_GROUP_LIST type: 511 0x1ff 5623 DH_GROUP_LIST length: 3 0x3 5624 DH_GROUP_LIST group IDs: 3,4,8 5626 C.2. IPv4 HIP Packet (I1 packet) 5628 The IPv4 checksum value for the example I1 packet is shown below. 5630 Source Address: 192.0.2.1 5631 Destination Address: 192.0.2.2 5632 Upper-Layer Packet Length: 48 0x30 5633 Next Header: 139 0x8b 5634 Payload Protocol: 59 0x3b 5635 Header Length: 4 0x4 5636 Packet Type: 1 0x1 5637 Version: 2 0x2 5638 Reserved: 1 0x1 5639 Control: 0 0x0 5640 Checksum: 61934 0xf1ee 5641 Sender's HIT : 2001:10::1 5642 Receiver's HIT: 2001:10::2 5643 DH_GROUP_LIST type: 511 0x1ff 5644 DH_GROUP_LIST length: 3 0x3 5645 DH_GROUP_LIST group IDs: 3,4,8 5647 C.3. TCP Segment 5649 Regardless of whether IPv6 or IPv4 is used, the TCP and UDP sockets 5650 use the IPv6 pseudo-header format [RFC2460], with the HITs used in 5651 place of the IPv6 addresses. 5653 Sender's HIT: 2001:10::1 5654 Receiver's HIT: 2001:10::2 5655 Upper-Layer Packet Length: 20 0x14 5656 Next Header: 6 0x06 5657 Source port: 65500 0xffdc 5658 Destination port: 22 0x0016 5659 Sequence number: 1 0x00000001 5660 Acknowledgment number: 0 0x00000000 5661 Header length: 20 0x14 5662 Flags: SYN 0x02 5663 Window size: 65535 0xffff 5664 Checksum: 28618 0x6fca 5665 Urgent pointer: 0 0x0000 5667 0x0000: 6000 0000 0014 0640 2001 0010 0000 0000 5668 0x0010: 0000 0000 0000 0001 2001 0010 0000 0000 5669 0x0020: 0000 0000 0000 0002 ffdc 0016 0000 0001 5670 0x0030: 0000 0000 5002 ffff 6fca 0000 5672 Appendix D. ECDH and ECDSA 160 Bit Groups 5674 The ECDH and ECDSA 160-bit group SECP160R1 is rated at 80 bits 5675 symmetric strength. Once this was considered appropriate for one 5676 year of security. Today these groups should be used only when the 5677 host is not powerful enough (e.g., some embedded devices) and when 5678 security requirements are low (e.g., long-term confidentiality is not 5679 required). 5681 Appendix E. HIT Suites and HIT Generation 5683 The HIT as an ORCHID [I-D.ietf-hip-rfc4843-bis] consists of three 5684 parts: A 28-bit prefix, a 4-bit encoding of the ORCHID generation 5685 algorithm (OGA) and the representation of the public key. The OGA is 5686 an index pointing to the specific algorithm by which the public key 5687 and the 96-bit hashed encoding is generated. The OGA is protocol 5688 specific and is to be interpreted as defined below for all protocols 5689 that use the same context ID as HIP. HIP groups sets of valid 5690 combinations of signature and hash algorithms into HIT Suites. These 5691 HIT suites are addressed by an index, which is transmitted in the OGA 5692 field of the ORCHID. 5694 The set of used HIT Suites will be extended to counter the progress 5695 in computation capabilities and vulnerabilities in the employed 5696 algorithms. The intended use of the HIT Suites is to introduce a new 5697 HIT Suite and phase out an old one before it becomes insecure. Since 5698 the 4-bit OGA field only permits 15 HIT Suites (the HIT Suite with ID 5699 0 is reserved) to be used in parallel, phased-out HIT Suites must be 5700 reused at some point. In such a case, there will be a rollover of 5701 the HIT Suite ID and the next newly introduced HIT Suite will start 5702 with a lower HIT Suite index than the previously introduced one. The 5703 rollover effectively deprecates the reused HIT Suite. For a smooth 5704 transition, the HIT Suite should be deprecated a considerable time 5705 before the HIT Suite index is reused. 5707 Since the number of HIT Suites is tightly limited to 16, the HIT 5708 Suites must be assigned carefully. Hence, sets of suitable 5709 algorithms are grouped in a HIT Suite. 5711 The HIT Suite of the Responder's HIT determines the RHASH and the 5712 hash function to be used for the HMAC in HIP packets as well as the 5713 signature algorithm family used for generating the HI. The list of 5714 HIT Suites is defined in Table 11. 5716 The following HIT Suites are defined for HIT generation. The input 5717 for each generation algorithm is the encoding of the HI as defined in 5718 Section 3.2. The output is 96 bits long and is directly used in the 5719 ORCHID. 5721 +-------+----------+--------------+------------+--------------------+ 5722 | Index | Hash | HMAC | Signature | Description | 5723 | | function | | algorithm | | 5724 | | | | family | | 5725 +-------+----------+--------------+------------+--------------------+ 5726 | 0 | | | | Reserved | 5727 | 1 | SHA-256 | HMAC-SHA-256 | RSA, DSA | RSA or DSA HI | 5728 | | | | | hashed with | 5729 | | | | | SHA-256, truncated | 5730 | | | | | to 96 bits | 5731 | 2 | SHA-384 | HMAC-SHA-384 | ECDSA | ECDSA HI hashed | 5732 | | | | | with SHA-384, | 5733 | | | | | truncated to 96 | 5734 | | | | | bits | 5735 | 3 | SHA-1 | HMAC-SHA-1 | ECDSA_LOW | ECDSA_LOW HI | 5736 | | | | | hashed with SHA-1, | 5737 | | | | | truncated to 96 | 5738 | | | | | bits | 5739 +-------+----------+--------------+------------+--------------------+ 5741 Table 11: HIT Suites 5743 The hash of the responder as defined in the HIT Suite determines the 5744 HMAC to be used for the HMAC parameter. The HMACs currently defined 5745 here are HMAC-SHA-256 [RFC4868], HMAC-SHA-384 [RFC4868], and HMAC- 5746 SHA-1 [RFC2404]. 5748 Authors' Addresses 5750 Robert Moskowitz (editor) 5751 Verizon Telcom and Business 5752 1000 Bent Creek Blvd, Suite 200 5753 Mechanicsburg, PA 5754 USA 5756 EMail: robert.moskowitz@verizonbusiness.com 5758 Tobias Heer 5759 Hirschmann Automation and Control 5760 Stuttgarter Strasse 45-51 5761 Neckartenzlingen 72654 5762 Germany 5764 EMail: tobias.heer@belden.com 5766 Petri Jokela 5767 Ericsson Research NomadicLab 5768 JORVAS FIN-02420 5769 FINLAND 5771 Phone: +358 9 299 1 5772 EMail: petri.jokela@nomadiclab.com 5774 Thomas R. Henderson 5775 University of Washington 5776 Campus Box 352500 5777 Seattle, WA 5778 USA 5780 EMail: tomhend@u.washington.edu