idnits 2.17.1 draft-ietf-hip-rfc5201-bis-20.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 2196 has weird spacing: '...c Value leng...' == Line 2198 has weird spacing: '...c Value the ...' == Line 2766 has weird spacing: '...ication info...' == Line 2904 has weird spacing: '...ue data opaqu...' == Line 2934 has weird spacing: '...ue data opaqu...' == (2 more instances...) -- The document date (October 29, 2014) is 3460 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-07) exists of draft-ietf-hip-rfc5202-bis-05 ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542) == Outdated reference: A later version (-20) exists of draft-ietf-hip-rfc4423-bis-05 == Outdated reference: A later version (-08) exists of draft-ietf-hip-rfc5204-bis-02 == Outdated reference: A later version (-10) exists of draft-ietf-hip-rfc5205-bis-02 == Outdated reference: A later version (-14) exists of draft-ietf-hip-rfc5206-bis-06 -- Obsolete informational reference (is this intentional?): RFC 2898 (Obsoleted by RFC 8018) -- Obsolete informational reference (is this intentional?): RFC 3447 (Obsoleted by RFC 8017) -- Obsolete informational reference (is this intentional?): RFC 5201 (Obsoleted by RFC 7401) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) -- Obsolete informational reference (is this intentional?): RFC 6253 (Obsoleted by RFC 8002) Summary: 3 errors (**), 0 flaws (~~), 13 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Moskowitz, Ed. 3 Internet-Draft Verizon 4 Obsoletes: 5201 (if approved) T. Heer 5 Intended status: Standards Track Hirschmann Automation and Control 6 Expires: May 2, 2015 P. Jokela 7 Ericsson Research NomadicLab 8 T. Henderson 9 University of Washington 10 October 29, 2014 12 Host Identity Protocol Version 2 (HIPv2) 13 draft-ietf-hip-rfc5201-bis-20 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 May 2, 2015. 50 Copyright Notice 52 Copyright (c) 2014 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 68 1.1. A New Namespace and Identifiers . . . . . . . . . . . . . 6 69 1.2. The HIP Base Exchange (BEX) . . . . . . . . . . . . . . . 7 70 1.3. Memo Structure . . . . . . . . . . . . . . . . . . . . . 7 71 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 8 72 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 8 73 2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 8 74 2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 8 75 3. Host Identity (HI) and its Structure . . . . . . . . . . . . 9 76 3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 10 77 3.2. Generating a HIT from an HI . . . . . . . . . . . . . . . 11 78 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 12 79 4.1. Creating a HIP Association . . . . . . . . . . . . . . . 12 80 4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . 14 81 4.1.2. Puzzle Exchange . . . . . . . . . . . . . . . . . . . 15 82 4.1.3. Authenticated Diffie-Hellman Protocol with DH Group 83 Negotiation . . . . . . . . . . . . . . . . . . . . . 16 84 4.1.4. HIP Replay Protection . . . . . . . . . . . . . . . . 18 85 4.1.5. Refusing a HIP base exchange . . . . . . . . . . . . 19 86 4.1.6. Aborting a HIP base exchange . . . . . . . . . . . . 19 87 4.1.7. HIP Downgrade Protection . . . . . . . . . . . . . . 20 88 4.1.8. HIP Opportunistic Mode . . . . . . . . . . . . . . . 21 89 4.2. Updating a HIP Association . . . . . . . . . . . . . . . 23 90 4.3. Error Processing . . . . . . . . . . . . . . . . . . . . 24 91 4.4. HIP State Machine . . . . . . . . . . . . . . . . . . . . 25 92 4.4.1. State Machine Terminology . . . . . . . . . . . . . . 26 93 4.4.2. HIP States . . . . . . . . . . . . . . . . . . . . . 26 94 4.4.3. HIP State Processes . . . . . . . . . . . . . . . . . 27 95 4.4.4. Simplified HIP State Diagram . . . . . . . . . . . . 35 97 4.5. User Data Considerations . . . . . . . . . . . . . . . . 37 98 4.5.1. TCP and UDP Pseudo-Header Computation for User Data . 37 99 4.5.2. Sending Data on HIP Packets . . . . . . . . . . . . . 37 100 4.5.3. Transport Formats . . . . . . . . . . . . . . . . . . 37 101 4.5.4. Reboot, Timeout, and Restart of HIP . . . . . . . . . 37 102 4.6. Certificate Distribution . . . . . . . . . . . . . . . . 38 103 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 38 104 5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 38 105 5.1.1. Checksum . . . . . . . . . . . . . . . . . . . . . . 40 106 5.1.2. HIP Controls . . . . . . . . . . . . . . . . . . . . 40 107 5.1.3. HIP Fragmentation Support . . . . . . . . . . . . . . 40 108 5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 41 109 5.2.1. TLV Format . . . . . . . . . . . . . . . . . . . . . 44 110 5.2.2. Defining New Parameters . . . . . . . . . . . . . . . 46 111 5.2.3. R1_COUNTER . . . . . . . . . . . . . . . . . . . . . 46 112 5.2.4. PUZZLE . . . . . . . . . . . . . . . . . . . . . . . 47 113 5.2.5. SOLUTION . . . . . . . . . . . . . . . . . . . . . . 48 114 5.2.6. DH_GROUP_LIST . . . . . . . . . . . . . . . . . . . . 49 115 5.2.7. DIFFIE_HELLMAN . . . . . . . . . . . . . . . . . . . 51 116 5.2.8. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . 52 117 5.2.9. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 53 118 5.2.10. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 55 119 5.2.11. TRANSPORT_FORMAT_LIST . . . . . . . . . . . . . . . . 57 120 5.2.12. HIP_MAC . . . . . . . . . . . . . . . . . . . . . . . 58 121 5.2.13. HIP_MAC_2 . . . . . . . . . . . . . . . . . . . . . . 59 122 5.2.14. HIP_SIGNATURE . . . . . . . . . . . . . . . . . . . . 60 123 5.2.15. HIP_SIGNATURE_2 . . . . . . . . . . . . . . . . . . . 61 124 5.2.16. SEQ . . . . . . . . . . . . . . . . . . . . . . . . . 61 125 5.2.17. ACK . . . . . . . . . . . . . . . . . . . . . . . . . 62 126 5.2.18. ENCRYPTED . . . . . . . . . . . . . . . . . . . . . . 62 127 5.2.19. NOTIFICATION . . . . . . . . . . . . . . . . . . . . 64 128 5.2.20. ECHO_REQUEST_SIGNED . . . . . . . . . . . . . . . . . 67 129 5.2.21. ECHO_REQUEST_UNSIGNED . . . . . . . . . . . . . . . . 68 130 5.2.22. ECHO_RESPONSE_SIGNED . . . . . . . . . . . . . . . . 68 131 5.2.23. ECHO_RESPONSE_UNSIGNED . . . . . . . . . . . . . . . 69 132 5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 70 133 5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 71 134 5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 71 135 5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 74 136 5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 76 137 5.3.5. UPDATE - the HIP Update Packet . . . . . . . . . . . 76 138 5.3.6. NOTIFY - the HIP Notify Packet . . . . . . . . . . . 77 139 5.3.7. CLOSE - the HIP Association Closing Packet . . . . . 78 140 5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet . . 78 141 5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 79 142 5.4.1. Invalid Version . . . . . . . . . . . . . . . . . . . 79 143 5.4.2. Other Problems with the HIP Header and Packet 144 Structure . . . . . . . . . . . . . . . . . . . . . . 79 146 5.4.3. Invalid Puzzle Solution . . . . . . . . . . . . . . . 79 147 5.4.4. Non-Existing HIP Association . . . . . . . . . . . . 80 148 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 80 149 6.1. Processing Outgoing Application Data . . . . . . . . . . 80 150 6.2. Processing Incoming Application Data . . . . . . . . . . 81 151 6.3. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 82 152 6.4. HIP_MAC and SIGNATURE Calculation and Verification . . . 84 153 6.4.1. HMAC Calculation . . . . . . . . . . . . . . . . . . 84 154 6.4.2. Signature Calculation . . . . . . . . . . . . . . . . 86 155 6.5. HIP KEYMAT Generation . . . . . . . . . . . . . . . . . . 88 156 6.6. Initiation of a HIP Base Exchange . . . . . . . . . . . . 90 157 6.6.1. Sending Multiple I1 Packets in Parallel . . . . . . . 91 158 6.6.2. Processing Incoming ICMP Protocol Unreachable 159 Messages . . . . . . . . . . . . . . . . . . . . . . 91 160 6.7. Processing Incoming I1 Packets . . . . . . . . . . . . . 92 161 6.7.1. R1 Management . . . . . . . . . . . . . . . . . . . . 93 162 6.7.2. Handling Malformed Messages . . . . . . . . . . . . . 93 163 6.8. Processing Incoming R1 Packets . . . . . . . . . . . . . 94 164 6.8.1. Handling of Malformed Messages . . . . . . . . . . . 96 165 6.9. Processing Incoming I2 Packets . . . . . . . . . . . . . 96 166 6.9.1. Handling of Malformed Messages . . . . . . . . . . . 99 167 6.10. Processing of Incoming R2 Packets . . . . . . . . . . . . 100 168 6.11. Sending UPDATE Packets . . . . . . . . . . . . . . . . . 100 169 6.12. Receiving UPDATE Packets . . . . . . . . . . . . . . . . 101 170 6.12.1. Handling a SEQ Parameter in a Received UPDATE 171 Message . . . . . . . . . . . . . . . . . . . . . . 102 172 6.12.2. Handling an ACK Parameter in a Received UPDATE 173 Packet . . . . . . . . . . . . . . . . . . . . . . . 103 174 6.13. Processing of NOTIFY Packets . . . . . . . . . . . . . . 103 175 6.14. Processing CLOSE Packets . . . . . . . . . . . . . . . . 104 176 6.15. Processing CLOSE_ACK Packets . . . . . . . . . . . . . . 104 177 6.16. Handling State Loss . . . . . . . . . . . . . . . . . . . 104 178 7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 105 179 8. Security Considerations . . . . . . . . . . . . . . . . . . . 105 180 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 108 181 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 112 182 11. Changes from RFC 5201 . . . . . . . . . . . . . . . . . . . . 113 183 11.1. Changes from draft-ietf-hip-rfc5201-bis-19 . . . . . . . 113 184 11.2. Changes from draft-ietf-hip-rfc5201-bis-18 . . . . . . . 113 185 11.3. Changes from draft-ietf-hip-rfc5201-bis-17 . . . . . . . 113 186 11.4. Changes from draft-ietf-hip-rfc5201-bis-16 . . . . . . . 114 187 11.5. Changes from draft-ietf-hip-rfc5201-bis-15 . . . . . . . 114 188 11.6. Changes from draft-ietf-hip-rfc5201-bis-14 . . . . . . . 114 189 11.7. Changes from draft-ietf-hip-rfc5201-bis-13 . . . . . . . 114 190 11.8. Changes from draft-ietf-hip-rfc5201-bis-12 . . . . . . . 114 191 11.9. Changes from draft-ietf-hip-rfc5201-bis-11 . . . . . . . 114 192 11.10. Changes from draft-ietf-hip-rfc5201-bis-10 . . . . . . . 114 193 11.11. Changes from draft-ietf-hip-rfc5201-bis-09 . . . . . . . 115 194 11.12. Changes from draft-ietf-hip-rfc5201-bis-08 . . . . . . . 115 195 11.13. Changes from draft-ietf-hip-rfc5201-bis-07 . . . . . . . 115 196 11.14. Changes from draft-ietf-hip-rfc5201-bis-06 . . . . . . . 115 197 11.15. Changes from draft-ietf-hip-rfc5201-bis-05 . . . . . . . 115 198 11.16. Changes from draft-ietf-hip-rfc5201-bis-04 . . . . . . . 116 199 11.17. Changes from draft-ietf-hip-rfc5201-bis-03 . . . . . . . 117 200 11.18. Changes from draft-ietf-hip-rfc5201-bis-02 . . . . . . . 118 201 11.19. Changes from draft-ietf-hip-rfc5201-bis-01 . . . . . . . 118 202 11.20. Changes from draft-ietf-hip-rfc5201-bis-00 . . . . . . . 120 203 11.21. Contents of draft-ietf-hip-rfc5201-bis-00 . . . . . . . 120 204 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 120 205 12.1. Normative References . . . . . . . . . . . . . . . . . . 120 206 12.2. Informative References . . . . . . . . . . . . . . . . . 122 207 Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 126 208 Appendix B. Generating a Public Key Encoding from an HI . . 127 209 Appendix C. Example Checksums for HIP Packets . . . . . . . . . 127 210 C.1. IPv6 HIP Example (I1 packet) . . . . . . . . . . . . . . 128 211 C.2. IPv4 HIP Packet (I1 packet) . . . . . . . . . . . . . . . 128 212 C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . . 129 213 Appendix D. ECDH and ECDSA 160 Bit Groups . . . . . . . . . . . 129 214 Appendix E. HIT Suites and HIT Generation . . . . . . . . . . . 129 216 1. Introduction 218 This document specifies the details of the Host Identity Protocol 219 (HIP). A high-level description of the protocol and the underlying 220 architectural thinking is available in the separate HIP architecture 221 description [I-D.ietf-hip-rfc4423-bis]. Briefly, the HIP 222 architecture proposes an alternative to the dual use of IP addresses 223 as "locators" (routing labels) and "identifiers" (endpoint, or host, 224 identifiers). In HIP, public cryptographic keys, of a public/private 225 key pair, are used as Host Identifiers, to which higher layer 226 protocols are bound instead of an IP address. By using public keys 227 (and their representations) as host identifiers, dynamic changes to 228 IP address sets can be directly authenticated between hosts, and if 229 desired, strong authentication between hosts at the TCP/IP stack 230 level can be obtained. 232 This memo specifies the base HIP protocol ("base exchange") used 233 between hosts to establish an IP-layer communications context, called 234 a HIP association, prior to communications. It also defines a packet 235 format and procedures for updating and terminating an active HIP 236 association. Other elements of the HIP architecture are specified in 237 other documents, such as: 239 o "Using the Encapsulating Security Payload (ESP) transport format 240 with the Host Identity Protocol (HIP)" [I-D.ietf-hip-rfc5202-bis]: 242 how to use the Encapsulating Security Payload (ESP) for integrity 243 protection and optional encryption 245 o "Host Mobility with the Host Identity Protocol" 246 [I-D.ietf-hip-rfc5206-bis]: how to support host mobility in HIP 248 o "Host Identity Protocol (HIP) Domain Name System (DNS) Extensions" 249 [I-D.ietf-hip-rfc5205-bis]: how to extend DNS to contain Host 250 Identity information 252 o "Host Identity Protocol (HIP) Rendezvous Extension" 253 [I-D.ietf-hip-rfc5204-bis]: using a rendezvous mechanism to 254 contact mobile HIP hosts 256 Since the HIP base exchange was first developed, there have been a 257 few advances in cryptography and attacks against cryptographic 258 systems. As a result, all cryptographic protocols need to be agile. 259 That is, it should be a part of the protocol to be able to switch 260 from one cryptographic primitive to another. It is important to 261 support a reasonable set of mainstream algorithms to cater for 262 different use cases and allow moving away from algorithms that are 263 later discovered to be vulnerable. This update to the base exchange 264 includes this needed cryptographic agility while addressing the 265 downgrade attacks that such flexibility introduces. In particular, 266 Elliptic Curve support by Elliptic Curve DSA (ECDSA) and Elliptic 267 Curve Diffie-Hellman (ECDH) and alternative hash functions have been 268 added. 270 1.1. A New Namespace and Identifiers 272 The Host Identity Protocol introduces a new namespace, the Host 273 Identity namespace. Some ramifications of this new namespace are 274 explained in the HIP architecture description 275 [I-D.ietf-hip-rfc4423-bis]. 277 There are two main representations of the Host Identity, the full 278 Host Identity (HI) and the Host Identity Tag (HIT). The HI is a 279 public key and directly represents the Identity of a host. Since 280 there are different public key algorithms that can be used with 281 different key lengths, the HI, as such, is unsuitable for use as a 282 packet identifier, or as an index into the various state-related 283 implementation structures needed to support HIP. Consequently, a 284 hash of the HI, the Host Identity Tag (HIT), is used as the 285 operational representation. The HIT is 128 bits long and is used in 286 the HIP headers and to index the corresponding state in the end 287 hosts. The HIT has an important security property in that it is 288 self-certifying (see Section 3). 290 1.2. The HIP Base Exchange (BEX) 292 The HIP base exchange is a two-party cryptographic protocol used to 293 establish communications context between hosts. The base exchange is 294 a SIGMA-compliant [KRA03] four-packet exchange. The first party is 295 called the Initiator and the second party the Responder. The 296 protocol exchanges Diffie-Hellman [DIF76] keys in the 2nd and 3rd 297 packets, and authenticates the parties in the 3rd and 4th packets. 298 The four-packet design helps to make HIP DoS resilient. It allows 299 the Responder to stay stateless until the IP address and the 300 cryptographic puzzle is verified. The Responder starts the puzzle 301 exchange in the 2nd packet, with the Initiator completing it in the 302 3rd packet before the Responder stores any state from the exchange. 304 The exchange can use the Diffie-Hellman output to encrypt the Host 305 Identity of the Initiator in the 3rd packet (although Aura, et al., 306 [AUR03] notes that such operation may interfere with packet- 307 inspecting middleboxes), or the Host Identity may instead be sent 308 unencrypted. The Responder's Host Identity is not protected. It 309 should be noted, however, that both the Initiator's and the 310 Responder's HITs are transported as such (in cleartext) in the 311 packets, allowing an eavesdropper with a priori knowledge about the 312 parties to identify them by their HITs. Hence, encrypting the HI of 313 any party does not provide privacy against such attacker. 315 Data packets start to flow after the 4th packet. The 3rd and 4th HIP 316 packets may carry a data payload in the future. However, the details 317 of this may be defined later. 319 An existing HIP association can be updated using the update mechanism 320 defined in this document, and when the association is no longer 321 needed, it can be closed using the defined closing mechanism. 323 Finally, HIP is designed as an end-to-end authentication and key 324 establishment protocol, to be used with Encapsulated Security Payload 325 (ESP) [I-D.ietf-hip-rfc5202-bis] and other end-to-end security 326 protocols. The base protocol does not cover all the fine-grained 327 policy control found in Internet Key Exchange (IKE) [RFC5996] that 328 allows IKE to support complex gateway policies. Thus, HIP is not a 329 complete replacement for IKE. 331 1.3. Memo Structure 333 The rest of this memo is structured as follows. Section 2 defines 334 the central keywords, notation, and terms used throughout the rest of 335 the document. Section 3 defines the structure of the Host Identity 336 and its various representations. Section 4 gives an overview of the 337 HIP base exchange protocol. Sections 5 and 6 define the detailed 338 packet formats and rules for packet processing. Finally, Sections 7, 339 8, and 9 discuss policy, security, and IANA considerations, 340 respectively. 342 2. Terms and Definitions 344 2.1. Requirements Terminology 346 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 347 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 348 document are to be interpreted as described in RFC 2119 [RFC2119]. 350 2.2. Notation 352 [x] indicates that x is optional. 354 {x} indicates that x is encrypted. 356 X(y) indicates that y is a parameter of X. 358 i indicates that x exists i times. 360 --> signifies "Initiator to Responder" communication (requests). 362 <-- signifies "Responder to Initiator" communication (replies). 364 | signifies concatenation of information (e.g., X | Y is the 365 concatenation of X with Y). 367 Ltrunc (H(x), K) denotes the lowest order #K bits of the result of 368 the hash function H on the input x. 370 2.3. Definitions 372 HIP base exchange (BEX): the handshake for establishing a new HIP 373 association. 375 Host Identity (HI): The public key of the signature algorithm that 376 represents the identity of the host. In HIP, a host proves its 377 identity by creating a signature with the private key belonging to 378 its HI (c.f. Section 3). 380 Host Identity Tag (HIT): A shorthand for the HI in IPv6 format. It 381 is generated by hashing the HI (c.f. Section 3.1). 383 HIT Suite: A HIT Suite groups all cryptographic algorithms that are 384 required to generate and use an HI and its HIT. In particular, 385 these algorithms are: 1) the public key signature algorithm and 2) 386 the hash function, 3) the truncation (c.f. Appendix E). 388 HIP association: The shared state between two peers after 389 completion of the BEX. 391 HIP packet: A control packet carrying a HIP packet header relating 392 to the establishment, maintenance, or termination of the HIP 393 association. 395 Initiator: The host that initiates the BEX. This role is typically 396 forgotten once the BEX is completed. 398 Responder: The host that responds to the Initiator in the BEX. 399 This role is typically forgotten once the BEX is completed. 401 Responder's HIT Hash Algorithm (RHASH): The Hash algorithm used for 402 various hash calculations in this document. The algorithm is the 403 same as is used to generate the Responder's HIT. The RHASH is the 404 hash function defined by the HIT Suite of the Responder's HIT 405 (c.f. Section 5.2.10). 407 Length of the Responder's HIT Hash Algorithm (RHASH_len): The 408 natural output length of RHASH in bits. 410 Signed data: Data that is signed is protected by a digital 411 signature that was created by the sender of the data by using the 412 private key of its HI. 414 KDF: The Key Derivation Function (KDF) is used for deriving the 415 symmetric keys from the Diffie-Hellman key exchange. 417 KEYMAT: The keying material derived from the Diffie-Hellman key 418 exchange by using the KDF. Symmetric keys for encryption and 419 integrity protection of HIP packets and encrypted user data 420 packets are drawn from this keying material. 422 3. Host Identity (HI) and its Structure 424 In this section, the properties of the Host Identity and Host 425 Identity Tag are discussed, and the exact format for them is defined. 426 In HIP, the public key of an asymmetric key pair is used as the Host 427 Identity (HI). Correspondingly, the host itself is defined as the 428 entity that holds the private key of the key pair. See the HIP 429 architecture specification [I-D.ietf-hip-rfc4423-bis] for more 430 details on the difference between an identity and the corresponding 431 identifier. 433 HIP implementations MUST support the Rivest Shamir Adelman [RSA] 434 public key algorithm and the Elliptic Curve Digital Signature 435 Algorithm (ECDSA) for generating the HI as defined in Section 5.2.9. 436 Additional algorithms MAY be supported. 438 A hashed encoding of the HI, the Host Identity Tag (HIT), is used in 439 protocols to represent the Host Identity. The HIT is 128 bits long 440 and has the following three key properties: i) it is the same length 441 as an IPv6 address and can be used in fixed address-sized fields in 442 APIs and protocols, ii) it is self-certifying (i.e., given a HIT, it 443 is computationally hard to find a Host Identity key that matches the 444 HIT), and iii) the probability of a HIT collision between two hosts 445 is very low, hence, it is infeasible for an attacker to find a 446 collision with a HIT that is in use. For details on the security 447 properties of the HIT see [I-D.ietf-hip-rfc4423-bis]. 449 The structure of the HIT is defined in [RFC7343]. The HIT is an 450 Overlay Routable Cryptographic Hash Identifier (ORCHID) and consists 451 of three parts: first, an IANA assigned prefix to distinguish it from 452 other IPv6 addresses. Second, a four-bit encoding of the algorithms 453 that were used for generating the HI and the hashed representation of 454 HI. Third, a 96-bit hashed representation of the Host Identity. The 455 encoding of the ORCHID generation algorithm and the exact algorithm 456 for generating the hashed representation is specified in Appendix E 457 and [RFC7343]. 459 Carrying HIs and HITs in the header of user data packets would 460 increase the overhead of packets. Thus, it is not expected that they 461 are carried in every packet, but other methods are used to map the 462 data packets to the corresponding HIs. In some cases, this makes it 463 possible to use HIP without any additional headers in the user data 464 packets. For example, if ESP is used to protect data traffic, the 465 Security Parameter Index (SPI) carried in the ESP header can be used 466 to map the encrypted data packet to the correct HIP association. 468 3.1. Host Identity Tag (HIT) 470 The Host Identity Tag is a 128-bit value -- a hashed encoding of the 471 Host Identifier. There are two advantages of using a hashed encoding 472 over the actual variable-sized Host Identity public key in protocols. 473 First, the fixed length of the HIT keeps packet sizes manageable and 474 eases protocol coding. Second, it presents a consistent format for 475 the protocol, independent of the underlying identity technology in 476 use. 478 RFC 7343 [RFC7343] specifies 128-bit hash-based identifiers, called 479 Overlay Routable Cryptographic Hash Identifiers, ORCHIDs. Their 480 prefix, allocated from the IPv6 address block, is defined in 481 [RFC7343]. The Host Identity Tag is one type of an ORCHID. 483 This document extends the original, experimental HIP specification 484 [RFC5201] with measures to support crypto agility. One of these 485 measures is to allow different hash functions for creating a HIT. 486 HIT Suites group the sets of algorithms that are required to generate 487 and use a particular HIT. The Suites are encoded in HIT Suite IDs. 488 These HIT Suite IDs are transmitted in the ORCHID Generation 489 Algorithm (OGA) field in the ORCHID. With the HIT Suite ID in the 490 OGA field, a host can tell from another host's HIT, whether it 491 supports the necessary hash and signature algorithms to establish a 492 HIP association with that host. 494 3.2. Generating a HIT from an HI 496 The HIT MUST be generated according to the ORCHID generation method 497 described in [RFC7343] using a context ID value of 0xF0EF F02F BFF4 498 3D0F E793 0C3C 6E61 74EA (this tag value has been generated randomly 499 by the editor of this specification), and an input that encodes the 500 Host Identity field (see Section 5.2.9) present in a HIP payload 501 packet. The set of hash function, signature algorithm, and the 502 algorithm used for generating the HIT from the HI depends on the HIT 503 Suite (see Section 5.2.10) and is indicated by the four bits of the 504 ORCHID Generation Algorithm (OGA) field in the ORCHID. Currently, 505 truncated SHA-1, truncated SHA-384, and truncated SHA-256 506 [FIPS.180-2.2002] are defined as hashes for generating a HIT. 508 For identities that are either RSA, Digital Signature Algorithm (DSA) 509 [FIPS186-3], or Elliptic Curve DSA (ECDSA) public keys, the ORCHID 510 input consists of the public key encoding as specified for the Host 511 Identity field of the HOST_ID parameter (see Section 5.2.9). This 512 document defines four algorithm profiles: RSA, DSA, ECDSA, and 513 ECDSA_LOW. The ECDSA_LOW profile is meant for devices with low 514 computational capabilities. Hence, one of the following applies: 516 The RSA public key is encoded as defined in [RFC3110] Section 2, 517 taking the exponent length (e_len), exponent (e), and modulus (n) 518 fields concatenated. The length (n_len) of the modulus (n) can be 519 determined from the total HI Length and the preceding HI fields 520 including the exponent (e). Thus, the data that serves as input 521 for the HIT generation has the same length as the HI. The fields 522 MUST be encoded in network byte order, as defined in [RFC3110]. 524 The DSA public key is encoded as defined in [RFC2536] Section 2, 525 taking the fields T, Q, P, G, and Y, concatenated as input. Thus, 526 the data to be hashed is 1 + 20 + 3 * 64 + 3 * 8 * T octets long, 527 where T is the size parameter as defined in [RFC2536]. The size 528 parameter T, affecting the field lengths, MUST be selected as the 529 minimum value that is long enough to accommodate P, G, and Y. The 530 fields MUST be encoded in network byte order, as defined in 531 [RFC2536]. 533 The ECDSA public keys are encoded as defined in [RFC6090] 534 Section 4.2 and 6. 536 In Appendix B, the public key encoding process is illustrated using 537 pseudo-code. 539 4. Protocol Overview 541 This section is a simplified overview of the HIP protocol operation, 542 and does not contain all the details of the packet formats or the 543 packet processing steps. Sections 5 and 6 describe in more detail 544 the packet formats and packet processing steps, respectively, and are 545 normative in case of any conflicts with this section. 547 The protocol number 139 has been assigned by IANA to the Host 548 Identity Protocol. 550 The HIP payload (Section 5.1) header could be carried in every IP 551 datagram. However, since HIP headers are relatively large (40 552 bytes), it is desirable to 'compress' the HIP header so that the HIP 553 header only occurs in control packets used to establish or change HIP 554 association state. The actual method for header 'compression' and 555 for matching data packets with existing HIP associations (if any) is 556 defined in separate documents, describing transport formats and 557 methods. All HIP implementations MUST implement, at minimum, the ESP 558 transport format for HIP [I-D.ietf-hip-rfc5202-bis]. 560 4.1. Creating a HIP Association 562 By definition, the system initiating a HIP base exchange is the 563 Initiator, and the peer is the Responder. This distinction is 564 typically forgotten once the base exchange completes, and either 565 party can become the Initiator in future communications. 567 The HIP base exchange serves to manage the establishment of state 568 between an Initiator and a Responder. The first packet, I1, 569 initiates the exchange, and the last three packets, R1, I2, and R2, 570 constitute an authenticated Diffie-Hellman [DIF76] key exchange for 571 session-key generation. In the first two packets, the hosts agree on 572 a set of cryptographic identifiers and algorithms that are then used 573 in and after the exchange. During the Diffie-Hellman key exchange, a 574 piece of keying material is generated. The HIP association keys are 575 drawn from this keying material by using a Key Derivation Function 576 (KDF). If other cryptographic keys are needed, e.g., to be used with 577 ESP, they are expected to be drawn from the same keying material by 578 using the KDF. 580 The Initiator first sends a trigger packet, I1, to the Responder. 581 The packet contains the HIT of the Initiator and possibly the HIT of 582 the Responder, if it is known. Moreover, the I1 packet initializes 583 the negotiation of the Diffie-Hellman group that is used for 584 generating the keying material. Therefore, the I1 packet contains a 585 list of Diffie Hellman Group IDs supported by the Initiator. Note 586 that in some cases it may be possible to replace this trigger packet 587 by some other form of a trigger, in which case the protocol starts 588 with the Responder sending the R1 packet. In such cases, another 589 mechanism to convey the Initiator's supported DH Groups (e.g., by 590 using a default group) must be specified. 592 The second packet, R1, starts the actual authenticated Diffie-Hellman 593 exchange. It contains a puzzle -- a cryptographic challenge that the 594 Initiator must solve before continuing the exchange. The level of 595 difficulty of the puzzle can be adjusted based on level of trust with 596 the Initiator, current load, or other factors. In addition, the R1 597 contains the Responder's Diffie-Hellman parameter and lists of 598 cryptographic algorithms supported by the Responder. Based on these 599 lists, the Initiator can continue, abort, or restart the base 600 exchange with a different selection of cryptographic algorithms. 601 Also, the R1 packet contains a signature that covers selected parts 602 of the message. Some fields are left outside the signature to 603 support pre-created R1s. 605 In the I2 packet, the Initiator MUST display the solution to the 606 received puzzle. Without a correct solution, the I2 message is 607 discarded. The I2 packet also contains a Diffie-Hellman parameter 608 that carries needed information for the Responder. The I2 packet is 609 signed by the Initiator. 611 The R2 packet acknowledges the receipt of the I2 packet and completes 612 the base exchange. The packet is signed by the Responder. 614 The base exchange is illustrated below in Figure 1. The term "key" 615 refers to the Host Identity public key, and "sig" represents a 616 signature using such a key. The packets contain other parameters not 617 shown in this figure. 619 Initiator Responder 621 I1: DH list 622 --------------------------> 623 select precomputed R1 624 R1: puzzle, DH, key, sig 625 <------------------------- 626 check sig remain stateless 627 solve puzzle 628 I2: solution, DH, {key}, sig 629 --------------------------> 630 compute DH check puzzle 631 check sig 632 R2: sig 633 <-------------------------- 634 check sig compute DH 636 Figure 1 638 4.1.1. HIP Puzzle Mechanism 640 The purpose of the HIP puzzle mechanism is to protect the Responder 641 from a number of denial-of-service threats. It allows the Responder 642 to delay state creation until receiving the I2 packet. Furthermore, 643 the puzzle allows the Responder to use a fairly cheap calculation to 644 check that the Initiator is "sincere" in the sense that it has 645 churned enough CPU cycles in solving the puzzle. 647 The puzzle allows a Responder implementation to completely delay 648 association-specific state creation until a valid I2 packet is 649 received. An I2 packet without valid puzzle solution can be rejected 650 immediately once the Responder has checked the solution by computing 651 only one hash function before state is created and CPU-intensive 652 public-key signature verification and Diffie-Hellman key generation 653 are performed. By varying the difficulty of the puzzle, the 654 Responder can frustrate CPU or memory targeted DoS attacks. 656 The Responder can remain stateless and drop most spoofed I2 packets 657 because puzzle calculation is based on the Initiator's Host Identity 658 Tag. The idea is that the Responder has a (perhaps varying) number of 659 pre-calculated R1 packets, and it selects one of these based on the 660 information carried in the I1 packet. When the Responder then later 661 receives the I2 packet, it can verify that the puzzle has been solved 662 using the Initiator's HIT. This makes it impractical for the 663 attacker to first exchange one I1/R1 packet, and then generate a 664 large number of spoofed I2 packets that seemingly come from different 665 HITs. This method does not protect the Responder from an attacker 666 that uses fixed HITs, though. Against such an attacker, a viable 667 approach may be to create a piece of local state, and remember that 668 the puzzle check has previously failed. See Appendix A for one 669 possible implementation. Responder implementations SHOULD include 670 sufficient randomness in the puzzle values so that algorithmic 671 complexity attacks become impossible [CRO03]. 673 The Responder can set the puzzle difficulty for the Initiator, based 674 on its level of trust of the Initiator. Because the puzzle is not 675 included in the signature calculation, the Responder can use pre- 676 calculated R1 packets and include the puzzle just before sending the 677 R1 to the Initiator. The Responder SHOULD use heuristics to 678 determine when it is under a denial-of-service attack, and set the 679 puzzle difficulty value #K appropriately as explained later. 681 4.1.2. Puzzle Exchange 683 The Responder starts the puzzle exchange when it receives an I1 684 packet. The Responder supplies a random number #I, and requires the 685 Initiator to find a number J. To select a proper #J, the Initiator 686 must create the concatenation of #I, the HITs of the parties, and #J, 687 and calculate a hash over this concatenation using the RHASH 688 algorithm. The lowest order #K bits of the result MUST be zeros. 689 The value #K sets the difficulty of the puzzle. 691 To generate a proper number #J, the Initiator will have to generate a 692 number of Js until one produces the hash target of zeros. The 693 Initiator SHOULD give up after exceeding the puzzle Lifetime in the 694 PUZZLE parameter (as described in Section 5.2.4). The Responder 695 needs to re-create the concatenation of #I, the HITs, and the 696 provided #J, and compute the hash once to prove that the Initiator 697 completed its assigned task. 699 To prevent precomputation attacks, the Responder MUST select the 700 number #I in such a way that the Initiator cannot guess it. 701 Furthermore, the construction MUST allow the Responder to verify that 702 the value #I was indeed selected by it and not by the Initiator. See 703 Appendix A for an example on how to implement this. 705 Using the Opaque data field in the PUZZLE (see Section 5.2.4), in an 706 ECHO_REQUEST_SIGNED (see Section 5.2.20) or in an 707 ECHO_REQUEST_UNSIGNED parameter (see Section 5.2.21), the Responder 708 can include some data in R1 that the Initiator MUST copy unmodified 709 in the corresponding I2 packet. The Responder can use the opaque 710 data to transfer a piece of local state information to the Initiator 711 and back, for example to recognize that the I2 is a response to a 712 previously sent R1. The Responder can generate the Opaque data in 713 various ways; e.g., using encryption or hashing with some secret, the 714 sent #I, and possibly using other related data. With the same 715 secret, the received #I (from the I2 packet), and the other related 716 data (if any), the Responder can verify that it has itself sent the 717 #I to the Initiator. The Responder MUST periodically change such a 718 secret. 720 It is RECOMMENDED that the Responder generates new secrets for the 721 puzzle and new R1s once every few minutes. Furthermore, it is 722 RECOMMENDED that the Responder is able to verify valid puzzle 723 solution at least Lifetime seconds after the puzzle secret has been 724 deprecated. This time value guarantees that the puzzle is valid for 725 at least Lifetime and at most 2 * Lifetime seconds. This limits the 726 usability that an old, solved puzzle has to an attacker. Moreover, 727 it avoids problems with the validity of puzzles if the lifetime is 728 relatively short compared to the network delay and the time for 729 solving the puzzle. 731 The puzzle value #I and the solution #J are inputs for deriving the 732 keying material from the Diffie-Hellman key exchange (see 733 Section 6.5). Therefore, a Responder SHOULD NOT use the same puzzle 734 #I with the same DH keys for the same Initiator twice to ensure that 735 the derived keying material differs. Such uniqueness can be 736 achieved, for example, by using a counter as an additional input for 737 generating #I. This counter can be increased for each processed I1 738 packet. The state of the counter can be transmitted in the Opaque 739 data field in the PUZZLE (see Section 5.2.4), in an 740 ECHO_REQUEST_SIGNED (see Section 5.2.20) or in an 741 ECHO_REQUEST_UNSIGNED parameter (see Section 5.2.21) without the need 742 to establish state. 744 NOTE: The protocol developers explicitly considered whether R1 should 745 include a timestamp in order to protect the Initiator from replay 746 attacks. The decision was to NOT include a timestamp to avoid 747 problems with global time synchronization. 749 NOTE: The protocol developers explicitly considered whether a memory 750 bound function should be used for the puzzle instead of a CPU-bound 751 function. The decision was not to use memory-bound functions. 753 4.1.3. Authenticated Diffie-Hellman Protocol with DH Group Negotiation 755 The packets R1, I2, and R2 implement a standard authenticated Diffie- 756 Hellman exchange. The Responder sends one of its public Diffie- 757 Hellman keys and its public authentication key, i.e., its Host 758 Identity, in R1. The signature in the R1 packet allows the Initiator 759 to verify that the R1 has been once generated by the Responder. 760 However, since the R1 is precomputed and therefore does not cover 761 association-specific information in the I1 packet, it does not 762 protect from replay attacks. 764 Before the actual authenticated Diffie-Hellman exchange, the 765 Initiator expresses its preference regarding its choice of the DH 766 groups in the I1 packet. The preference is expressed as a sorted 767 list of DH Group IDs. The I1 packet is not protected by a signature. 768 Therefore, this list is sent in an unauthenticated way to avoid 769 costly computations for processing the I1 packet at the Responder 770 side. Based on the preferences of the Initiator, the Responder sends 771 an R1 packet containing its most suitable public DH value. The 772 Responder also attaches a list of its own preferences to the R1 to 773 convey the basis for the DH group selection to the Initiator. This 774 list is carried in the signed part of the R1 packet. If the choice 775 of the DH group value in the R1 does not match the preferences of the 776 Initiator and the Responder, the Initiator can detect that the list 777 of DH Group IDs in the I1 was manipulated (see below for details). 779 If none of the DH Group IDs in the I1 packet is supported by the 780 Responder, the Responder selects the DH Group most suitable for it 781 regardless of the Initiator's preference. It then sends the R1 782 containing this DH Group and its list of supported DH Group IDs to 783 the Initiator. 785 When the Initiator receives an R1, it receives one of the Responder's 786 public Diffie-Hellman values and the list of DH Group IDs supported 787 by the Responder. This list is covered by the signature in the R1 788 packet to avoid forgery. The Initiator compares the Group ID of the 789 public DH value in the R1 packet to the list of supported DH Group 790 IDs in the R1 packets and to its own preferences expressed in the 791 list of supported DH Group IDs. The Initiator continues the BEX only 792 if the Group ID of the public DH value of the Responder is the most 793 preferred of the IDs supported by both the Initiator and Responder. 794 Otherwise, the communication is subject of a downgrade attack and the 795 Initiator MUST either restart the base exchange with a new I1 packet 796 or abort the base exchange. If the Responder's choice of the DH 797 Group is not supported by the Initiator, the Initiator MAY abort the 798 handshake or send a new I1 packet with a different list of supported 799 DH Groups. However, the Initiator MUST verify the signature of the 800 R1 packet before restarting or aborting the handshake. It MUST 801 silently ignore the R1 packet if the signature is not valid. 803 If the preferences regarding the DH Group ID match, the Initiator 804 computes the Diffie-Hellman session key (Kij). The Initiator creates 805 a HIP association using keying material from the session key (see 806 Section 6.5), and may use the HIP association to encrypt its public 807 authentication key, i.e., the Host Identity. The resulting I2 packet 808 contains the Initiator's Diffie-Hellman key and its (optionally 809 encrypted) public authentication key. The signature of the I2 810 message covers all parameters of the signed parameter ranges (see 811 Section 5.2) in the packet without exceptions as in the R1. 813 The Responder extracts the Initiator's Diffie-Hellman public key from 814 the I2 packet, computes the Diffie-Hellman session key, creates a 815 corresponding HIP association, and decrypts the Initiator's public 816 authentication key. It can then verify the signature using the 817 authentication key. 819 The final message, R2, completes the BEX and protects the Initiator 820 against replay attacks because the Responder uses the shared key from 821 the Diffie-Hellman exchange to create an HMAC as well as uses the 822 private key of its Host Identity to sign the packet contents. 824 4.1.4. HIP Replay Protection 826 The HIP protocol includes the following mechanisms to protect against 827 malicious packet replays. Responders are protected against replays 828 of I1 packets by virtue of the stateless response to I1 packets with 829 pre-signed R1 messages. Initiators are protected against R1 replays 830 by a monotonically increasing "R1 generation counter" included in the 831 R1. Responders are protected against replays of forged I2 packets by 832 the puzzle mechanism (see Section 4.1.1 above), and optional use of 833 opaque data. Hosts are protected against replays of R2 packets and 834 UPDATEs by use of a less expensive HMAC verification preceding the 835 HIP signature verification. 837 The R1 generation counter is a monotonically increasing 64-bit 838 counter that may be initialized to any value. The scope of the 839 counter MAY be system-wide but there SHOULD be a separate counter for 840 each Host Identity, if there is more than one local host identity. 841 The value of this counter SHOULD be preserved across system reboots 842 and invocations of the HIP base exchange. This counter indicates the 843 current generation of puzzles. Implementations MUST accept puzzles 844 from the current generation and MAY accept puzzles from earlier 845 generations. A system's local counter MUST be incremented at least 846 as often as every time old R1s cease to be valid. The local counter 847 SHOULD never be decremented, otherwise the host exposes its peers to 848 the replay of previously generated, higher numbered R1s. 850 A host may receive more than one R1, either due to sending multiple 851 I1 packets (see Section 6.6.1) or due to a replay of an old R1. When 852 sending multiple I1 packets to the same host, an Initiator SHOULD 853 wait for a small amount of time (a reasonable time may be 2 * 854 expected RTT) after the first R1 reception to allow possibly multiple 855 R1s to arrive, and it SHOULD respond to an R1 among the set with the 856 largest R1 generation counter. If an Initiator is processing an R1 857 or has already sent an I2 packet (still waiting for the R2 packet) 858 and it receives another R1 with a larger R1 generation counter, it 859 MAY elect to restart R1 processing with the fresher R1, as if it were 860 the first R1 to arrive. 862 The R1 generation counter may roll over or may become reset. It is 863 important for an Initiator to be robust to the loss of state about 864 the R1 generation counter of a peer, or to a reset of the peer's 865 counter. It is recommended that, when choosing between multiple R1s, 866 the Initiator prefer to use the R1 that corresponds to the current R1 867 generation counter, but that if it is unable to make progress with 868 that R1, the Initiator may try the other R1s beginning with the R1 869 packet with the highest counter. 871 4.1.5. Refusing a HIP base exchange 873 A HIP-aware host may choose not to accept a HIP base exchange. If 874 the host's policy is to only be an Initiator, and policy allows the 875 establishment of a HIP association with the original Initiator, it 876 should begin its own HIP base exchange. A host MAY choose to have 877 such a policy since only the privacy of the Initiator's HI is 878 protected in the exchange. It should be noted that such behavior can 879 introduce the risk of a race condition if each host's policy is to 880 only be an Initiator, at which point the HIP base exchange will fail. 882 If the host's policy does not permit it to enter into a HIP exchange 883 with the Initiator, it should send an ICMP 'Destination Unreachable, 884 Administratively Prohibited' message. A more complex HIP packet is 885 not used here as it actually opens up more potential DoS attacks than 886 a simple ICMP message. A HIP NOTIFY message is not used because no 887 HIP association exists between the two hosts at that time. 889 4.1.6. Aborting a HIP base exchange 891 Two HIP hosts may encounter situations in which they cannot complete 892 a HIP base exchange because of insufficient support for cryptographic 893 algorithms, in particular the HIT Suites and DH Groups. After 894 receiving the R1 packet, the Initiator can determine whether the 895 Responder supports the required cryptographic operations to 896 successfully establish a HIP association. The Initiator can abort 897 the BEX silently after receiving an R1 packet that indicates an 898 unsupported set of algorithms. The specific conditions are described 899 below. 901 The R1 packet contains a signed list of HIT Suite IDs as supported by 902 the Responder. Therefore, the Initiator can determine whether its 903 source HIT is supported by the Responder. If the HIT Suite ID of the 904 Initiator's HIT is not contained in the list of HIT Suites in the R1, 905 the Initiator MAY abort the handshake silently or MAY restart the 906 handshake with a new I1 packet that contains a source HIT supported 907 by the Responder. 909 During the Handshake, the Initiator and the Responder agree on a 910 single DH Group. The Responder selects the DH Group and its DH 911 public value in the R1 based on the list of DH Suite IDs in the I1 912 packet. If the responder supports none of the DH Groups requested by 913 the Initiator, the Responder selects an arbitrary DH and replies with 914 an R1 containing its list of supported DH Group IDs. In such case, 915 the Initiator receives an R1 packet containing the DH public value 916 for an unrequested DH Group and also the Responder's DH Group list in 917 the signed part of the R1 packet. At this point, the Initiator MAY 918 abort the handshake or MAY restart the handshake by sending a new I1 919 packet containing a selection of DH Group IDs that is supported by 920 the Responder. 922 4.1.7. HIP Downgrade Protection 924 In a downgrade attack, an attacker attempts to unnoticeably 925 manipulate the packets of an Initiator and/or a Responder to 926 influence the result of the cryptographic negotiations in the BEX to 927 its favor. As a result, the victims select weaker cryptographic 928 algorithms than they would otherwise have selected without the 929 attacker's interference. Downgrade attacks can only be successful if 930 they remain un-detected by the victims and the victims falsely assume 931 a secure communication channel. 933 In HIP, almost all packet parameters related to cryptographic 934 negotiations are covered by signatures. These parameters cannot be 935 directly manipulated in a downgrade attack without invalidating the 936 signature. However, signed packets can be subject to replay attacks. 937 In such a replay attack, the attacker could use an old BEX packet 938 with an outdated and weak selection of cryptographic algorithms and 939 replay it instead of a more recent packet with a collection of 940 stronger cryptographic algorithms. Signed packets that could be 941 subject to this replay attack are the R1 and I2 packet. However, 942 replayed R1 and I2 packets cannot be used to successfully establish a 943 HIP BEX because these packets also contain the public DH values of 944 the Initiator and the Responder. Old DH values from replayed packets 945 lead to invalid keying material and mismatching shared secrets 946 because the attacker is unable to derive valid keying material from 947 the DH public keys in the R1 and cannot generate a valid HMAC and 948 signature for a replayed I2. 950 In contrast to the first version of HIP [RFC5201],the version 2 of 951 HIP defined in this document begins the negotiation of the DH Groups 952 already in the first BEX packet, the I1. The I1 packet is, by 953 intention, not protected by a signature to avoid CPU-intensive 954 cryptographic operations for processing floods of I1 packets targeted 955 at the Responder. Hence, the list of DH Group IDs in the I1 packet 956 is vulnerable to forgery and manipulation. To thwart an unnoticed 957 manipulation of the I1 packet, the Responder chooses the DH Group 958 deterministically and includes its own list of DH Group IDs in the 959 signed part of the R1 packet. The Initiator can detect an attempted 960 downgrade attack by comparing the list of DH Group IDs in the R1 961 packet to its own preferences in the I1 packet. If the choice of the 962 DH Group in the R1 packet does not equal to the best match of the two 963 lists (the highest priority DH ID of the Responder that is present in 964 the Initiator's DH list), the Initiator can conclude that its list in 965 the I1 packet was altered by an attacker. In this case, the 966 Initiator can restart or abort the BEX. As mentioned before, the 967 detection of the downgrade attack is sufficient to prevent it. 969 4.1.8. HIP Opportunistic Mode 971 It is possible to initiate a HIP BEX even if the Responder's HI (and 972 HIT) is unknown. In this case, the initial I1 packet contains all 973 zeros as the destination HIT. This kind of connection setup is 974 called opportunistic mode. 976 The Responder may have multiple HITs due to multiple supported HIT 977 Suites. Since the Responder's HIT Suite in the opportunistic mode is 978 not determined by the destination HIT of the I1 packet, the Responder 979 can freely select a HIT of any HIT Suite. The complete set of HIT 980 Suites supported by the Initiator is not known to the Responder. 981 Therefore, the Responder SHOULD select its HIT from the same HIT 982 Suite as the Initiator's HIT (indicated by the HIT suite information 983 in the OGA field of the Initiator's HIT) because this HIT Suite is 984 obviously supported by the Initiator. If the Responder selects a 985 different HIT that is not supported by the Initiator, the Initiator 986 MAY restart the BEX with an I1 packet with a source HIT that is 987 contained in the list of the Responder's HIT Suites in the R1 packet. 989 Note that the Initiator cannot verify the signature of the R1 packet 990 if the Responder's HIT Suite is not supported. Therefore, the 991 Initiator MUST treat R1 packets with unsupported Responder HITs as 992 potentially forged and MUST NOT use any parameters from the 993 unverified R1 besides the HIT Suite List. Moreover, an Initiator 994 that uses an unverified HIT Suite List from an R1 packet to determine 995 a possible source HIT MUST verify that the HIT_SUITE_LIST in the 996 first unverified R1 packet matches the HIT_SUITE_LIST in the second 997 R1 packet for which the Initiator supports the signature algorithm. 998 The Initiator MUST restart the BEX with a new I1 packet for which the 999 algorithm was mentioned in the verifiable R1 if the two lists do not 1000 match. This procedure is necessary to mitigate downgrade attacks. 1002 There are both security and API issues involved with the 1003 opportunistic mode. These issues are described in the reminder of 1004 this section. 1006 Given that the Responder's HI is not known by the Initiator, there 1007 must be suitable API calls that allow the Initiator to request, 1008 directly or indirectly, that the underlying system initiates the HIP 1009 base exchange solely based on locators. The Responder's HI will be 1010 tentatively available in the R1 packet, and in an authenticated form 1011 once the R2 packet has been received and verified. Hence, the 1012 Responder's HIT could be communicated to the application via new API 1013 mechanisms. However, with a backwards-compatible API the application 1014 sees only the locators used for the initial contact. Depending on 1015 the desired semantics of the API, this can raise the following 1016 issues: 1018 o The actual locators may later change if an UPDATE message is used, 1019 even if from the API perspective the association still appears to 1020 be between two specific locators. However, the locator update is 1021 still secure and the association is still between the same nodes. 1023 o Different associations between the same two locators may result in 1024 connections to different nodes, if the implementation no longer 1025 remembers which identifier the peer had in an earlier association. 1026 This is possible when the peer's locator has changed for 1027 legitimate reasons or when an attacker pretends to be a node that 1028 has the peer's locator. Therefore, when using opportunistic mode, 1029 HIP implementations MUST NOT place any expectation that the peer's 1030 HI returned in the R1 message matches any HI previously seen from 1031 that address. 1033 If the HIP implementation and application do not have the same 1034 understanding of what constitutes an association, this may even 1035 happen within the same association. For instance, an 1036 implementation may not know when HIP state can be purged for UDP- 1037 based applications. 1039 In addition, the following security considerations apply. The 1040 generation counter mechanism will be less efficient in protecting 1041 against replays of the R1 packet, given that the Responder can choose 1042 a replay that uses an arbitrary HI, not just the one given in the I1 1043 packet. 1045 More importantly, the opportunistic exchange is vulnerable to man-in- 1046 the-middle attacks, because the Initiator does not have any public 1047 key information about the peer. To assess the impacts of this 1048 vulnerability, we compare it to vulnerabilities in current, non-HIP- 1049 capable communications. 1051 An attacker on the path between the two peers can insert itself as a 1052 man-in-the-middle by providing its own identifier to the Initiator 1053 and then initiating another HIP association towards the Responder. 1054 For this to be possible, the Initiator must employ opportunistic 1055 mode, and the Responder must be configured to accept a connection 1056 from any HIP-enabled node. 1058 An attacker outside the path will be unable to do so, given that it 1059 cannot respond to the messages in the base exchange. 1061 These security properties are characteristic also of communications 1062 in the current Internet. A client contacting a server without 1063 employing end-to-end security may find itself talking to the server 1064 via a man-in-the-middle, assuming again that the server is willing to 1065 talk to anyone. 1067 If end-to-end security is in place, then the worst that can happen in 1068 both the opportunistic HIP and non-HIP (normal IP) cases is denial- 1069 of-service; an entity on the path can disrupt communications, but 1070 will be unable to successfully insert itself as a man-in-the-middle. 1072 However, once the opportunistic exchange has successfully completed, 1073 HIP provides confidentiality and integrity protection for the 1074 communications, and can securely change the locators of the 1075 endpoints. 1077 As a result, opportunistic mode in HIP offers a "better than nothing" 1078 security model. Initially, a base exchange authenticated in the 1079 opportunistic mode involves a leap of faith subject to man-in-the- 1080 middle attacks, but subsequent datagrams related to the same HIP 1081 association cannot be compromised by a new man-in-the-middle attack, 1082 and further, if the man-in-the-middle moves away from the path of the 1083 active association, the attack would be exposed after the fact. 1084 Thus, it can be stated that opportunistic mode in HIP is at least as 1085 secure as unprotected IP-based communications. 1087 4.2. Updating a HIP Association 1089 A HIP association between two hosts may need to be updated over time. 1090 Examples include the need to rekey expiring security associations, 1091 add new security associations, or change IP addresses associated with 1092 hosts. The UPDATE packet is used for those and other similar 1093 purposes. This document only specifies the UPDATE packet format and 1094 basic processing rules, with mandatory parameters. The actual usage 1095 is defined in separate specifications. 1097 HIP provides a general purpose UPDATE packet, which can carry 1098 multiple HIP parameters, for updating the HIP state between two 1099 peers. The UPDATE mechanism has the following properties: 1101 UPDATE messages carry a monotonically increasing sequence number 1102 and are explicitly acknowledged by the peer. Lost UPDATEs or 1103 acknowledgments may be recovered via retransmission. Multiple 1104 UPDATE messages may be outstanding under certain circumstances. 1106 UPDATE is protected by both HIP_MAC and HIP_SIGNATURE parameters, 1107 since processing UPDATE signatures alone is a potential DoS attack 1108 against intermediate systems. 1110 UPDATE packets are explicitly acknowledged by the use of an 1111 acknowledgment parameter that echoes an individual sequence number 1112 received from the peer. A single UPDATE packet may contain both a 1113 sequence number and one or more acknowledgment numbers (i.e., 1114 piggybacked acknowledgment(s) for the peer's UPDATE). 1116 The UPDATE packet is defined in Section 5.3.5. 1118 4.3. Error Processing 1120 HIP error processing behavior depends on whether or not there exists 1121 an active HIP association. In general, if a HIP association exists 1122 between the sender and receiver of a packet causing an error 1123 condition, the receiver SHOULD respond with a NOTIFY packet. On the 1124 other hand, if there are no existing HIP associations between the 1125 sender and receiver, or the receiver cannot reasonably determine the 1126 identity of the sender, the receiver MAY respond with a suitable ICMP 1127 message; see Section 5.4 for more details. 1129 The HIP protocol and state machine are designed to recover from one 1130 of the parties crashing and losing its state. The following 1131 scenarios describe the main use cases covered by the design. 1133 No prior state between the two systems. 1135 The system with data to send is the Initiator. The process 1136 follows the standard four-packet base exchange, establishing 1137 the HIP association. 1139 The system with data to send has no state with the receiver, but 1140 the receiver has a residual HIP association. 1142 The system with data to send is the Initiator. The Initiator 1143 acts as in no prior state, sending an I1 packet and receiving 1144 an R1 packet. When the Responder receives a valid I2 packet, 1145 the old association is 'discovered' and deleted, and the new 1146 association is established. 1148 The system with data to send has a HIP association, but the 1149 receiver does not. 1151 The system sends data on the outbound user data security 1152 association. The receiver 'detects' the situation when it 1153 receives a user data packet that it cannot match to any HIP 1154 association. The receiving host MUST discard this packet. 1156 The receiving host SHOULD send an ICMP packet, with the type 1157 Parameter Problem, to inform the sender that the HIP 1158 association does not exist (see Section 5.4), and it MAY 1159 initiate a new HIP BEX. However, responding with these 1160 optional mechanisms is implementation or policy dependent. If 1161 the sending application doesn't expect a response, the system 1162 could possibly send a large number of packets in this state, so 1163 for this reason, the sending of one or more ICMP packets is 1164 RECOMMENDED. However, any such responses MUST be rate-limited 1165 to prevent abuse (see Section 5.4). 1167 4.4. HIP State Machine 1169 The HIP protocol itself has little state. In the HIP base exchange, 1170 there is an Initiator and a Responder. Once the security 1171 associations (SAs) are established, this distinction is lost. If the 1172 HIP state needs to be re-established, the controlling parameters are 1173 which peer still has state and which has a datagram to send to its 1174 peer. The following state machine attempts to capture these 1175 processes. 1177 The state machine is symmetric and is presented in a single system 1178 view, representing either an Initiator or a Responder. The state 1179 machine is not a full representation of the processing logic. 1180 Additional processing rules are presented in the packet definitions. 1181 Hence, both are needed to completely implement HIP. 1183 This document extends the state machine as defined in [RFC5201] and 1184 introduces a restart option to allow for the negotiation of 1185 cryptographic algorithms. The extension to the previous state 1186 machine in [RFC5201] is a transition from state I1-SENT to I1-SENT - 1187 the restart option. An Initiator is required to restart the HIP base 1188 exchange if the Responder does not support the HIT Suite of the 1189 Initiator. In this case, the Initiator restarts the HIP base 1190 exchange by sending a new I1 packet with a source HIT supported by 1191 the Responder. 1193 Implementors must understand that the state machine, as described 1194 here, is informational. Specific implementations are free to 1195 implement the actual processing logic differently. Section 6 1196 describes the packet processing rules in more detail. This state 1197 machine focuses on the HIP I1, R1, I2, and R2 packets only. New 1198 states and state transitions may be introduced by mechanisms in other 1199 specifications (such as mobility and multihoming). 1201 4.4.1. State Machine Terminology 1203 Unused Association Lifetime (UAL): Implementation-specific time for 1204 which, if no packet is sent or received for this time interval, a 1205 host MAY begin to tear down an active HIP association. 1207 Maximum Segment Lifetime (MSL): Maximum time that a HIP packet is 1208 expected to spend in the network. A default value of 2 minutes 1209 has been borrowed from [RFC0793] because it is a prevailing 1210 assumption for packet lifetimes. 1212 Exchange Complete (EC): Time that the host spends at the R2-SENT 1213 state before it moves to the ESTABLISHED state. The time is n * 1214 I2 retransmission timeout, where n is about I2_RETRIES_MAX. 1216 Receive ANYOTHER: Any received packet for which no state 1217 transitions or processing rules are defined for a given state. 1219 4.4.2. HIP States 1220 +---------------------+---------------------------------------------+ 1221 | State | Explanation | 1222 +---------------------+---------------------------------------------+ 1223 | UNASSOCIATED | State machine start | 1224 | | | 1225 | I1-SENT | Initiating base exchange | 1226 | | | 1227 | I2-SENT | Waiting to complete base exchange | 1228 | | | 1229 | R2-SENT | Waiting to complete base exchange | 1230 | | | 1231 | ESTABLISHED | HIP association established | 1232 | | | 1233 | CLOSING | HIP association closing, no data can be | 1234 | | sent | 1235 | | | 1236 | CLOSED | HIP association closed, no data can be sent | 1237 | | | 1238 | E-FAILED | HIP base exchange failed | 1239 +---------------------+---------------------------------------------+ 1241 Table 1: HIP States 1243 4.4.3. HIP State Processes 1244 System behavior in state UNASSOCIATED, Table 2. 1246 +----------------------------+--------------------------------------+ 1247 | Trigger | Action | 1248 +----------------------------+--------------------------------------+ 1249 | User data to send, | Send I1 and go to I1-SENT | 1250 | requiring a new HIP | | 1251 | association | | 1252 | | | 1253 | Receive I1 | Send R1 and stay at UNASSOCIATED | 1254 | | | 1255 | Receive I2, process | If successful, send R2 and go to | 1256 | | R2-SENT | 1257 | | | 1258 | | If fail, stay at UNASSOCIATED | 1259 | | | 1260 | Receive user data for an | Optionally send ICMP as defined in | 1261 | unknown HIP association | Section 5.4 and stay at UNASSOCIATED | 1262 | | | 1263 | Receive CLOSE | Optionally send ICMP Parameter | 1264 | | Problem and stay at UNASSOCIATED | 1265 | | | 1266 | Receive ANYOTHER | Drop and stay at UNASSOCIATED | 1267 +----------------------------+--------------------------------------+ 1269 Table 2: UNASSOCIATED - Start state 1271 System behavior in state I1-SENT, Table 3. 1273 +---------------------+---------------------------------------------+ 1274 | Trigger | Action | 1275 +---------------------+---------------------------------------------+ 1276 | Receive I1 from | If the local HIT is smaller than the peer | 1277 | Responder | HIT, drop I1 and stay at I1-SENT (see | 1278 | | Section 6.5 for HIT comparison) | 1279 | | | 1280 | | If the local HIT is greater than the peer | 1281 | | HIT, send R1 and stay at I1-SENT | 1282 | | | 1283 | Receive I2, process | If successful, send R2 and go to R2-SENT | 1284 | | | 1285 | | If fail, stay at I1-SENT | 1286 | | | 1287 | Receive R1, process | If the HIT Suite of the local HIT is not | 1288 | | supported by the peer, select supported | 1289 | | local HIT, send I1 and stay at I1-SENT | 1290 | | | 1291 | | If successful, send I2 and go to I2-SENT | 1292 | | | 1293 | | If fail, stay at I1-SENT | 1294 | | | 1295 | Receive ANYOTHER | Drop and stay at I1-SENT | 1296 | | | 1297 | Timeout | Increment trial counter | 1298 | | | 1299 | | If counter is less than I1_RETRIES_MAX, | 1300 | | send I1 and stay at I1-SENT | 1301 | | | 1302 | | If counter is greater than I1_RETRIES_MAX, | 1303 | | go to E-FAILED | 1304 +---------------------+---------------------------------------------+ 1306 Table 3: I1-SENT - Initiating the HIP base exchange 1308 System behavior in state I2-SENT, Table 4. 1310 +---------------------+---------------------------------------------+ 1311 | Trigger | Action | 1312 +---------------------+---------------------------------------------+ 1313 | Receive I1 | Send R1 and stay at I2-SENT | 1314 | | | 1315 | Receive R1, process | If successful, send I2 and stay at I2-SENT | 1316 | | | 1317 | | If fail, stay at I2-SENT | 1318 | | | 1319 | Receive I2, process | If successful and local HIT is smaller than | 1320 | | the peer HIT, drop I2 and stay at I2-SENT | 1321 | | | 1322 | | If successful and local HIT is greater than | 1323 | | the peer HIT, send R2 and go to R2-SENT | 1324 | | | 1325 | | If fail, stay at I2-SENT | 1326 | | | 1327 | Receive R2, process | If successful, go to ESTABLISHED | 1328 | | | 1329 | | If fail, stay at I2-SENT | 1330 | | | 1331 | Receive CLOSE, | If successful, send CLOSE_ACK and go to | 1332 | process | CLOSED | 1333 | | | 1334 | | If fail, stay at I2-SENT | 1335 | | | 1336 | Receive ANYOTHER | Drop and stay at I2-SENT | 1337 | | | 1338 | Timeout | Increment trial counter | 1339 | | | 1340 | | If counter is less than I2_RETRIES_MAX, | 1341 | | send I2 and stay at I2-SENT | 1342 | | | 1343 | | If counter is greater than I2_RETRIES_MAX, | 1344 | | go to E-FAILED | 1345 +---------------------+---------------------------------------------+ 1347 Table 4: I2-SENT - Waiting to finish the HIP base exchange 1349 System behavior in state R2-SENT, Table 5. 1351 +------------------------+------------------------------------------+ 1352 | Trigger | Action | 1353 +------------------------+------------------------------------------+ 1354 | Receive I1 | Send R1 and stay at R2-SENT | 1355 | | | 1356 | Receive I2, process | If successful, send R2 and stay at | 1357 | | R2-SENT | 1358 | | | 1359 | | If fail, stay at R2-SENT | 1360 | | | 1361 | Receive R1 | Drop and stay at R2-SENT | 1362 | | | 1363 | Receive R2 | Drop and stay at R2-SENT | 1364 | | | 1365 | Receive data or UPDATE | Move to ESTABLISHED | 1366 | | | 1367 | Exchange Complete | Move to ESTABLISHED | 1368 | Timeout | | 1369 | | | 1370 | Receive CLOSE, process | If successful, send CLOSE_ACK and go to | 1371 | | CLOSED | 1372 | | | 1373 | | If fail, stay at ESTABLISHED | 1374 | | | 1375 | Receive CLOSE_ACK | Drop and stay at R2-SENT | 1376 | | | 1377 | Receive NOTIFY | Process and stay at R2-SENT | 1378 +------------------------+------------------------------------------+ 1380 Table 5: R2-SENT - Waiting to finish HIP 1382 System behavior in state ESTABLISHED, Table 6. 1384 +---------------------+---------------------------------------------+ 1385 | Trigger | Action | 1386 +---------------------+---------------------------------------------+ 1387 | Receive I1 | Send R1 and stay at ESTABLISHED | 1388 | | | 1389 | Receive I2 | Process with puzzle and possible Opaque | 1390 | | data verification | 1391 | | | 1392 | | If successful, send R2, drop old HIP | 1393 | | association, establish a new HIP | 1394 | | association and go to R2-SENT | 1395 | | | 1396 | | If fail, stay at ESTABLISHED | 1397 | | | 1398 | Receive R1 | Drop and stay at ESTABLISHED | 1399 | | | 1400 | Receive R2 | Drop and stay at ESTABLISHED | 1401 | | | 1402 | Receive user data | Process and stay at ESTABLISHED | 1403 | for HIP association | | 1404 | | | 1405 | No packet | Send CLOSE and go to CLOSING | 1406 | sent/received | | 1407 | during UAL minutes | | 1408 | | | 1409 | Receive UPDATE | Process and stay at ESTABLISHED | 1410 | | | 1411 | Receive CLOSE, | If successful, send CLOSE_ACK and go to | 1412 | process | CLOSED | 1413 | | | 1414 | | If fail, stay at ESTABLISHED | 1415 | | | 1416 | Receive CLOSE_ACK | Drop and stay at ESTABLISHED | 1417 | | | 1418 | Receive NOTIFY | Process and stay at ESTABLISHED | 1419 +---------------------+---------------------------------------------+ 1421 Table 6: ESTABLISHED - HIP association established 1423 System behavior in state CLOSING, Table 7. 1425 +----------------------------+--------------------------------------+ 1426 | Trigger | Action | 1427 +----------------------------+--------------------------------------+ 1428 | User data to send, | Send I1 and go to I1-SENT | 1429 | requires the creation of | | 1430 | another incarnation of the | | 1431 | HIP association | | 1432 | | | 1433 | Receive I1 | Send R1 and stay at CLOSING | 1434 | | | 1435 | Receive I2, process | If successful, send R2 and go to | 1436 | | R2-SENT | 1437 | | | 1438 | | If fail, stay at CLOSING | 1439 | | | 1440 | Receive R1, process | If successful, send I2 and go to | 1441 | | I2-SENT | 1442 | | | 1443 | | If fail, stay at CLOSING | 1444 | | | 1445 | Receive CLOSE, process | If successful, send CLOSE_ACK, | 1446 | | discard state and go to CLOSED | 1447 | | | 1448 | | If fail, stay at CLOSING | 1449 | | | 1450 | Receive CLOSE_ACK, process | If successful, discard state and go | 1451 | | to UNASSOCIATED | 1452 | | | 1453 | | If fail, stay at CLOSING | 1454 | | | 1455 | Receive ANYOTHER | Drop and stay at CLOSING | 1456 | | | 1457 | Timeout | Increment timeout sum and reset | 1458 | | timer. If timeout sum is less than | 1459 | | UAL+MSL minutes, retransmit CLOSE | 1460 | | and stay at CLOSING | 1461 | | | 1462 | | If timeout sum is greater than | 1463 | | UAL+MSL minutes, go to UNASSOCIATED | 1464 +----------------------------+--------------------------------------+ 1466 Table 7: CLOSING - HIP association has not been used for UAL minutes 1467 System behavior in state CLOSED, Table 8. 1469 +----------------------------------------+--------------------------+ 1470 | Trigger | Action | 1471 +----------------------------------------+--------------------------+ 1472 | Datagram to send, requires the | Send I1, and stay at | 1473 | creation of another incarnation of the | CLOSED | 1474 | HIP association | | 1475 | | | 1476 | Receive I1 | Send R1 and stay at | 1477 | | CLOSED | 1478 | | | 1479 | Receive I2, process | If successful, send R2 | 1480 | | and go to R2-SENT | 1481 | | | 1482 | | If fail, stay at CLOSED | 1483 | | | 1484 | Receive R1, process | If successful, send I2 | 1485 | | and go to I2-SENT | 1486 | | | 1487 | | If fail, stay at CLOSED | 1488 | | | 1489 | Receive CLOSE, process | If successful, send | 1490 | | CLOSE_ACK, stay at | 1491 | | CLOSED | 1492 | | | 1493 | | If fail, stay at CLOSED | 1494 | | | 1495 | Receive CLOSE_ACK, process | If successful, discard | 1496 | | state and go to | 1497 | | UNASSOCIATED | 1498 | | | 1499 | | If fail, stay at CLOSED | 1500 | | | 1501 | Receive ANYOTHER | Drop and stay at CLOSED | 1502 | | | 1503 | Timeout (UAL+2MSL) | Discard state, and go to | 1504 | | UNASSOCIATED | 1505 +----------------------------------------+--------------------------+ 1507 Table 8: CLOSED - CLOSE_ACK sent, resending CLOSE_ACK if necessary 1509 System behavior in state E-FAILED, Table 9. 1511 +-------------------------+-----------------------------------------+ 1512 | Trigger | Action | 1513 +-------------------------+-----------------------------------------+ 1514 | Wait for | Go to UNASSOCIATED. Re-negotiation is | 1515 | implementation-specific | possible after moving to UNASSOCIATED | 1516 | time | state. | 1517 +-------------------------+-----------------------------------------+ 1519 Table 9: E-FAILED - HIP failed to establish association with peer 1521 4.4.4. Simplified HIP State Diagram 1523 The following diagram (Figure 2) shows the major state transitions. 1524 Transitions based on received packets implicitly assume that the 1525 packets are successfully authenticated or processed. 1527 +--+ +----------------------------+ 1528 recv I1, send R1 | | | | 1529 | v v | 1530 +--------------+ recv I2, send R2 | 1531 +----------------| UNASSOCIATED |----------------+ | 1532 datagram | +--+ +--------------+ | | 1533 to send, | | | Alg. not supported, | | 1534 send I1 | | | send I1 | | 1535 . v | v | | 1536 . +---------+ recv I2, send R2 | | 1537 +---->| I1-SENT |--------------------------------------+ | | 1538 | +---------+ +----------------------+ | | | 1539 | | recv R2, | recv I2, send R2 | | | | 1540 | v send I2 | v v v | 1541 | +---------+ | +---------+ | 1542 | +--->| I2-SENT |----------+ +--------------| R2-SENT |<---+ | 1543 | | +---------+ | +---------+ | | 1544 | | | |recv R2 | data or| | | 1545 | |recv R1, | | | EC timeout| | | 1546 | |send I2 +--|-----------------+ | receive I2,| | 1547 | | | | +-------------+ | send R2| | 1548 | | | +------>| ESTABLISHED |<----------+ | | 1549 | | | +-------------+ | | 1550 | | | | | | receive I2, send R2 | | 1551 | | +------------+ | +-------------------------------+ | 1552 | | | +-----------+ | | 1553 | | | no packet sent/received| +---+ | | 1554 | | | for UAL min, send CLOSE| | |timeout | | 1555 | | | v v |(UAL+MSL) | | 1556 | | | +---------+ |retransmit | | 1557 +--|----------|------------------------| CLOSING |-+CLOSE | | 1558 | | +---------+ | | 1559 | | | | | | | | 1560 +----------|-------------------------+ | | +----------------+ | 1561 | | +-----------+ +------------------|--+ 1562 | | |recv CLOSE, recv CLOSE_ACK | | 1563 | +-------------+ |send CLOSE_ACK or timeout | | 1564 | recv CLOSE, | | (UAL+MSL) | | 1565 | send CLOSE_ACK v v | | 1566 | +--------+ receive I2, send R2 | | 1567 +---------------------| CLOSED |------------------------------+ | 1568 +--------+ | 1569 ^ | | | 1570 recv CLOSE, send CLOSE_ACK| | | timeout (UAL+2MSL) | 1571 +-+ +------------------------------------+ 1573 Figure 2 1575 4.5. User Data Considerations 1577 4.5.1. TCP and UDP Pseudo-Header Computation for User Data 1579 When computing TCP and UDP checksums on user data packets that flow 1580 through sockets bound to HITs, the IPv6 pseudo-header format 1581 [RFC2460] MUST be used, even if the actual addresses in the header of 1582 the packet are IPv4 addresses. Additionally, the HITs MUST be used 1583 in place of the IPv6 addresses in the IPv6 pseudo-header. Note that 1584 the pseudo-header for actual HIP payloads is computed differently; 1585 see Section 5.1.1. 1587 4.5.2. Sending Data on HIP Packets 1589 Other documents may define how to include user data in various HIP 1590 packets. However, currently the HIP header is a terminal header, and 1591 not followed by any other headers. 1593 4.5.3. Transport Formats 1595 The actual data transmission format, used for user data after the HIP 1596 base exchange, is not defined in this document. Such transport 1597 formats and methods are described in separate specifications. All 1598 HIP implementations MUST implement, at minimum, the ESP transport 1599 format for HIP [I-D.ietf-hip-rfc5202-bis]. The transport format to 1600 be chosen is negotiated in the base exchange. The Responder 1601 expresses its preference of the transport format in the 1602 TRANSPORT_FORMAT_LIST in the R1 packet and the Initiator selects one 1603 transport format and adds the respective HIP parameter to the I2 1604 packet. 1606 4.5.4. Reboot, Timeout, and Restart of HIP 1608 Simulating a loss of state is a potential DoS attack. The following 1609 process has been crafted to manage state recovery without presenting 1610 a DoS opportunity. 1612 If a host reboots or the HIP association times out, it has lost its 1613 HIP state. If the host that lost state has a datagram to send to the 1614 peer, it simply restarts the HIP base exchange. After the base 1615 exchange has completed, the Initiator can create a new payload 1616 association and start sending data. The peer does not reset its 1617 state until it receives a valid I2 packet. 1619 If a system receives a user data packet that cannot be matched to any 1620 existing HIP association, it is possible that it has lost the state 1621 and its peer has not. It MAY send an ICMP packet with the Parameter 1622 Problem type, and with the pointer pointing to the referred HIP- 1623 related association information. Reacting to such traffic depends on 1624 the implementation and the environment where the implementation is 1625 used. 1627 If the host, that apparently has lost its state, decides to restart 1628 the HIP base exchange, it sends an I1 packet to the peer. After the 1629 base exchange has been completed successfully, the Initiator can 1630 create a new HIP association and the peer drops its old payload 1631 associations and creates a new one. 1633 4.6. Certificate Distribution 1635 This document does not define how to use certificates or how to 1636 transfer them between hosts. These functions are expected to be 1637 defined in a future specification as for HIP Version 1 [RFC6253]. A 1638 parameter type value, meant to be used for carrying certificates, is 1639 reserved, though: CERT, Type 768; see Section 5.2. 1641 5. Packet Formats 1643 5.1. Payload Format 1645 All HIP packets start with a fixed header. 1647 0 1 2 3 1648 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 1649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1650 | Next Header | Header Length |0| Packet Type |Version| RES.|1| 1651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1652 | Checksum | Controls | 1653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1654 | Sender's Host Identity Tag (HIT) | 1655 | | 1656 | | 1657 | | 1658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1659 | Receiver's Host Identity Tag (HIT) | 1660 | | 1661 | | 1662 | | 1663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1664 | | 1665 / HIP Parameters / 1666 / / 1667 | | 1668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1669 The HIP header is logically an IPv6 extension header. However, this 1670 document does not describe processing for Next Header values other 1671 than decimal 59, IPPROTO_NONE, the IPv6 'no next header' value. 1672 Future documents MAY define behavior for also other values. However, 1673 current implementations MUST ignore trailing data if an unimplemented 1674 Next Header value is received. 1676 The Header Length field contains the combined length of the HIP 1677 Header and HIP parameters in 8-byte units, excluding the first 8 1678 bytes. Since all HIP headers MUST contain the sender's and 1679 receiver's HIT fields, the minimum value for this field is 4, and 1680 conversely, the maximum length of the HIP Parameters field is 1681 (255*8)-32 = 2008 bytes (see Section 5.1.3 regarding HIP 1682 fragmentation). Note: this sets an additional limit for sizes of 1683 parameters included in the Parameters field, independent of the 1684 individual parameter maximum lengths. 1686 The Packet Type indicates the HIP packet type. The individual packet 1687 types are defined in the relevant sections. If a HIP host receives a 1688 HIP packet that contains an unrecognized packet type, it MUST drop 1689 the packet. 1691 The HIP Version field is four bits. The version defined in this 1692 document is 2. The version number is expected to be incremented only 1693 if there are incompatible changes to the protocol. Most extensions 1694 can be handled by defining new packet types, new parameter types, or 1695 new Controls (see Section 5.1.2) . 1697 The following three bits are reserved for future use. They MUST be 1698 zero when sent, and they MUST be ignored when handling a received 1699 packet. 1701 The two fixed bits in the header are reserved for SHIM6 compatibility 1702 [RFC5533], Section 5.3. For implementations adhering (only) to this 1703 specification, they MUST be set as shown when sending and MUST be 1704 ignored when receiving. This is to ensure optimal forward 1705 compatibility. Note that for implementations that implement other 1706 compatible specifications in addition to this specification, the 1707 corresponding rules may well be different. For example, an 1708 implementation that implements both this specification and the SHIM6 1709 protocol may need to check these bits in order to determine how to 1710 handle the packet. 1712 The HIT fields are always 128 bits (16 bytes) long. 1714 5.1.1. Checksum 1716 Since the checksum covers the source and destination addresses in the 1717 IP header, it MUST be recomputed on HIP-aware NAT devices. 1719 If IPv6 is used to carry the HIP packet, the pseudo-header [RFC2460] 1720 contains the source and destination IPv6 addresses, HIP packet length 1721 in the pseudo-header length field, a zero field, and the HIP protocol 1722 number (see Section 5.1) in the Next Header field. The length field 1723 is in bytes and can be calculated from the HIP header length field: 1725 (HIP Header Length + 1) * 8. 1727 In case of using IPv4, the IPv4 UDP pseudo-header format [RFC0768] is 1728 used. In the pseudo-header, the source and destination addresses are 1729 those used in the IP header, the zero field is obviously zero, the 1730 protocol is the HIP protocol number (see Section 4), and the length 1731 is calculated as in the IPv6 case. 1733 5.1.2. HIP Controls 1735 The HIP Controls field conveys information about the structure of the 1736 packet and capabilities of the host. 1738 The following fields have been defined: 1740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1741 | | | | | | | | | | | | | | | |A| 1742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1744 A - Anonymous: If this is set, the sender's HI in this packet is 1745 anonymous, i.e., one not listed in a directory. Anonymous HIs 1746 SHOULD NOT be stored. This control is set in packets using 1747 anonymous sender HIs. The peer receiving an anonymous HI in an R1 1748 or I2 may choose to refuse it. 1750 The rest of the fields are reserved for future use and MUST be set to 1751 zero in sent packets and MUST be ignored in received packets. 1753 5.1.3. HIP Fragmentation Support 1755 A HIP implementation MUST support IP fragmentation/reassembly. 1756 Fragment reassembly MUST be implemented in both IPv4 and IPv6, but 1757 fragment generation is REQUIRED to be implemented in IPv4 (IPv4 1758 stacks and networks will usually do this by default) and RECOMMENDED 1759 to be implemented in IPv6. In IPv6 networks, the minimum MTU is 1760 larger, 1280 bytes, than in IPv4 networks. The larger MTU size is 1761 usually sufficient for most HIP packets, and therefore fragment 1762 generation may not be needed. If it is expected that a host will 1763 send HIP packets that are larger than the minimum IPv6 MTU, the 1764 implementation MUST implement fragment generation even for IPv6. 1766 In IPv4 networks, HIP packets may encounter low MTUs along their 1767 routed path. Since basic HIP, as defined in this document, does not 1768 provide a mechanism to use multiple IP datagrams for a single HIP 1769 packet, support for path MTU discovery does not bring any value to 1770 HIP in IPv4 networks. HIP-aware NAT devices SHOULD perform IPv4 1771 reassembly/fragmentation for HIP packets. 1773 All HIP implementations have to be careful while employing a 1774 reassembly algorithm so that the algorithm is sufficiently resistant 1775 to DoS attacks. 1777 Certificate chains can cause the packet to be fragmented and 1778 fragmentation can open implementations to denial-of-service attacks 1779 [KAU03]. "Hash and URL" schemes as defined in [RFC6253] for HIP 1780 version 1 may be used to avoid fragmentation and mitigate resulting 1781 DoS attacks. 1783 5.2. HIP Parameters 1785 The HIP parameters carry information that is necessary for 1786 establishing and maintaining a HIP association. For example, the 1787 peer's public keys as well as the signaling for negotiating ciphers 1788 and payload handling are encapsulated in HIP parameters. Additional 1789 information, meaningful for end-hosts or middleboxes, may also be 1790 included in HIP parameters. The specification of the HIP parameters 1791 and their mapping to HIP packets and packet types is flexible to 1792 allow HIP extensions to define new parameters and new protocol 1793 behavior. 1795 In HIP packets, HIP parameters are ordered according to their numeric 1796 type number and encoded in TLV format. 1798 The following parameter types are currently defined. 1800 +------------------------+-------+-----------+----------------------+ 1801 | TLV | Type | Length | Data | 1802 +------------------------+-------+-----------+----------------------+ 1803 | R1_COUNTER | 129 | 12 | Puzzle generation | 1804 | | | | counter | 1805 | | | | | 1806 | PUZZLE | 257 | 12 | K and Random #I | 1807 | | | | | 1808 | SOLUTION | 321 | 20 | K, Random #I and | 1809 | | | | puzzle solution J | 1810 | | | | | 1811 | SEQ | 385 | 4 | UPDATE packet ID | 1812 | | | | number | 1813 | | | | | 1814 | ACK | 449 | variable | UPDATE packet ID | 1815 | | | | number | 1816 | | | | | 1817 | DH_GROUP_LIST | 511 | variable | Ordered list of DH | 1818 | | | | Group IDs supported | 1819 | | | | by a host | 1820 | | | | | 1821 | DIFFIE_HELLMAN | 513 | variable | public key | 1822 | | | | | 1823 | HIP_CIPHER | 579 | variable | List of HIP | 1824 | | | | encryption | 1825 | | | | algorithms | 1826 | | | | | 1827 | ENCRYPTED | 641 | variable | Encrypted part of a | 1828 | | | | HIP packet | 1829 | | | | | 1830 | HOST_ID | 705 | variable | Host Identity with | 1831 | | | | Fully-Qualified | 1832 | | | | Domain FQDN (Name) | 1833 | | | | or Network Access | 1834 | | | | Identifier (NAI) | 1835 | | | | | 1836 | HIT_SUITE_LIST | 715 | variable | Ordered list of the | 1837 | | | | HIT suites supported | 1838 | | | | by the Responder | 1839 | | | | | 1840 | CERT | 768 | variable | HI Certificate; used | 1841 | | | | to transfer | 1842 | | | | certificates. | 1843 | | | | Specified in a | 1844 | | | | separate docment. | 1845 | | | | | 1846 | NOTIFICATION | 832 | variable | Informational data | 1847 | | | | | 1848 | ECHO_REQUEST_SIGNED | 897 | variable | Opaque data to be | 1849 | | | | echoed back; signed | 1850 | | | | | 1851 | ECHO_RESPONSE_SIGNED | 961 | variable | Opaque data echoed | 1852 | | | | back by request; | 1853 | | | | signed | 1854 | | | | | 1855 | TRANSPORT_FORMAT_LIST | 2049 | Ordered | variable | 1856 | | | list of | | 1857 | | | preferred | | 1858 | | | HIP | | 1859 | | | transport | | 1860 | | | type | | 1861 | | | numbers | | 1862 | | | | | 1863 | HIP_MAC | 61505 | variable | HMAC-based message | 1864 | | | | authentication code, | 1865 | | | | with key material | 1866 | | | | from KEYMAT | 1867 | | | | | 1868 | HIP_MAC_2 | 61569 | variable | HMAC based message | 1869 | | | | authentication code, | 1870 | | | | with key material | 1871 | | | | from KEYMAT. Unlike | 1872 | | | | HIP_MAC, the HOST_ID | 1873 | | | | parameter is | 1874 | | | | included in | 1875 | | | | HIP_MAC_2 | 1876 | | | | calculation. | 1877 | | | | | 1878 | HIP_SIGNATURE_2 | 61633 | variable | Signature used in R1 | 1879 | | | | packet | 1880 | | | | | 1881 | HIP_SIGNATURE | 61697 | variable | Signature of the | 1882 | | | | packet | 1883 | | | | | 1884 | ECHO_REQUEST_UNSIGNED | 63661 | variable | Opaque data to be | 1885 | | | | echoed back; after | 1886 | | | | signature | 1887 | | | | | 1888 | ECHO_RESPONSE_UNSIGNED | 63425 | variable | Opaque data echoed | 1889 | | | | back by request; | 1890 | | | | after signature | 1891 +------------------------+-------+-----------+----------------------+ 1893 As the ordering (from lowest to highest) of HIP parameters is 1894 strictly enforced (see Section 5.2.1), the parameter type values for 1895 existing parameters have been spaced to allow for future protocol 1896 extensions. 1898 The following parameter type number ranges are defined. 1900 +---------------+---------------------------------------------------+ 1901 | Type Range | Purpose | 1902 +---------------+---------------------------------------------------+ 1903 | 0 - 1023 | Handshake | 1904 | | | 1905 | 1024 - 2047 | Reserved | 1906 | | | 1907 | 2048 - 4095 | Parameters related to HIP transport formats | 1908 | | | 1909 | 4096 - 8191 | Signed parameters allocated through specification | 1910 | | documents | 1911 | | | 1912 | 8192 - 32767 | Reserved | 1913 | | | 1914 | 32768 - 49151 | Free for experimentation. Signed parameters. | 1915 | | | 1916 | 49152 - 61439 | Reserved | 1917 | | | 1918 | 61440 - 62463 | Signatures and (signed) MACs | 1919 | | | 1920 | 62464 - 63487 | Parameters that are neither signed nor MACed | 1921 | | | 1922 | 63488 - 64511 | Rendezvous and relaying | 1923 | | | 1924 | 64512 - 65023 | Parameters that are neither signed nor MACed | 1925 | | | 1926 | 65024 - 65535 | Reserved | 1927 +---------------+---------------------------------------------------+ 1929 The process for defining new parameters is described in Section 5.2.2 1930 of this document. 1932 The range between 32768 (2^15) and 49151 (2^15 + 2^14) are free for 1933 experimentation. Types from this range SHOULD be selected in a 1934 random fashion to reduce the probability of collisions. 1936 5.2.1. TLV Format 1938 The TLV-encoded parameters are described in the following 1939 subsections. The type-field value also describes the order of these 1940 fields in the packet. The parameters MUST be included in the packet 1941 so that their types form an increasing order. If multiple parameters 1942 with the same type number are in one packet, the parameters with the 1943 same type MUST be consecutive in the packet. If the order does not 1944 follow this rule, the packet is considered to be malformed and it 1945 MUST be discarded. 1947 Parameters using type values from 2048 up to 4095 are related to 1948 transport formats. Currently, one transport format is defined: the 1949 ESP transport format [I-D.ietf-hip-rfc5202-bis]. 1951 All of the encoded TLV parameters have a length (that includes the 1952 Type and Length fields), which is a multiple of 8 bytes. When 1953 needed, padding MUST be added to the end of the parameter so that the 1954 total length is a multiple of 8 bytes. This rule ensures proper 1955 alignment of data. Any added padding bytes MUST be zeroed by the 1956 sender, and their values SHOULD NOT be checked by the receiver. 1958 The Length field indicates the length of the Contents field (in 1959 bytes). Consequently, the total length of the TLV parameter 1960 (including Type, Length, Contents, and Padding) is related to the 1961 Length field according to the following formula: 1963 Total Length = 11 + Length - (Length + 3) % 8; 1965 where % is the modulo operator 1967 0 1 2 3 1968 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 1969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1970 | Type |C| Length | 1971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1972 | | 1973 / Contents / 1974 / +-+-+-+-+-+-+-+-+ 1975 | | Padding | 1976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1978 Type Type code for the parameter. 16 bits long, C-bit 1979 being part of the Type code. 1980 C Critical. One if this parameter is critical, and 1981 MUST be recognized by the recipient, zero otherwise. 1982 The C bit is considered to be a part of the Type 1983 field. Consequently, critical parameters are always 1984 odd and non-critical ones have an even value. 1985 Length Length of the Contents, in bytes excluding Type, 1986 Length, and Padding. 1987 Contents Parameter specific, defined by Type 1988 Padding Padding, 0-7 bytes, added if needed 1990 Critical parameters (indicated by the odd type number) MUST be 1991 recognized by the recipient. If a recipient encounters a critical 1992 parameter that it does not recognize, it MUST NOT process the packet 1993 any further. It MAY send an ICMP or NOTIFY, as defined in 1994 Section 4.3. 1996 Non-critical parameters MAY be safely ignored. If a recipient 1997 encounters a non-critical parameter that it does not recognize, it 1998 SHOULD proceed as if the parameter was not present in the received 1999 packet. 2001 5.2.2. Defining New Parameters 2003 Future specifications may define new parameters as needed. When 2004 defining new parameters, care must be taken to ensure that the 2005 parameter type values are appropriate and leave suitable space for 2006 other future extensions. One must remember that the parameters MUST 2007 always be arranged in numerically increasing order by Type code, 2008 thereby limiting the order of parameters (see Section 5.2.1). 2010 The following rules MUST be followed when defining new parameters. 2012 1. The low-order bit C of the Type code is used to distinguish 2013 between critical and non-critical parameters. Hence, even 2014 parameter type numbers indicate non-critical parameters while odd 2015 parameter type numbers indicate critical parameters. 2017 2. A new parameter MAY be critical only if an old implementation 2018 that ignored it would cause security problems. In general, new 2019 parameters SHOULD be defined as non-critical, and expect a reply 2020 from the recipient. 2022 3. If a system implements a new critical parameter, it MUST provide 2023 the ability to set the associated feature off, such that the 2024 critical parameter is not sent at all. The configuration option 2025 MUST be well documented. Implementations operating in a mode 2026 adhering to this specification MUST disable the sending of new 2027 critical parameters by default. In other words, the management 2028 interface MUST allow vanilla standards-only mode as a default 2029 configuration setting, and MAY allow new critical payloads to be 2030 configured on (and off). 2032 4. See Section 9 for allocation rules regarding Type codes. 2034 5.2.3. R1_COUNTER 2035 0 1 2 3 2036 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 2037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2038 | Type | Length | 2039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2040 | Reserved, 4 bytes | 2041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2042 | R1 generation counter, 8 bytes | 2043 | | 2044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2046 Type 129 2047 Length 12 2048 R1 generation 2049 counter The current generation of valid puzzles 2051 The R1_COUNTER parameter contains a 64-bit unsigned integer in 2052 network-byte order, indicating the current generation of valid 2053 puzzles. The sender SHOULD increment this counter periodically. It 2054 is RECOMMENDED that the counter value is incremented at least as 2055 often as old PUZZLE values are deprecated so that SOLUTIONs to them 2056 are no longer accepted. 2058 Support for the R1_COUNTER parameter is mandatory although its 2059 inclusion in the R1 packet is optional. It SHOULD be included in the 2060 R1 (in which case, it is covered by the signature), and if present in 2061 the R1, it MUST be echoed (including the Reserved field verbatim) by 2062 the Initiator in the I2 packet. 2064 5.2.4. PUZZLE 2065 0 1 2 3 2066 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 2067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2068 | Type | Length | 2069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2070 | #K, 1 byte | Lifetime | Opaque, 2 bytes | 2071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2072 | Random #I, RHASH_len/8 bytes | 2073 / / 2074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2076 Type 257 2077 Length 4 + RHASH_len / 8 2078 #K #K is the number of verified bits 2079 Lifetime puzzle lifetime 2^(value-32) seconds 2080 Opaque data set by the Responder, indexing the puzzle 2081 Random #I random number of size RHASH_len bits 2083 Random #I is represented as a n-bit integer (where n is RHASH_len), 2084 #K and Lifetime as 8-bit integers, all in network byte order. 2086 The PUZZLE parameter contains the puzzle difficulty #K and a n-bit 2087 random integer #I. The Puzzle Lifetime indicates the time during 2088 which the puzzle solution is valid, and sets a time limit that should 2089 not be exceeded by the Initiator while it attempts to solve the 2090 puzzle. The lifetime is indicated as a power of 2 using the formula 2091 2^(Lifetime-32) seconds. A puzzle MAY be augmented with an 2092 ECHO_REQUEST_SIGNED or an ECHO_REQUEST_UNSIGNED parameter included in 2093 the R1; the contents of the echo request are then echoed back in the 2094 ECHO_RESPONSE_SIGNED or in the ECHO_RESPONSE_UNSIGNED parameter, 2095 allowing the Responder to use the included information as a part of 2096 its puzzle processing. 2098 The Opaque and Random #I field are not covered by the HIP_SIGNATURE_2 2099 parameter. 2101 5.2.5. SOLUTION 2102 0 1 2 3 2103 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 2104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2105 | Type | Length | 2106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2107 | #K, 1 byte | Reserved | Opaque, 2 bytes | 2108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2109 | Random #I, n bytes | 2110 / / 2111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2112 | Puzzle solution #J, RHASH_len/8 bytes | 2113 / / 2114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2116 Type 321 2117 Length 4 + RHASH_len /4 2118 #K #K is the number of verified bits 2119 Reserved zero when sent, ignored when received 2120 Opaque copied unmodified from the received PUZZLE 2121 parameter 2122 Random #I random number of size RHASH_len bits 2123 Puzzle solution #J random number of size RHASH_len bits 2125 Random #I and Random #J are represented as n-bit unsigned integers 2126 (where n is RHASH_len), #K as an 8-bit unsigned integer, all in 2127 network byte order. 2129 The SOLUTION parameter contains a solution to a puzzle. It also 2130 echoes back the random difficulty #K, the Opaque field, and the 2131 puzzle integer #I. 2133 5.2.6. DH_GROUP_LIST 2134 0 1 2 3 2135 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 2136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2137 | Type | Length | 2138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2139 | DH GROUP ID #1| DH GROUP ID #2| DH GROUP ID #3| DH GROUP ID #4| 2140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2141 | DH GROUP ID #n| Padding | 2142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2144 Type 511 2145 Length number of DH Group IDs 2146 DH GROUP ID identifies a DH GROUP ID supported by the host. 2147 The list of IDs is ordered by preference of the 2148 host. The possible DH Group IDs are defined 2149 in the DIFFIE_HELLMAN parameter. Each DH Group ID 2150 is one octet long. 2152 The DH_GROUP_LIST parameter contains the list of supported DH Group 2153 IDs of a host. The Initiator sends the DH_GROUP_LIST in the I1 2154 packet, the Responder sends its own list in the signed part of the R1 2155 packet. The DH Group IDs in the DH_GROUP_LIST are listed in the 2156 order of their preference of the host sending the list. DH Group IDs 2157 that are listed first are preferred over the DH Group IDs listed 2158 later. The information in the DH_GROUP_LIST allows the Responder to 2159 select the DH group preferred by itself and supported by the 2160 Initiator. Based on the DH_GROUP_LIST in the R1 packet, the 2161 Initiator can determine if the Responder has selected the best 2162 possible choice based on the Initiator's and Responder's preferences. 2163 If the Responder's choice differs from the best choice, the Initiator 2164 can conclude that there was an attempted downgrade attack (see 2165 Section 4.1.7). 2167 When selecting the DH group for the DIFFIE_HELLMAN parameter in the 2168 R1 packet, the Responder MUST select the first DH Group ID in its 2169 DH_GROUP_LIST in the R1 packet that is compatible with one of the 2170 Suite IDs in the Initiator's DH_GROUP_LIST in the I1 packet. The 2171 Responder MUST NOT select any other DH Group ID that is contained in 2172 both lists because a downgrade attack cannot be detected then. 2174 In general, hosts SHOULD prefer stronger groups over weaker ones if 2175 the computation overhead is not prohibitively high for the intended 2176 application. 2178 5.2.7. DIFFIE_HELLMAN 2180 0 1 2 3 2181 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 2182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2183 | Type | Length | 2184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2185 | Group ID | Public Value Length | Public Value / 2186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2187 / | 2188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2189 / | Padding | 2190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2192 Type 513 2193 Length length in octets, excluding Type, Length, and 2194 Padding 2195 Group ID identifies values for p and g as well as the KDF 2196 Public Value length of the following Public Value in octets 2197 Length 2198 Public Value the sender's public Diffie-Hellman key 2200 A single DIFFIE_HELLMAN parameter may be included in selected HIP 2201 packets based on the DH Group ID selected (Section 5.2.6). The 2202 following Group IDs have been defined: 2204 Group KDF Value 2205 Reserved 0 2206 DEPRECATED 1 2207 DEPRECATED 2 2208 1536-bit MODP group [RFC3526] HKDF [RFC5869] 3 2209 3072-bit MODP group [RFC3526] HKDF [RFC5869] 4 2210 DEPRECATED 5 2211 DEPRECATED 6 2212 NIST P-256 [RFC5903] HKDF [RFC5869] 7 2213 NIST P-384 [RFC5903] HKDF [RFC5869] 8 2214 NIST P-521 [RFC5903] HKDF [RFC5869] 9 2215 SECP160R1 [SECG] HKDF [RFC5869] 10 2216 2048-bit MODP group [RFC3526] HKDF [RFC5869] 11 2218 The MODP Diffie-Hellman groups are defined in [RFC3526]. The ECDH 2219 groups 7 - 9 are defined in [RFC5903] and [RFC6090]. ECDH group 10 2220 is covered in Appendix D. Any ECDH used with HIP MUST have a co- 2221 factor of 1. 2223 The Group ID also defines the key derivation function that is to be 2224 used for deriving the symmetric keys for the HMAC and symmetric 2225 encryption from the keying material from the Diffie Hellman key 2226 exchange (see Section 6.5). 2228 A HIP implementation MUST implement Group ID 3. The 160-bit 2229 SECP160R1 group can be used when lower security is enough (e.g., web 2230 surfing) and when the equipment is not powerful enough (e.g., some 2231 PDAs). Implementations SHOULD implement Group IDs 4 and 8. 2233 To avoid unnecessary failures during the base exchange, the rest of 2234 the groups SHOULD be implemented in hosts where resources are 2235 adequate. 2237 5.2.8. HIP_CIPHER 2239 0 1 2 3 2240 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 2241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2242 | Type | Length | 2243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2244 | Cipher ID #1 | Cipher ID #2 | 2245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2246 | Cipher ID #n | Padding | 2247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2249 Type 579 2250 Length length in octets, excluding Type, Length, and 2251 Padding 2252 Cipher ID identifies the cipher algorithm to be used for 2253 encrypting the contents of the ENCRYPTED parameter 2255 The following Cipher IDs are defined: 2257 Suite ID Value 2259 RESERVED 0 2260 NULL-ENCRYPT 1 ([RFC2410]) 2261 AES-128-CBC 2 ([RFC3602]) 2262 RESERVED 3 (unused value) 2263 AES-256-CBC 4 ([RFC3602]) 2265 The sender of a HIP_CIPHER parameter MUST make sure that there are no 2266 more than six (6) Cipher IDs in one HIP_CIPHER parameter. 2267 Conversely, a recipient MUST be prepared to handle received transport 2268 parameters that contain more than six Cipher IDs by accepting the 2269 first six Cipher IDs and dropping the rest. The limited number of 2270 Cipher IDs sets the maximum size of the HIP_CIPHER parameter. As the 2271 default configuration, the HIP_CIPHER parameter MUST contain at least 2272 one of the mandatory Cipher IDs. There MAY be a configuration option 2273 that allows the administrator to override this default. 2275 The Responder lists supported and desired Cipher IDs in order of 2276 preference in the R1, up to the maximum of six Cipher IDs. The 2277 Initiator MUST choose only one of the corresponding Cipher IDs. This 2278 Cipher ID will be used for generating the ENCRYPTED parameter. 2280 Mandatory implementation: AES-128-CBC. Implementors SHOULD support 2281 NULL-ENCRYPT for testing/debugging purposes, but MUST NOT offer or 2282 accept this value unless explicitly configured for testing/debugging 2283 of the HIP protocol. 2285 5.2.9. HOST_ID 2287 0 1 2 3 2288 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 2289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2290 | Type | Length | 2291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2292 | HI Length |DI-type| DI Length | 2293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2294 | Algorithm | Host Identity / 2295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2296 / | Domain Identifier / 2297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2298 / | Padding | 2299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2301 Type 705 2302 Length length in octets, excluding Type, Length, and 2303 Padding 2304 HI Length length of the Host Identity in octets 2305 DI-type type of the following Domain Identifier field 2306 DI Length length of the Domain Identifier field in octets 2307 Algorithm index to the employed algorithm 2308 Host Identity actual Host Identity 2309 Domain Identifier the identifier of the sender 2311 The following DI-types have been defined: 2313 Type Value 2314 none included 0 2315 FQDN 1 2316 NAI 2 2318 FQDN Fully Qualified Domain Name, in binary format. 2319 NAI Network Access Identifier 2321 The format for the FQDN is defined in RFC 1035 [RFC1035] Section 3.1. 2322 The format for the NAI is defined in [RFC4282] 2324 A host MAY optionally associate the Host Identity with a single 2325 Domain Identifier in the HOST_ID parameter. If there is no Domain 2326 Identifier, i.e., the DI-type field is zero, the DI Length field is 2327 set to zero as well. 2329 The following HI Algorithms have been defined: 2331 Algorithm 2332 profiles Values 2334 RESERVED 0 2335 DSA 3 [FIPS186-3] (RECOMMENDED) 2336 RSA 5 [RFC3447] (REQUIRED) 2337 ECDSA 7 [RFC4754] (REQUIRED) 2338 ECDSA_LOW 9 [SECG] (RECOMMENDED) 2340 For DSA, RSA, and ECDSA key types, profiles containing at least 112 2341 bits of security strength (as defined by [NIST.800-131A.2011]) should 2342 be used. For RSA signature padding, the PSS method of padding 2343 [RFC3447] MUST be used. 2345 The Host Identity is derived from the DNSKEY format for RSA and DSA. 2346 For these, the Public Key field of the RDATA part from RFC 4034 2347 [RFC4034] is used. For ECC we distinguish two different profiles: 2348 ECDSA and ECDSA_LOW. ECC contains curves approved by NIST and 2349 defined in RFC 4754 [RFC4754]. ECDSA_LOW is defined for devices with 2350 low computational capabilities and uses shorter curves from SECG 2351 [SECG]. Any ECDSA used with HIP MUST have a co-factor of 1. 2353 For ECDSA and ECDSA_LOW Host Identities are represented by the 2354 following fields: 2356 0 1 2 3 2357 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 2358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2359 | ECC Curve | / 2360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2361 / Public Key | 2362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2364 ECC Curve Curve label 2365 Public Key Represented in Octet-string format 2366 [RFC6090] 2368 For hosts that implement ECDSA as algorithm the following ECC curves 2369 are required: 2371 Algorithm Curve Values 2373 ECDSA RESERVED 0 2374 ECDSA NIST P-256 1 [RFC4754] 2375 ECDSA NIST P-384 2 [RFC4754] 2377 For hosts that implement the ECDSA_LOW algorithm profile, the 2378 following curve is required: 2380 Algorithm Curve Values 2382 ECDSA_LOW RESERVED 0 2383 ECDSA_LOW SECP160R1 1 [SECG] 2385 5.2.10. HIT_SUITE_LIST 2387 The HIT_SUITE_LIST parameter contains a list of the supported HIT 2388 Suite IDs of the Responder. The Responder sends the HIT_SUITE_LIST 2389 in the signed part of the R1 packet. Based on the HIT_SUITE_LIST, 2390 the Initiator can determine which source HIT Suite IDs are supported 2391 by the Responder. 2393 0 1 2 3 2394 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 2395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2396 | Type | Length | 2397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2398 | ID #1 | ID #2 | ID #3 | ID #4 | 2399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2400 | ID #n | Padding | 2401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2403 Type 715 2404 Length number of HIT Suite IDs 2405 ID identifies a HIT Suite ID supported by the host. 2406 The list of IDs is ordered by preference of the 2407 host. Each HIT Suite ID is one octet long. The four 2408 higher-order bits of the ID field correspond to the 2409 HIT Suite ID in the ORCHID OGA field. The four 2410 lower-order bits are reserved and set to 0 by 2411 the sender. The reception of an ID with the 2412 four lower-order bits not set to 0 SHOULD be 2413 considered as an error that MAY result in a 2414 NOTIFICATION of type UNSUPPORTED_HIT_SUITE. 2416 The HIT Suite ID indexes a HIT Suite. HIT Suites are composed of 2417 signature algorithms as defined in Section 5.2.9 and hash functions. 2419 The ID field in the HIT_SUITE_LIST is defined as eight-bit field as 2420 opposed to the four-bit HIT Suite ID and OGA field in the ORCHID. 2421 This difference is a measure to accommodate larger HIT Suite IDs if 2422 the 16 available values prove insufficient. In that case, one of the 2423 16 values, zero, will be used to indicate that four additional bits 2424 of the ORCHID will be used to encode the HIT Suite ID. Hence, the 2425 current four-bit HIT Suite-IDs only use the four higher order bits in 2426 the ID field. Future documents may define the use of the four lower- 2427 order bits in the ID field. 2429 The following HIT Suites ID are defined, and the relationship between 2430 the four-bit ID value used in the OGA ID field, and the eight-bit 2431 encoding within the HIT_SUITE_LIST ID field, is clarified: 2433 HIT Suite Four-bit ID Eight-bit encoding 2434 RESERVED 0 0x00 2435 RSA,DSA/SHA-256 1 0x10 (REQUIRED) 2436 ECDSA/SHA-384 2 0x20 (RECOMMENDED) 2437 ECDSA_LOW/SHA-1 3 0x30 (RECOMMENDED) 2439 The following table provides more detail on the above HIT Suite 2440 combinations. The input for each generation algorithm is the 2441 encoding of the HI as defined in Section 3.2. The output is 96 bits 2442 long and is directly used in the ORCHID. 2444 +-------+----------+--------------+------------+--------------------+ 2445 | Index | Hash | HMAC | Signature | Description | 2446 | | function | | algorithm | | 2447 | | | | family | | 2448 +-------+----------+--------------+------------+--------------------+ 2449 | 0 | | | | Reserved | 2450 | 1 | SHA-256 | HMAC-SHA-256 | RSA, DSA | RSA or DSA HI | 2451 | | | | | hashed with | 2452 | | | | | SHA-256, truncated | 2453 | | | | | to 96 bits | 2454 | 2 | SHA-384 | HMAC-SHA-384 | ECDSA | ECDSA HI hashed | 2455 | | | | | with SHA-384, | 2456 | | | | | truncated to 96 | 2457 | | | | | bits | 2458 | 3 | SHA-1 | HMAC-SHA-1 | ECDSA_LOW | ECDSA_LOW HI | 2459 | | | | | hashed with SHA-1, | 2460 | | | | | truncated to 96 | 2461 | | | | | bits | 2462 +-------+----------+--------------+------------+--------------------+ 2464 Table 10: HIT Suites 2466 The hash of the responder as defined in the HIT Suite determines the 2467 HMAC to be used for the RHASH function. The HMACs currently defined 2468 here are HMAC-SHA-256 [RFC4868], HMAC-SHA-384 [RFC4868], and HMAC- 2469 SHA-1 [RFC2404]. 2471 5.2.11. TRANSPORT_FORMAT_LIST 2473 The TRANSPORT_FORMAT_LIST parameter contains a list of the supported 2474 HIP transport formats (TFs) of the Responder. The Responder sends 2475 the TRANSPORT_FORMAT_LIST in the signed part of the R1 packet. Based 2476 on the TRANSPORT_FORMAT_LIST, the Initiator chooses one suitable 2477 transport format and includes the respective HIP transport format 2478 parameter in its response packet. 2480 0 1 2 3 2481 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 2482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2483 | Type | Length | 2484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2485 | TF type #1 | TF type #2 / 2486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2487 / TF type #n | Padding | 2488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2490 Type 2049 2491 Length 2x number of TF types 2492 TF Type identifies a transport format (TF) type supported by 2493 the host. The TF type numbers correspond to the HIP 2494 parameter type numbers of the respective transport 2495 format 2496 parameters. The list of TF types is ordered by 2497 preference of the sender 2499 The TF type numbers index the respective HIP parameters for the 2500 transport formats in the type number range between 2050 to 4095. The 2501 parameters and their use are defined in separate documents. 2502 Currently, the only transport format defined is IPsec ESP 2503 [I-D.ietf-hip-rfc5202-bis]. 2505 For each listed TF type, the sender of the TRANSPORT_FORMAT_LIST 2506 parameter MUST include the respective transport format parameter in 2507 the HIP packet. The receiver MUST ignore the TF type in the 2508 TRANSPORT_FORMAT_LIST if no matching transport format parameter is 2509 present in the packet. 2511 5.2.12. HIP_MAC 2512 0 1 2 3 2513 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 2514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2515 | Type | Length | 2516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2517 | | 2518 | HMAC | 2519 / / 2520 / +-------------------------------+ 2521 | | Padding | 2522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2524 Type 61505 2525 Length length in octets, excluding Type, Length, and 2526 Padding 2527 HMAC HMAC computed over the HIP packet, excluding the 2528 HIP_MAC parameter and any following parameters, such 2529 as HIP_SIGNATURE, HIP_SIGNATURE_2, 2530 ECHO_REQUEST_UNSIGNED, or ECHO_RESPONSE_UNSIGNED. 2531 The checksum field MUST be set to zero and the HIP 2532 header length in the HIP common header MUST be 2533 calculated not to cover any excluded parameters 2534 when the HMAC is calculated. The size of the 2535 HMAC is the natural size of the hash computation 2536 output depending on the used hash function. 2538 The HMAC uses RHASH as hash algorithm. The calculation and 2539 verification process is presented in Section 6.4.1. 2541 5.2.13. HIP_MAC_2 2543 The HIP_MAC_2 is a MAC of the packet and the HI of the sender in the 2544 form of a HOST_ID parameter when that parameter is not actually 2545 included in the packet. The parameter structure is the same as in 2546 Section 5.2.12. The fields are: 2548 Type 61569 2549 Length length in octets, excluding Type, Length, and 2550 Padding 2551 HMAC HMAC computed over the HIP packet, excluding the 2552 HIP_MAC_2 parameter and any following parameters 2553 such as HIP_SIGNATURE, HIP_SIGNATURE_2, 2554 ECHO_REQUEST_UNSIGNED, or ECHO_RESPONSE_UNSIGNED, 2555 and including an additional sender's HOST_ID 2556 parameter during the HMAC calculation. The checksum 2557 field MUST be set to zero and the HIP header length 2558 in the HIP common header MUST be calculated not to 2559 cover any excluded parameters when the HMAC is 2560 calculated. The size of the HMAC is the natural 2561 size of the hash computation output depending on the 2562 used hash function. 2564 The HMAC uses RHASH as hash algorithm. The calculation and 2565 verification process is presented in Section 6.4.1. 2567 5.2.14. HIP_SIGNATURE 2569 0 1 2 3 2570 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 2571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2572 | Type | Length | 2573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2574 | SIG alg | Signature / 2575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2576 / | Padding | 2577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2579 Type 61697 2580 Length length in octets, excluding Type, Length, and 2581 Padding 2582 SIG alg signature algorithm 2583 Signature the signature is calculated over the HIP packet, 2584 excluding the HIP_SIGNATURE parameter and any 2585 parameters that follow the HIP_SIGNATURE parameter. 2586 When the signature is calculated the checksum field 2587 MUST be set to zero, and the HIP header length in 2588 the HIP common header MUST be calculated only up to 2589 the beginning of the HIP_SIGNATURE parameter. 2591 The signature algorithms are defined in Section 5.2.9. The signature 2592 in the Signature field is encoded using the method depending on the 2593 signature algorithm (e.g., according to [RFC3110] in case of RSA/SHA- 2594 1, according to [RFC5702] in case of RSA/SHA-256, according to 2596 [RFC2536] in case of DSA, or according to [RFC6090] in case of 2597 ECDSA). 2599 The HIP_SIGNATURE calculation and verification process are presented 2600 in Section 6.4.2. 2602 5.2.15. HIP_SIGNATURE_2 2604 The HIP_SIGNATURE_2 excludes the variable parameters in the R1 packet 2605 to allow R1 pre-creation. The parameter structure is the same as in 2606 Section 5.2.14. The fields are: 2608 Type 61633 2609 Length length in octets, excluding Type, Length, and 2610 Padding 2611 SIG alg signature algorithm 2612 Signature Within the R1 packet that contains the 2613 HIP_SIGNATURE_2 parameter, the Initiator's HIT, the 2614 checksum field, and the Opaque and Random #I fields 2615 in the PUZZLE parameter MUST be set to zero while 2616 computing the HIP_SIGNATURE_2 signature. Further, 2617 the HIP packet length in the HIP header MUST be 2618 adjusted as if the HIP_SIGNATURE_2 was not in the 2619 packet during the signature calculation, i.e., the 2620 HIP packet length points to the beginning of 2621 the HIP_SIGNATURE_2 parameter during signing and 2622 verification. 2624 Zeroing the Initiator's HIT makes it possible to create R1 packets 2625 beforehand, to minimize the effects of possible DoS attacks. Zeroing 2626 the Random #I and Opaque fields within the PUZZLE parameter allows 2627 these fields to be populated dynamically on precomputed R1s. 2629 Signature calculation and verification follows the process defined in 2630 Section 6.4.2. 2632 5.2.16. SEQ 2634 0 1 2 3 2635 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2637 | Type | Length | 2638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2639 | Update ID | 2640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2641 Type 385 2642 Length 8 2643 Update ID 32-bit sequence number 2645 The Update ID is an unsigned number in network byte order, 2646 initialized by a host to zero upon moving to ESTABLISHED state. The 2647 Update ID has scope within a single HIP association, and not across 2648 multiple associations or multiple hosts. The Update ID is 2649 incremented by one before each new UPDATE that is sent by the host; 2650 the first UPDATE packet originated by a host has an Update ID of 0. 2652 5.2.17. ACK 2654 0 1 2 3 2655 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 2656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2657 | Type | Length | 2658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2659 | peer Update ID 1 | 2660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2661 / peer Update ID n | 2662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2664 Type 449 2665 Length length in octets, excluding Type and Length 2666 peer Update ID 32-bit sequence number corresponding to the 2667 Update ID being ACKed. 2669 The ACK parameter includes one or more Update IDs that have been 2670 received from the peer. The number of peer Update IDs can be 2671 inferred from the length by dividing it by 4. 2673 5.2.18. ENCRYPTED 2674 0 1 2 3 2675 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 2676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2677 | Type | Length | 2678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2679 | Reserved | 2680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2681 | IV / 2682 / / 2683 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 2685 / Encrypted data / 2686 / / 2687 / +-------------------------------+ 2688 / | Padding | 2689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2691 Type 641 2692 Length length in octets, excluding Type, Length, and 2693 Padding 2694 Reserved zero when sent, ignored when received 2695 IV Initialization vector, if needed, otherwise 2696 nonexistent. The length of the IV is inferred from 2697 the HIP_CIPHER. 2698 Encrypted The data is encrypted using the encryption algorithm 2699 data defined in the HIP_CIPHER parameter. 2701 The ENCRYPTED parameter encapsulates other parameters, the encrypted 2702 data, which holds one or more HIP parameters in block encrypted form. 2704 Consequently, the first fields in the encapsulated parameter(s) are 2705 Type and Length of the first such parameter, allowing the contents to 2706 be easily parsed after decryption. 2708 The field labeled "Encrypted data" consists of the output of one or 2709 more HIP parameters concatenated together that have been passed 2710 through an encryption algorithm. Each of these inner parameters is 2711 padded according to the rules of Section 5.2.1 for padding individual 2712 parameters. As a result, the concatenated parameters will be a block 2713 of data that is 8-byte aligned. 2715 Some encryption algorithms require that the data to be encrypted must 2716 be a multiple of the cipher algorithm block size. In this case, the 2717 above block of data MUST include additional padding, as specified by 2718 the encryption algorithm. The size of the extra padding is selected 2719 so that the length of the unencrypted data block is a multiple of the 2720 cipher block size. The encryption algorithm may specify padding 2721 bytes other than zero; for example, AES [FIPS.197.2001] uses the 2722 PKCS5 padding scheme (see section 6.1.1 of [RFC2898]) where the 2723 remaining n bytes to fill the block each have the value of n. This 2724 yields an "unencrypted data" block that is transformed to an 2725 "encrypted data" block by the cipher suite. This extra padding added 2726 to the set of parameters to satisfy the cipher block alignment rules 2727 is not counted in HIP TLV length fields, and this extra padding 2728 should be removed by the cipher suite upon decryption. 2730 Note that the length of the cipher suite output may be smaller or 2731 larger than the length of the set of parameters to be encrypted, 2732 since the encryption process may compress the data or add additional 2733 padding to the data. 2735 Once this encryption process is completed, the Encrypted data field 2736 is ready for inclusion in the parameter. If necessary, additional 2737 Padding for 8-byte alignment is then added according to the rules of 2738 Section 5.2.1. 2740 5.2.19. NOTIFICATION 2742 The NOTIFICATION parameter is used to transmit informational data, 2743 such as error conditions and state transitions, to a HIP peer. A 2744 NOTIFICATION parameter may appear in NOTIFY packets. The use of the 2745 NOTIFICATION parameter in other packet types is for further study. 2747 0 1 2 3 2748 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 2749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2750 | Type | Length | 2751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2752 | Reserved | Notify Message Type | 2753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2754 | / 2755 / Notification Data / 2756 / +---------------+ 2757 / | Padding | 2758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2760 Type 832 2761 Length length in octets, excluding Type, Length, and 2762 Padding 2763 Reserved zero when sent, ignored when received 2764 Notify Message specifies the type of notification 2765 Type 2766 Notification informational or error data transmitted in addition 2767 Data to the Notify Message Type. Values for this field 2768 are type specific (see below). 2769 multiple of 8 bytes. 2771 Notification information can be error messages specifying why an HIP 2772 Security Association could not be established. It can also be status 2773 data that a HIP implementation wishes to communicate with a peer 2774 process. The table below lists the notification messages and their 2775 Notification Message Types. HIP packets MAY contain multiple 2776 NOTIFICATION parameters if several problems exist or several 2777 independent pieces of information must be transmitted. 2779 To avoid certain types of attacks, a Responder SHOULD avoid sending a 2780 NOTIFICATION to any host with which it has not successfully verified 2781 a puzzle solution. 2783 Notify Message Types in the range 0-16383 are intended for reporting 2784 errors and in the range 16384-65535 for other status information. An 2785 implementation that receives a NOTIFY packet with a Notify Message 2786 Type that indicates an error in response to a request packet (e.g., 2787 I1, I2, UPDATE) SHOULD assume that the corresponding request has 2788 failed entirely. Unrecognized error types MUST be ignored except 2789 that they SHOULD be logged. 2791 As currently defined, Notify Message Type values 1-10 are used for 2792 informing about errors in packet structures, values 11-20 for 2793 informing about problems in parameters. 2795 Notification Data in NOTIFICATION parameters where the Notify Message 2796 Type is in the status range MUST be ignored if not recognized. 2798 Notify Message Types - Errors Value 2799 ----------------------------- ----- 2801 UNSUPPORTED_CRITICAL_PARAMETER_TYPE 1 2803 Sent if the parameter type has the "critical" bit set and the 2804 parameter type is not recognized. Notification Data contains the 2805 two-octet parameter type. 2807 INVALID_SYNTAX 7 2809 Indicates that the HIP message received was invalid because some 2810 type, length, or value was out of range or because the request 2811 was otherwise malformed. To avoid a denial-of-service 2812 attack using forged messages, this status may only be returned 2813 for packets whose HIP_MAC (if present) and SIGNATURE have been 2814 verified. This status MUST be sent in response to any error not 2815 covered by one of the other status types, and SHOULD NOT contain 2816 details to avoid leaking information to someone probing a node. 2817 To aid debugging, more detailed error information SHOULD be 2818 written to a console or log. 2820 NO_DH_PROPOSAL_CHOSEN 14 2822 None of the proposed group IDs was acceptable. 2824 INVALID_DH_CHOSEN 15 2826 The DH Group ID field does not correspond to one offered 2827 by the Responder. 2829 NO_HIP_PROPOSAL_CHOSEN 16 2831 None of the proposed HIT Suites or HIP Encryption Algorithms was 2832 acceptable. 2834 INVALID_HIP_CIPHER_CHOSEN 17 2836 The HIP_CIPHER Crypto ID does not correspond to one offered by 2837 the Responder. 2839 UNSUPPORTED_HIT_SUITE 20 2841 Sent in response to an I1 or R1 packet for which the HIT suite 2842 is not supported. 2844 AUTHENTICATION_FAILED 24 2846 Sent in response to a HIP signature failure, except when 2847 the signature verification fails in a NOTIFY message. 2849 CHECKSUM_FAILED 26 2851 Sent in response to a HIP checksum failure. 2853 HIP_MAC_FAILED 28 2855 Sent in response to a HIP HMAC failure. 2857 ENCRYPTION_FAILED 32 2859 The Responder could not successfully decrypt the 2860 ENCRYPTED parameter. 2862 INVALID_HIT 40 2864 Sent in response to a failure to validate the peer's 2865 HIT from the corresponding HI. 2867 BLOCKED_BY_POLICY 42 2868 The Responder is unwilling to set up an association 2869 for some policy reason (e.g., received HIT is NULL 2870 and policy does not allow opportunistic mode). 2872 RESPONDER_BUSY_PLEASE_RETRY 44 2874 The Responder is unwilling to set up an association as it is 2875 suffering under some kind of overload and has chosen to shed load 2876 by rejecting the Initiator's request. The Initiator may retry; 2877 however, the Initiator MUST find another (different) puzzle 2878 solution for any such retries. Note that the Initiator may need 2879 to obtain a new puzzle with a new I1/R1 exchange. 2881 Notify Message Types - Status Value 2882 ----------------------------- ----- 2884 I2_ACKNOWLEDGEMENT 16384 2886 The Responder has an I2 packet from the Initiator but had to 2887 queue the I2 packet for processing. The puzzle was correctly 2888 solved and the Responder is willing to set up an association but 2889 currently has a number of I2 packets in the processing queue. 2890 The R2 packet is sent after the I2 packet was processed. 2892 5.2.20. ECHO_REQUEST_SIGNED 2894 0 1 2 3 2895 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 2896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2897 | Type | Length | 2898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2899 | Opaque data (variable length) | 2900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2902 Type 897 2903 Length length of the opaque data in octets 2904 Opaque data opaque data, supposed to be meaningful only to the 2905 node that sends ECHO_REQUEST_SIGNED and receives a 2906 corresponding ECHO_RESPONSE_SIGNED or 2907 ECHO_RESPONSE_UNSIGNED. 2909 The ECHO_REQUEST_SIGNED parameter contains an opaque blob of data 2910 that the sender wants to get echoed back in the corresponding reply 2911 packet. 2913 The ECHO_REQUEST_SIGNED and corresponding echo response parameters 2914 MAY be used for any purpose where a node wants to carry some state in 2915 a request packet and get it back in a response packet. The 2916 ECHO_REQUEST_SIGNED is covered by the HIP_MAC and SIGNATURE. A HIP 2917 packet can contain only one ECHO_REQUEST_SIGNED parameter and MAY 2918 contain multiple ECHO_REQUEST_UNSIGNED parameters. The 2919 ECHO_REQUEST_SIGNED parameter MUST be responded to with an 2920 ECHO_RESPONSE_SIGNED. 2922 5.2.21. ECHO_REQUEST_UNSIGNED 2924 0 1 2 3 2925 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2927 | Type | Length | 2928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2929 | Opaque data (variable length) | 2930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2932 Type 63661 2933 Length length of the opaque data in octets 2934 Opaque data opaque data, supposed to be meaningful only to the 2935 node that sends ECHO_REQUEST_UNSIGNED and receives a 2936 corresponding ECHO_RESPONSE_UNSIGNED. 2938 The ECHO_REQUEST_UNSIGNED parameter contains an opaque blob of data 2939 that the sender wants to get echoed back in the corresponding reply 2940 packet. 2942 The ECHO_REQUEST_UNSIGNED and corresponding echo response parameters 2943 MAY be used for any purpose where a node wants to carry some state in 2944 a request packet and get it back in a response packet. The 2945 ECHO_REQUEST_UNSIGNED is not covered by the HIP_MAC and SIGNATURE. A 2946 HIP packet can contain one or more ECHO_REQUEST_UNSIGNED parameters. 2947 It is possible that middleboxes add ECHO_REQUEST_UNSIGNED parameters 2948 in HIP packets passing by. The creator of the ECHO_REQUEST_UNSIGNED 2949 (end-host or middlebox) has to create the Opaque field so that it can 2950 later identify and remove the corresponding ECHO_RESPONSE_UNSIGNED 2951 parameter. 2953 The ECHO_REQUEST_UNSIGNED parameter MUST be responded to with an 2954 ECHO_RESPONSE_UNSIGNED parameter. 2956 5.2.22. ECHO_RESPONSE_SIGNED 2957 0 1 2 3 2958 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 2959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2960 | Type | Length | 2961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2962 | Opaque data (variable length) | 2963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2965 Type 961 2966 Length length of the opaque data in octets 2967 Opaque data opaque data, copied unmodified from the 2968 ECHO_REQUEST_SIGNED or ECHO_REQUEST_UNSIGNED 2969 parameter that triggered this response. 2971 The ECHO_RESPONSE_SIGNED parameter contains an opaque blob of data 2972 that the sender of the ECHO_REQUEST_SIGNED wants to get echoed back. 2973 The opaque data is copied unmodified from the ECHO_REQUEST_SIGNED 2974 parameter. 2976 The ECHO_REQUEST_SIGNED and ECHO_RESPONSE_SIGNED parameters MAY be 2977 used for any purpose where a node wants to carry some state in a 2978 request packet and get it back in a response packet. The 2979 ECHO_RESPONSE_SIGNED is covered by the HIP_MAC and SIGNATURE. 2981 5.2.23. ECHO_RESPONSE_UNSIGNED 2983 0 1 2 3 2984 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 2985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2986 | Type | Length | 2987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2988 | Opaque data (variable length) | 2989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2991 Type 63425 2992 Length length of the opaque data in octets 2993 Opaque data opaque data, copied unmodified from the 2994 ECHO_REQUEST_SIGNED or ECHO_REQUEST_UNSIGNED 2995 parameter that triggered this response. 2997 The ECHO_RESPONSE_UNSIGNED parameter contains an opaque blob of data 2998 that the sender of the ECHO_REQUEST_SIGNED or ECHO_REQUEST_UNSIGNED 2999 wants to get echoed back. The opaque data is copied unmodified from 3000 the corresponding echo request parameter. 3002 The echo request and ECHO_RESPONSE_UNSIGNED parameters MAY be used 3003 for any purpose where a node wants to carry some state in a request 3004 packet and get it back in a response packet. The 3005 ECHO_RESPONSE_UNSIGNED is not covered by the HIP_MAC and SIGNATURE. 3007 5.3. HIP Packets 3009 There are eight basic HIP packets (see Table 11). Four are for the 3010 HIP base exchange, one is for updating, one is for sending 3011 notifications, and two are for closing a HIP association. Support 3012 for NOTIFY packet type is optional, but support for all other HIP 3013 packet types listed below is mandatory. 3015 +------------------+------------------------------------------------+ 3016 | Packet type | Packet name | 3017 +------------------+------------------------------------------------+ 3018 | 1 | I1 - the HIP Initiator Packet | 3019 | | | 3020 | 2 | R1 - the HIP Responder Packet | 3021 | | | 3022 | 3 | I2 - the Second HIP Initiator Packet | 3023 | | | 3024 | 4 | R2 - the Second HIP Responder Packet | 3025 | | | 3026 | 16 | UPDATE - the HIP Update Packet | 3027 | | | 3028 | 17 | NOTIFY - the HIP Notify Packet | 3029 | | | 3030 | 18 | CLOSE - the HIP Association Closing Packet | 3031 | | | 3032 | 19 | CLOSE_ACK - the HIP Closing Acknowledgment | 3033 | | Packet | 3034 +------------------+------------------------------------------------+ 3036 Table 11: HIP packets and packet type values 3038 Packets consist of the fixed header as described in Section 5.1, 3039 followed by the parameters. The parameter part, in turn, consists of 3040 zero or more TLV-coded parameters. 3042 In addition to the base packets, other packet types may be defined 3043 later in separate specifications. For example, support for mobility 3044 and multi-homing is not included in this specification. 3046 See Notation (Section 2.2) for the notation used in the operations. 3048 In the future, an optional upper-layer payload MAY follow the HIP 3049 header. The Next Header field in the header indicates if there is 3050 additional data following the HIP header. The HIP packet, however, 3051 MUST NOT be fragmented into multiple extension headers by setting the 3052 Next Header field in a HIP header to the HIP protocol number. This 3053 limits the size of the possible additional data in the packet. 3055 5.3.1. I1 - the HIP Initiator Packet 3057 The HIP header values for the I1 packet: 3059 Header: 3060 Packet Type = 1 3061 SRC HIT = Initiator's HIT 3062 DST HIT = Responder's HIT, or NULL 3064 IP ( HIP ( DH_GROUP_LIST ) ) 3066 The I1 packet contains the fixed HIP header and the Initiator's 3067 DH_GROUP_LIST. 3069 Valid control bits: none 3071 The Initiator receives the Responder's HIT either from a DNS lookup 3072 of the Responder's FQDN (see 5205-bis), from some other repository, 3073 or from a local table. If the Initiator does not know the 3074 Responder's HIT, it may attempt to use opportunistic mode by using 3075 NULL (all zeros) as the Responder's HIT. See also "HIP Opportunistic 3076 Mode" (Section 4.1.8). 3078 Since the I1 packet is so easy to spoof even if it were signed, no 3079 attempt is made to add to its generation or processing cost. 3081 The Initiator includes a DH_GROUP_LIST parameter in the I1 packet to 3082 inform the Responder of its preferred DH Group IDs. Note that the 3083 DH_GROUP_LIST in the I1 packet is not protected by a signature. 3085 Implementations MUST be able to handle a storm of received I1 3086 packets, discarding those with common content that arrive within a 3087 small time delta. 3089 5.3.2. R1 - the HIP Responder Packet 3091 The HIP header values for the R1 packet: 3093 Header: 3094 Packet Type = 2 3095 SRC HIT = Responder's HIT 3096 DST HIT = Initiator's HIT 3098 IP ( HIP ( [ R1_COUNTER, ] 3099 PUZZLE, 3100 DIFFIE_HELLMAN, 3101 HIP_CIPHER, 3102 HOST_ID, 3103 HIT_SUITE_LIST, 3104 DH_GROUP_LIST, 3105 [ ECHO_REQUEST_SIGNED, ] 3106 TRANSPORT_FORMAT_LIST, 3107 HIP_SIGNATURE_2 ) 3108 <, ECHO_REQUEST_UNSIGNED >i) 3110 Valid control bits: A 3112 If the Responder's HI is an anonymous one, the A control MUST be set. 3114 The Initiator's HIT MUST match the one received in the I1 packet if 3115 the R1 is a response to an I1. If the Responder has multiple HIs, 3116 the Responder's HIT used MUST match Initiator's request. If the 3117 Initiator used opportunistic mode, the Responder may select freely 3118 among its HIs. See also "HIP Opportunistic Mode" (Section 4.1.8). 3120 The R1 packet generation counter is used to determine the currently 3121 valid generation of puzzles. The value is increased periodically, 3122 and it is RECOMMENDED that it is increased at least as often as 3123 solutions to old puzzles are no longer accepted. 3125 The Puzzle contains a Random #I and the difficulty #K. The 3126 difficulty #K indicates the number of lower-order bits, in the puzzle 3127 hash result, that must be zeros; see Section 4.1.2. The Random #I is 3128 not covered by the signature and must be zeroed during the signature 3129 calculation, allowing the sender to select and set the #I into a 3130 precomputed R1 packet just prior sending it to the peer. 3132 The Responder selects the Diffie-Hellman public value based on the 3133 Initiator's preference expressed in the DH_GROUP_LIST parameter in 3134 the I1 packet. The Responder sends back its own preference based on 3135 which it chose the DH public value as DH_GROUP_LIST. This allows the 3136 Initiator to determine whether its own DH_GROUP_LIST in the sent I1 3137 packet was manipulated by an attacker. 3139 The Diffie-Hellman public value is ephemeral, and values SHOULD NOT 3140 be reused across different HIP associations. Once the Responder has 3141 received a valid response to an R1 packet, that Diffie-Hellman value 3142 SHOULD be deprecated. It is possible that the Responder has sent the 3143 same Diffie-Hellman value to different hosts simultaneously in 3144 corresponding R1 packets and those responses should also be accepted. 3145 However, as a defense against I1 packet storms, an implementation MAY 3146 propose, and re-use unless avoidable, the same Diffie-Hellman value 3147 for a period of time, for example, 15 minutes. By using a small 3148 number of different puzzles for a given Diffie-Hellman value, the R1 3149 packets can be precomputed and delivered as quickly as I1 packets 3150 arrive. A scavenger process should clean up unused Diffie-Hellman 3151 values and puzzles. 3153 Re-using Diffie-Hellman public values opens up the potential security 3154 risk of more than one Initiator ending up with the same keying 3155 material (due to faulty random number generators). Also, more than 3156 one Initiator using the same Responder public key half may lead to 3157 potentially easier cryptographic attacks and to imperfect forward 3158 security. 3160 However, these risks involved in re-using the same public value are 3161 statistical; that is, the authors are not aware of any mechanism that 3162 would allow manipulation of the protocol so that the risk of the re- 3163 use of any given Responder Diffie-Hellman public key would differ 3164 from the base probability. Consequently, it is RECOMMENDED that 3165 Responders avoid re-using the same DH key with multiple Initiators, 3166 but because the risk is considered statistical and not known to be 3167 manipulable, the implementations MAY re-use a key in order to ease 3168 resource-constrained implementations and to increase the probability 3169 of successful communication with legitimate clients even under an I1 3170 packet storm. In particular, when it is too expensive to generate 3171 enough precomputed R1 packets to supply each potential Initiator with 3172 a different DH key, the Responder MAY send the same DH key to several 3173 Initiators, thereby creating the possibility of multiple legitimate 3174 Initiators ending up using the same Responder-side public key. 3175 However, as soon as the Responder knows that it will use a particular 3176 DH key, it SHOULD stop offering it. This design is aimed to allow 3177 resource-constrained Responders to offer services under I1 packet 3178 storms and to simultaneously make the probability of DH key re-use 3179 both statistical and as low as possible. 3181 If the Responder uses the same DH keypair for multiple handshakes, it 3182 must take care to avoid small subgroup attacks [RFC2785]. To avoid 3183 these attacks, when receiving the I2 message, the Responder SHOULD 3184 validate the Initiators DH public key as described in [RFC2785] 3185 Section 3.1. In case the validation fails, the Responder MUST NOT 3186 generate a DH shared key and MUST silently abort the HIP BEX. 3188 The HIP_CIPHER contains the encryption algorithms supported by the 3189 Responder to encrypt the contents of the ENCRYPTED parameter, in the 3190 order of preference. All implementations MUST support AES [RFC3602]. 3192 The HIT_SUITE_LIST parameter is an ordered list of the Responder's 3193 preferred and supported HIT Suites. The list allows the Initiator to 3194 determine whether its own source HIT matches any suite supported by 3195 the Responder. 3197 The ECHO_REQUEST_SIGNED and ECHO_REQUEST_UNSIGNED parameters contain 3198 data that the sender wants to receive unmodified in the corresponding 3199 response packet in the ECHO_RESPONSE_SIGNED or ECHO_RESPONSE_UNSIGNED 3200 parameter. The R1 packet may contain zero or more 3201 ECHO_REQUEST_UNSIGNED parameters as described in 3202 Section Section 5.2.21. 3204 The TRANSPORT_FORMAT_LIST parameter is an ordered list of the 3205 Responder's preferred and supported transport format types. The list 3206 allows the Initiator and the Responder to agree on a common type for 3207 payload protection. This parameter is described in Section 5.2.11. 3209 The signature is calculated over the whole HIP packet as described in 3210 Section 5.2.15. This allows the Responder to use precomputed R1s. 3211 The Initiator SHOULD validate this signature. It MUST check that the 3212 Responder's HI matches with the one expected, if any. 3214 5.3.3. I2 - the Second HIP Initiator Packet 3216 The HIP header values for the I2 packet: 3218 Header: 3219 Type = 3 3220 SRC HIT = Initiator's HIT 3221 DST HIT = Responder's HIT 3223 IP ( HIP ( [R1_COUNTER,] 3224 SOLUTION, 3225 DIFFIE_HELLMAN, 3226 HIP_CIPHER, 3227 ENCRYPTED { HOST_ID } or HOST_ID, 3228 [ ECHO_RESPONSE_SIGNED ,] 3229 TRANSPORT_FORMAT_LIST, 3230 HIP_MAC, 3231 HIP_SIGNATURE 3232 <, ECHO_RESPONSE_UNSIGNED>i ) ) 3234 Valid control bits: A 3235 The HITs used MUST match the ones used in the R1. 3237 If the Initiator's HI is an anonymous one, the A control bit MUST be 3238 set. 3240 If present in the I1 packet, the Initiator MUST include an unmodified 3241 copy of the R1_COUNTER parameter received in the corresponding R1 3242 packet into the I2 packet. 3244 The Solution contains the Random #I from R1 and the computed #J. The 3245 low-order #K bits of the RHASH(I | ... | J) MUST be zero. 3247 The Diffie-Hellman value is ephemeral. If precomputed, a scavenger 3248 process should clean up unused Diffie-Hellman values. The Responder 3249 MAY re-use Diffie-Hellman values under some conditions as specified 3250 in Section 5.3.2. 3252 The HIP_CIPHER contains the single encryption suite selected by the 3253 Initiator, that it uses to encrypt the ENCRYPTED parameters. The 3254 chosen cipher MUST correspond to one of the ciphers offered by the 3255 Responder in the R1. All implementations MUST support AES [RFC3602]. 3257 The Initiator's HI MAY be encrypted using the HIP_CIPHER encryption 3258 algorithm. The keying material is derived from the Diffie-Hellman 3259 exchanged as defined in Section 6.5. 3261 The ECHO_RESPONSE_SIGNED and ECHO_RESPONSE_UNSIGNED contain the 3262 unmodified Opaque data copied from the corresponding echo request 3263 parameter(s). 3265 The TRANSPORT_FORMAT_LIST contains the single transport format type 3266 selected by the Initiator. The chosen type MUST correspond to one of 3267 the types offered by the Responder in the R1. Currently, the only 3268 transport format defined is the ESP transport format 3269 ([I-D.ietf-hip-rfc5202-bis]). 3271 The HMAC value in the HIP_MAC parameter is calculated over the whole 3272 HIP packet, excluding any parameters after the HIP_MAC, as described 3273 in Section 6.4.1. The Responder MUST validate the HIP_MAC. 3275 The signature is calculated over the whole HIP packet, excluding any 3276 parameters after the HIP_SIGNATURE, as described in Section 5.2.14. 3277 The Responder MUST validate this signature. The Responder uses the 3278 HI in the packet or a HI acquired by some other means for verifying 3279 the signature. 3281 5.3.4. R2 - the Second HIP Responder Packet 3283 The HIP header values for the R2 packet: 3285 Header: 3286 Packet Type = 4 3287 SRC HIT = Responder's HIT 3288 DST HIT = Initiator's HIT 3290 IP ( HIP ( HIP_MAC_2, HIP_SIGNATURE ) ) 3292 Valid control bits: none 3294 The HIP_MAC_2 is calculated over the whole HIP packet, with 3295 Responder's HOST_ID parameter concatenated with the HIP packet. The 3296 HOST_ID parameter is removed after the HMAC calculation. The 3297 procedure is described in Section 6.4.1. 3299 The signature is calculated over the whole HIP packet. 3301 The Initiator MUST validate both the HIP_MAC and the signature. 3303 5.3.5. UPDATE - the HIP Update Packet 3305 The HIP header values for the UPDATE packet: 3307 Header: 3308 Packet Type = 16 3309 SRC HIT = Sender's HIT 3310 DST HIT = Recipient's HIT 3312 IP ( HIP ( [SEQ, ACK, ] HIP_MAC, HIP_SIGNATURE ) ) 3314 Valid control bits: None 3316 The UPDATE packet contains mandatory HIP_MAC and HIP_SIGNATURE 3317 parameters, and other optional parameters. 3319 The UPDATE packet contains zero or one SEQ parameter. The presence 3320 of a SEQ parameter indicates that the receiver MUST acknowledge the 3321 the UPDATE. An UPDATE that does not contain a SEQ but only an ACK 3322 parameter is simply an acknowledgment of a previous UPDATE and itself 3323 MUST NOT be acknowledged by a separate ACK parameter. Such UPDATE 3324 packets containing only an ACK parameter do not require processing in 3325 relative order to other UPDATE packets. An UPDATE packet without 3326 either a SEQ or an ACK parameter is invalid; such unacknowledged 3327 updates MUST instead use a NOTIFY packet. 3329 An UPDATE packet contains zero or one ACK parameters. The ACK 3330 parameter echoes the SEQ sequence number of the UPDATE packet being 3331 ACKed. A host MAY choose to acknowledge more than one UPDATE packet 3332 at a time; e.g., the ACK parameter may contain the last two SEQ 3333 values received, for resilience against packet loss. ACK values are 3334 not cumulative; each received unique SEQ value requires at least one 3335 corresponding ACK value in reply. Received ACK parameters that are 3336 redundant are ignored. Hosts MUST implement the processing of ACK 3337 parameters with multiple SEQ numbers even if they do not implement 3338 sending ACK parameters with multiple SEQ numbers. 3340 The UPDATE packet may contain both a SEQ and an ACK parameter. In 3341 this case, the ACK parameter is being piggybacked on an outgoing 3342 UPDATE. In general, UPDATEs carrying SEQ SHOULD be ACKed upon 3343 completion of the processing of the UPDATE. A host MAY choose to 3344 hold the UPDATE carrying an ACK parameter for a short period of time 3345 to allow for the possibility of piggybacking the ACK parameter, in a 3346 manner similar to TCP delayed acknowledgments. 3348 A sender MAY choose to forego reliable transmission of a particular 3349 UPDATE (e.g., it becomes overcome by events). The semantics are such 3350 that the receiver MUST acknowledge the UPDATE, but the sender MAY 3351 choose to not care about receiving the ACK parameter. 3353 UPDATEs MAY be retransmitted without incrementing SEQ. If the same 3354 subset of parameters is included in multiple UPDATEs with different 3355 SEQs, the host MUST ensure that the receiver's processing of the 3356 parameters multiple times will not result in a protocol error. 3358 5.3.6. NOTIFY - the HIP Notify Packet 3360 The NOTIFY packet MAY be used to provide information to a peer. 3361 Typically, NOTIFY is used to indicate some type of protocol error or 3362 negotiation failure. NOTIFY packets are unacknowledged. The 3363 receiver can handle the packet only as informational, and SHOULD NOT 3364 change its HIP state (see Section 4.4.2) based purely on a received 3365 NOTIFY packet. 3367 The HIP header values for the NOTIFY packet: 3369 Header: 3370 Packet Type = 17 3371 SRC HIT = Sender's HIT 3372 DST HIT = Recipient's HIT, or zero if unknown 3374 IP ( HIP (i, [HOST_ID, ] HIP_SIGNATURE) ) 3376 Valid control bits: None 3377 The NOTIFY packet is used to carry one or more NOTIFICATION 3378 parameters. 3380 5.3.7. CLOSE - the HIP Association Closing Packet 3382 The HIP header values for the CLOSE packet: 3384 Header: 3385 Packet Type = 18 3386 SRC HIT = Sender's HIT 3387 DST HIT = Recipient's HIT 3389 IP ( HIP ( ECHO_REQUEST_SIGNED, HIP_MAC, HIP_SIGNATURE ) ) 3391 Valid control bits: none 3393 The sender MUST include an ECHO_REQUEST_SIGNED used to validate 3394 CLOSE_ACK received in response, and both a HIP_MAC and a signature 3395 (calculated over the whole HIP packet). 3397 The receiver peer MUST reply with a CLOSE_ACK containing an 3398 ECHO_RESPONSE_SIGNED corresponding to the received 3399 ECHO_REQUEST_SIGNED. 3401 5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet 3403 The HIP header values for the CLOSE_ACK packet: 3405 Header: 3406 Packet Type = 19 3407 SRC HIT = Sender's HIT 3408 DST HIT = Recipient's HIT 3410 IP ( HIP ( ECHO_RESPONSE_SIGNED, HIP_MAC, HIP_SIGNATURE ) ) 3412 Valid control bits: none 3414 The sender MUST include both an HMAC and signature (calculated over 3415 the whole HIP packet). 3417 The receiver peer MUST validate the ECHO_RESPONSE_SIGNED and validate 3418 both the HIP_MAC and the signature if the receiver has state for a 3419 HIP association. 3421 5.4. ICMP Messages 3423 When a HIP implementation detects a problem with an incoming packet, 3424 and it either cannot determine the identity of the sender of the 3425 packet or does not have any existing HIP association with the sender 3426 of the packet, it MAY respond with an ICMP packet. Any such replies 3427 MUST be rate-limited as described in [RFC4443]. In most cases, the 3428 ICMP packet has the Parameter Problem type (12 for ICMPv4, 4 for 3429 ICMPv6), with the Pointer field pointing to the field that caused the 3430 ICMP message to be generated. 3432 5.4.1. Invalid Version 3434 If a HIP implementation receives a HIP packet that has an 3435 unrecognized HIP version number, it SHOULD respond, rate-limited, 3436 with an ICMP packet with type Parameter Problem, with the Pointer 3437 pointing to the Version/RES. byte in the HIP header. 3439 5.4.2. Other Problems with the HIP Header and Packet Structure 3441 If a HIP implementation receives a HIP packet that has other 3442 unrecoverable problems in the header or packet format, it MAY 3443 respond, rate-limited, with an ICMP packet with type Parameter 3444 Problem, the Pointer pointing to the field that failed to pass the 3445 format checks. However, an implementation MUST NOT send an ICMP 3446 message if the checksum fails; instead, it MUST silently drop the 3447 packet. 3449 5.4.3. Invalid Puzzle Solution 3451 If a HIP implementation receives an I2 packet that has an invalid 3452 puzzle solution, the behavior depends on the underlying version of 3453 IP. If IPv6 is used, the implementation SHOULD respond with an ICMP 3454 packet with type Parameter Problem, the Pointer pointing to the 3455 beginning of the Puzzle solution #J field in the SOLUTION payload in 3456 the HIP message. 3458 If IPv4 is used, the implementation MAY respond with an ICMP packet 3459 with the type Parameter Problem, copying enough of bytes from the I2 3460 message so that the SOLUTION parameter fits into the ICMP message, 3461 the Pointer pointing to the beginning of the Puzzle solution #J 3462 field, as in the IPv6 case. Note, however, that the resulting ICMPv4 3463 message exceeds the typical ICMPv4 message size as defined in 3464 [RFC0792]. 3466 5.4.4. Non-Existing HIP Association 3468 If a HIP implementation receives a CLOSE or UPDATE packet, or any 3469 other packet whose handling requires an existing association, that 3470 has either a Receiver or Sender HIT that does not match with any 3471 existing HIP association, the implementation MAY respond, rate- 3472 limited, with an ICMP packet with the type Parameter Problem. The 3473 Pointer of the ICMP Parameter Problem packet is set pointing to the 3474 beginning of the first HIT that does not match. 3476 A host MUST NOT reply with such an ICMP if it receives any of the 3477 following messages: I1, R2, I2, R2, and NOTIFY packet. When 3478 introducing new packet types, a specification SHOULD define the 3479 appropriate rules for sending or not sending this kind of ICMP reply. 3481 6. Packet Processing 3483 Each host is assumed to have a single HIP protocol implementation 3484 that manages the host's HIP associations and handles requests for new 3485 ones. Each HIP association is governed by a conceptual state 3486 machine, with states defined above in Section 4.4. The HIP 3487 implementation can simultaneously maintain HIP associations with more 3488 than one host. Furthermore, the HIP implementation may have more 3489 than one active HIP association with another host; in this case, HIP 3490 associations are distinguished by their respective HITs. It is not 3491 possible to have more than one HIP association between any given pair 3492 of HITs. Consequently, the only way for two hosts to have more than 3493 one parallel association is to use different HITs, at least at one 3494 end. 3496 The processing of packets depends on the state of the HIP 3497 association(s) with respect to the authenticated or apparent 3498 originator of the packet. A HIP implementation determines whether it 3499 has an active association with the originator of the packet based on 3500 the HITs. In the case of user data carried in a specific transport 3501 format, the transport format document specifies how the incoming 3502 packets are matched with the active associations. 3504 6.1. Processing Outgoing Application Data 3506 In a HIP host, an application can send application-level data using 3507 an identifier specified via the underlying API. The API can be a 3508 backwards-compatible API (see [RFC5338]), using identifiers that look 3509 similar to IP addresses, or a completely new API, providing enhanced 3510 services related to Host Identities. Depending on the HIP 3511 implementation, the identifier provided to the application may be 3512 different; for example, it can be a HIT or an IP address. 3514 The exact format and method for transferring the user data from the 3515 source HIP host to the destination HIP host is defined in the 3516 corresponding transport format document. The actual data is 3517 transferred in the network using the appropriate source and 3518 destination IP addresses. 3520 In this document, conceptual processing rules are defined only for 3521 the base case where both hosts have only single usable IP addresses; 3522 the multi-address multi-homing case is specified separately. 3524 The following conceptual algorithm describes the steps that are 3525 required for handling outgoing datagrams destined to a HIT. 3527 1. If the datagram has a specified source address, it MUST be a HIT. 3528 If it is not, the implementation MAY replace the source address 3529 with a HIT. Otherwise, it MUST drop the packet. 3531 2. If the datagram has an unspecified source address, the 3532 implementation MUST choose a suitable source HIT for the 3533 datagram. Selecting the source HIT is subject to local policy. 3535 3. If there is no active HIP association with the given HIT pair, one MUST be created by running the base 3537 exchange. While waiting for the base exchange to complete, the 3538 implementation SHOULD queue at least one user data packet per HIP 3539 association to be formed, and it MAY queue more than one. 3541 4. Once there is an active HIP association for the given HIT pair, the outgoing datagram is passed to 3543 transport handling. The possible transport formats are defined 3544 in separate documents, of which the ESP transport format for HIP 3545 is mandatory for all HIP implementations. 3547 5. Before sending the packet, the HITs in the datagram are replaced 3548 with suitable IP addresses. For IPv6, the rules defined in 3549 [RFC6724] SHOULD be followed. Note that this HIT-to-IP-address 3550 conversion step MAY also be performed at some other point in the 3551 stack, e.g., before wrapping the packet into the output format. 3553 6.2. Processing Incoming Application Data 3555 The following conceptual algorithm describes the incoming datagram 3556 handling when HITs are used at the receiving host as application- 3557 level identifiers. More detailed steps for processing packets are 3558 defined in corresponding transport format documents. 3560 1. The incoming datagram is mapped to an existing HIP association, 3561 typically using some information from the packet. For example, 3562 such mapping may be based on the ESP Security Parameter Index 3563 (SPI). 3565 2. The specific transport format is unwrapped, in a way depending on 3566 the transport format, yielding a packet that looks like a 3567 standard (unencrypted) IP packet. If possible, this step SHOULD 3568 also verify that the packet was indeed (once) sent by the remote 3569 HIP host, as identified by the HIP association. 3571 Depending on the used transport mode, the verification method can 3572 vary. While the HI (as well as HIT) is used as the higher-layer 3573 identifier, the verification method has to verify that the data 3574 packet was sent by the correct node identity and that the actual 3575 identity maps to this particular HIT. When using ESP transport 3576 format [I-D.ietf-hip-rfc5202-bis], the verification is done using 3577 the SPI value in the data packet to find the corresponding SA 3578 with associated HIT and key, and decrypting the packet with that 3579 associated key. 3581 3. The IP addresses in the datagram are replaced with the HITs 3582 associated with the HIP association. Note that this IP-address- 3583 to-HIT conversion step MAY also be performed at some other point 3584 in the stack. 3586 4. The datagram is delivered to the upper layer (e.g., UDP or TCP). 3587 When demultiplexing the datagram, the right upper-layer socket is 3588 selected based on the HITs. 3590 6.3. Solving the Puzzle 3592 This subsection describes the details for solving the puzzle. 3594 In the R1 packet, the values #I and #K are sent in network byte 3595 order. Similarly, in the I2 packet, the values #I and #J are sent in 3596 network byte order. The hash is created by concatenating, in network 3597 byte order, the following data, in the following order and using the 3598 RHASH algorithm: 3600 n-bit random value #I (where n is RHASH_len), in network byte 3601 order, as appearing in the R1 and I2 packets. 3603 128-bit Initiator's HIT, in network byte order, as appearing in 3604 the HIP Payload in the R1 and I2 packets. 3606 128-bit Responder's HIT, in network byte order, as appearing in 3607 the HIP Payload in the R1 and I2 packets. 3609 n-bit random value #J (where n is RHASH_len), in network byte 3610 order, as appearing in the I2 packet. 3612 In a valid response puzzle, the #K low-order bits of the resulting 3613 RHASH digest MUST be zero. 3615 Notes: 3617 i) The length of the data to be hashed is variable depending on 3618 the output length of the Responder's hash function RHASH. 3620 ii) All the data in the hash input MUST be in network byte order. 3622 iii) The order of the Initiator's and Responder's HITs are 3623 different in the R1 and I2 packets; see Section 5.1. Care must be 3624 taken to copy the values in the right order to the hash input. 3626 iv) For a puzzle #I, there may exist multiple valid puzzle 3627 solutions #J. 3629 The following procedure describes the processing steps involved, 3630 assuming that the Responder chooses to precompute the R1 packets: 3632 Precomputation by the Responder: 3633 Sets up the puzzle difficulty #K. 3634 Creates a signed R1 and caches it. 3636 Responder: 3637 Selects a suitable cached R1. 3638 Generates a random number #I. 3639 Sends #I and #K in an R1. 3640 Saves #I and #K for a Delta time. 3642 Initiator: 3643 Generates repeated attempts to solve the puzzle until a matching 3644 #J is found: 3645 Ltrunc( RHASH( #I | HIT-I | HIT-R | #J ), #K ) == 0 3646 Sends #I and #J in an I2. 3648 Responder: 3649 Verifies that the received #I is a saved one. 3650 Finds the right #K based on #I. 3651 Computes V := Ltrunc( RHASH( #I | HIT-I | HIT-R | #J ), #K ) 3652 Rejects if V != 0 3653 Accept if V == 0 3655 6.4. HIP_MAC and SIGNATURE Calculation and Verification 3657 The following subsections define the actions for processing HIP_MAC, 3658 HIP_MAC_2, HIP_SIGNATURE and HIP_SIGNATURE_2 parameters. The 3659 HIP_MAC_2 parameter is contained in the R2 packet. The 3660 HIP_SIGNATURE_2 parameter is contained in the R1 packet. The 3661 HIP_SIGNATURE and HIP_MAC parameter are contained in other HIP 3662 packets. 3664 6.4.1. HMAC Calculation 3666 The HMAC uses RHASH as underlying hash function. The type of RHASH 3667 depends on the HIT Suite of the Responder. Hence, HMAC-SHA-256 3668 [RFC4868] is used for HIT Suite RSA/DSA/SHA-256, HMAC-SHA-1 [RFC2404] 3669 is used for HIT Suite ECDSA_LOW/SHA-1, and HMAC-SHA-384 [RFC4868] for 3670 HIT Suite ECDSA/SHA-384. 3672 The following process applies both to the HIP_MAC and HIP_MAC_2 3673 parameters. When processing HIP_MAC_2, the difference is that the 3674 HIP_MAC calculation includes a pseudo HOST_ID field containing the 3675 Responder's information as sent in the R1 packet earlier. 3677 Both the Initiator and the Responder should take some care when 3678 verifying or calculating the HIP_MAC_2. Specifically, the Initiator 3679 has to preserve the HOST_ID exactly as it was received in the R1 3680 packet until it receives the HIP_MAC_2 in the R2 packet. 3682 The scope of the calculation for HIP_MAC is: 3684 HMAC: { HIP header | [ Parameters ] } 3686 where Parameters include all HIP parameters of the packet that is 3687 being calculated with Type values ranging from 1 to (HIP_MAC's Type 3688 value - 1) and exclude parameters with Type values greater or equal 3689 to HIP_MAC's Type value. 3691 During HIP_MAC calculation, the following applies: 3693 o In the HIP header, the Checksum field is set to zero. 3695 o In the HIP header, the Header Length field value is calculated to 3696 the beginning of the HIP_MAC parameter. 3698 Parameter order is described in Section 5.2.1. 3700 The scope of the calculation for HIP_MAC_2 is: 3702 HIP_MAC_2: { HIP header | [ Parameters ] | HOST_ID } 3704 where Parameters include all HIP parameters for the packet that is 3705 being calculated with Type values from 1 to (HIP_MAC_2's Type value - 3706 1) and exclude parameters with Type values greater or equal to 3707 HIP_MAC_2's Type value. 3709 During HIP_MAC_2 calculation, the following applies: 3711 o In the HIP header, the Checksum field is set to zero. 3713 o In the HIP header, the Header Length field value is calculated to 3714 the beginning of the HIP_MAC_2 parameter and increased by the 3715 length of the concatenated HOST_ID parameter length (including 3716 type and length fields). 3718 o HOST_ID parameter is exactly in the form it was received in the R1 3719 packet from the Responder. 3721 Parameter order is described in Section 5.2.1, except that the 3722 HOST_ID parameter in this calculation is added to the end. 3724 The HIP_MAC parameter is defined in Section 5.2.12 and the HIP_MAC_2 3725 parameter in Section 5.2.13. The HMAC calculation and verification 3726 process (the process applies both to HIP_MAC and HIP_MAC_2 except 3727 where HIP_MAC_2 is mentioned separately) is as follows: 3729 Packet sender: 3731 1. Create the HIP packet, without the HIP_MAC, HIP_SIGNATURE, 3732 HIP_SIGNATURE_2, or any other parameter with greater Type value 3733 than the HIP_MAC parameter has. 3735 2. In case of HIP_MAC_2 calculation, add a HOST_ID (Responder) 3736 parameter to the end of the packet. 3738 3. Calculate the Header Length field in the HIP header including the 3739 added HOST_ID parameter in case of HIP_MAC_2. 3741 4. Compute the HMAC using either HIP-gl or HIP-lg integrity key 3742 retrieved from KEYMAT as defined in Section 6.5. 3744 5. In case of HIP_MAC_2, remove the HOST_ID parameter from the 3745 packet. 3747 6. Add the HIP_MAC parameter to the packet and any parameter with 3748 greater Type value than the HIP_MAC's (HIP_MAC_2's) that may 3749 follow, including possible HIP_SIGNATURE or HIP_SIGNATURE_2 3750 parameters 3752 7. Recalculate the Length field in the HIP header. 3754 Packet receiver: 3756 1. Verify the HIP header Length field. 3758 2. Remove the HIP_MAC or HIP_MAC_2 parameter, as well as all other 3759 parameters that follow it with greater Type value including 3760 possible HIP_SIGNATURE or HIP_SIGNATURE_2 fields, saving the 3761 contents if they are needed later. 3763 3. In case of HIP_MAC_2, build and add a HOST_ID parameter (with 3764 Responder information) to the packet. The HOST_ID parameter 3765 should be identical to the one previously received from the 3766 Responder. 3768 4. Recalculate the HIP packet length in the HIP header and clear the 3769 Checksum field (set it to all zeros). In case of HIP_MAC_2, the 3770 length is calculated with the added HOST_ID parameter. 3772 5. Compute the HMAC using either HIP-gl or HIP-lg integrity key as 3773 defined in Section 6.5 and verify it against the received HMAC. 3775 6. Set Checksum and Header Length field in the HIP header to 3776 original values. Note that the checksum and length fields 3777 contain incorrect values after this step. 3779 7. In case of HIP_MAC_2, remove the HOST_ID parameter from the 3780 packet before further processing. 3782 6.4.2. Signature Calculation 3784 The following process applies both to the HIP_SIGNATURE and 3785 HIP_SIGNATURE_2 parameters. When processing the HIP_SIGNATURE_2, the 3786 only difference is that instead of the HIP_SIGNATURE parameter, the 3787 HIP_SIGNATURE_2 parameter is used, and the Initiator's HIT and PUZZLE 3788 Opaque and Random #I fields are cleared (set to all zeros) before 3789 computing the signature. The HIP_SIGNATURE parameter is defined in 3790 Section 5.2.14 and the HIP_SIGNATURE_2 parameter in Section 5.2.15. 3792 The scope of the calculation for HIP_SIGNATURE and HIP_SIGNATURE_2 3793 is: 3795 HIP_SIGNATURE: { HIP header | [ Parameters ] } 3797 where Parameters include all HIP parameters for the packet that is 3798 being calculated with Type values from 1 to (HIP_SIGNATURE's Type 3799 value - 1). 3801 During signature calculation, the following applies: 3803 o In the HIP header, the Checksum field is set to zero. 3805 o In the HIP header, the Header Length field value is calculated to 3806 the beginning of the HIP_SIGNATURE parameter. 3808 The parameter order is described in Section 5.2.1. 3810 HIP_SIGNATURE_2: { HIP header | [ Parameters ] } 3812 where Parameters include all HIP parameters for the packet that is 3813 being calculated with Type values ranging from 1 to 3814 (HIP_SIGNATURE_2's Type value - 1). 3816 During signature calculation, the following apply: 3818 o In the HIP header, the Initiator's HIT field and Checksum fields 3819 are set to zero. 3821 o In the HIP header, the Header Length field value is calculated to 3822 the beginning of the HIP_SIGNATURE_2 parameter. 3824 o PUZZLE parameter's Opaque and Random #I fields are set to zero. 3826 Parameter order is described in Section 5.2.1. 3828 The signature calculation and verification process (the process 3829 applies both to HIP_SIGNATURE and HIP_SIGNATURE_2 except in the case 3830 where HIP_SIGNATURE_2 is separately mentioned) is as follows: 3832 Packet sender: 3834 1. Create the HIP packet without the HIP_SIGNATURE parameter or any 3835 other parameters that follow the HIP_SIGNATURE parameter. 3837 2. Calculate the Length field and zero the Checksum field in the HIP 3838 header. In case of HIP_SIGNATURE_2, set Initiator's HIT field in 3839 the HIP header as well as PUZZLE parameter's Opaque and Random #I 3840 fields to zero. 3842 3. Compute the signature using the private key corresponding to the 3843 Host Identifier (public key). 3845 4. Add the HIP_SIGNATURE parameter to the packet. 3847 5. Add any parameters that follow the HIP_SIGNATURE parameter. 3849 6. Recalculate the Length field in the HIP header, and calculate the 3850 Checksum field. 3852 Packet receiver: 3854 1. Verify the HIP header Length field and checksum. 3856 2. Save the contents of the HIP_SIGNATURE parameter and any other 3857 parameters following the HIP_SIGNATURE parameter and remove them 3858 from the packet. 3860 3. Recalculate the HIP packet Length in the HIP header and clear the 3861 Checksum field (set it to all zeros). In case of 3862 HIP_SIGNATURE_2, set Initiator's HIT field in the HIP header as 3863 well as PUZZLE parameter's Opaque and Random #I fields to zero. 3865 4. Compute the signature and verify it against the received 3866 signature using the packet sender's Host Identity (public key). 3868 5. Restore the original packet by adding removed parameters (in step 3869 2) and resetting the values that were set to zero (in step 3). 3871 The verification can use either the HI received from a HIP packet, 3872 the HI from a DNS query, if the FQDN has been received in the HOST_ID 3873 packet or one received by some other means. 3875 6.5. HIP KEYMAT Generation 3877 HIP keying material is derived from the Diffie-Hellman session key, 3878 Kij, produced during the HIP base exchange (see Section 4.1.3). The 3879 Initiator has Kij during the creation of the I2 packet, and the 3880 Responder has Kij once it receives the I2 packet. This is why I2 can 3881 already contain encrypted information. 3883 The KEYMAT is derived by feeding Kij into the key derivation function 3884 defined by the DH Group ID. Currently the only key derivation 3885 function defined in this document is the Hash-based Key Derivation 3886 Function (HKDF) [RFC5869] using the RHASH hash function. Other 3887 documents may define new DH Group IDs and corresponding key 3888 distribution functions. 3890 In the following we provide the details for deriving the keying 3891 material using HKDF. 3893 where 3895 info = sort(HIT-I | HIT-R) 3896 salt = #I | #J 3898 Sort(HIT-I | HIT-R) is defined as the network byte order 3899 concatenation of the two HITs, with the smaller HIT preceding the 3900 larger HIT, resulting from the numeric comparison of the two HITs 3901 interpreted as positive (unsigned) 128-bit integers in network byte 3902 order. The #I and #J values are from the puzzle and its solution 3903 that were exchanged in R1 and I2 messages when this HIP association 3904 was set up. Both hosts have to store #I and #J values for the HIP 3905 association for future use. 3907 The initial keys are drawn sequentially in the order that is 3908 determined by the numeric comparison of the two HITs, with comparison 3909 method described in the previous paragraph. HOST_g denotes the host 3910 with the greater HIT value, and HOST_l the host with the lower HIT 3911 value. 3913 The drawing order for the four initial keys is as follows: 3915 HIP-gl encryption key for HOST_g's ENCRYPTED parameter 3917 HIP-gl integrity (HMAC) key for HOST_g's outgoing HIP packets 3919 HIP-lg encryption key for HOST_l's ENCRYPTED parameter 3921 HIP-lg integrity (HMAC) key for HOST_l's outgoing HIP packets 3923 The number of bits drawn for a given algorithm is the "natural" size 3924 of the keys. For the mandatory algorithms, the following sizes 3925 apply: 3927 AES 128 or 256 bits 3929 SHA-1 160 bits 3931 SHA-256 256 bits 3933 SHA-384 384 bits 3935 NULL 0 bits 3936 If other key sizes are used, they MUST be treated as different 3937 encryption algorithms and defined separately. 3939 6.6. Initiation of a HIP Base Exchange 3941 An implementation may originate a HIP base exchange to another host 3942 based on a local policy decision, usually triggered by an application 3943 datagram, in much the same way that an IPsec IKE key exchange can 3944 dynamically create a Security Association. Alternatively, a system 3945 may initiate a HIP exchange if it has rebooted or timed out, or 3946 otherwise lost its HIP state, as described in Section 4.5.4. 3948 The implementation prepares an I1 packet and sends it to the IP 3949 address that corresponds to the peer host. The IP address of the 3950 peer host may be obtained via conventional mechanisms, such as DNS 3951 lookup. The I1 packet contents are specified in Section 5.3.1. The 3952 selection of which source or destination Host Identity to use, if a 3953 Initiator or Responder has more than one to choose from, is typically 3954 a policy decision. 3956 The following steps define the conceptual processing rules for 3957 initiating a HIP base exchange: 3959 1. The Initiator receives one or more of the Responder's HITs and 3960 one or more addresses either from a DNS lookup of the Responder's 3961 FQDN, from some other repository, or from a local database. If 3962 the Initiator does not know the Responder's HIT, it may attempt 3963 opportunistic mode by using NULL (all zeros) as the Responder's 3964 HIT (see also "HIP Opportunistic Mode" (Section 4.1.8)). If the 3965 Initiator can choose from multiple Responder HITs, it selects a 3966 HIT for which the Initiator supports the HIT Suite. 3968 2. The Initiator sends an I1 packet to one of the Responder's 3969 addresses. The selection of which address to use is a local 3970 policy decision. 3972 3. The Initiator includes the DH_GROUP_LIST in the I1 packet. The 3973 selection and order of DH Group IDs in the DH_GROUP_LIST MUST be 3974 stored by the Initiator because this list is needed for later R1 3975 processing. In most cases, the preferences regarding the DH 3976 Groups will be static, so no per-association storage is 3977 necessary. 3979 4. Upon sending an I1 packet, the sender transitions to state 3980 I1-SENT, starts a timer for which the timeout value SHOULD be 3981 larger than the worst-case anticipated RTT. The sender SHOULD 3982 also increment the trial counter associated with the I1. 3984 5. Upon timeout, the sender SHOULD retransmit the I1 packet and 3985 restart the timer, up to a maximum of I1_RETRIES_MAX tries. 3987 6.6.1. Sending Multiple I1 Packets in Parallel 3989 For the sake of minimizing the association establishment latency, an 3990 implementation MAY send the same I1 packet to more than one of the 3991 Responder's addresses. However, it MUST NOT send to more than three 3992 (3) Responder addresses in parallel. Furthermore, upon timeout, the 3993 implementation MUST refrain from sending the same I1 packet to 3994 multiple addresses. That is, if it retries to initialize the 3995 connection after a timeout, it MUST NOT send the I1 packet to more 3996 than one destination address. These limitations are placed in order 3997 to avoid congestion of the network, and potential DoS attacks that 3998 might occur, e.g., because someone's claim to have hundreds or 3999 thousands of addresses could generate a huge number of I1 packets 4000 from the Initiator. 4002 As the Responder is not guaranteed to distinguish the duplicate I1 4003 packets it receives at several of its addresses (because it avoids 4004 storing states when it answers back an R1 packet), the Initiator may 4005 receive several duplicate R1 packets. 4007 The Initiator SHOULD then select the initial preferred destination 4008 address using the source address of the selected received R1, and use 4009 the preferred address as a source address for the I2 packet. 4010 Processing rules for received R1s are discussed in Section 6.8. 4012 6.6.2. Processing Incoming ICMP Protocol Unreachable Messages 4014 A host may receive an ICMP 'Destination Protocol Unreachable' message 4015 as a response to sending a HIP I1 packet. Such a packet may be an 4016 indication that the peer does not support HIP, or it may be an 4017 attempt to launch an attack by making the Initiator believe that the 4018 Responder does not support HIP. 4020 When a system receives an ICMP 'Destination Protocol Unreachable' 4021 message while it is waiting for an R1 packet, it MUST NOT terminate 4022 waiting. It MAY continue as if it had not received the ICMP message, 4023 and send a few more I1 packets. Alternatively, it MAY take the ICMP 4024 message as a hint that the peer most probably does not support HIP, 4025 and return to state UNASSOCIATED earlier than otherwise. However, at 4026 minimum, it MUST continue waiting for an R1 packet for a reasonable 4027 time before returning to UNASSOCIATED. 4029 6.7. Processing Incoming I1 Packets 4031 An implementation SHOULD reply to an I1 with an R1 packet, unless the 4032 implementation is unable or unwilling to set up a HIP association. 4033 If the implementation is unable to set up a HIP association, the host 4034 SHOULD send an ICMP Destination Protocol Unreachable, 4035 Administratively Prohibited, message to the I1 packet source IP 4036 address. If the implementation is unwilling to set up a HIP 4037 association, the host MAY ignore the I1 packet. This latter case may 4038 occur during a DoS attack such as an I1 packet flood. 4040 The implementation SHOULD be able to handle a storm of received I1 4041 packets, discarding those with common content that arrive within a 4042 small time delta. 4044 A spoofed I1 packet can result in an R1 attack on a system. An R1 4045 packet sender MUST have a mechanism to rate-limit R1 packets sent to 4046 an address. 4048 It is RECOMMENDED that the HIP state machine does not transition upon 4049 sending an R1 packet. 4051 The following steps define the conceptual processing rules for 4052 responding to an I1 packet: 4054 1. The Responder MUST check that the Responder's HIT in the received 4055 I1 packet is either one of its own HITs or NULL. Otherwise it 4056 must drop the packet. 4058 2. If the Responder is in ESTABLISHED state, the Responder MAY 4059 respond to this with an R1 packet, prepare to drop an existing 4060 HIP security association with the peer, and stay at ESTABLISHED 4061 state. 4063 3. If the Responder is in I1-SENT state, it MUST make a comparison 4064 between the sender's HIT and its own (i.e., the receiver's) HIT. 4065 If the sender's HIT is greater than its own HIT, it should drop 4066 the I1 packet and stay at I1-SENT. If the sender's HIT is 4067 smaller than its own HIT, it SHOULD send the R1 packet and stay 4068 at I1-SENT. The HIT comparison is performed as defined in 4069 Section 6.5. 4071 4. If the implementation chooses to respond to the I1 packet with an 4072 R1 packet, it creates a new R1 or selects a precomputed R1 4073 according to the format described in Section 5.3.2. It creates 4074 or chooses an R1 that contains its most preferred DH public value 4075 that is also contained in the DH_GROUP_LIST in the I1 packet. If 4076 no suitable DH Group ID was contained in the DH_GROUP_LIST in the 4077 I1 packet, it sends an R1 with any suitable DH public key. 4079 5. If the received Responder's HIT in the I1 is NULL, the Responder 4080 selects a HIT with a the same HIT Suite as the Initiator's HIT. 4081 If this HIT Suite is not supported by the Responder, it SHOULD 4082 select a REQUIRED HIT Suite from Section 5.2.10, which is 4083 currently RSA/DSA/SHA-256. Other than that, selecting the HIT is 4084 a local policy matter. 4086 6. The responder expresses its supported HIP transport formats in 4087 the TRANSPORT_FORMAT_LIST as described in Section 5.2.11. The 4088 Responder MUST at least provide one payload transport format 4089 type. 4091 7. The Responder sends the R1 packet to the source IP address of the 4092 I1 packet. 4094 6.7.1. R1 Management 4096 All compliant implementations MUST be able to produce R1 packets; 4097 even if a device is configured by policy to only initiate 4098 associations, it must be able to process I1s in case of recovery from 4099 loss of state or key exhaustion. An R1 packet MAY be precomputed. 4100 An R1 packet MAY be reused for time Delta T, which is implementation 4101 dependent, and SHOULD be deprecated and not used once a valid 4102 response I2 packet has been received from an Initiator. During an I1 4103 message storm, an R1 packet MAY be re-used beyond this limit. R1 4104 information MUST NOT be discarded until Delta S after T. Time S is 4105 the delay needed for the last I2 packet to arrive back to the 4106 Responder. 4108 Implementations that support multiple DH groups MAY pre-compute R1 4109 packets for each supported group so that incoming I1 packets with 4110 different DH Group IDs in the DH_GROUP_LIST can be served quickly. 4112 An implementation MAY keep state about received I1 packets and match 4113 the received I2 packets against the state, as discussed in 4114 Section 4.1.1. 4116 6.7.2. Handling Malformed Messages 4118 If an implementation receives a malformed I1 packet, it SHOULD NOT 4119 respond with a NOTIFY message, as such practice could open up a 4120 potential denial-of-service threat. Instead, it MAY respond with an 4121 ICMP packet, as defined in Section 5.4. 4123 6.8. Processing Incoming R1 Packets 4125 A system receiving an R1 packet MUST first check to see if it has 4126 sent an I1 packet to the originator of the R1 packet (i.e., it is in 4127 state I1-SENT). If so, it SHOULD process the R1 as described below, 4128 send an I2 packet, and transition to state I2-SENT, setting a timer 4129 to protect the I2 packet. If the system is in state I2-SENT, it MAY 4130 respond to the R1 packet if the R1 packet has a larger R1 generation 4131 counter; if so, it should drop its state due to processing the 4132 previous R1 packet and start over from state I1-SENT. If the system 4133 is in any other state with respect to that host, the system SHOULD 4134 silently drop the R1 packet. 4136 When sending multiple I1 packets, an Initiator SHOULD wait for a 4137 small amount of time after the first R1 reception to allow possibly 4138 multiple R1 packets to arrive, and it SHOULD respond to an R1 packet 4139 among the set with the largest R1 generation counter. 4141 The following steps define the conceptual processing rules for 4142 responding to an R1 packet: 4144 1. A system receiving an R1 MUST first check to see if it has sent 4145 an I1 packet to the originator of the R1 packet (i.e., it has a 4146 HIP association that is in state I1-SENT and that is associated 4147 with the HITs in the R1). Unless the I1 packet was sent in 4148 opportunistic mode (see Section 4.1.8), the IP addresses in the 4149 received R1 packet SHOULD be ignored by the R1 processing and, 4150 when looking up the right HIP association, the received R1 4151 packet SHOULD be matched against the associations using only the 4152 HITs. If a match exists, the system should process the R1 4153 packet as described below. 4155 2. Otherwise, if the system is in any other state than I1-SENT or 4156 I2-SENT with respect to the HITs included in the R1 packet, it 4157 SHOULD silently drop the R1 packet and remain in the current 4158 state. 4160 3. If the HIP association state is I1-SENT or I2-SENT, the received 4161 Initiator's HIT MUST correspond to the HIT used in the original 4162 I1. Also, the Responder's HIT MUST correspond to the one used 4163 in the I1, unless the I1 packet contained a NULL HIT. 4165 4. The system SHOULD validate the R1 signature before applying 4166 further packet processing, according to Section 5.2.15. 4168 5. If the HIP association state is I1-SENT, and multiple valid R1 4169 packets are present, the system MUST select from among the R1 4170 packets with the largest R1 generation counter. 4172 6. The system MUST check that the Initiator HIT Suite is contained 4173 in the HIT_SUITE_LIST parameter in the R1 packet (i.e., the 4174 Initiator's HIT Suite is supported by the Responder). If the 4175 HIT Suite is supported by the Responder, the system proceeds 4176 normally. Otherwise, the system MAY stay in state I1-sent and 4177 restart the BEX by sending a new I1 packet with an Initiator HIT 4178 that is supported by the Responder and hence is contained in the 4179 HIT_SUITE_LIST in the R1 packet. The system MAY abort the BEX 4180 if no suitable source HIT is available. The system SHOULD wait 4181 for an acceptable time span to allow further R1 packets with 4182 higher R1 generation counters or different HIT and HIT Suites to 4183 arrive before restarting or aborting the BEX. 4185 7. The system MUST check that the DH Group ID in the DIFFIE_HELLMAN 4186 parameter in the R1 matches the first DH Suite ID in the 4187 Responder's DH_GROUP_LIST in the R1 packet that was also 4188 contained in the Initiator's DH_GROUP_LIST in the I1 packet. If 4189 the DH Group ID of the DIFFIE_HELLMAN parameter does not express 4190 the Responder's best choice, the Initiator can conclude that the 4191 DH_GROUP_LIST in the I1 packet was adversely modified. In such 4192 case, the Initiator MAY send a new I1 packet, however, it SHOULD 4193 NOT change its preference in the DH_GROUP_LIST in the new I1 4194 packet. Alternatively, the Initiator MAY abort the HIP base 4195 exchange. 4197 8. If the HIP association state is I2-SENT, the system MAY re-enter 4198 state I1-SENT and process the received R1 packet if it has a 4199 larger R1 generation counter than the R1 packet responded to 4200 previously. 4202 9. The R1 packet may have the A bit set -- in this case, the system 4203 MAY choose to refuse it by dropping the R1 packet and returning 4204 to state UNASSOCIATED. The system SHOULD consider dropping the 4205 R1 packet only if it used a NULL HIT in I1 packet. If the A bit 4206 is set, the Responder's HIT is anonymous and SHOULD NOT be 4207 stored permanently. 4209 10. The system SHOULD attempt to validate the HIT against the 4210 received Host Identity by using the received Host Identity to 4211 construct a HIT and verify that it matches the Sender's HIT. 4213 11. The system MUST store the received R1 generation counter for 4214 future reference. 4216 12. The system attempts to solve the puzzle in the R1 packet. The 4217 system MUST terminate the search after exceeding the remaining 4218 lifetime of the puzzle. If the puzzle is not successfully 4219 solved, the implementation MAY either resend the I1 packet 4220 within the retry bounds or abandon the HIP base exchange. 4222 13. The system computes standard Diffie-Hellman keying material 4223 according to the public value and Group ID provided in the 4224 DIFFIE_HELLMAN parameter. The Diffie-Hellman keying material 4225 Kij is used for key extraction as specified in Section 6.5. 4227 14. The system selects the HIP_CIPHER ID from the choices presented 4228 in the R1 packet and uses the selected values subsequently when 4229 generating and using encryption keys, and when sending the I2 4230 packet. If the proposed alternatives are not acceptable to the 4231 system, it may either resend an I1 within the retry bounds or 4232 abandon the HIP base exchange. 4234 15. The system chooses one suitable transport format from the 4235 TRANSPORT_FORMAT_LIST and includes the respective transport 4236 format parameter in the subsequent I2 packet. 4238 16. The system initializes the remaining variables in the associated 4239 state, including Update ID counters. 4241 17. The system prepares and sends an I2 packet, as described in 4242 Section 5.3.3. 4244 18. The system SHOULD start a timer whose timeout value SHOULD be 4245 larger than the worst-case anticipated RTT, and MUST increment a 4246 trial counter associated with the I2 packet. The sender SHOULD 4247 retransmit the I2 packet upon a timeout and restart the timer, 4248 up to a maximum of I2_RETRIES_MAX tries. 4250 19. If the system is in state I1-SENT, it SHALL transition to state 4251 I2-SENT. If the system is in any other state, it remains in the 4252 current state. 4254 6.8.1. Handling of Malformed Messages 4256 If an implementation receives a malformed R1 message, it MUST 4257 silently drop the packet. Sending a NOTIFY or ICMP would not help, 4258 as the sender of the R1 packet typically doesn't have any state. An 4259 implementation SHOULD wait for some more time for a possibly well- 4260 formed R1, after which it MAY try again by sending a new I1 packet. 4262 6.9. Processing Incoming I2 Packets 4264 Upon receipt of an I2 packet, the system MAY perform initial checks 4265 to determine whether the I2 packet corresponds to a recent R1 packet 4266 that has been sent out, if the Responder keeps such state. For 4267 example, the sender could check whether the I2 packet is from an 4268 address or HIT for which the Responder has recently received an I1. 4269 The R1 packet may have had Opaque data included that was echoed back 4270 in the I2 packet. If the I2 packet is considered to be suspect, it 4271 MAY be silently discarded by the system. 4273 Otherwise, the HIP implementation SHOULD process the I2 packet. This 4274 includes validation of the puzzle solution, generating the Diffie- 4275 Hellman key, possibly decrypting the Initiator's Host Identity, 4276 verifying the signature, creating state, and finally sending an R2 4277 packet. 4279 The following steps define the conceptual processing rules for 4280 responding to an I2 packet: 4282 1. The system MAY perform checks to verify that the I2 packet 4283 corresponds to a recently sent R1 packet. Such checks are 4284 implementation dependent. See Appendix A for a description of 4285 an example implementation. 4287 2. The system MUST check that the Responder's HIT corresponds to 4288 one of its own HITs and MUST drop the packet otherwise. 4290 3. The system MUST further check that the Initiator's HIT Suite is 4291 supported. The Responder SHOULD silently drop I2 packets with 4292 unsupported Initiator HITs. 4294 4. If the system's state machine is in the R2-SENT state, the 4295 system MAY check if the newly received I2 packet is similar to 4296 the one that triggered moving to R2-SENT. If so, it MAY 4297 retransmit a previously sent R2 packet, reset the R2-SENT timer, 4298 and the state machine stays in R2-SENT. 4300 5. If the system's state machine is in the I2-SENT state, the 4301 system MUST make a comparison between its local and sender's 4302 HITs (similarly as in Section 6.5). If the local HIT is smaller 4303 than the sender's HIT, it should drop the I2 packet, use the 4304 peer Diffie-Hellman key and nonce #I from the R1 packet received 4305 earlier, and get the local Diffie-Hellman key and nonce #J from 4306 the I2 packet sent to the peer earlier. Otherwise, the system 4307 should process the received I2 packet and drop any previously 4308 derived Diffie-Hellman keying material Kij it might have formed 4309 upon sending the I2 packet previously. The peer Diffie-Hellman 4310 key and the nonce #J are taken from the just arrived I2 packet. 4311 The local Diffie-Hellman key and the nonce I are the ones that 4312 were sent earlier in the R1 packet. 4314 6. If the system's state machine is in the I1-SENT state, and the 4315 HITs in the I2 packet match those used in the previously sent I1 4316 packet, the system uses this received I2 packet as the basis for 4317 the HIP association it was trying to form, and stops 4318 retransmitting I1 packets (provided that the I2 packet passes 4319 the additional checks below). 4321 7. If the system's state machine is in any other state than 4322 R2-SENT, the system SHOULD check that the echoed R1 generation 4323 counter in the I2 packet is within the acceptable range if the 4324 counter is included. Implementations MUST accept puzzles from 4325 the current generation and MAY accept puzzles from earlier 4326 generations. If the generation counter in the newly received I2 4327 packet is outside the accepted range, the I2 packet is stale 4328 (and perhaps replayed) and SHOULD be dropped. 4330 8. The system MUST validate the solution to the puzzle by computing 4331 the hash described in Section 5.3.3 using the same RHASH 4332 algorithm. 4334 9. The I2 packet MUST have a single value in the HIP_CIPHER 4335 parameter, which MUST match one of the values offered to the 4336 Initiator in the R1 packet. 4338 10. The system must derive Diffie-Hellman keying material Kij based 4339 on the public value and Group ID in the DIFFIE_HELLMAN 4340 parameter. This key is used to derive the HIP association keys, 4341 as described in Section 6.5. If the Diffie-Hellman Group ID is 4342 unsupported, the I2 packet is silently dropped. 4344 11. The encrypted HOST_ID is decrypted by the Initiator's encryption 4345 key defined in Section 6.5. If the decrypted data is not a 4346 HOST_ID parameter, the I2 packet is silently dropped. 4348 12. The implementation SHOULD also verify that the Initiator's HIT 4349 in the I2 packet corresponds to the Host Identity sent in the I2 4350 packet. (Note: some middleboxes may not able to make this 4351 verification.) 4353 13. The system MUST process the TRANSPORT_FORMAT_LIST parameter. 4354 Other documents specifying transport formats (e.g. 4355 [I-D.ietf-hip-rfc5202-bis]) contain specifications for handling 4356 any specific transport selected. 4358 14. The system MUST verify the HIP_MAC according to the procedures 4359 in Section 5.2.12. 4361 15. The system MUST verify the HIP_SIGNATURE according to 4362 Section 5.2.14 and Section 5.3.3. 4364 16. If the checks above are valid, then the system proceeds with 4365 further I2 processing; otherwise, it discards the I2 and its 4366 state machine remains in the same state. 4368 17. The I2 packet may have the A bit set -- in this case, the system 4369 MAY choose to refuse it by dropping the I2 and the state machine 4370 returns to state UNASSOCIATED. If the A bit is set, the 4371 Initiator's HIT is anonymous and should not be stored 4372 permanently. 4374 18. The system initializes the remaining variables in the associated 4375 state, including Update ID counters. 4377 19. Upon successful processing of an I2 message when the system's 4378 state machine is in state UNASSOCIATED, I1-SENT, I2-SENT, or 4379 R2-SENT, an R2 packet is sent and the system's state machine 4380 transitions to state R2-SENT. 4382 20. Upon successful processing of an I2 packet when the system's 4383 state machine is in state ESTABLISHED, the old HIP association 4384 is dropped and a new one is installed, an R2 packet is sent, and 4385 the system's state machine transitions to R2-SENT. 4387 21. Upon the system's state machine transitioning to R2-SENT, the 4388 system starts a timer. The state machine transitions to 4389 ESTABLISHED if some data has been received on the incoming HIP 4390 association, or an UPDATE packet has been received (or some 4391 other packet that indicates that the peer system's state machine 4392 has moved to ESTABLISHED). If the timer expires (allowing for 4393 maximal amount of retransmissions of I2 packets), the state 4394 machine transitions to ESTABLISHED. 4396 6.9.1. Handling of Malformed Messages 4398 If an implementation receives a malformed I2 message, the behavior 4399 SHOULD depend on how many checks the message has already passed. If 4400 the puzzle solution in the message has already been checked, the 4401 implementation SHOULD report the error by responding with a NOTIFY 4402 packet. Otherwise, the implementation MAY respond with an ICMP 4403 message as defined in Section 5.4. 4405 6.10. Processing of Incoming R2 Packets 4407 An R2 packet received in states UNASSOCIATED, I1-SENT, or ESTABLISHED 4408 results in the R2 packet being dropped and the state machine staying 4409 in the same state. If an R2 packet is received in state I2-SENT, it 4410 MUST be processed. 4412 The following steps define the conceptual processing rules for an 4413 incoming R2 packet: 4415 1. If the system is in any other state than I2-SENT, the R2 packet 4416 is silently dropped. 4418 2. The system MUST verify that the HITs in use correspond to the 4419 HITs that were received in the R1 packet that caused the 4420 transition to the I1-SENT state. 4422 3. The system MUST verify the HIP_MAC_2 according to the procedures 4423 in Section 5.2.13. 4425 4. The system MUST verify the HIP signature according to the 4426 procedures in Section 5.2.14. 4428 5. If any of the checks above fail, there is a high probability of 4429 an ongoing man-in-the-middle or other security attack. The 4430 system SHOULD act accordingly, based on its local policy. 4432 6. Upon successful processing of the R2 packet, the state machine 4433 transitions to state ESTABLISHED. 4435 6.11. Sending UPDATE Packets 4437 A host sends an UPDATE packet when it intends to update some 4438 information related to a HIP association. There are a number of 4439 possible scenarios when this can occur, e.g., mobility management and 4440 rekeying of an existing ESP Security Association. The following 4441 paragraphs define the conceptual rules for sending an UPDATE packet 4442 to the peer. Additional steps can be defined in other documents 4443 where the UPDATE packet is used. 4445 The sequence of UPDATE messages is indicated by their SEQ parameter. 4446 Before sending an UPDATE message, the system first determines whether 4447 there are any outstanding UPDATE messages that may conflict with the 4448 new UPDATE message under consideration. When multiple UPDATEs are 4449 outstanding (not yet acknowledged), the sender must assume that such 4450 UPDATEs may be processed in an arbitrary order by the receiver. 4451 Therefore, any new UPDATEs that depend on a previous outstanding 4452 UPDATE being successfully received and acknowledged MUST be postponed 4453 until reception of the necessary ACK(s) occurs. One way to prevent 4454 any conflicts is to only allow one outstanding UPDATE at a time. 4455 However, allowing multiple UPDATEs may improve the performance of 4456 mobility and multihoming protocols. 4458 The following steps define the conceptual processing rules for 4459 sending UPDATE packets. 4461 1. The first UPDATE packet is sent with Update ID of zero. 4462 Otherwise, the system increments its own Update ID value by one 4463 before continuing the steps below. 4465 2. The system creates an UPDATE packet that contains a SEQ parameter 4466 with the current value of Update ID. The UPDATE packet MAY also 4467 include zero or more ACKs of the peer's Update ID(s) from 4468 previously received UPDATE SEQ parameter(s) 4470 3. The system sends the created UPDATE packet and starts an UPDATE 4471 timer. The default value for the timer is 2 * RTT estimate. If 4472 multiple UPDATEs are outstanding, multiple timers are in effect. 4474 4. If the UPDATE timer expires, the UPDATE is resent. The UPDATE 4475 can be resent UPDATE_RETRY_MAX times. The UPDATE timer SHOULD be 4476 exponentially backed off for subsequent retransmissions. If no 4477 acknowledgment is received from the peer after UPDATE_RETRY_MAX 4478 times, the HIP association is considered to be broken and the 4479 state machine SHOULD move from state ESTABLISHED to state CLOSING 4480 as depicted in Section 4.4.4. The UPDATE timer is cancelled upon 4481 receiving an ACK from the peer that acknowledges receipt of the 4482 UPDATE. 4484 6.12. Receiving UPDATE Packets 4486 When a system receives an UPDATE packet, its processing depends on 4487 the state of the HIP association and the presence and values of the 4488 SEQ and ACK parameters. Typically, an UPDATE message also carries 4489 optional parameters whose handling is defined in separate documents. 4491 For each association, a host stores the peer's next expected in- 4492 sequence Update ID ("peer Update ID"). Initially, this value is 4493 zero. Update ID comparisons of "less than" and "greater than" are 4494 performed with respect to a circular sequence number space. Hence, a 4495 wrap around after 2^32 updates has to be expected and MUST be handled 4496 accordingly. 4498 The sender MAY send multiple outstanding UPDATE messages. These 4499 messages are processed in the order in which they are received at the 4500 receiver (i.e., no re-sequencing is performed). When processing 4501 UPDATEs out-of-order, the receiver MUST keep track of which UPDATEs 4502 were previously processed, so that duplicates or retransmissions are 4503 ACKed and not reprocessed. A receiver MAY choose to define a receive 4504 window of Update IDs that it is willing to process at any given time, 4505 and discard received UPDATEs falling outside of that window. 4507 The following steps define the conceptual processing rules for 4508 receiving UPDATE packets. 4510 1. If there is no corresponding HIP association, the implementation 4511 MAY reply with an ICMP Parameter Problem, as specified in 4512 Section 5.4.4. 4514 2. If the association is in the ESTABLISHED state and the SEQ (but 4515 not ACK) parameter is present, the UPDATE is processed and 4516 replied to as described in Section 6.12.1. 4518 3. If the association is in the ESTABLISHED state and the ACK (but 4519 not SEQ) parameter is present, the UPDATE is processed as 4520 described in Section 6.12.2. 4522 4. If the association is in the ESTABLISHED state and there is both 4523 an ACK and SEQ in the UPDATE, the ACK is first processed as 4524 described in Section 6.12.2, and then the rest of the UPDATE is 4525 processed as described in Section 6.12.1. 4527 6.12.1. Handling a SEQ Parameter in a Received UPDATE Message 4529 The following steps define the conceptual processing rules for 4530 handling a SEQ parameter in a received UPDATE packet. 4532 1. If the Update ID in the received SEQ is not the next in the 4533 sequence of Update IDs and is greater than the receiver's window 4534 for new UPDATEs, the packet MUST be dropped. 4536 2. If the Update ID in the received SEQ corresponds to an UPDATE 4537 that has recently been processed, the packet is treated as a 4538 retransmission. The HIP_MAC verification (next step) MUST NOT be 4539 skipped. (A byte-by-byte comparison of the received and a stored 4540 packet would be acceptable, though.) It is recommended that a 4541 host caches UPDATE packets sent with ACKs to avoid the cost of 4542 generating a new ACK packet to respond to a replayed UPDATE. The 4543 system MUST acknowledge, again, such (apparent) UPDATE message 4544 retransmissions but SHOULD also consider rate-limiting such 4545 retransmission responses to guard against replay attacks. 4547 3. The system MUST verify the HIP_MAC in the UPDATE packet. If the 4548 verification fails, the packet MUST be dropped. 4550 4. The system MAY verify the SIGNATURE in the UPDATE packet. If the 4551 verification fails, the packet SHOULD be dropped and an error 4552 message logged. 4554 5. If a new SEQ parameter is being processed, the parameters in the 4555 UPDATE are then processed. The system MUST record the Update ID 4556 in the received SEQ parameter, for replay protection. 4558 6. An UPDATE acknowledgment packet with ACK parameter is prepared 4559 and sent to the peer. This ACK parameter MAY be included in a 4560 separate UPDATE or piggybacked in an UPDATE with SEQ parameter, 4561 as described in Section 5.3.5. The ACK parameter MAY acknowledge 4562 more than one of the peer's Update IDs. 4564 6.12.2. Handling an ACK Parameter in a Received UPDATE Packet 4566 The following steps define the conceptual processing rules for 4567 handling an ACK parameter in a received UPDATE packet. 4569 1. The sequence number reported in the ACK must match with an UPDATE 4570 packet sent earlier that has not already been acknowledged. If 4571 no match is found or if the ACK does not acknowledge a new 4572 UPDATE, the packet MUST either be dropped if no SEQ parameter is 4573 present, or the processing steps in Section 6.12.1 are followed. 4575 2. The system MUST verify the HIP_MAC in the UPDATE packet. If the 4576 verification fails, the packet MUST be dropped. 4578 3. The system MAY verify the SIGNATURE in the UPDATE packet. If the 4579 verification fails, the packet SHOULD be dropped and an error 4580 message logged. 4582 4. The corresponding UPDATE timer is stopped (see Section 6.11) so 4583 that the now acknowledged UPDATE is no longer retransmitted. If 4584 multiple UPDATEs are acknowledged, multiple timers are stopped. 4586 6.13. Processing of NOTIFY Packets 4588 Processing of NOTIFY packets is OPTIONAL. If processed, any errors 4589 in a received NOTIFICATION parameter SHOULD be logged. Received 4590 errors MUST be considered only as informational, and the receiver 4591 SHOULD NOT change its HIP state (see Section 4.4.2) purely based on 4592 the received NOTIFY message. 4594 6.14. Processing CLOSE Packets 4596 When the host receives a CLOSE message, it responds with a CLOSE_ACK 4597 message and moves to CLOSED state. (The authenticity of the CLOSE 4598 message is verified using both HIP_MAC and SIGNATURE). This 4599 processing applies whether or not the HIP association state is 4600 CLOSING in order to handle simultaneous CLOSE messages from both ends 4601 that cross in flight. 4603 The HIP association is not discarded before the host moves to the 4604 UNASSOCIATED state. 4606 Once the closing process has started, any new need to send data 4607 packets triggers creating and establishing of a new HIP association, 4608 starting with sending of an I1 packet. 4610 If there is no corresponding HIP association, the CLOSE packet is 4611 dropped. 4613 6.15. Processing CLOSE_ACK Packets 4615 When a host receives a CLOSE_ACK message, it verifies that it is in 4616 CLOSING or CLOSED state and that the CLOSE_ACK was in response to the 4617 CLOSE. A host can map CLOSE_ACK messages to CLOSE messages by 4618 comparing the value of ECHO_REQUEST_SIGNED (in the CLOSE packet) to 4619 the value of ECHO_RESPONSE_SIGNED (in the CLOSE_ACK packet). 4621 The CLOSE_ACK contains the HIP_MAC and the SIGNATURE parameters for 4622 verification. The state is discarded when the state changes to 4623 UNASSOCIATED and, after that, the host MAY respond with an ICMP 4624 Parameter Problem to an incoming CLOSE message (see Section 5.4.4). 4626 6.16. Handling State Loss 4628 In the case of a system crash and unanticipated state loss, the 4629 system SHOULD delete the corresponding HIP state, including the 4630 keying material. That is, the state SHOULD NOT be stored in long- 4631 term storage. If the implementation does drop the state (as 4632 RECOMMENDED), it MUST also drop the peer's R1 generation counter 4633 value, unless a local policy explicitly defines that the value of 4634 that particular host is stored. An implementation MUST NOT store a 4635 peer's R1 generation counters by default, but storing R1 generation 4636 counter values, if done, MUST be configured by explicit HITs. 4638 7. HIP Policies 4640 There are a number of variables that will influence the HIP base 4641 exchanges that each host must support. All HIP implementations MUST 4642 support more than one simultaneous HI, at least one of which SHOULD 4643 be reserved for anonymous usage. Although anonymous HIs will be 4644 rarely used as Responders' HIs, they will be common for Initiators. 4645 Support for more than two HIs is RECOMMENDED. 4647 Initiators MAY use a different HI for different Responders to provide 4648 basic privacy. Whether such private HIs are used repeatedly with the 4649 same Responder and how long these HIs are used is decided by local 4650 policy and depends on the privacy requirements of the Initiator. 4652 The value of #K used in the HIP R1 must be chosen with care. Too 4653 high numbers of #K will exclude clients with weak CPUs because these 4654 devices cannot solve the puzzle within reasonable time. #K should 4655 only be raised if a Responder is under high load, i.e., it cannot 4656 process all incoming HIP handshakes any more. If a responder is not 4657 under high load, K SHOULD be 0. 4659 Responders that only respond to selected Initiators require an ACL, 4660 representing for which hosts they accept HIP base exchanges, and the 4661 preferred transport format and local lifetimes. Wildcarding SHOULD 4662 be supported for such ACLs, and also for Responders that offer public 4663 or anonymous services. 4665 8. Security Considerations 4667 HIP is designed to provide secure authentication of hosts. HIP also 4668 attempts to limit the exposure of the host to various denial-of- 4669 service and man-in-the-middle (MitM) attacks. In doing so, HIP 4670 itself is subject to its own DoS and MitM attacks that potentially 4671 could be more damaging to a host's ability to conduct business as 4672 usual. 4674 Denial-of-service attacks often take advantage of asymmetries in the 4675 cost of an starting an association. One example of such asymmetry is 4676 the need of a Responder to store local state while a malicious 4677 Initiator can stay stateless. HIP makes no attempt to increase the 4678 cost of the start of state at the Initiator, but makes an effort to 4679 reduce the cost for the Responder. This is accomplished by having 4680 the Responder start the 3-way exchange instead of the Initiator, 4681 making the HIP protocol 4 packets long. In doing this, the first 4682 packet from the Responder, R1, becomes a 'stock' packet that the 4683 Responder MAY use many times, until some Initiator has provided a 4684 valid response to such an R1 packet. During an I1 packet storm, the 4685 host may reuse the same DH value also even if some Initiator has 4686 provided a valid response using that particular DH value. However, 4687 such behavior is discouraged and should be avoided. Using the same 4688 Diffie-Hellman values and random puzzle #I value has some risks. 4689 This risk needs to be balanced against a potential storm of HIP I1 4690 packets. 4692 This shifting of the start of state cost to the Initiator in creating 4693 the I2 HIP packet presents another DoS attack. The attacker can 4694 spoof the I1 packet and the Responder sends out the R1 HIP packet. 4695 This could conceivably tie up the 'Initiator' with evaluating the R1 4696 HIP packet, and creating the I2 packet. The defense against this 4697 attack is to simply ignore any R1 packet where a corresponding I1 4698 packet was not sent (as defined in Section 6.8 step 1). 4700 The R1 packet is considerably larger than the I1 packet. This 4701 asymmetry can be exploited in an reflection attack. A malicious 4702 attacker could spoof the IP address of a victim and send a flood of 4703 I1 messages to a powerful Responder. For each small I1 packet, the 4704 Responder would send a larger R1 packet to the victim. The 4705 difference in packet sizes can further amplify a flooding attack 4706 against the victim. To avoid such reflection attacks, the Responder 4707 SHOULD rate limit the sending of R1 packets in general or SHOULD rate 4708 limit the sending of R1 packets to a specific IP address. 4710 Floods of forged I2 packets form a second kind of DoS attack. Once 4711 the attacking Initiator has solved the puzzle, it can send packets 4712 with spoofed IP source addresses with either an invalid HIP signature 4713 or invalid encrypted HIP payload (in the ENCRYPTED parameter). This 4714 would take resources in the Responder's part to reach the point to 4715 discover that the I2 packet cannot be completely processed. The 4716 defense against this attack is after N bad I2 packets with the same 4717 puzzle solution, the Responder would discard any I2 packets that 4718 contain the given solution. This will shut down the attack. The 4719 attacker would have to request another R1 packet and use that to 4720 launch a new attack. The Responder could increase the value of #K 4721 while under attack. Keeping a list of solutions from malformed 4722 packets requires that the Responder keeps state for these malformed 4723 I2 packets. This state has to be kept until the R1 counter is 4724 increased. As malformed packets are generally filtered by their 4725 checksum before signature verification, only solutions in packets 4726 that are forged to pass the checksum and puzzle are put to the 4727 blacklist. In addition, a valid puzzle is required before a new list 4728 entry is created. Hence, attackers that intend to flood the 4729 blacklist must solve puzzles first. 4731 A third form of DoS attack is emulating the restart of state after a 4732 reboot of one of the peers. A restarting host would send an I1 4733 packet to the peers, which would respond with an R1 packet even if it 4734 were in the ESTABLISHED state. If the I1 packet were spoofed, the 4735 resulting R1 packet would be received unexpectedly by the spoofed 4736 host and would be dropped, as in the first case above. 4738 A fourth form of DoS attack is emulating closing of the HIP 4739 association. HIP relies on timers and a CLOSE/CLOSE_ACK handshake to 4740 explicitly signal the end of a HIP association. Because both CLOSE 4741 and CLOSE_ACK messages contain a HIP_MAC, an outsider cannot close a 4742 connection. The presence of an additional SIGNATURE allows 4743 middleboxes to inspect these messages and discard the associated 4744 state (for e.g., firewalling, SPI-based NATing, etc.). However, the 4745 optional behavior of replying to CLOSE with an ICMP Parameter Problem 4746 packet (as described in Section 5.4.4) might allow an attacker 4747 spoofing the source IP address to send CLOSE messages to launch 4748 reflection attacks. 4750 A fifth form of DoS attack is replaying R1s to cause the Initiator to 4751 solve stale puzzles and become out of synchronization with the 4752 Responder. The R1 generation counter is a monotonically increasing 4753 counter designed to protect against this attack, as described in 4754 Section 4.1.4. 4756 Man-in-the-middle attacks are difficult to defend against, without 4757 third-party authentication. A skillful MitM could easily handle all 4758 parts of HIP, but HIP indirectly provides the following protection 4759 from a MitM attack. If the Responder's HI is retrieved from a signed 4760 DNS zone, a certificate, or through some other secure means, the 4761 Initiator can use this to validate the R1 HIP packet. 4763 Likewise, if the Initiator's HI is in a secure DNS zone, a trusted 4764 certificate, or otherwise securely available, the Responder can 4765 retrieve the HI (after having got the I2 HIP packet) and verify that 4766 the HI indeed can be trusted. 4768 The HIP Opportunistic Mode concept has been introduced in this 4769 document, but this document does not specify what the semantics of 4770 such a connection setup are for applications. There are certain 4771 concerns with opportunistic mode, as discussed in Section 4.1.8. 4773 NOTIFY messages are used only for informational purposes and they are 4774 unacknowledged. A HIP implementation cannot rely solely on the 4775 information received in a NOTIFY message because the packet may have 4776 been replayed. An implementation SHOULD NOT change any state 4777 information purely based on a received NOTIFY message. 4779 Since not all hosts will ever support HIP, ICMP 'Destination Protocol 4780 Unreachable' messages are to be expected and may be used for a DoS 4781 attack. Against an Initiator, the attack would look like the 4782 Responder does not support HIP, but shortly after receiving the ICMP 4783 message, the Initiator would receive a valid R1 HIP packet. Thus, to 4784 protect from this attack, an Initiator SHOULD NOT react to an ICMP 4785 message until a reasonable delta time to get the real Responder's R1 4786 HIP packet. A similar attack against the Responder is more involved. 4787 Normally, if an I1 message received by a Responder was a bogus one 4788 sent by an attacker, the Responder may receive an ICMP message from 4789 the IP address the R1 message was sent to. However, a sophisticated 4790 attacker can try to take advantage of such a behavior and try to 4791 break up the HIP base exchange by sending such an ICMP message to the 4792 Responder before the Initiator has a chance to send a valid I2 4793 message. Hence, the Responder SHOULD NOT act on such an ICMP 4794 message. Especially, it SHOULD NOT remove any minimal state created 4795 when it sent the R1 HIP packet (if it did create one), but wait for 4796 either a valid I2 HIP packet or the natural timeout (that is, if R1 4797 packets are tracked at all). Likewise, the Initiator SHOULD ignore 4798 any ICMP message while waiting for an R2 HIP packet, and SHOULD 4799 delete any pending state only after a natural timeout. 4801 9. IANA Considerations 4803 IANA has reserved protocol number 139 for the Host Identity Protocol 4804 and included it in the "IPv6 Extension Header Types" registry 4805 [RFC7045] and the "Assigned Internet Protocol Numbers" registry. The 4806 reference in both of these registries should be updated from 4807 [RFC5201] to this specification. 4809 The reference to the 128-bit value under the CGA Message Type 4810 namespace [RFC3972] of "0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA" 4811 should be changed from [RFC5201] to this specification. 4813 The following changes to the "Host Identity Protocol (HIP) 4814 Parameters" registries are requested. In many cases, the changes 4815 required involve updating the reference from [RFC5201] to this 4816 specification, but there are some differences as outlined below. 4817 Allocation terminology is defined in [RFC5226]; any existing 4818 references to "IETF Consensus" can be replaced with "IETF Review" as 4819 per [RFC5226]. 4821 HIP Version 4823 This document adds the value "2" to the existing registry. The 4824 value of "1" should be left with a reference to [RFC5201]. 4826 Packet Type 4828 The 7-bit Packet Type field in a HIP protocol packet describes the 4829 type of a HIP protocol message. It is defined in Section 5.1. 4831 All existing values referring to [RFC5201] should be updated to 4832 refer to this specification. Other values should be left 4833 unchanged. 4835 HIT Suite ID 4837 This specification creates a new registry for "HIT Suite ID". 4838 This is different than the existing registry for "Suite ID" which 4839 can be left unmodified for version 1 of the protocol ([RFC5201]). 4840 The registry should be closed to new registrations. 4842 The four-bit HIT Suite ID uses the OGA field in the ORCHID to 4843 express the type of the HIT. This document defines three HIT 4844 Suites (see Section 5.2.10). 4846 The HIT Suite ID is also carried in the four higher-order bits of 4847 the ID field in the HIT_SUITE_LIST parameter. The four lower- 4848 order bits are reserved for future extensions of the HIT Suite ID 4849 space beyond 16 values. 4851 For the time being, the HIT Suite uses only four bits because 4852 these bits have to be carried in the HIT. Using more bits for the 4853 HIT Suite ID reduces the cryptographic strength of the HIT. HIT 4854 Suite IDs must be allocated carefully to avoid namespace 4855 exhaustion. Moreover, deprecated IDs should be reused after an 4856 appropriate time span. If 15 Suite IDs (the zero value is 4857 initially reserved) prove to be insufficient and more HIT Suite 4858 IDs are needed concurrently, more bits can be used for the HIT 4859 Suite ID by using one HIT Suite ID (0) to indicate that more bits 4860 should be used. The HIT_SUITE_LIST parameter already supports 4861 8-bit HIT Suite IDs, should longer IDs be needed. However, RFC 4862 7343 [RFC7343] does not presently support such an extension, and 4863 the rollover approach described in Appendix E is suggested to be 4864 tried first. Possible extensions of the HIT Suite ID space to 4865 accommodate eight bits and new HIT Suite IDs are defined through 4866 IETF Review. 4868 Requests to register reused values should include a note that the 4869 value is being reused after a deprecation period, to ensure 4870 appropriate IETF review and approval. 4872 Parameter Type 4874 The 16-bit Type field in a HIP parameter describes the type of the 4875 parameter. It is defined in Section 5.2.1. The current values 4876 are defined in Sections 5.2.3 through 5.2.23. The existing 4877 registry for "Parameter Type" should be updated as follows. 4879 A new value (129) for R1_COUNTER should be introduced, with a 4880 reference to this specification, and the existing value (128) for 4881 R1_COUNTER left in place with a reference to [RFC5201]. This 4882 documents the change in value that has occurred in version 2 of 4883 this protocol. For clarity, we recommend that the name for the 4884 value 128 be changed from "R1_COUNTER" to "R1_Counter (v1 only)". 4886 A new value (579) for a new Parameter Type HIP_CIPHER should be 4887 added, with reference to this specification. This Parameter Type 4888 functionally replaces the HIP_TRANSFORM Parameter Type (value 577) 4889 which can be left in the table with existing reference to 4890 [RFC5201]. For clarity, we recommend that the name for the value 4891 577 be changed from "HIP_TRANSFORM" to "HIP_TRANSFORM (v1 only)". 4893 A new value (715) for a new Parameter Type HIT_SUITE_LIST should 4894 be added, with reference to this specification. 4896 A new value (2049) for a new Parameter Type TRANSPORT_FORMAT_LIST 4897 should be added, with reference to this specification. 4899 The name of the HMAC Parameter Type (value 61505) should be 4900 changed to HIP_MAC. The name of the HMAC_2 Parameter Type (value 4901 61569) should be changed to HIP_MAC_2. The reference should be 4902 changed to this specification. 4904 All other Parameter Types that reference [RFC5201] should be 4905 updated to refer to this specification, and Parameter Types that 4906 reference other RFCs should be unchanged. 4908 Regarding the range assignments, the Type codes 32768 through 4909 49151 (not 49141) should be Reserved for Private Use. Where the 4910 existing ranges state "First Come First Served with Specification 4911 Required", this should be changed to "Specification Required". 4913 The Type codes 32768 through 49151 are reserved for 4914 experimentation. Implementors SHOULD select types in a random 4915 fashion from this range, thereby reducing the probability of 4916 collisions. A method employing genuine randomness (such as 4917 flipping a coin) SHOULD be used. 4919 Group ID 4921 The eight-bit Group ID values appear in the DIFFIE_HELLMAN 4922 parameter and the DH_GROUP_LIST parameter and are defined in 4923 Section 5.2.7. This registry should be updated based on the new 4924 values specified in Section 5.2.7; values noted as being 4925 DEPRECATED can be left in the table with reference to [RFC5201]. 4926 New values are assigned through IETF Review. 4928 HIP Cipher ID 4930 The 16-bit Cipher ID values in a HIP_CIPHER parameter are defined 4931 in Section 5.2.8. This is a new registry. New values either from 4932 the reserved or unassigned space are assigned through IETF Review. 4934 DI-Type 4936 The four-bit DI-Type values in a HOST_ID parameter are defined in 4937 Section 5.2.9. New values are assigned through IETF Review. All 4938 existing values referring to [RFC5201] should be updated to refer 4939 to this specification. 4941 HI Algorithm 4943 The 16-bit Algorithm values in a HOST_ID parameter are defined in 4944 Section 5.2.9. This is a new registry. New values either from 4945 the reserved or unassigned space are assigned through IETF Review. 4947 ECC Curve Label 4949 When the HI Algorithm values in a HOST_ID parameter is defined to 4950 the values of either "ECDSA" or "ECDSA_LOW", a new registry is 4951 needed to maintain the values for the ECC Curve Label as defined 4952 in Section 5.2.9. This might be handled by specifying two 4953 algorithm-specific sub-registries named "ECDSA Curve Label" and 4954 "ECDSA_LOW Curve Label". New values are to be assigned through 4955 IETF Review. 4957 Notify Message Type 4959 The 16-bit Notify Message Type values in a NOTIFICATION parameter 4960 are defined in Section 5.2.19. 4962 Notify Message Type values 1-10 are used for informing about 4963 errors in packet structures, values 11-20 for informing about 4964 problems in parameters containing cryptographic related material, 4965 values 21-30 for informing about problems in authentication or 4966 packet integrity verification. Parameter numbers above 30 can be 4967 used for informing about other types of errors or events. 4969 The existing registration procedures should be updated as follows. 4970 The range from 1-50 can remain as "IETF Review". The range from 4971 51-8191 should be marked as "Specification Required". Values 4972 8192-16383 can remain as "Reserved for Private Use". Values 4973 16385-40959 should be marked as "Specification Required". Values 4974 40960-65535 can remain as "Reserved for Private Use". 4976 The following updates to the values should be made to the existing 4977 registry. All existing values referring to [RFC5201] should be 4978 updated to refer to this specification. 4980 INVALID_HIP_TRANSFORM_CHOSEN should be renamed to 4981 INVALID_HIP_CIPHER_CHOSEN with the same value (17). 4983 A new value of 20 for the type UNSUPPORTED_HIT_SUITE should be 4984 added. 4986 HMAC_FAILED should be renamed to HIP_MAC_FAILED with the same 4987 value (28). 4989 SERVER_BUSY_PLEASE_RETRY should be renamed to 4990 RESPONDER_BUSY_PLEASE_RETRY with the same value (44). 4992 10. Acknowledgments 4994 The drive to create HIP came to being after attending the MALLOC 4995 meeting at the 43rd IETF meeting. Baiju Patel and Hilarie Orman 4996 really gave the original author, Bob Moskowitz, the assist to get HIP 4997 beyond 5 paragraphs of ideas. It has matured considerably since the 4998 early versions thanks to extensive input from IETFers. Most 4999 importantly, its design goals are articulated and are different from 5000 other efforts in this direction. Particular mention goes to the 5001 members of the NameSpace Research Group of the IRTF. Noel Chiappa 5002 provided valuable input at early stages of discussions about 5003 identifier handling and Keith Moore the impetus to provide 5004 resolvability. Steve Deering provided encouragement to keep working, 5005 as a solid proposal can act as a proof of ideas for a research group. 5007 Many others contributed; extensive security tips were provided by 5008 Steve Bellovin. Rob Austein kept the DNS parts on track. Paul 5009 Kocher taught Bob Moskowitz how to make the puzzle exchange expensive 5010 for the Initiator to respond, but easy for the Responder to validate. 5011 Bill Sommerfeld supplied the Birthday concept, which later evolved 5012 into the R1 generation counter, to simplify reboot management. Erik 5013 Nordmark supplied the CLOSE-mechanism for closing connections. 5014 Rodney Thayer and Hugh Daniels provided extensive feedback. In the 5015 early times of this document, John Gilmore kept Bob Moskowitz 5016 challenged to provide something of value. 5018 During the later stages of this document, when the editing baton was 5019 transferred to Pekka Nikander, the input from the early implementors 5020 was invaluable. Without having actual implementations, this document 5021 would not be on the level it is now. 5023 In the usual IETF fashion, a large number of people have contributed 5024 to the actual text or ideas. The list of these people include Jeff 5025 Ahrenholz, Francis Dupont, Derek Fawcus, George Gross, Andrew 5026 McGregor, Julien Laganier, Miika Komu, Mika Kousa, Jan Melen, Henrik 5027 Petander, Michael Richardson, Rene Hummen, Tim Shepard, Jorma Wall, 5028 Xin Gu, and Jukka Ylitalo. Our apologies to anyone whose name is 5029 missing. 5031 Once the HIP Working Group was founded in early 2004, a number of 5032 changes were introduced through the working group process. Most 5033 notably, the original document was split in two, one containing the 5034 base exchange and the other one defining how to use ESP. Some 5035 modifications to the protocol proposed by Aura, et al., [AUR03] were 5036 added at a later stage. 5038 11. Changes from RFC 5201 5040 This section summarizes the changes made from [RFC5201]. 5042 11.1. Changes from draft-ietf-hip-rfc5201-bis-19 5044 o Clarified encoding of HIT Suite ID in HIT_SUITE_LIST parameter. 5045 Moved Table 11 from Appendix E forward to the HIT_SUITE_LIST 5046 parameter section. 5048 o Clarified the possible strategies for reusing HIT Suite ID values 5049 or expanding the field, noting that RFC 7343 does not support HIT 5050 Suite ID field expansion and that any such future changes are to 5051 be defined through IETF Review. 5053 11.2. Changes from draft-ietf-hip-rfc5201-bis-18 5055 o Correct documentation prefix in Appendix C from 2001:D88/32 to 5056 2001:DB8/32, and update IPv6 checksum 5058 o Correct documentation prefix reference from RFC 5747 to 5737 5060 o Clarified HIT generation in Appendix E 5062 11.3. Changes from draft-ietf-hip-rfc5201-bis-17 5064 o Update ORCHID reference to newly published RFC 7343 5066 o Update example checksum section to RFC 7343 HIT prefix of 5067 2001:20::/28, and fix incorrect Header Length fields 5069 o Update IANA considerations comment on legacy HIP_TRANSFORM 5070 parameter naming 5072 o Add 2048-bit MODP DHE group as Group ID value 11. 5074 11.4. Changes from draft-ietf-hip-rfc5201-bis-16 5076 o Clarify that receipt of user data in state CLOSING (Table 7) 5077 results in transition to I1-SENT 5079 o Add academic reference for the first mention of the RSA algorithm 5081 o As part of comment resolution on use of NULL encryption, note that 5082 use of a NULL HIP CIPHER is only to be used when debugging and 5083 testing the HIP protocol. This only pertains to the ENCRYPTED 5084 parameter, which is optional; in practice, if encryption is not 5085 desired, better to just not encrypt the Host ID. 5087 11.5. Changes from draft-ietf-hip-rfc5201-bis-15 5089 o Additional edits to IANA Considerations section based on initial 5090 IANA review. 5092 11.6. Changes from draft-ietf-hip-rfc5201-bis-14 5094 o Update source XML to comply with xmlrfcv2 version of the xml2rfc 5095 tool, resulting in a few table formatting changes. 5097 o Editorial and minor technical revisions based on IESG review. 5099 o Significant revisions to IANA Considerations section based on 5100 initial IANA review. 5102 11.7. Changes from draft-ietf-hip-rfc5201-bis-13 5104 o Update a few references and fix some editorial nits. 5106 11.8. Changes from draft-ietf-hip-rfc5201-bis-12 5108 o Fix I-D nits. 5110 11.9. Changes from draft-ietf-hip-rfc5201-bis-11 5112 o Specify that TRANSPORT_FORMAT_LIST is mandatory in R1 and I2; fix 5113 incorrect section reference. 5115 11.10. Changes from draft-ietf-hip-rfc5201-bis-10 5117 o Issue 39: Text clarifying R1 counter rollover and Initiator 5118 response to unexpected reset of the counter. 5120 11.11. Changes from draft-ietf-hip-rfc5201-bis-09 5122 o Editorial changes based on working group last call. 5124 11.12. Changes from draft-ietf-hip-rfc5201-bis-08 5126 o Issue 29: Use different RSA mode OEAP/PSS, elevate ECDSA to 5127 REQUIRED status 5129 o Issue 35: limiting ECC cofactor to 1 5131 o Changed text regarding issue 33 reusing DH values 5133 o Fix tracker issue 32 on Domain Identifier normative text 5135 11.13. Changes from draft-ietf-hip-rfc5201-bis-07 5137 o Removed lingering references to SHA-1 as the mandatory hash 5138 algorithm (which was changed to SHA-256 in the -02 draft version). 5140 o For parameter type number changes, changed "IETF Review" to "IETF 5141 Review or IESG Approval". 5143 o Updated Appendix C checksum examples to conform to HIPv2 packets. 5145 11.14. Changes from draft-ietf-hip-rfc5201-bis-06 5147 o Made echoing the R1_COUNTER in the I2 mandatory if the R1 contains 5148 an R1_COUNTER. This required to make the R1 counter a critical 5149 parameter. Hence, the parameter type number of the R1_COUNTER 5150 changed from 128 to 129. 5152 o Made KDF dependent on DH Group to enable negotiation of the KDF. 5154 11.15. Changes from draft-ietf-hip-rfc5201-bis-05 5156 o Changed type number of DH_GROUP_LIST from 2151 to 511 because it 5157 was in the number space that is reserved for the HIP transport 5158 mode negotiations. 5160 o Added transport form type list parameter. Transport forms are now 5161 negotiated with this list instead of by their order in the HIP 5162 packet. This allows to remove the exception of the transport 5163 format parameters that were ordered by their preference instead of 5164 by their type number. This should remove complexity from 5165 implementations. 5167 o Clarify that in HIP signature processing, the restored checksum 5168 and length fields have been rendered invalid by the previous 5169 steps. 5171 o Clarify behavior for when UPDATE does not contain SEQ or ACQ 5172 (disallow this). 5174 o For namespace changes, changed "IETF Review" to "IETF Review or 5175 IESG Approval". 5177 o Addressed IESG comment about ignoring packet IP addresses. 5179 o Permit using Anonymous HI control in packets other than R1/I2. 5181 o Fixed minor reference error (RFC2418, RFC2410). 5183 o Deleted comment that NULL-ENCRYPTION SHOULD NOT be configurable 5184 via the UI. 5186 o Editorial changes. 5188 11.16. Changes from draft-ietf-hip-rfc5201-bis-04 5190 o Clarifications of the Security Considerations section. One DoS 5191 defense mechanism was changed to be more effective and less prone 5192 to misuse. 5194 o Minor clarifications of the state machine. 5196 o Clarified text on HIP puzzle. 5198 o Added names and references for figures. 5200 o Extended the definitions section. 5202 o Added a reference to the HIP Version 1 certificate document. 5204 o Added Initiator, Responder, HIP association, and signed data to 5205 the definitions section. 5207 o Changed parameter figure for PUZZLE and SOLUTION to use 5208 RHASH_len/8 instead of n-byte. 5210 o Replaced occurrences of lowercase 'not' in SHOULD NOT. 5212 o Changed text to reflect the fact that several 5213 ECHO_REQUEST_UNSIGNED parameters may be present in an R1 and 5214 several ECHO_RESPONSE parameters may be present in an I2. 5216 o Added text on verifying the ECHO_RESPONSE_SIGNED parameter in 5217 CLOSE_ACK. 5219 o Changed wording from HMAC to HIP_MAC in Section 5.3.8. 5221 o Reflected fact that the UPDATE packet MAY include zero or more 5222 ACKs. 5224 o Added BEX to Definitions section. 5226 o Changed HIP_SIGNATURE algorithm field from 8 bit to 16 bit to 5227 achieve alignment with the HOST_ID parameters. 5229 o Fixed the wrong figures of the SEQ and ACK parameters. SEQ always 5230 contains ONE update ID. ACK may acknowledge SEVERAL update IDs. 5232 o Added wording that several NOTIFY parameters may be present in a 5233 HIP packet. 5235 o Changed wording for the ECHO_RESPONSE_SIGNED parameter. Also 5236 lifted the restriction that only one ECHO_RESPONSE_UNSIGNED 5237 parameter MUST be present in each HIP packet. This did contradict 5238 the definition of the ECHO_RESPONSE_UNSIGNED parameter. 5240 o Changed IETF Consensus to IETF Review or IESG Approval in IANA 5241 section. 5243 o Aligned use of I, J, and K. Now I is #I, J is #J and K is #K 5244 throughout the document. 5246 o Updated references. 5248 o Editorial changes. 5250 11.17. Changes from draft-ietf-hip-rfc5201-bis-03 5252 o Editorial changes to improve clarity and readability. 5254 o Removed obsoleted (not applicable) attack from security 5255 consideration section. 5257 o Added a requirement that hosts MUST support processing of ACK 5258 parameters with several SEQ numbers even when they do not support 5259 sending such parameters. 5261 o Removed note on memory bound puzzles. The use of memory bound 5262 puzzles was reconsidered but no convincing arguments for inclusion 5263 in this document have been made on the list. 5265 o Changed references to reference the new bis documents. 5267 o Specified the ECC curves and the hashes used for these. 5269 o Specified representation of ECC curves in the HI. 5271 o Added text on the dependency between RHASH and HMAC. 5273 o Rephrased part of the security considerations to make them 5274 clearer. 5276 o Clarified the use of HITs in opportunistic mode. 5278 o Clarified the difference between HIP_MAC and HIP_MAC_2 as well as 5279 between SIGNATURE and SIGNATURE_2. 5281 o Changed NOTIFY name for value 44 from SERVER_BUSY_PLEASE_RETRY to 5282 RESPONDER_BUSY_PLEASE_RETRY. 5284 o Mentioned that there are multiple valid puzzle solutions. 5286 11.18. Changes from draft-ietf-hip-rfc5201-bis-02 5288 o Added recommendation to not use puzzle #I twice for the same host 5289 to avoid identical key material. 5291 o Revised state machine and added missing event handling. 5293 o Added UNSUPPORTED_HIT_SUITE to NOTIFY to indicate unsupported HIT 5294 suites. 5296 o Revised parameter type numbers (corresponding to IANA allocations) 5297 and added missing "free for experimentation" range to the 5298 description. 5300 o Clarifying note on the use of the C bit in the parameter type 5301 numbers. 5303 11.19. Changes from draft-ietf-hip-rfc5201-bis-01 5305 o Changed RHASH-len to RHASH_len to avoid confusion in calculations 5306 (- could be minus) 5308 o Added RHASH_len to list of abbreviations 5310 o Fixed length of puzzle #I and #J to be 1*RHASH_len 5311 o Changed RHASH-len to RHASH_len to avoid confusion in calculations 5312 (- could be minus) 5314 o Added RHASH_len to list of abbreviations 5316 o Fixed length of puzzle #I and #J to be 1*RHASH_len 5318 o Included HIT_SUITEs. 5320 o Added DH negotiation to I1 and R1. 5322 o Added DH_LIST parameter. 5324 o Added text for DH Group negotiation. 5326 o Removed second DH public value from DH parameter. 5328 o Added ECC to HI generation. 5330 o Added Responder HIT selection to opportunistic mode. 5332 o Added ECDSA HI text and references (not complete yet). 5334 o Added separate section on aborting BEX. 5336 o Added separate section on downgrade attack prevention. 5338 o Added text about DH Group selection for use cases without I1. 5340 o Removed type range allocation for parameters related to HIP 5341 transform types. 5343 o New type range allocation for parameters that are only covered by 5344 a signature if a signature is present (Applies to DH_GROUP_LIST). 5346 o Renamed HIP_TRANSFORM to HIP_CIPHER and removed hashes from it - 5347 hashes are determined by RHASH. 5349 o The length of #I and #J for the puzzle now depends on RHASH. 5351 o New keymat generation. 5353 o Puzzle seed and solution now use RHASH and have variable length. 5355 o Moved timing definitions closer to state machine. 5357 o Simplified text regarding puzzle lifetime. 5359 o Clarified the description of the use of #I in the puzzle 5361 o Removed "Opportunistic mode" description from general definitions. 5363 o More consistency across the old RFC5201 text. Aligned 5364 capitalization and abbreviations. 5366 o Extended protocol overview to include restart option. 5368 o Extended state machine to include restart option because of 5369 unsupported Algorithms. 5371 o Replaced SHA-1 with SHA-256 for required implementation. 5373 o Added OGA list parameter (715) for detecting the Responder's set 5374 of OGAs. 5376 o Added Appendix on ORCHID use in HITs. 5378 o Added truncated SHA-256 option for HITs. 5380 o Added truncated SHA-1 option for HITs. 5382 o Added text about new ORCHID structure to HIT overview. 5384 o Moved Editor role to Robert Moskowitz. 5386 o Added SHA-256 to puzzle parameter. 5388 o Generalized LTRUNC to be hash-function agnostic. 5390 o Added text about RHASH depending on OGA. 5392 11.20. Changes from draft-ietf-hip-rfc5201-bis-00 5394 o Added reasoning why BIS document is needed. 5396 11.21. Contents of draft-ietf-hip-rfc5201-bis-00 5398 o RFC5201 was submitted as draft-RFC. 5400 12. References 5402 12.1. Normative References 5404 [FIPS.180-2.2002] 5405 National Institute of Standards and Technology, "Secure 5406 Hash Standard", FIPS PUB 180-2, August 2002, 5407 . 5410 [I-D.ietf-hip-rfc5202-bis] 5411 Jokela, P., Moskowitz, R., and J. Melen, "Using the 5412 Encapsulating Security Payload (ESP) Transport Format with 5413 the Host Identity Protocol (HIP)", draft-ietf-hip- 5414 rfc5202-bis-05 (work in progress), November 2013. 5416 [NIST.800-131A.2011] 5417 National Institute of Standards and Technology, 5418 "Transitions: Recommendation for Transitioning the Use of 5419 Cryptographic Algorithms and Key Lengths", NIST 800-131A, 5420 January 2011. 5422 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 5423 August 1980. 5425 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 5426 793, September 1981. 5428 [RFC1035] Mockapetris, P., "Domain names - implementation and 5429 specification", STD 13, RFC 1035, November 1987. 5431 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 5432 Requirement Levels", BCP 14, RFC 2119, March 1997. 5434 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within 5435 ESP and AH", RFC 2404, November 1998. 5437 [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and 5438 Its Use With IPsec", RFC 2410, November 1998. 5440 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 5441 (IPv6) Specification", RFC 2460, December 1998. 5443 [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System 5444 (DNS)", RFC 2536, March 1999. 5446 [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain 5447 Name System (DNS)", RFC 3110, May 2001. 5449 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 5450 Diffie-Hellman groups for Internet Key Exchange (IKE)", 5451 RFC 3526, May 2003. 5453 [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher 5454 Algorithm and Its Use with IPsec", RFC 3602, September 5455 2003. 5457 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 5458 RFC 3972, March 2005. 5460 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 5461 Rose, "Resource Records for the DNS Security Extensions", 5462 RFC 4034, March 2005. 5464 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 5465 Network Access Identifier", RFC 4282, December 2005. 5467 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 5468 Message Protocol (ICMPv6) for the Internet Protocol 5469 Version 6 (IPv6) Specification", RFC 4443, March 2006. 5471 [RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using 5472 the Elliptic Curve Digital Signature Algorithm (ECDSA)", 5473 RFC 4754, January 2007. 5475 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 5476 384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007. 5478 [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY 5479 and RRSIG Resource Records for DNSSEC", RFC 5702, October 5480 2009. 5482 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 5483 "Default Address Selection for Internet Protocol Version 6 5484 (IPv6)", RFC 6724, September 2012. 5486 [RFC7343] Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay 5487 Routable Cryptographic Hash Identifiers Version 2 5488 (ORCHIDv2)", RFC 7343, September 2014. 5490 12.2. Informative References 5492 [AUR03] Aura, T., Nagarajan, A., and A. Gurtov, "Analysis of the 5493 HIP Base Exchange Protocol", in Proceedings of 10th 5494 Australasian Conference on Information Security and 5495 Privacy, July 2003. 5497 [CRO03] Crosby, SA. and DS. Wallach, "Denial of Service via 5498 Algorithmic Complexity Attacks", in Proceedings of Usenix 5499 Security Symposium 2003, Washington, DC., August 2003. 5501 [DIF76] Diffie, W. and M. Hellman, "New Directions in 5502 Cryptography", IEEE Transactions on Information Theory 5503 vol. IT-22, number 6, pages 644-654, Nov 1976. 5505 [FIPS.197.2001] 5506 National Institute of Standards and Technology, "Advanced 5507 Encryption Standard (AES)", FIPS PUB 197, November 2001, 5508 . 5511 [FIPS186-3] 5512 U.S. Department of Commerce/National Institute of 5513 Standards and Technology, "FIPS PUB 186-3: Digital 5514 Signature Standard (DSS).", June 2009. 5516 [I-D.ietf-hip-rfc4423-bis] 5517 Moskowitz, R., "Host Identity Protocol Architecture", 5518 draft-ietf-hip-rfc4423-bis-05 (work in progress), 5519 September 2012. 5521 [I-D.ietf-hip-rfc5204-bis] 5522 Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 5523 Rendezvous Extension", draft-ietf-hip-rfc5204-bis-02 (work 5524 in progress), September 2012. 5526 [I-D.ietf-hip-rfc5205-bis] 5527 Laganier, J., "Host Identity Protocol (HIP) Domain Name 5528 System (DNS) Extension", draft-ietf-hip-rfc5205-bis-02 5529 (work in progress), September 2012. 5531 [I-D.ietf-hip-rfc5206-bis] 5532 Henderson, T., Vogt, C., and J. Arkko, "Host Mobility with 5533 the Host Identity Protocol", draft-ietf-hip-rfc5206-bis-06 5534 (work in progress), July 2013. 5536 [KAU03] Kaufman, C., Perlman, R., and B. Sommerfeld, "DoS 5537 protection for UDP-based protocols", ACM Conference on 5538 Computer and Communications Security , Oct 2003. 5540 [KRA03] Krawczyk, H., "SIGMA: The 'SIGn-and-MAc' Approach to 5541 Authenticated Diffie-Hellman and Its Use in the IKE- 5542 Protocols", in Proceedings of CRYPTO 2003, pages 400-425, 5543 August 2003. 5545 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 5546 RFC 792, September 1981. 5548 [RFC2785] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup" 5549 Attacks on the Diffie-Hellman Key Agreement Method for S/ 5550 MIME", RFC 2785, March 2000. 5552 [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography 5553 Specification Version 2.0", RFC 2898, September 2000. 5555 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 5556 Standards (PKCS) #1: RSA Cryptography Specifications 5557 Version 2.1", RFC 3447, February 2003. 5559 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 5560 Reserved for Documentation", RFC 3849, July 2004. 5562 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 5563 "Host Identity Protocol", RFC 5201, April 2008. 5565 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 5566 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 5567 May 2008. 5569 [RFC5338] Henderson, T., Nikander, P., and M. Komu, "Using the Host 5570 Identity Protocol with Legacy Applications", RFC 5338, 5571 September 2008. 5573 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 5574 Shim Protocol for IPv6", RFC 5533, June 2009. 5576 [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks 5577 Reserved for Documentation", RFC 5737, January 2010. 5579 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 5580 Key Derivation Function (HKDF)", RFC 5869, May 2010. 5582 [RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a 5583 Prime (ECP Groups) for IKE and IKEv2", RFC 5903, June 5584 2010. 5586 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 5587 "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5588 5996, September 2010. 5590 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 5591 Curve Cryptography Algorithms", RFC 6090, February 2011. 5593 [RFC6253] Heer, T. and S. Varjonen, "Host Identity Protocol 5594 Certificates", RFC 6253, May 2011. 5596 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 5597 of IPv6 Extension Headers", RFC 7045, December 2013. 5599 [RSA] Rivest, R., Shamir, A., and L. Adleman, "A Method for 5600 Obtaining Digital Signatures and Public-Key 5601 Cryptosystems", Communications of the ACM 21 (2), pp. 5602 120-126, February 1978. 5604 [SECG] SECG, "Recommended Elliptic Curve Domain Parameters", SEC 5605 2 , 2000, . 5607 Appendix A. Using Responder Puzzles 5609 As mentioned in Section 4.1.1, the Responder may delay state creation 5610 and still reject most spoofed I2 packets by using a number of pre- 5611 calculated R1 packets and a local selection function. This appendix 5612 defines one possible implementation in detail. The purpose of this 5613 appendix is to give the implementors an idea on how to implement the 5614 mechanism. If the implementation is based on this appendix, it MAY 5615 contain some local modification that makes an attacker's task harder. 5617 The Responder creates a secret value S, that it regenerates 5618 periodically. The Responder needs to remember the two latest values 5619 of S. Each time the S is regenerated, the R1 generation counter 5620 value is incremented by one. 5622 The Responder generates a pre-signed R1 packet. The signature for 5623 pre-generated R1s must be recalculated when the Diffie-Hellman key is 5624 recomputed or when the R1_COUNTER value changes due to S value 5625 regeneration. 5627 When the Initiator sends the I1 packet for initializing a connection, 5628 the Responder receives the HIT and IP address from the packet, and 5629 generates an #I value for the puzzle. The #I value is set to the 5630 pre-signed R1 packet. 5632 #I value calculation: 5633 #I = Ltrunc( RHASH ( S | HIT-I | HIT-R | IP-I | IP-R ), n) 5634 where n = RHASH_len 5636 The RHASH algorithm is the same that is used to generate the 5637 Responder's HIT value. 5639 From an incoming I2 packet, the Responder receives the required 5640 information to validate the puzzle: HITs, IP addresses, and the 5641 information of the used S value from the R1_COUNTER. Using these 5642 values, the Responder can regenerate the #I, and verify it against 5643 the #I received in the I2 packet. If the #I values match, it can 5644 verify the solution using #I, #J, and difficulty #K. If the #I 5645 values do not match, the I2 is dropped. 5647 puzzle_check: 5648 V := Ltrunc( RHASH( I2.I | I2.hit_i | I2.hit_r | I2.J ), #K ) 5649 if V != 0, drop the packet 5651 If the puzzle solution is correct, the #I and #J values are stored 5652 for later use. They are used as input material when keying material 5653 is generated. 5655 Keeping state about failed puzzle solutions depends on the 5656 implementation. Although it is possible for the Responder not to 5657 keep any state information, it still may do so to protect itself 5658 against certain attacks (see Section 4.1.1). 5660 Appendix B. Generating a Public Key Encoding from an HI 5662 The following pseudo-code illustrates the process to generate a 5663 public key encoding from an HI for both RSA and DSA. 5665 The symbol ":=" denotes assignment; the symbol "+=" denotes 5666 appending. The pseudo-function "encode_in_network_byte_order" takes 5667 two parameters, an integer (bignum) and a length in bytes, and 5668 returns the integer encoded into a byte string of the given length. 5670 switch ( HI.algorithm ) 5671 { 5673 case RSA: 5674 buffer := encode_in_network_byte_order ( HI.RSA.e_len, 5675 ( HI.RSA.e_len > 255 ) ? 3 : 1 ) 5676 buffer += encode_in_network_byte_order ( HI.RSA.e, HI.RSA.e_len ) 5677 buffer += encode_in_network_byte_order ( HI.RSA.n, HI.RSA.n_len ) 5678 break; 5680 case DSA: 5681 buffer := encode_in_network_byte_order ( HI.DSA.T , 1 ) 5682 buffer += encode_in_network_byte_order ( HI.DSA.Q , 20 ) 5683 buffer += encode_in_network_byte_order ( HI.DSA.P , 64 + 5684 8 * HI.DSA.T ) 5685 buffer += encode_in_network_byte_order ( HI.DSA.G , 64 + 5686 8 * HI.DSA.T ) 5687 buffer += encode_in_network_byte_order ( HI.DSA.Y , 64 + 5688 8 * HI.DSA.T ) 5689 break; 5691 } 5693 Appendix C. Example Checksums for HIP Packets 5695 The HIP checksum for HIP packets is specified in Section 5.1.1. 5696 Checksums for TCP and UDP packets running over HIP-enabled security 5697 associations are specified in Section 4.5.1. The examples below use 5698 [RFC3849] and [RFC5737] addresses, and HITs with the prefix of 5699 2001:20 followed by zeros, followed by a decimal 1 or 2, 5700 respectively. 5702 The following example is defined only for testing the checksum 5703 calculation. 5705 C.1. IPv6 HIP Example (I1 packet) 5707 Source Address: 2001:DB8::1 5708 Destination Address: 2001:DB8::2 5709 Upper-Layer Packet Length: 48 0x30 5710 Next Header: 139 0x8b 5711 Payload Protocol: 59 0x3b 5712 Header Length: 5 0x5 5713 Packet Type: 1 0x1 5714 Version: 2 0x2 5715 Reserved: 1 0x1 5716 Control: 0 0x0 5717 Checksum: 6750 0x1a5e 5718 Sender's HIT : 2001:20::1 5719 Receiver's HIT: 2001:20::2 5720 DH_GROUP_LIST type: 511 0x1ff 5721 DH_GROUP_LIST length: 3 0x3 5722 DH_GROUP_LIST group IDs: 3,4,8 5724 C.2. IPv4 HIP Packet (I1 packet) 5726 The IPv4 checksum value for the example I1 packet is shown below. 5728 Source Address: 192.0.2.1 5729 Destination Address: 192.0.2.2 5730 Upper-Layer Packet Length: 48 0x30 5731 Next Header: 139 0x8b 5732 Payload Protocol: 59 0x3b 5733 Header Length: 5 0x5 5734 Packet Type: 1 0x1 5735 Version: 2 0x2 5736 Reserved: 1 0x1 5737 Control: 0 0x0 5738 Checksum: 61902 0xf1ce 5739 Sender's HIT : 2001:20::1 5740 Receiver's HIT: 2001:20::2 5741 DH_GROUP_LIST type: 511 0x1ff 5742 DH_GROUP_LIST length: 3 0x3 5743 DH_GROUP_LIST group IDs: 3,4,8 5745 C.3. TCP Segment 5747 Regardless of whether IPv6 or IPv4 is used, the TCP and UDP sockets 5748 use the IPv6 pseudo-header format [RFC2460], with the HITs used in 5749 place of the IPv6 addresses. 5751 Sender's HIT: 2001:20::1 5752 Receiver's HIT: 2001:20::2 5753 Upper-Layer Packet Length: 20 0x14 5754 Next Header: 6 0x06 5755 Source port: 65500 0xffdc 5756 Destination port: 22 0x0016 5757 Sequence number: 1 0x00000001 5758 Acknowledgment number: 0 0x00000000 5759 Data offset: 5 0x5 5760 Flags: SYN 0x02 5761 Window size: 65535 0xffff 5762 Checksum: 28586 0x6faa 5763 Urgent pointer: 0 0x0000 5765 Appendix D. ECDH and ECDSA 160 Bit Groups 5767 The ECDH and ECDSA 160-bit group SECP160R1 is rated at 80 bits 5768 symmetric strength. Once this was considered appropriate for one 5769 year of security. Today these groups should be used only when the 5770 host is not powerful enough (e.g., some embedded devices) and when 5771 security requirements are low (e.g., long-term confidentiality is not 5772 required). 5774 Appendix E. HIT Suites and HIT Generation 5776 The HIT as an ORCHID [RFC7343] consists of three parts: A 28-bit 5777 prefix, a 4-bit encoding of the ORCHID generation algorithm (OGA) and 5778 a hash that includes the Host Identity and a context ID. The OGA is 5779 an index pointing to the specific algorithm by which the public key 5780 and the 96-bit hashed encoding is generated. The OGA is protocol 5781 specific and is to be interpreted as defined below for all protocols 5782 that use the same context ID as HIP. HIP groups sets of valid 5783 combinations of signature and hash algorithms into HIT Suites. These 5784 HIT suites are addressed by an index, which is transmitted in the OGA 5785 field of the ORCHID. 5787 The set of used HIT Suites will be extended to counter the progress 5788 in computation capabilities and vulnerabilities in the employed 5789 algorithms. The intended use of the HIT Suites is to introduce a new 5790 HIT Suite and phase out an old one before it becomes insecure. Since 5791 the 4-bit OGA field only permits 15 HIT Suites to be used at the same 5792 time (the HIT Suite with ID 0 is reserved), phased-out HIT Suites 5793 must be reused at some point. In such a case, there will be a 5794 rollover of the HIT Suite ID and the next newly introduced HIT Suite 5795 will start with a lower HIT Suite index than the previously 5796 introduced one. The rollover effectively deprecates the reused HIT 5797 Suite. For a smooth transition, the HIT Suite should be deprecated a 5798 considerable time before the HIT Suite index is reused. 5800 Since the number of HIT Suites is tightly limited to 16, the HIT 5801 Suites must be assigned carefully. Hence, sets of suitable 5802 algorithms are grouped in a HIT Suite. 5804 The HIT Suite of the Responder's HIT determines the RHASH and the 5805 hash function to be used for the HMAC in HIP packets as well as the 5806 signature algorithm family used for generating the HI. The list of 5807 HIT Suites is defined in Table 10. 5809 Authors' Addresses 5811 Robert Moskowitz (editor) 5812 Verizon Telcom and Business 5813 1000 Bent Creek Blvd, Suite 200 5814 Mechanicsburg, PA 5815 USA 5817 EMail: robert.moskowitz@verizonbusiness.com 5819 Tobias Heer 5820 Hirschmann Automation and Control 5821 Stuttgarter Strasse 45-51 5822 Neckartenzlingen 72654 5823 Germany 5825 EMail: tobias.heer@belden.com 5827 Petri Jokela 5828 Ericsson Research NomadicLab 5829 JORVAS FIN-02420 5830 FINLAND 5832 Phone: +358 9 299 1 5833 EMail: petri.jokela@nomadiclab.com 5834 Thomas R. Henderson 5835 University of Washington 5836 Campus Box 352500 5837 Seattle, WA 5838 USA 5840 EMail: tomhend@u.washington.edu