idnits 2.17.1 draft-ietf-hip-rfc5201-bis-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. == There are 2 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 2187 has weird spacing: '...c Value leng...' == Line 2189 has weird spacing: '...c Value the ...' == Line 2706 has weird spacing: '...ication info...' == Line 2845 has weird spacing: '...ue data opaqu...' == Line 2875 has weird spacing: '...ue data opaqu...' == (2 more instances...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: o Replaced occurrences of SHOULD not with SHOULD NOT. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 31, 2011) is 4554 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-08) exists of draft-ietf-hip-rfc4843-bis-00 == Outdated reference: A later version (-07) exists of draft-ietf-hip-rfc5202-bis-00 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2898 (Obsoleted by RFC 8018) ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) ** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542) ** Obsolete normative reference: RFC 5201 (Obsoleted by RFC 7401) ** Downref: Normative reference to an Informational RFC: RFC 5869 ** Downref: Normative reference to an Informational RFC: RFC 5903 ** Downref: Normative reference to an Informational RFC: RFC 6090 == Outdated reference: A later version (-12) exists of draft-ietf-hip-cert-09 == Outdated reference: A later version (-20) exists of draft-ietf-hip-rfc4423-bis-02 == Outdated reference: A later version (-08) exists of draft-ietf-hip-rfc5204-bis-00 == Outdated reference: A later version (-10) exists of draft-ietf-hip-rfc5205-bis-00 == Outdated reference: A later version (-14) exists of draft-ietf-hip-rfc5206-bis-01 -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 9 errors (**), 0 flaws (~~), 17 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Moskowitz, Ed. 3 Internet-Draft Verizon 4 Obsoletes: 5201 (if approved) T. Heer 5 Intended status: Standards Track RWTH Aachen University, 6 Expires: May 3, 2012 Communication and Distributed 7 Systems Group 8 P. Jokela 9 Ericsson Research NomadicLab 10 T. Henderson 11 The Boeing Company 12 October 31, 2011 14 Host Identity Protocol Version 2 (HIPv2) 15 draft-ietf-hip-rfc5201-bis-07 17 Abstract 19 This document specifies the details of the Host Identity Protocol 20 (HIP). HIP allows consenting hosts to securely establish and 21 maintain shared IP-layer state, allowing separation of the identifier 22 and locator roles of IP addresses, thereby enabling continuity of 23 communications across IP address changes. HIP is based on a SIGMA- 24 compliant Diffie-Hellman key exchange, using public key identifiers 25 from a new Host Identity namespace for mutual peer authentication. 26 The protocol is designed to be resistant to denial-of-service (DoS) 27 and man-in-the-middle (MitM) attacks. When used together with 28 another suitable security protocol, such as the Encapsulated Security 29 Payload (ESP), it provides integrity protection and optional 30 encryption for upper-layer protocols, such as TCP and UDP. 32 This document obsoletes RFC 5201 and addresses the concerns raised by 33 the IESG, particularly that of crypto agility. It also incorporates 34 lessons learned from the implementations of RFC 5201. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on May 3, 2012. 53 Copyright Notice 55 Copyright (c) 2011 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 This document may contain material from IETF Documents or IETF 69 Contributions published or made publicly available before November 70 10, 2008. The person(s) controlling the copyright in some of this 71 material may not have granted the IETF Trust the right to allow 72 modifications of such material outside the IETF Standards Process. 73 Without obtaining an adequate license from the person(s) controlling 74 the copyright in such materials, this document may not be modified 75 outside the IETF Standards Process, and derivative works of it may 76 not be created outside the IETF Standards Process, except to format 77 it for publication as an RFC or to translate it into languages other 78 than English. 80 Table of Contents 82 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 83 1.1. A New Namespace and Identifiers . . . . . . . . . . . . . 7 84 1.2. The HIP Base Exchange (BEX) . . . . . . . . . . . . . . . 7 85 1.3. Memo Structure . . . . . . . . . . . . . . . . . . . . . 8 86 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 8 87 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 8 88 2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 8 89 2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 9 90 3. Host Identity (HI) and its Structure . . . . . . . . . . . . 10 91 3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 11 92 3.2. Generating a HIT from an HI . . . . . . . . . . . . . . . 11 93 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 12 94 4.1. Creating a HIP Association . . . . . . . . . . . . . . . 13 95 4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . 15 96 4.1.2. Puzzle Exchange . . . . . . . . . . . . . . . . . . . 15 97 4.1.3. Authenticated Diffie-Hellman Protocol with DH 98 Group Negotiation . . . . . . . . . . . . . . . . . . 17 99 4.1.4. HIP Replay Protection . . . . . . . . . . . . . . . . 18 100 4.1.5. Refusing a HIP Base Exchange . . . . . . . . . . . . 19 101 4.1.6. Aborting a HIP Base Exchange . . . . . . . . . . . . 20 102 4.1.7. HIP Downgrade Protection . . . . . . . . . . . . . . 20 103 4.1.8. HIP Opportunistic Mode . . . . . . . . . . . . . . . 21 104 4.2. Updating a HIP Association . . . . . . . . . . . . . . . 24 105 4.3. Error Processing . . . . . . . . . . . . . . . . . . . . 25 106 4.4. HIP State Machine . . . . . . . . . . . . . . . . . . . . 26 107 4.4.1. State Machine Terminology . . . . . . . . . . . . . . 26 108 4.4.2. HIP States . . . . . . . . . . . . . . . . . . . . . 27 109 4.4.3. HIP State Processes . . . . . . . . . . . . . . . . . 27 110 4.4.4. Simplified HIP State Diagram . . . . . . . . . . . . 35 111 4.5. User Data Considerations . . . . . . . . . . . . . . . . 37 112 4.5.1. TCP and UDP Pseudo-Header Computation for User Data . 37 113 4.5.2. Sending Data on HIP Packets . . . . . . . . . . . . . 37 114 4.5.3. Transport Formats . . . . . . . . . . . . . . . . . . 37 115 4.5.4. Reboot, Timeout, and Restart of HIP . . . . . . . . . 37 116 4.6. Certificate Distribution . . . . . . . . . . . . . . . . 38 117 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 38 118 5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 38 119 5.1.1. Checksum . . . . . . . . . . . . . . . . . . . . . . 39 120 5.1.2. HIP Controls . . . . . . . . . . . . . . . . . . . . 40 121 5.1.3. HIP Fragmentation Support . . . . . . . . . . . . . . 40 122 5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 41 123 5.2.1. TLV Format . . . . . . . . . . . . . . . . . . . . . 44 124 5.2.2. Defining New Parameters . . . . . . . . . . . . . . . 46 125 5.2.3. R1_COUNTER . . . . . . . . . . . . . . . . . . . . . 47 126 5.2.4. PUZZLE . . . . . . . . . . . . . . . . . . . . . . . 48 127 5.2.5. SOLUTION . . . . . . . . . . . . . . . . . . . . . . 49 128 5.2.6. DH_GROUP_LIST . . . . . . . . . . . . . . . . . . . . 50 129 5.2.7. DIFFIE_HELLMAN . . . . . . . . . . . . . . . . . . . 51 130 5.2.8. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . 52 131 5.2.9. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 53 132 5.2.10. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 55 133 5.2.11. TRANSPORT_FORMAT_LIST . . . . . . . . . . . . . . . . 56 134 5.2.12. HIP_MAC . . . . . . . . . . . . . . . . . . . . . . . 57 135 5.2.13. HIP_MAC_2 . . . . . . . . . . . . . . . . . . . . . . 57 136 5.2.14. HIP_SIGNATURE . . . . . . . . . . . . . . . . . . . . 58 137 5.2.15. HIP_SIGNATURE_2 . . . . . . . . . . . . . . . . . . . 59 138 5.2.16. SEQ . . . . . . . . . . . . . . . . . . . . . . . . . 59 139 5.2.17. ACK . . . . . . . . . . . . . . . . . . . . . . . . . 60 140 5.2.18. ENCRYPTED . . . . . . . . . . . . . . . . . . . . . . 61 141 5.2.19. NOTIFICATION . . . . . . . . . . . . . . . . . . . . 62 142 5.2.20. ECHO_REQUEST_SIGNED . . . . . . . . . . . . . . . . . 66 143 5.2.21. ECHO_REQUEST_UNSIGNED . . . . . . . . . . . . . . . . 66 144 5.2.22. ECHO_RESPONSE_SIGNED . . . . . . . . . . . . . . . . 67 145 5.2.23. ECHO_RESPONSE_UNSIGNED . . . . . . . . . . . . . . . 68 146 5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 68 147 5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 69 148 5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 70 149 5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 73 150 5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 74 151 5.3.5. UPDATE - the HIP Update Packet . . . . . . . . . . . 74 152 5.3.6. NOTIFY - the HIP Notify Packet . . . . . . . . . . . 76 153 5.3.7. CLOSE - the HIP Association Closing Packet . . . . . 76 154 5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet . . 77 155 5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 77 156 5.4.1. Invalid Version . . . . . . . . . . . . . . . . . . . 77 157 5.4.2. Other Problems with the HIP Header and Packet 158 Structure . . . . . . . . . . . . . . . . . . . . . . 77 159 5.4.3. Invalid Puzzle Solution . . . . . . . . . . . . . . . 78 160 5.4.4. Non-Existing HIP Association . . . . . . . . . . . . 78 161 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 78 162 6.1. Processing Outgoing Application Data . . . . . . . . . . 79 163 6.2. Processing Incoming Application Data . . . . . . . . . . 80 164 6.3. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 81 165 6.4. HIP_MAC and SIGNATURE Calculation and Verification . . . 82 166 6.4.1. HMAC Calculation . . . . . . . . . . . . . . . . . . 82 167 6.4.2. Signature Calculation . . . . . . . . . . . . . . . . 85 168 6.5. HIP KEYMAT Generation . . . . . . . . . . . . . . . . . . 87 169 6.6. Initiation of a HIP Base Exchange . . . . . . . . . . . . 88 170 6.6.1. Sending Multiple I1 Packets in Parallel . . . . . . . 89 171 6.6.2. Processing Incoming ICMP Protocol Unreachable 172 Messages . . . . . . . . . . . . . . . . . . . . . . 89 173 6.7. Processing Incoming I1 Packets . . . . . . . . . . . . . 90 174 6.7.1. R1 Management . . . . . . . . . . . . . . . . . . . . 91 175 6.7.2. Handling Malformed Messages . . . . . . . . . . . . . 92 176 6.8. Processing Incoming R1 Packets . . . . . . . . . . . . . 92 177 6.8.1. Handling of Malformed Messages . . . . . . . . . . . 94 178 6.9. Processing Incoming I2 Packets . . . . . . . . . . . . . 95 179 6.9.1. Handling of Malformed Messages . . . . . . . . . . . 97 180 6.10. Processing of Incoming R2 Packets . . . . . . . . . . . . 97 181 6.11. Sending UPDATE Packets . . . . . . . . . . . . . . . . . 98 182 6.12. Receiving UPDATE Packets . . . . . . . . . . . . . . . . 99 183 6.12.1. Handling a SEQ Parameter in a Received UPDATE 184 Message . . . . . . . . . . . . . . . . . . . . . . . 100 185 6.12.2. Handling an ACK Parameter in a Received UPDATE 186 Packet . . . . . . . . . . . . . . . . . . . . . . . 101 187 6.13. Processing of NOTIFY Packets . . . . . . . . . . . . . . 101 188 6.14. Processing CLOSE Packets . . . . . . . . . . . . . . . . 101 189 6.15. Processing CLOSE_ACK Packets . . . . . . . . . . . . . . 102 190 6.16. Handling State Loss . . . . . . . . . . . . . . . . . . . 102 191 7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 102 192 8. Security Considerations . . . . . . . . . . . . . . . . . . . 103 193 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 106 194 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 108 195 11. Changes from RFC 5201 . . . . . . . . . . . . . . . . . . . . 109 196 11.1. Changes from draft-ietf-hip-rfc5201-bis-06 . . . . . . . 109 197 11.2. Changes from draft-ietf-hip-rfc5201-bis-05 . . . . . . . 109 198 11.3. Changes from draft-ietf-hip-rfc5201-bis-04 . . . . . . . 110 199 11.4. Changes from draft-ietf-hip-rfc5201-bis-03 . . . . . . . 111 200 11.5. Changes from draft-ietf-hip-rfc5201-bis-02 . . . . . . . 112 201 11.6. Changes from draft-ietf-hip-rfc5201-bis-01 . . . . . . . 112 202 11.7. Changes from draft-ietf-hip-rfc5201-bis-00 . . . . . . . 114 203 11.8. Contents of draft-ietf-hip-rfc5201-bis-00 . . . . . . . . 114 204 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 114 205 12.1. Normative References . . . . . . . . . . . . . . . . . . 114 206 12.2. Informative References . . . . . . . . . . . . . . . . . 117 207 Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 119 208 Appendix B. Generating a Public Key Encoding from an HI . . . . 120 209 Appendix C. Example Checksums for HIP Packets . . . . . . . . . 121 210 C.1. IPv6 HIP Example (I1 packet) . . . . . . . . . . . . . . 121 211 C.2. IPv4 HIP Packet (I1 packet) . . . . . . . . . . . . . . . 121 212 C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . . 121 213 Appendix D. ECDH and ECDSA 160 Bit Groups . . . . . . . . . . . 122 214 Appendix E. HIT Suites and HIT Generation . . . . . . . . . . . 122 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 an active HIP association. Other 236 elements of the HIP architecture are specified in other documents, 237 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]: 241 how to use the Encapsulating Security Payload (ESP) for integrity 242 protection and optional encryption 244 o "Host Mobility with the Host Identity Protocol" 245 [I-D.ietf-hip-rfc5206-bis]: how to support host mobility in HIP 247 o "Host Identity Protocol (HIP) Domain Name System (DNS) Extensions" 248 [I-D.ietf-hip-rfc5205-bis]: how to extend DNS to contain Host 249 Identity information 251 o "Host Identity Protocol (HIP) Rendezvous Extension" 252 [I-D.ietf-hip-rfc5204-bis]: using a rendezvous mechanism to 253 contact mobile HIP hosts 255 Since the HIP Base Exchange was first developed, there have been a 256 few advances in cryptography and attacks against cryptographic 257 systems. As a result, all cryptographic protocols need to be agile. 258 That is, it should be a part of the protocol to be able to switch 259 from one cryptographic primitive to another. It is important to 260 support a reasonable set of mainstream algorithms to cater for 261 different use cases and allow moving away from algorithms that are 262 later discovered to be vulnerable This update to the Base Exchange 263 includes this needed cryptographic agility while addressing the 264 downgrade attacks that such flexibility introduces. In particular, 265 Elliptic Curve support by Elliptic Curve DSA (ECDSA) and Elliptic 266 Curve Diffie-Hellman (ECDH) and alternative hash functions have been 267 added. 269 1.1. A New Namespace and Identifiers 271 The Host Identity Protocol introduces a new namespace, the Host 272 Identity namespace. Some ramifications of this new namespace are 273 explained in the HIP architecture description 274 [I-D.ietf-hip-rfc4423-bis]. 276 There are two main representations of the Host Identity, the full 277 Host Identity (HI) and the Host Identity Tag (HIT). The HI is a 278 public key and directly represents the Identity of a host. Since 279 there are different public key algorithms that can be used with 280 different key lengths, the HI, as such, is unsuitable for use as a 281 packet identifier, or as an index into the various state-related 282 implementation structures needed to support HIP. Consequently, a 283 hash of the HI, the Host Identity Tag (HIT), is used as the 284 operational representation. The HIT is 128 bits long and is used in 285 the HIP headers and to index the corresponding state in the end 286 hosts. The HIT has an important security property in that it is 287 self-certifying (see Section 3). 289 1.2. The HIP Base Exchange (BEX) 291 The HIP base exchange is a two-party cryptographic protocol used to 292 establish communications context between hosts. The base exchange is 293 a SIGMA-compliant [KRA03] four-packet exchange. The first party is 294 called the Initiator and the second party the Responder. The 295 protocol exchanges Diffie-Hellman [DIF76] keys in the 2nd and 3rd 296 packets, and authenticates the parties in the 3rd and 4th packets. 297 The four-packet design helps to make HIP DoS resilient. It allows 298 the Responder to stay stateless until the IP address and the 299 cryptographic puzzle is verified. The Responder starts the puzzle 300 exchange in the 2nd packet, with the Initiator completing it in the 301 3rd packet before the Responder stores any state from the exchange. 303 The exchange can use the Diffie-Hellman output to encrypt the Host 304 Identity of the Initiator in the 3rd packet (although Aura, et al., 305 [AUR03] notes that such operation may interfere with packet- 306 inspecting middleboxes), or the Host Identity may instead be sent 307 unencrypted. The Responder's Host Identity is not protected. It 308 should be noted, however, that both the Initiator's and the 309 Responder's HITs are transported as such (in cleartext) in the 310 packets, allowing an eavesdropper with a priori knowledge about the 311 parties to identify them by their HITs. Hence, encrypting the HI of 312 any party does not provide privacy against such attacker. 314 Data packets start to flow after the 4th packet. The 3rd and 4th HIP 315 packets may carry a data payload in the future. However, the details 316 of this may be defined later. 318 An existing HIP association can be updated using the update mechanism 319 defined in this document, and when the association is no longer 320 needed, it can be closed using the defined closing mechanism. 322 Finally, HIP is designed as an end-to-end authentication and key 323 establishment protocol, to be used with Encapsulated Security Payload 324 (ESP) [I-D.ietf-hip-rfc5202-bis] and other end-to-end security 325 protocols. The base protocol does not cover all the fine-grained 326 policy control found in Internet Key Exchange (IKE) [RFC4306] that 327 allows IKE to support complex gateway policies. Thus, HIP is not a 328 complete replacement for IKE. 330 1.3. Memo Structure 332 The rest of this memo is structured as follows. Section 2 defines 333 the central keywords, notation, and terms used throughout the rest of 334 the document. Section 3 defines the structure of the Host Identity 335 and its various representations. Section 4 gives an overview of the 336 HIP base exchange protocol. Sections 5 and 6 define the detailed 337 packet formats and rules for packet processing. Finally, Sections 7, 338 8, and 9 discuss policy, security, and IANA considerations, 339 respectively. 341 2. Terms and Definitions 343 2.1. Requirements Terminology 345 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 346 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 347 document are to be interpreted as described in RFC 2119 [RFC2119]. 349 2.2. Notation 351 [x] indicates that x is optional. 353 {x} indicates that x is encrypted. 355 X(y) indicates that y is a parameter of X. 357 i indicates that x exists i times. 359 --> signifies "Initiator to Responder" communication (requests). 361 <-- signifies "Responder to Initiator" communication (replies). 363 | signifies concatenation of information (e.g., X | Y is the 364 concatenation of X with Y). 366 Ltrunc (H(x), K) denotes the lowest order #K bits of the result of 367 the hash function H on the input x. 369 2.3. Definitions 371 HIP Base Exchange (BEX): the handshake for establishing a new HIP 372 association. 374 Host Identity (HI): The public key of the signature algorithm that 375 represents the identity of the host. In HIP, a host proves its 376 identity by creating a signature with the private key belonging to 377 its HI (c.f. Section 3). 379 Host Identity Tag (HIT): A shorthand for the HI in IPv6 format. It 380 is generated by hashing the HI (c.f. Section 3.1). 382 HIT Suite: A HIT Suite groups all cryptographic algorithms that are 383 required to generate and use an HI and its HIT. In particular, 384 these algorithms are: 1) the public key signature algorithm and 2) 385 the hash function, 3) the truncation (c.f. Appendix E). 387 HIP association: The shared state between two peers after 388 completion of the BEX. 390 Initiator: The host that initiates the BEX. This role is typically 391 forgotten once the BEX is completed. 393 Responder: The host that responds to the Initiator in the BEX. 394 This role is typically forgotten once the BEX is completed. 396 Responder's HIT Hash Algorithm (RHASH): The Hash algorithm used for 397 various hash calculations in this document. The algorithm is the 398 same as is used to generate the Responder's HIT. The RHASH is the 399 hash function defined by the HIT Suite of the Responder's HIT 400 (c.f. Appendix E). 402 Length of the Responder's HIT Hash Algorithm (RHASH_len): The 403 natural output length of RHASH in bits. 405 Signed data: Data that is signed is protected by a digital 406 signature that was created by the sender of the data by using the 407 private key of its HI. 409 KDF: The Key Derivation Function (KDF) is used for deriving the 410 symmetric keys from the Diffie-Hellman key exchange. 412 KEYMAT: The keying material derived from the Diffie-Hellman key 413 exchange by using the KDF. Symmetric keys for encryption and 414 integrity protection of HIP control and payload packets are drawn 415 from this keying material. 417 3. Host Identity (HI) and its Structure 419 In this section, the properties of the Host Identity and Host 420 Identity Tag are discussed, and the exact format for them is defined. 421 In HIP, the public key of an asymmetric key pair is used as the Host 422 Identity (HI). Correspondingly, the host itself is defined as the 423 entity that holds the private key of the key pair. See the HIP 424 architecture specification [I-D.ietf-hip-rfc4423-bis] for more 425 details on the difference between an identity and the corresponding 426 identifier. 428 HIP implementations MUST support the Rivest Shamir Adelman (RSA) 429 [RFC3110] public key algorithm, and SHOULD support the Digital 430 Signature Algorithm (DSA) [RFC2536] algorithms, and Elliptic Curve 431 Digital Signature Algorithm (ECDSA) for generating the HI as defined 432 in Section 5.2.9. Additional algorithms MAY be supported. 434 A hashed encoding of the HI, the Host Identity Tag (HIT), is used in 435 protocols to represent the Host Identity. The HIT is 128 bits long 436 and has the following three key properties: i) it is the same length 437 as an IPv6 address and can be used in fixed address-sized fields in 438 APIs and protocols, ii) it is self-certifying (i.e., given a HIT, it 439 is computationally hard to find a Host Identity key that matches the 440 HIT), and iii) the probability of a HIT collision between two hosts 441 is very low, hence, it is infeasible for an attacker to find a 442 collision with a HIT that is in use. For details on the security 443 properties of the HIT see [I-D.ietf-hip-rfc4423-bis]. 445 The structure of the HIT is defined in [I-D.ietf-hip-rfc4843-bis]. 446 The HIT is an Overlay Routable Cryptographic Hash Identifier (ORCHID) 447 and consists of three parts: first, an IANA assigned prefix to 448 distinguish it from other IPv6 addresses. Second, a four-bit 449 encoding of the algorithms that were used for generating the HI and 450 the hashed representation of HI. Third, a 96-bit hashed 451 representation of the Host Identity. The encoding of the ORCHID 452 generation algorithm and the exact algorithm for generating the 453 hashed representation is specified in Appendix E. 455 Carrying HIs and HITs in the header of user data packets would 456 increase the overhead of packets. Thus, it is not expected that they 457 are carried in every packet, but other methods are used to map the 458 data packets to the corresponding HIs. In some cases, this makes it 459 possible to use HIP without any additional headers in the user data 460 packets. For example, if ESP is used to protect data traffic, the 461 Security Parameter Index (SPI) carried in the ESP header can be used 462 to map the encrypted data packet to the correct HIP association. 464 3.1. Host Identity Tag (HIT) 466 The Host Identity Tag is a 128-bit value -- a hashed encoding of the 467 Host Identifier. There are two advantages of using a hashed encoding 468 over the actual variable-sized Host Identity public key in protocols. 469 First, the fixed length of the HIT keeps packet sizes manageable and 470 eases protocol coding. Second, it presents a consistent format for 471 the protocol, independent of the underlying identity technology in 472 use. 474 RFC 4843-bis [I-D.ietf-hip-rfc4843-bis] specifies 128-bit hash-based 475 identifiers, called Overlay Routable Cryptographic Hash Identifiers, 476 ORCHIDs. Their prefix, allocated from the IPv6 address block, is 477 defined in [I-D.ietf-hip-rfc4843-bis]. The Host Identity Tag is one 478 type of an ORCHID. 480 This document extends the original, experimental HIP specification 481 [RFC5201] with measures to support crypto agility. One of these 482 measures is to allow different hash functions for creating a HIT. 483 HIT Suites group the sets of algorithms that are required to generate 484 and use a particular HIT. The Suites are encoded in HIT Suite IDs. 485 These HIT Suite IDs are transmitted in the ORCHID Generation 486 Algorithm (OGA) field in the ORCHID. With the HIT Suite ID in the 487 OGA field, a hosts can tell from another host's HIT, whether it 488 supports the necessary hash and signature algorithms to establish a 489 HIP association with that host. 491 3.2. Generating a HIT from an HI 493 The HIT MUST be generated according to the ORCHID generation method 494 described in [I-D.ietf-hip-rfc4843-bis] using a context ID value of 495 0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA (this tag value has been 496 generated randomly by the editor of this specification), and an input 497 that encodes the Host Identity field (see Section 5.2.9) present in a 498 HIP payload packet. The set of hash function, signature algorithm, 499 and the algorithm used for generating the HIT from the HI depends on 500 the HIT Suite (see Appendix E) and is indicated by the four bits of 501 the ORCHID Generation Algorithm (OGA) field in the ORCHID. 502 Currently, truncated SHA-1 and truncated SHA-256 [FIPS.180-2.2002] 503 are defined as hashes for generating a HIT. 505 For identities that are either RSA, Digital Signature Algorithm 506 (DSA), or Elliptic Curve DSA (ECDSA) public keys, the ORCHID input 507 consists of the public key encoding as specified for the Host 508 Identity field of the HOST_ID parameter (see Section 5.2.9). This 509 document defines four algorithm profiles: RSA, DSA, ECDSA, and 510 ECDSA_LOW. The ECDSA_LOW profile is meant for devices with low 511 computational capabilities. There are currently only three defined 512 public key algorithm classes: RSA/SHA-1, DSA, and ECDSA. Hence, 513 either of the following applies: 515 The RSA public key is encoded as defined in [RFC3110] Section 2, 516 taking the exponent length (e_len), exponent (e), and modulus (n) 517 fields concatenated. The length (n_len) of the modulus (n) can be 518 determined from the total HI Length and the preceding HI fields 519 including the exponent (e). Thus, the data that serves as input 520 for the HIT generation has the same length as the HI. The fields 521 MUST be encoded in network byte order, as defined in [RFC3110]. 523 The DSA public key is encoded as defined in [RFC2536] Section 2, 524 taking the fields T, Q, P, G, and Y, concatenated as input. Thus, 525 the data to be hashed is 1 + 20 + 3 * 64 + 3 * 8 * T octets long, 526 where T is the size parameter as defined in [RFC2536]. The size 527 parameter T, affecting the field lengths, MUST be selected as the 528 minimum value that is long enough to accommodate P, G, and Y. The 529 fields MUST be encoded in network byte order, as defined in 530 [RFC2536]. 532 The ECDSA public keys are encoded as defined in [RFC6090] Section 533 4.2 and 6. 535 In Appendix B, the public key encoding process is illustrated using 536 pseudo-code. 538 4. Protocol Overview 540 This section is a simplified overview of the HIP protocol operation, 541 and does not contain all the details of the packet formats or the 542 packet processing steps. Sections 5 and 6 describe in more detail 543 the packet formats and packet processing steps, respectively, and are 544 normative in case of any conflicts with this section. 546 The protocol number 139 has been assigned by IANA to the Host 547 Identity Protocol. 549 The HIP payload (Section 5.1) header could be carried in every IP 550 datagram. However, since HIP headers are relatively large (40 551 bytes), it is desirable to 'compress' the HIP header so that the HIP 552 header only occurs in control packets used to establish or change HIP 553 association state. The actual method for header 'compression' and 554 for matching data packets with existing HIP associations (if any) is 555 defined in separate documents, describing transport formats and 556 methods. All HIP implementations MUST implement, at minimum, the ESP 557 transport format for HIP [I-D.ietf-hip-rfc5202-bis]. 559 4.1. Creating a HIP Association 561 By definition, the system initiating a HIP base exchange is the 562 Initiator, and the peer is the Responder. This distinction is 563 typically forgotten once the base exchange completes, and either 564 party can become the Initiator in future communications. 566 The HIP base exchange serves to manage the establishment of state 567 between an Initiator and a Responder. The first packet, I1, 568 initiates the exchange, and the last three packets, R1, I2, and R2, 569 constitute an authenticated Diffie-Hellman [DIF76] key exchange for 570 session-key generation. In the first two packets, the hosts agree on 571 a set of cryptographic identifiers and algorithms that are then used 572 in and after the exchange. During the Diffie-Hellman key exchange, a 573 piece of keying material is generated. The HIP association keys are 574 drawn from this keying material by using a Key Derivation Function 575 (KDF). If other cryptographic keys are needed, e.g., to be used with 576 ESP, they are expected to be drawn from the same keying material by 577 using the KDF. 579 The Initiator first sends a trigger packet, I1, to the Responder. 580 The packet contains the HIT of the Initiator and possibly the HIT of 581 the Responder, if it is known. Moreover, the I1 packet initializes 582 the negotiation of the Diffie-Hellman group that is used for 583 generating the keying material. Therefore, the I1 packet contains a 584 list of Diffie Hellman Group IDs supported by the Initiator. Note 585 that in some cases it may be possible to replace this trigger packet 586 by some other form of a trigger, in which case the protocol starts 587 with the Responder sending the R1 packet. In such cases, another 588 mechanism to convey the Initiator's supported DH Groups (e.g., by 589 using a default group) must be specified. 591 The second packet, R1, starts the actual authenticated Diffie-Hellman 592 exchange. It contains a puzzle -- a cryptographic challenge that the 593 Initiator must solve before continuing the exchange. The level of 594 difficulty of the puzzle can be adjusted based on level of trust with 595 the Initiator, current load, or other factors. In addition, the R1 596 contains the Responder's Diffie-Hellman parameter and lists of 597 cryptographic algorithms supported by the Responder. Based on these 598 lists, the Initiator can continue, abort, or restart the base 599 exchange with a different selection of cryptographic algorithms. 600 Also, the R1 packet contains a signature that covers selected parts 601 of the message. Some fields are left outside the signature to 602 support pre-created R1s. 604 In the I2 packet, the Initiator MUST display the solution to the 605 received puzzle. Without a correct solution, the I2 message is 606 discarded. The I2 packet also contains a Diffie-Hellman parameter 607 that carries needed information for the Responder. The I2 packet is 608 signed by the Initiator. 610 The R2 packet acknowledges the receipt of the I2 packet and completes 611 the base exchange. The packet is signed by the Responder. 613 The base exchange is illustrated below in Figure 1. The term "key" 614 refers to the Host Identity public key, and "sig" represents a 615 signature using such a key. The packets contain other parameters not 616 shown in this figure. 618 Initiator Responder 620 I1: DH list 621 --------------------------> 622 select precomputed R1 623 R1: puzzle, DH, key, sig 624 <------------------------- 625 check sig remain stateless 626 solve puzzle 627 I2: solution, DH, {key}, sig 628 --------------------------> 629 compute DH check puzzle 630 check sig 631 R2: sig 632 <-------------------------- 633 check sig compute DH 635 Figure 1 637 4.1.1. HIP Puzzle Mechanism 639 The purpose of the HIP puzzle mechanism is to protect the Responder 640 from a number of denial-of-service threats. It allows the Responder 641 to delay state creation until receiving the I2 packet. Furthermore, 642 the puzzle allows the Responder to use a fairly cheap calculation to 643 check that the Initiator is "sincere" in the sense that it has 644 churned enough CPU cycles in solving the puzzle. 646 The puzzle allows a Responder implementation to completely delay 647 session-specific state creation until a valid I2 packet is received. 648 An I2 packet without valid puzzle solution can be rejected 649 immediately once the Responder has checked the solution by computing 650 only one hash function before state is created and CPU-intensive 651 public-key signature verification and Diffie-Hellman key generation 652 are performed. By varying the difficulty of the puzzle, the 653 Responder can frustrate CPU or memory targeted DoS attacks. 655 The Responder can remain stateless and drop most spoofed I2 packets 656 because puzzle calculation is based on the Initiator's Host Identity 657 Tag. The idea is that the Responder has a (perhaps varying) number of 658 pre-calculated R1 packets, and it selects one of these based on the 659 information carried in the I1 packet. When the Responder then later 660 receives the I2 packet, it can verify that the puzzle has been solved 661 using the Initiator's HIT. This makes it impractical for the 662 attacker to first exchange one I1/R1 packet, and then generate a 663 large number of spoofed I2 packets that seemingly come from different 664 HITs. This method does not protect the Responder from an attacker 665 that uses fixed HITs, though. Against such an attacker, a viable 666 approach may be to create a piece of local state, and remember that 667 the puzzle check has previously failed. See Appendix A for one 668 possible implementation. Responder implementations SHOULD include 669 sufficient randomness in the puzzle values so that algorithmic 670 complexity attacks become impossible [CRO03]. 672 The Responder can set the puzzle difficulty for the Initiator, based 673 on its level of trust of the Initiator. Because the puzzle is not 674 included in the signature calculation, the Responder can use pre- 675 calculated R1 packets and include the puzzle just before sending the 676 R1 to the Initiator. The Responder SHOULD use heuristics to 677 determine when it is under a denial-of-service attack, and set the 678 puzzle difficulty value #K appropriately as explained later. 680 4.1.2. Puzzle Exchange 682 The Responder starts the puzzle exchange when it receives an I1 683 packet. The Responder supplies a random number #I, and requires the 684 Initiator to find a number J. To select a proper #J, the Initiator 685 must create the concatenation of #I, the HITs of the parties, and #J, 686 and calculate a hash over this concatenation using the RHASH 687 algorithm. The lowest order #K bits of the result MUST be zeros. 688 The value #K sets the difficulty of the puzzle. 690 To generate a proper number #J, the Initiator will have to generate a 691 number of Js until one produces the hash target of zeros. The 692 Initiator SHOULD give up after exceeding the puzzle Lifetime in the 693 PUZZLE parameter (as described in Section 5.2.4). The Responder 694 needs to re-create the concatenation of #I, the HITs, and the 695 provided #J, and compute the hash once to prove that the Initiator 696 completed its assigned task. 698 To prevent precomputation attacks, the Responder MUST select the 699 number #I in such a way that the Initiator cannot guess it. 700 Furthermore, the construction MUST allow the Responder to verify that 701 the value #I was indeed selected by it and not by the Initiator. See 702 Appendix A for an example on how to implement this. 704 Using the Opaque data field in the PUZZLE (see Section 5.2.4), in an 705 ECHO_REQUEST_SIGNED (see Section 5.2.20) or in an 706 ECHO_REQUEST_UNSIGNED parameter (see Section 5.2.21), the Responder 707 can include some data in R1 that the Initiator MUST copy unmodified 708 in the corresponding I2 packet. The Responder can use the opaque 709 data to transfer a piece of local state information to the Initiator 710 and back, for example to recognize that the I2 is a response to a 711 previously sent R1. The Responder can generate the Opaque data in 712 various ways; e.g., using encryption or hashing with some secret, the 713 sent #I, and possibly using other related data. With the same 714 secret, the received #I (from the I2 packet), and the other related 715 data (if any), the Responder can verify that it has itself sent the 716 #I to the Initiator. The Responder MUST periodically change such a 717 secret. 719 It is RECOMMENDED that the Responder generates new secrets for the 720 puzzle and new R1s once every few minutes. Furthermore, it is 721 RECOMMENDED that the Responder is able to verify valid puzzle 722 solution at least Lifetime seconds after the puzzle secret has been 723 deprecated. This time value guarantees that the puzzle is valid for 724 at least Lifetime and at most 2 * Lifetime seconds. This limits the 725 usability that an old, solved puzzle has to an attacker. Moreover, 726 it avoids problems with the validity of puzzles if the lifetime is 727 relatively short compared to the network delay and the time for 728 solving the puzzle. 730 The puzzle value #I and the solution #J are inputs for deriving the 731 keying material from the Diffie-Hellman key exchange (see 732 Section 6.5). Therefore, a Responder SHOULD NOT use the same puzzle 733 #I with the same DH keys for the same Initiator twice to ensure that 734 the derived keying material differs. Such uniqueness can be 735 achieved, for example, by using a counter as an additional input for 736 generating #I. This counter can be increased for each processed I1 737 packet. The state of the counter can be transmitted in the Opaque 738 data field in the PUZZLE (see Section 5.2.4), in an 739 ECHO_REQUEST_SIGNED (see Section 5.2.20) or in an 740 ECHO_REQUEST_UNSIGNED parameter (see Section 5.2.21) without the need 741 to establish state. 743 NOTE: The protocol developers explicitly considered whether R1 should 744 include a timestamp in order to protect the Initiator from replay 745 attacks. The decision was to NOT include a timestamp to avoid 746 problems with global time synchronization. 748 NOTE: The protocol developers explicitly considered whether a memory 749 bound function should be used for the puzzle instead of a CPU-bound 750 function. The decision was not to use memory-bound functions. 752 4.1.3. Authenticated Diffie-Hellman Protocol with DH Group Negotiation 754 The packets R1, I2, and R2 implement a standard authenticated Diffie- 755 Hellman exchange. The Responder sends one of its public Diffie- 756 Hellman keys and its public authentication key, i.e., its Host 757 Identity, in R1. The signature in the R1 packet allows the Initiator 758 to verify that the R1 has been once generated by the Responder. 759 However, since the R1 is precomputed and therefore does not cover 760 association-specific information in the I1 packet, it does not 761 protect from replay attacks. 763 Before the actual authenticated Diffie-Hellman exchange, the 764 Initiator expresses its preference regarding its choice of the DH 765 groups in the I1 packet. The preference is expressed as a sorted 766 list of DH Group IDs. The I1 packet is not protected by a signature. 767 Therefore, this list is sent in an unauthenticated way to avoid 768 costly computations for processing the I1 packet at the Responder 769 side. Based on the preferences of the Initiator, the Responder sends 770 an R1 packet containing its most suitable public DH value. The 771 Responder also attaches a list of its own preferences to the R1 to 772 convey the basis for the DH group selection to the Initiator. This 773 list is carried in the signed part of the R1 packet. If the choice 774 of the DH group value in the R1 does not match the preferences of the 775 Initiator and the Responder, the Initiator can detect that the list 776 of DH Group IDs in the I1 was manipulated (see below for details). 778 If none of the DH Group IDs in the I1 packet is supported by the 779 Responder, the Responder selects the DH Group most suitable for it 780 regardless of the Initiator's preference. It then sends the R1 781 containing this DH Group and its list of supported DH Group IDs to 782 the Initiator. 784 When the Initiator receives an R1, it receives one of the Responder's 785 public Diffie-Hellman values and the list of DH Group IDs supported 786 by the Responder. This list is covered by the signature in the R1 787 packet to avoid forgery. The Initiator compares the Group ID of the 788 public DH value in the R1 packet to the list of supported DH Group 789 IDs in the R1 packets and to its own preferences expressed in the 790 list of supported DH Group IDs. The Initiator continues the BEX only 791 if the Group ID of the public DH value of the Responder is the most 792 preferred of the IDs supported by both the Initiator and Responder. 793 Otherwise, the communication is subject of a downgrade attack and the 794 Initiator MUST either restart the base exchange with a new I1 packet 795 or abort the base exchange. If the Responder's choice of the DH 796 Group is not supported by the Initiator, the Initiator MAY abort the 797 handshake or send a new I1 packet with a different list of supported 798 DH Groups. However, the Initiator MUST verify the signature of the 799 R1 packet before restarting or aborting the handshake. It MUST 800 silently ignore the R1 packet if the signature is not valid. 802 If the preferences regarding the DH Group ID match, the Initiator 803 computes the Diffie-Hellman session key (Kij). The Initiator creates 804 a HIP association using keying material from the session key (see 805 Section 6.5), and may use the HIP association to encrypt its public 806 authentication key, i.e., the Host Identity. The resulting I2 packet 807 contains the Initiator's Diffie-Hellman key and its (optionally 808 encrypted) public authentication key. The signature of the I2 809 message covers all parameters of the signed parameter ranges (see 810 Section 5.2) in the packet without exceptions as in the R1. 812 The Responder extracts the Initiator's Diffie-Hellman public key from 813 the I2 packet, computes the Diffie-Hellman session key, creates a 814 corresponding HIP association, and decrypts the Initiator's public 815 authentication key. It can then verify the signature using the 816 authentication key. 818 The final message, R2, completes the BEX and protects the Initiator 819 against replay attacks because the Responder uses the shared key from 820 the Diffie-Hellman exchange to create an HMAC as well as uses the 821 private key of its Host Identity to sign the packet contents. 823 4.1.4. HIP Replay Protection 825 The HIP protocol includes the following mechanisms to protect against 826 malicious packet replays. Responders are protected against replays 827 of I1 packets by virtue of the stateless response to I1 packets with 828 pre-signed R1 messages. Initiators are protected against R1 replays 829 by a monotonically increasing "R1 generation counter" included in the 830 R1. Responders are protected against replays of forged I2 packets by 831 the puzzle mechanism (see Section 4.1.1 above), and optional use of 832 opaque data. Hosts are protected against replays of R2 packets and 833 UPDATEs by use of a less expensive HMAC verification preceding the 834 HIP signature verification. 836 The R1 generation counter is a monotonically increasing 64-bit 837 counter that may be initialized to any value. The scope of the 838 counter MAY be system-wide but there SHOULD be a separate counter for 839 each Host Identity, if there is more than one local host identity. 840 The value of this counter SHOULD be preserved across system reboots 841 and invocations of the HIP base exchange. This counter indicates the 842 current generation of puzzles. Implementations MUST accept puzzles 843 from the current generation and MAY accept puzzles from earlier 844 generations. A system's local counter MUST be incremented at least 845 as often as every time old R1s cease to be valid. The local counter 846 SHOULD never be decremented, otherwise the host exposes its peers to 847 the replay of previously generated, higher numbered R1s. The R1 848 counter SHOULD NOT roll over. 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 Upon conclusion of an active HIP association with another host, the 863 R1 generation counter associated with the peer host SHOULD be 864 flushed. A local policy MAY override the default flushing of R1 865 counters on a per-HIT basis. The reason for recommending the 866 flushing of this counter is that there may be hosts where the R1 867 generation counter (occasionally) decreases; e.g., due to hardware 868 failure. 870 4.1.5. Refusing a HIP Base Exchange 872 A HIP-aware host may choose not to accept a HIP base exchange. If 873 the host's policy is to only be an Initiator, it should begin its own 874 HIP base exchange. A host MAY choose to have such a policy since 875 only the privacy of the Initiator's HI is protected in the exchange. 876 It should be noted that such behavior can introduce the risk of a 877 race condition if each host's policy is to only be an Initiator, at 878 which point the HIP base exchange will fail. 880 If the host's policy does not permit it to enter into a HIP exchange 881 with the Initiator, it should send an ICMP 'Destination Unreachable, 882 Administratively Prohibited' message. A more complex HIP packet is 883 not used here as it actually opens up more potential DoS attacks than 884 a simple ICMP message. A HIP NOTIFY message is not used because no 885 HIP session exists between the two hosts at that time. 887 4.1.6. Aborting a HIP Base Exchange 889 Two HIP hosts may encounter situations in which they cannot complete 890 a HIP base exchange because of insufficient support for cryptographic 891 algorithms, in particular the HIT Suites and DH Groups. After 892 receiving the R1 packet, the Initiator can determine whether the 893 Responder supports the required cryptographic operations to 894 successfully establish a HIP association. The Initiator can abort 895 the BEX silently after receiving an R1 packet that indicates an 896 unsupported set of algorithms. The specific conditions are described 897 below. 899 The R1 packet contains a signed list of HIT Suite IDs as supported by 900 the Responder. Therefore, the Initiator can determine whether its 901 source HIT is supported by the Responder. If the HIT Suite ID of the 902 Initiator's HIT is not contained in the list of HIT Suites in the R1, 903 the Initiator MAY abort the handshake silently or MAY restart the 904 handshake with a new I1 packet that contains a source HIT supported 905 by the Responder. 907 During the Handshake, the Initiator and the Responder agree on a 908 single DH Group. The Responder selects the DH Group and its DH 909 public value in the R1 based on the list of DH Suite IDs in the I1 910 packet. If the responder supports none of the DH Groups requested by 911 the Initiator, the Responder selects an arbitrary DH and replies with 912 an R1 containing its list of supported DH Group IDs. In such case, 913 the Initiator receives an R1 packet containing the DH public value 914 for an unrequested DH Group and also the Responder's DH Group list in 915 the signed part of the R1 packet. At this point, the Initiator MAY 916 abort the handshake or MAY restart the handshake by sending a new I1 917 packet containing a selection of DH Group IDs that is supported by 918 the Responder. 920 4.1.7. HIP Downgrade Protection 922 In a downgrade attack, an attacker attempts to unnoticeably 923 manipulate the packets of an Initiator and/or a Responder to 924 influence the result of the cryptographic negotiations in the BEX to 925 its favor. As a result, the victims select weaker cryptographic 926 algorithms than they would otherwise have selected without the 927 attacker's interference. Downgrade attacks can only be successful if 928 they remain un-detected by the victims and the victims falsely assume 929 a secure communication channel. 931 In HIP, almost all packet parameters related to cryptographic 932 negotiations are covered by signatures. These parameters cannot be 933 directly manipulated in a downgrade attack without invalidating the 934 signature. However, signed packets can be subject to replay attacks. 935 In such a replay attack, the attacker could use an old BEX packet 936 with an outdated and weak selection of cryptographic algorithms and 937 replay it instead of a more recent packet with a collection of 938 stronger cryptographic algorithms. Signed packets that could be 939 subject to this replay attack are the R1 and I2 packet. However, 940 replayed R1 and I2 packets cannot be used to successfully establish a 941 HIP BEX because these packets also contain the public DH values of 942 the Initiator and the Responder. Old DH values from replayed packets 943 lead to invalid keying material and mismatching shared secrets 944 because the attacker is unable to derive valid keying material from 945 the DH public keys in the R1 and cannot generate a valid HMAC and 946 signature for a replayed I2. 948 In contrast to the first version of HIP [RFC5201],the version 2 of 949 HIP defined in this document begins the negotiation of the DH Groups 950 already in the first BEX packet, the I1. The I1 packet is, by 951 intention, not protected by a signature to avoid CPU-intensive 952 cryptographic operations for processing floods of I1 packets targeted 953 at the Responder. Hence, the list of DH Group IDs in the I1 packet 954 is vulnerable to forgery and manipulation. To thwart an unnoticed 955 manipulation of the I1 packet, the Responder chooses the DH Group 956 deterministically and includes its own list of DH Group IDs in the 957 signed part of the R1 packet. The Initiator can detect an attempted 958 downgrade attack by comparing the list of DH Group IDs in the R1 959 packet to its own preferences in the I1 packet. If the choice of the 960 DH Group in the R1 packet does not equal to the best match of the two 961 lists (the highest priority DH ID of the Responder that is present in 962 the Initiator's DH list), the Initiator can conclude that its list in 963 the I1 packet was altered by an attacker. In this case, the 964 Initiator can restart or abort the BEX. As mentioned before, the 965 detection of the downgrade attack is sufficient to prevent it. 967 4.1.8. HIP Opportunistic Mode 969 It is possible to initiate a HIP BEX even if the Responder's HI (and 970 HIT) is unknown. In this case, the initial I1 packet contains all 971 zeros as the destination HIT. This kind of connection setup is 972 called opportunistic mode. 974 The Responder may have multiple HITs due to multiple supported HIT 975 Suites. Since the Responder's HIT Suite in the opportunistic mode is 976 not determined by the destination HIT of the I1 packet, the Responder 977 can freely select a HIT of any HIT Suite. The complete set of HIT 978 Suites supported by the Initiator is not known to the Responder. 979 Therefore, the Responder SHOULD should select its HIT from the same 980 HIT Suite as the Initiator's HIT (indicated by the HIT suite 981 information in the OGA field of the Initiator's HIT) because this HIT 982 Suite is obviously supported by the Initiator. If the Responder 983 selects a different HIT that is not supported by the Initiator, the 984 Initiator MAY restart the BEX with an I1 packet with a source HIT 985 that is contained in the list of the Responder's HIT Suites in the R1 986 packet. 988 Note that the Initiator cannot verify the signature of the R1 packet 989 if the Responder's HIT Suite is not supported. Therefore, the 990 Initiator MUST treat R1 packets with unsupported Responder HITs as 991 potentially forged and MUST NOT use any parameters from the 992 unverified R1 besides the HIT Suite List. Moreover, an Initiator 993 that uses an unverified HIT Suite List from an R1 packet to determine 994 a possible source HIT MUST verify that the HIT_SUITE_LIST in the 995 first unverified R1 packet matches the HIT_SUITE_LIST in the second 996 R1 packet for which the Initiator supports the signature algorithm. 997 The Initiator MUST restart the BEX with a new I1 packet for which the 998 algorithm was mentioned in the verifiable R1 if the two lists do not 999 match. This procedure is necessary to mitigate downgrade attacks. 1001 There are both security and API issues involved with the 1002 opportunistic mode. These issues are described in the reminder of 1003 this section. 1005 Given that the Responder's HI is not known by the Initiator, there 1006 must be suitable API calls that allow the Initiator to request, 1007 directly or indirectly, that the underlying system initiates the HIP 1008 base exchange solely based on locators. The Responder's HI will be 1009 tentatively available in the R1 packet, and in an authenticated form 1010 once the R2 packet has been received and verified. Hence, the 1011 Responder's HIT could be communicated to the application via new API 1012 mechanisms. However, with a backwards-compatible API the application 1013 sees only the locators used for the initial contact. Depending on 1014 the desired semantics of the API, this can raise the following 1015 issues: 1017 o The actual locators may later change if an UPDATE message is used, 1018 even if from the API perspective the session still appears to be 1019 between two specific locators. However, the locator update is 1020 still secure and the session is still between the same nodes. 1022 o Different sessions between the same two locators may result in 1023 connections to different nodes, if the implementation no longer 1024 remembers which identifier the peer had in an earlier session. 1025 This is possible when the peer's locator has changed for 1026 legitimate reasons or when an attacker pretends to be a node that 1027 has the peer's locator. Therefore, when using opportunistic mode, 1028 HIP implementations MUST NOT place any expectation that the peer's 1029 HI returned in the R1 message matches any HI previously seen from 1030 that address. 1032 If the HIP implementation and application do not have the same 1033 understanding of what constitutes a session, this may even happen 1034 within the same session. For instance, an implementation may not 1035 know when HIP state can be purged for UDP-based applications. 1037 o As with all HIP base exchanges, the handling of locator-based or 1038 interface-based policy is unclear for HIP in opportunistic mode. 1039 An application may create a connection to a specific locator 1040 because the application has knowledge of the security properties 1041 along the network to that locator. If one of the nodes moves and 1042 the locators are updated, these security properties may not be 1043 maintained. Depending on the security policy of the application, 1044 this may be a problem. This is an area of ongoing study. As an 1045 example, there is work to create an API that applications can use 1046 to specify their security requirements in a similar context 1047 [I-D.ietf-btns-c-api]. 1049 In addition, the following security considerations apply. The 1050 generation counter mechanism will be less efficient in protecting 1051 against replays of the R1 packet, given that the Responder can choose 1052 a replay that uses an arbitrary HI, not just the one given in the I1 1053 packet. 1055 More importantly, the opportunistic exchange is vulnerable to man-in- 1056 the-middle attacks, because the Initiator does not have any public 1057 key information about the peer. To assess the impacts of this 1058 vulnerability, we compare it to vulnerabilities in current, non-HIP- 1059 capable communications. 1061 An attacker on the path between the two peers can insert itself as a 1062 man-in-the-middle by providing its own identifier to the Initiator 1063 and then initiating another HIP session towards the Responder. For 1064 this to be possible, the Initiator must employ opportunistic mode, 1065 and the Responder must be configured to accept a connection from any 1066 HIP-enabled node. 1068 An attacker outside the path will be unable to do so, given that it 1069 cannot respond to the messages in the base exchange. 1071 These security properties are characteristic also of communications 1072 in the current Internet. A client contacting a server without 1073 employing end-to-end security may find itself talking to the server 1074 via a man-in-the-middle, assuming again that the server is willing to 1075 talk to anyone. 1077 If end-to-end security is in place, then the worst that can happen in 1078 both the opportunistic HIP and non-HIP (normal IP) cases is denial- 1079 of-service; an entity on the path can disrupt communications, but 1080 will be unable to successfully insert itself as a man-in-the-middle. 1082 However, once the opportunistic exchange has successfully completed, 1083 HIP provides confidentiality and integrity protection for the 1084 communications, and can securely change the locators of the 1085 endpoints. 1087 As a result, it is believed that the HIP opportunistic mode is at 1088 least as secure as current IP. 1090 4.2. Updating a HIP Association 1092 A HIP association between two hosts may need to be updated over time. 1093 Examples include the need to rekey expiring security associations, 1094 add new security associations, or change IP addresses associated with 1095 hosts. The UPDATE packet is used for those and other similar 1096 purposes. This document only specifies the UPDATE packet format and 1097 basic processing rules, with mandatory parameters. The actual usage 1098 is defined in separate specifications. 1100 HIP provides a general purpose UPDATE packet, which can carry 1101 multiple HIP parameters, for updating the HIP state between two 1102 peers. The UPDATE mechanism has the following properties: 1104 UPDATE messages carry a monotonically increasing sequence number 1105 and are explicitly acknowledged by the peer. Lost UPDATEs or 1106 acknowledgments may be recovered via retransmission. Multiple 1107 UPDATE messages may be outstanding under certain circumstances. 1109 UPDATE is protected by both HIP_MAC and HIP_SIGNATURE parameters, 1110 since processing UPDATE signatures alone is a potential DoS attack 1111 against intermediate systems. 1113 UPDATE packets are explicitly acknowledged by the use of an 1114 acknowledgment parameter that echoes an individual sequence number 1115 received from the peer. A single UPDATE packet may contain both a 1116 sequence number and one or more acknowledgment numbers (i.e., 1117 piggybacked acknowledgment(s) for the peer's UPDATE). 1119 The UPDATE packet is defined in Section 5.3.5. 1121 4.3. Error Processing 1123 HIP error processing behavior depends on whether or not there exists 1124 an active HIP association. In general, if a HIP association exists 1125 between the sender and receiver of a packet causing an error 1126 condition, the receiver SHOULD respond with a NOTIFY packet. On the 1127 other hand, if there are no existing HIP associations between the 1128 sender and receiver, or the receiver cannot reasonably determine the 1129 identity of the sender, the receiver MAY respond with a suitable ICMP 1130 message; see Section 5.4 for more details. 1132 The HIP protocol and state machine are designed to recover from one 1133 of the parties crashing and losing its state. The following 1134 scenarios describe the main use cases covered by the design. 1136 No prior state between the two systems. 1138 The system with data to send is the Initiator. The process 1139 follows the standard four-packet base exchange, establishing 1140 the HIP association. 1142 The system with data to send has no state with the receiver, but 1143 the receiver has a residual HIP association. 1145 The system with data to send is the Initiator. The Initiator 1146 acts as in no prior state, sending an I1 packet and receiving 1147 an R1 packet. When the Responder receives a valid I2 packet, 1148 the old association is 'discovered' and deleted, and the new 1149 association is established. 1151 The system with data to send has a HIP association, but the 1152 receiver does not. 1154 The system sends data on the outbound user data security 1155 association. The receiver 'detects' the situation when it 1156 receives a user data packet that it cannot match to any HIP 1157 association. The receiving host MUST discard this packet. 1159 Optionally, the receiving host MAY send an ICMP packet, with 1160 the type Parameter Problem, to inform the sender that the HIP 1161 association does not exist (see Section 5.4), and it MAY 1162 initiate a new HIP BEX. However, responding with these 1163 optional mechanisms is implementation or policy dependent. 1165 4.4. HIP State Machine 1167 The HIP protocol itself has little state. In the HIP base exchange, 1168 there is an Initiator and a Responder. Once the security 1169 associations (SAs) are established, this distinction is lost. If the 1170 HIP state needs to be re-established, the controlling parameters are 1171 which peer still has state and which has a datagram to send to its 1172 peer. The following state machine attempts to capture these 1173 processes. 1175 The state machine is symmetric and is presented in a single system 1176 view, representing either an Initiator or a Responder. The state 1177 machine is not a full representation of the processing logic. 1178 Additional processing rules are presented in the packet definitions. 1179 Hence, both are needed to completely implement HIP. 1181 This document extends the state machine as defined in [RFC5201] and 1182 introduces a restart option to allow for the negotiation of 1183 cryptographic algorithms. The extension to the previous state 1184 machine in [RFC5201] is a transition from state I1-SENT to I1-SENT - 1185 the restart option. An Initiator is required to restart the HIP base 1186 exchange if the Responder does not support the HIT Suite of the 1187 Initiator. In this case, the Initiator restarts the HIP base 1188 exchange by sending a new I1 packet with a source HIT supported by 1189 the Responder. 1191 Implementors must understand that the state machine, as described 1192 here, is informational. Specific implementations are free to 1193 implement the actual processing logic differently. Section 6 1194 describes the packet processing rules in more detail. This state 1195 machine focuses on the HIP I1, R1, I2, and R2 packets only. New 1196 states and state transitions may be introduced by mechanisms in other 1197 specifications (such as mobility and multihoming). 1199 4.4.1. State Machine Terminology 1201 Unused Association Lifetime (UAL): Implementation-specific time for 1202 which, if no packet is sent or received for this time interval, a 1203 host MAY begin to tear down an active HIP association. 1205 Maximum Segment Lifetime (MSL): Maximum time that a TCP segment is 1206 expected to spend in the network. 1208 Exchange Complete (EC): Time that the host spends at the R2-SENT 1209 state before it moves to the ESTABLISHED state. The time is n * 1210 I2 retransmission timeout, where n is about I2_RETRIES_MAX. 1212 Receive ANYOTHER: Any received packet for which no state 1213 transitions or processing rules are defined for a given state. 1215 4.4.2. HIP States 1217 +---------------------+---------------------------------------------+ 1218 | State | Explanation | 1219 +---------------------+---------------------------------------------+ 1220 | UNASSOCIATED | State machine start | 1221 | | | 1222 | I1-SENT | Initiating base exchange | 1223 | | | 1224 | I2-SENT | Waiting to complete base exchange | 1225 | | | 1226 | R2-SENT | Waiting to complete base exchange | 1227 | | | 1228 | ESTABLISHED | HIP association established | 1229 | | | 1230 | CLOSING | HIP association closing, no data can be | 1231 | | sent | 1232 | | | 1233 | CLOSED | HIP association closed, no data can be sent | 1234 | | | 1235 | E-FAILED | HIP base exchange failed | 1236 +---------------------+---------------------------------------------+ 1238 Table 1: HIP States 1240 4.4.3. HIP State Processes 1241 System behavior in state UNASSOCIATED, Table 2. 1243 +---------------------+---------------------------------------------+ 1244 | Trigger | Action | 1245 +---------------------+---------------------------------------------+ 1246 | User data to send, | Send I1 and go to I1-SENT | 1247 | requiring a new HIP | | 1248 | association | | 1249 | | | 1250 | Receive I1 | Send R1 and stay at UNASSOCIATED | 1251 | | | 1252 | Receive I2, process | If successful, send R2 and go to R2-SENT | 1253 | | | 1254 | | If fail, stay at UNASSOCIATED | 1255 | | | 1256 | Receive user data | Optionally send ICMP as defined in | 1257 | for an unknown HIP | Section 5.4 and stay at UNASSOCIATED | 1258 | association | | 1259 | | | 1260 | Receive CLOSE | Optionally send ICMP Parameter Problem and | 1261 | | stay at UNASSOCIATED | 1262 | | | 1263 | Receive ANYOTHER | Drop and stay at UNASSOCIATED | 1264 +---------------------+---------------------------------------------+ 1266 Table 2: UNASSOCIATED - Start state 1268 System behavior in state I1-SENT, Table 3. 1270 +---------------------+---------------------------------------------+ 1271 | Trigger | Action | 1272 +---------------------+---------------------------------------------+ 1273 | Receive I1 from | If the local HIT is smaller than the peer | 1274 | Responder | HIT, drop I1 and stay at I1-SENT (see | 1275 | | Section 6.5 for HIT comparison) | 1276 | | | 1277 | | If the local HIT is greater than the peer | 1278 | | HIT, send R1 and stay at I1-SENT | 1279 | | | 1280 | Receive I2, process | If successful, send R2 and go to R2-SENT | 1281 | | | 1282 | | If fail, stay at I1-SENT | 1283 | | | 1284 | Receive R1, process | If the HIT Suite of the local HIT is not | 1285 | | supported by the peer, select supported | 1286 | | local HIT, send I1 and stay at I1-SENT | 1287 | | | 1288 | | If successful, send I2 and go to I2-SENT | 1289 | | | 1290 | | If fail, stay at I1-SENT | 1291 | | | 1292 | Receive ANYOTHER | Drop and stay at I1-SENT | 1293 | | | 1294 | Timeout | Increment timeout counter | 1295 | | | 1296 | | If counter is less than I1_RETRIES_MAX, | 1297 | | send I1 and stay at I1-SENT | 1298 | | | 1299 | | If counter is greater than I1_RETRIES_MAX, | 1300 | | go to E-FAILED | 1301 +---------------------+---------------------------------------------+ 1303 Table 3: I1-SENT - Initiating the HIP Base Exchange 1305 System behavior in state I2-SENT, Table 4. 1307 +---------------------+---------------------------------------------+ 1308 | Trigger | Action | 1309 +---------------------+---------------------------------------------+ 1310 | Receive I1 | Send R1 and stay at I2-SENT | 1311 | | | 1312 | Receive R1, process | If successful, send I2 and stay at I2-SENT | 1313 | | | 1314 | | If fail, stay at I2-SENT | 1315 | | | 1316 | Receive I2, process | If successful and local HIT is smaller than | 1317 | | the peer HIT, drop I2 and stay at I2-SENT | 1318 | | | 1319 | | If successful and local HIT is greater than | 1320 | | the peer HIT, send R2 and go to R2-SENT | 1321 | | | 1322 | | If fail, stay at I2-SENT | 1323 | | | 1324 | Receive R2, process | If successful, go to ESTABLISHED | 1325 | | | 1326 | | If fail, stay at I2-SENT | 1327 | | | 1328 | Receive CLOSE, | If successful, send CLOSE_ACK and go to | 1329 | process | CLOSED | 1330 | | | 1331 | | If fail, stay at I2-SENT | 1332 | | | 1333 | Receive ANYOTHER | Drop and stay at I2-SENT | 1334 | | | 1335 | Timeout | Increment timeout counter | 1336 | | | 1337 | | If counter is less than I2_RETRIES_MAX, | 1338 | | send I2 and stay at I2-SENT | 1339 | | | 1340 | | If counter is greater than I2_RETRIES_MAX, | 1341 | | go to E-FAILED | 1342 +---------------------+---------------------------------------------+ 1344 Table 4: I2-SENT - Waiting to finish the HIP Base Exchange 1346 System behavior in state R2-SENT, Table 5. 1348 +---------------------+---------------------------------------------+ 1349 | Trigger | Action | 1350 +---------------------+---------------------------------------------+ 1351 | Receive I1 | Send R1 and stay at R2-SENT | 1352 | | | 1353 | Receive I2, process | If successful, send R2 and stay at R2-SENT | 1354 | | | 1355 | | If fail, stay at R2-SENT | 1356 | | | 1357 | Receive R1 | Drop and stay at R2-SENT | 1358 | | | 1359 | Receive R2 | Drop and stay at R2-SENT | 1360 | | | 1361 | Receive data or | Move to ESTABLISHED | 1362 | UPDATE | | 1363 | | | 1364 | Exchange Complete | Move to ESTABLISHED | 1365 | Timeout | | 1366 | | | 1367 | Receive CLOSE, | If successful, send CLOSE_ACK and go to | 1368 | process | CLOSED | 1369 | | | 1370 | | If fail, stay at ESTABLISHED | 1371 | | | 1372 | Receive CLOSE_ACK | Drop and stay at R2-SENT | 1373 | | | 1374 | Receive NOTIFY | Process and stay at R2-SENT | 1375 +---------------------+---------------------------------------------+ 1377 Table 5: R2-SENT - Waiting to finish HIP 1379 System behavior in state ESTABLISHED, Table 6. 1381 +---------------------+---------------------------------------------+ 1382 | Trigger | Action | 1383 +---------------------+---------------------------------------------+ 1384 | Receive I1 | Send R1 and stay at ESTABLISHED | 1385 | | | 1386 | Receive I2 | Process with puzzle and possible Opaque | 1387 | | data verification | 1388 | | | 1389 | | If successful, send R2, drop old HIP | 1390 | | association, establish a new HIP | 1391 | | association and go to R2-SENT | 1392 | | | 1393 | | If fail, stay at ESTABLISHED | 1394 | | | 1395 | Receive R1 | Drop and stay at ESTABLISHED | 1396 | | | 1397 | Receive R2 | Drop and stay at ESTABLISHED | 1398 | | | 1399 | Receive user data | Process and stay at ESTABLISHED | 1400 | for HIP association | | 1401 | | | 1402 | No packet | Send CLOSE and go to CLOSING | 1403 | sent/received | | 1404 | during UAL minutes | | 1405 | | | 1406 | Receive UPDATE | Process and stay at ESTABLISHED | 1407 | | | 1408 | Receive CLOSE, | If successful, send CLOSE_ACK and go to | 1409 | process | CLOSED | 1410 | | | 1411 | | If fail, stay at ESTABLISHED | 1412 | | | 1413 | Receive CLOSE_ACK | Drop and stay at ESTABLISHED | 1414 | | | 1415 | Receive NOTIFY | Process and stay at ESTABLISHED | 1416 +---------------------+---------------------------------------------+ 1418 Table 6: ESTABLISHED - HIP association established 1420 System behavior in state CLOSING, Table 7. 1422 +---------------------+---------------------------------------------+ 1423 | Trigger | Action | 1424 +---------------------+---------------------------------------------+ 1425 | User data to send, | Send I1 and stay at CLOSING | 1426 | requires the | | 1427 | creation of another | | 1428 | incarnation of the | | 1429 | HIP association | | 1430 | | | 1431 | Receive I1 | Send R1 and stay at CLOSING | 1432 | | | 1433 | Receive I2, process | If successful, send R2 and go to R2-SENT | 1434 | | | 1435 | | If fail, stay at CLOSING | 1436 | | | 1437 | Receive R1, process | If successful, send I2 and go to I2-SENT | 1438 | | | 1439 | | If fail, stay at CLOSING | 1440 | | | 1441 | Receive CLOSE, | If successful, send CLOSE_ACK, discard | 1442 | process | state and go to CLOSED | 1443 | | | 1444 | | If fail, stay at CLOSING | 1445 | | | 1446 | Receive CLOSE_ACK, | If successful, discard state and go to | 1447 | process | UNASSOCIATED | 1448 | | | 1449 | | If fail, stay at CLOSING | 1450 | | | 1451 | Receive ANYOTHER | Drop and stay at CLOSING | 1452 | | | 1453 | Timeout | Increment timeout sum and reset timer. If | 1454 | | timeout sum is less than UAL+MSL minutes, | 1455 | | retransmit CLOSE and stay at CLOSING | 1456 | | | 1457 | | If timeout sum is greater than UAL+MSL | 1458 | | minutes, go to UNASSOCIATED | 1459 +---------------------+---------------------------------------------+ 1461 Table 7: CLOSING - HIP association has not been used for UAL minutes 1462 System behavior in state CLOSED, Table 8. 1464 +---------------------+---------------------------------------------+ 1465 | Trigger | Action | 1466 +---------------------+---------------------------------------------+ 1467 | Datagram to send, | Send I1, and stay at CLOSED | 1468 | requires the | | 1469 | creation of another | | 1470 | incarnation of the | | 1471 | HIP association | | 1472 | | | 1473 | Receive I1 | Send R1 and stay at CLOSED | 1474 | | | 1475 | Receive I2, process | If successful, send R2 and go to R2-SENT | 1476 | | | 1477 | | If fail, stay at CLOSED | 1478 | | | 1479 | Receive R1, process | If successful, send I2 and go to I2-SENT | 1480 | | | 1481 | | If fail, stay at CLOSED | 1482 | | | 1483 | Receive CLOSE, | If successful, send CLOSE_ACK, stay at | 1484 | process | CLOSED | 1485 | | | 1486 | | If fail, stay at CLOSED | 1487 | | | 1488 | Receive CLOSE_ACK, | If successful, discard state and go to | 1489 | process | UNASSOCIATED | 1490 | | | 1491 | | If fail, stay at CLOSED | 1492 | | | 1493 | Receive ANYOTHER | Drop and stay at CLOSED | 1494 | | | 1495 | Timeout (UAL+2MSL) | Discard state, and go to UNASSOCIATED | 1496 +---------------------+---------------------------------------------+ 1498 Table 8: CLOSED - CLOSE_ACK sent, resending CLOSE_ACK if necessary 1500 System behavior in state E-FAILED, Table 9. 1502 +-------------------------+-----------------------------------------+ 1503 | Trigger | Action | 1504 +-------------------------+-----------------------------------------+ 1505 | Wait for | Go to UNASSOCIATED. Re-negotiation is | 1506 | implementation-specific | possible after moving to UNASSOCIATED | 1507 | time | state. | 1508 +-------------------------+-----------------------------------------+ 1509 Table 9: E-FAILED - HIP failed to establish association with peer 1511 4.4.4. Simplified HIP State Diagram 1513 The following diagram (Figure 2) shows the major state transitions. 1514 Transitions based on received packets implicitly assume that the 1515 packets are successfully authenticated or processed. 1517 +--+ +----------------------------+ 1518 recv I1, send R1 | | | | 1519 | v v | 1520 +--------------+ recv I2, send R2 | 1521 +----------------| UNASSOCIATED |----------------+ | 1522 datagram| +--+ +--------------+ | | 1523 to send,| | | Alg. not supported, | | 1524 send I1| | | send I1 | | 1525 v | v | | 1526 +---------+ recv I2, send R2 | | 1527 +---->| I1-SENT |--------------------------------------+ | | 1528 | +---------+ +----------------------+ | | | 1529 | | recv R2, | recv I2, send R2 | | | | 1530 | v send I2 | v v v | 1531 | +---------+ | +---------+ | 1532 | +--->| I2-SENT |----------+ +--------------| R2-SENT |<---+ | 1533 | | +---------+ | +---------+ | | 1534 | | | |recv R2 | data or| | | 1535 | |recv R1, | | | EC timeout| | | 1536 | |send I2 +--|-----------------+ | receive I2,| | 1537 | | | | +-------------+ | send R2| | 1538 | | | +------>| ESTABLISHED |<----------+ | | 1539 | | | +-------------+ | | 1540 | | | | | | receive I2, send R2 | | 1541 | | +------------+ | +-------------------------------+ | 1542 | | | +-----------+ | | 1543 | | | no packet sent/received| +---+ | | 1544 | | | for UAL min, send CLOSE| | |timeout | | 1545 | | | v v |(UAL+MSL) | | 1546 | | | +---------+ |retransmit | | 1547 +--|----------|------------------------| CLOSING |-+CLOSE | | 1548 | | +---------+ | | 1549 | | | | | | | | 1550 +----------|-------------------------+ | | +----------------+ | 1551 | | +-----------+ +------------------|--+ 1552 | | |recv CLOSE, recv CLOSE_ACK | | 1553 | +-------------+ |send CLOSE_ACK or timeout | | 1554 | recv CLOSE, | | (UAL+MSL) | | 1555 | send CLOSE_ACK v v | | 1556 | +--------+ receive I2, send R2 | | 1557 +---------------------| CLOSED |------------------------------+ | 1558 +--------+ | 1559 ^ | | | 1560 recv CLOSE, send CLOSE_ACK| | | timeout (UAL+2MSL) | 1561 +-+ +------------------------------------+ 1563 Figure 2 1565 4.5. User Data Considerations 1567 4.5.1. TCP and UDP Pseudo-Header Computation for User Data 1569 When computing TCP and UDP checksums on user data packets that flow 1570 through sockets bound to HITs, the IPv6 pseudo-header format 1571 [RFC2460] MUST be used, even if the actual addresses in the header of 1572 the packet are IPv4 addresses. Additionally, the HITs MUST be used 1573 in place of the IPv6 addresses in the IPv6 pseudo-header. Note that 1574 the pseudo-header for actual HIP payloads is computed differently; 1575 see Section 5.1.1. 1577 4.5.2. Sending Data on HIP Packets 1579 Other documents may define how to include user data in various HIP 1580 packets. However, currently the HIP header is a terminal header, and 1581 not followed by any other headers. 1583 4.5.3. Transport Formats 1585 The actual data transmission format, used for user data after the HIP 1586 base exchange, is not defined in this document. Such transport 1587 formats and methods are described in separate specifications. All 1588 HIP implementations MUST implement, at minimum, the ESP transport 1589 format for HIP [I-D.ietf-hip-rfc5202-bis]. The transport format to 1590 be chosen is negotiated in the base exchange. The Responder 1591 expresses its preference of the transport format in the 1592 TRANSPORT_FORMAT_LIST in the R1 packet and the Initiator selects one 1593 transform and adds the respective HIP parameter to the I2 packet. 1595 4.5.4. Reboot, Timeout, and Restart of HIP 1597 Simulating a loss of state is a potential DoS attack. The following 1598 process has been crafted to manage state recovery without presenting 1599 a DoS opportunity. 1601 If a host reboots or the HIP association times out, it has lost its 1602 HIP state. If the host that lost state has a datagram to send to the 1603 peer, it simply restarts the HIP base exchange. After the base 1604 exchange has completed, the Initiator can create a new payload 1605 association and start sending data. The peer does not reset its 1606 state until it receives a valid I2 packet. 1608 If a system receives a user data packet that cannot be matched to any 1609 existing HIP association, it is possible that it has lost the state 1610 and its peer has not. It MAY send an ICMP packet with the Parameter 1611 Problem type, and with the pointer pointing to the referred HIP- 1612 related association information. Reacting to such traffic depends on 1613 the implementation and the environment where the implementation is 1614 used. 1616 If the host, that apparently has lost its state, decides to restart 1617 the HIP base exchange, it sends an I1 packet to the peer. After the 1618 base exchange has been completed successfully, the Initiator can 1619 create a new HIP association and the peer drops its old payload 1620 associations and creates a new one. 1622 4.6. Certificate Distribution 1624 This document does not define how to use certificates or how to 1625 transfer them between hosts. These functions are expected to be 1626 defined in a future specification as for HIP Version 1 1627 [I-D.ietf-hip-cert]. A parameter type value, meant to be used for 1628 carrying certificates, is reserved, though: CERT, Type 768; see 1629 Section 5.2. 1631 5. Packet Formats 1633 5.1. Payload Format 1635 All HIP packets start with a fixed header. 1637 0 1 2 3 1638 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 1639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1640 | Next Header | Header Length |0| Packet Type |Version| RES.|1| 1641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1642 | Checksum | Controls | 1643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1644 | Sender's Host Identity Tag (HIT) | 1645 | | 1646 | | 1647 | | 1648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1649 | Receiver's Host Identity Tag (HIT) | 1650 | | 1651 | | 1652 | | 1653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1654 | | 1655 / HIP Parameters / 1656 / / 1657 | | 1658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1659 The HIP header is logically an IPv6 extension header. However, this 1660 document does not describe processing for Next Header values other 1661 than decimal 59, IPPROTO_NONE, the IPv6 'no next header' value. 1662 Future documents MAY define behavior for also other values. However, 1663 current implementations MUST ignore trailing data if an unimplemented 1664 Next Header value is received. 1666 The Header Length field contains the combined length of the HIP 1667 Header and HIP parameters in 8-byte units, excluding the first 8 1668 bytes. Since all HIP headers MUST contain the sender's and 1669 receiver's HIT fields, the minimum value for this field is 4, and 1670 conversely, the maximum length of the HIP Parameters field is 1671 (255*8)-32 = 2008 bytes. Note: this sets an additional limit for 1672 sizes of parameters included in the Parameters field, independent of 1673 the individual parameter maximum lengths. 1675 The Packet Type indicates the HIP packet type. The individual packet 1676 types are defined in the relevant sections. If a HIP host receives a 1677 HIP packet that contains an unrecognized packet type, it MUST drop 1678 the packet. 1680 The HIP Version field is four bits. The version defined in this 1681 document is 2. The version number is expected to be incremented only 1682 if there are incompatible changes to the protocol. Most extensions 1683 can be handled by defining new packet types, new parameter types, or 1684 new Controls (see Section 5.1.2) . 1686 The following three bits are reserved for future use. They MUST be 1687 zero when sent, and they SHOULD be ignored when handling a received 1688 packet. 1690 The two fixed bits in the header are reserved for SHIM6 compatibility 1691 [RFC5533], Section 5.3. For implementations adhering (only) to this 1692 specification, they MUST be set as shown when sending and MUST be 1693 ignored when receiving. This is to ensure optimal forward 1694 compatibility. Note that for implementations that implement other 1695 compatible specifications in addition to this specification, the 1696 corresponding rules may well be different. For example, an 1697 implementation that implements both this specification and the SHIM6 1698 protocol may need to check these bits in order to determine how to 1699 handle the packet. 1701 The HIT fields are always 128 bits (16 bytes) long. 1703 5.1.1. Checksum 1705 Since the checksum covers the source and destination addresses in the 1706 IP header, it MUST be recomputed on HIP-aware NAT devices. 1708 If IPv6 is used to carry the HIP packet, the pseudo-header [RFC2460] 1709 contains the source and destination IPv6 addresses, HIP packet length 1710 in the pseudo-header length field, a zero field, and the HIP protocol 1711 number (see Section 4) in the Next Header field. The length field is 1712 in bytes and can be calculated from the HIP header length field: (HIP 1713 Header Length + 1) * 8. 1715 In case of using IPv4, the IPv4 UDP pseudo-header format [RFC0768] is 1716 used. In the pseudo-header, the source and destination addresses are 1717 those used in the IP header, the zero field is obviously zero, the 1718 protocol is the HIP protocol number (see Section 4), and the length 1719 is calculated as in the IPv6 case. 1721 5.1.2. HIP Controls 1723 The HIP Controls field conveys information about the structure of the 1724 packet and capabilities of the host. 1726 The following fields have been defined: 1728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1729 | | | | | | | | | | | | | | | |A| 1730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1732 A - Anonymous: If this is set, the sender's HI in this packet is 1733 anonymous, i.e., one not listed in a directory. Anonymous HIs 1734 SHOULD NOT be stored. This control is set in packets using 1735 anonymous sender HIs. The peer receiving an anonymous HI in an R1 1736 or I2 may choose to refuse it. 1738 The rest of the fields are reserved for future use and MUST be set to 1739 zero in sent packets and ignored in received packets. 1741 5.1.3. HIP Fragmentation Support 1743 A HIP implementation MUST support IP fragmentation/reassembly. 1744 Fragment reassembly MUST be implemented in both IPv4 and IPv6, but 1745 fragment generation is REQUIRED to be implemented in IPv4 (IPv4 1746 stacks and networks will usually do this by default) and RECOMMENDED 1747 to be implemented in IPv6. In IPv6 networks, the minimum MTU is 1748 larger, 1280 bytes, than in IPv4 networks. The larger MTU size is 1749 usually sufficient for most HIP packets, and therefore fragment 1750 generation may not be needed. If a host expects to send HIP packets 1751 that are larger than the minimum IPv6 MTU, it MUST implement fragment 1752 generation even for IPv6. 1754 In IPv4 networks, HIP packets may encounter low MTUs along their 1755 routed path. Since basic HIP, as defined in this document, does not 1756 provide a mechanism to use multiple IP datagrams for a single HIP 1757 packet, support for path MTU discovery does not bring any value to 1758 HIP in IPv4 networks. HIP-aware NAT devices SHOULD perform IPv4 1759 reassembly/fragmentation for HIP control packets. 1761 All HIP implementations have to be careful while employing a 1762 reassembly algorithm so that the algorithm is sufficiently resistant 1763 to DoS attacks. 1765 Certificate chains can cause the packet to be fragmented and 1766 fragmentation can open implementations to denial-of-service attacks 1767 [KAU03]. "Hash and URL" schemes as defined in [I-D.ietf-hip-cert] 1768 for HIP version 1 may be used to avoid fragmentation and mitigate 1769 resulting DoS attacks. 1771 5.2. HIP Parameters 1773 The HIP parameters carry information that is necessary for 1774 establishing and maintaining a HIP association. For example, the 1775 peer's public keys as well as the signaling for negotiating ciphers 1776 and payload handling are encapsulated in HIP parameters. Additional 1777 information, meaningful for end-hosts or middleboxes, may also be 1778 included in HIP parameters. The specification of the HIP parameters 1779 and their mapping to HIP packets and packet types is flexible to 1780 allow HIP extensions to define new parameters and new protocol 1781 behavior. 1783 In HIP packets, HIP parameters are ordered according to their numeric 1784 type number and encoded in TLV format. 1786 The following parameter types are currently defined. 1788 +------------------------+-------+-----------+----------------------+ 1789 | TLV | Type | Length | Data | 1790 +------------------------+-------+-----------+----------------------+ 1791 | R1_COUNTER | 129 | 12 | Puzzle generation | 1792 | | | | counter | 1793 | | | | | 1794 | PUZZLE | 257 | 12 | K and Random #I | 1795 | | | | | 1796 | SOLUTION | 321 | 20 | K, Random #I and | 1797 | | | | puzzle solution J | 1798 | | | | | 1799 | SEQ | 385 | 4 | UPDATE packet ID | 1800 | | | | number | 1801 | | | | | 1802 | ACK | 449 | variable | UPDATE packet ID | 1803 | | | | number | 1804 | | | | | 1805 | DH_GROUP_LIST | 511 | variable | Ordered list of DH | 1806 | | | | Group IDs supported | 1807 | | | | by a host | 1808 | | | | | 1809 | DIFFIE_HELLMAN | 513 | variable | public key | 1810 | | | | | 1811 | HIP_CIPHER | 579 | variable | List of HIP | 1812 | | | | encryption | 1813 | | | | algorithms | 1814 | | | | | 1815 | ENCRYPTED | 641 | variable | Encrypted part of a | 1816 | | | | HIP packet | 1817 | | | | | 1818 | HOST_ID | 705 | variable | Host Identity with | 1819 | | | | Fully-Qualified | 1820 | | | | Domain FQDN (Name) | 1821 | | | | or Network Access | 1822 | | | | Identifier (NAI) | 1823 | | | | | 1824 | HIT_SUITE_LIST | 715 | variable | Ordered list of the | 1825 | | | | HIT suites supported | 1826 | | | | by the Responder | 1827 | | | | | 1828 | CERT | 768 | variable | HI Certificate; used | 1829 | | | | to transfer | 1830 | | | | certificates. | 1831 | | | | Specified in a | 1832 | | | | separate docment. | 1833 | | | | | 1834 | NOTIFICATION | 832 | variable | Informational data | 1835 | | | | | 1836 | ECHO_REQUEST_SIGNED | 897 | variable | Opaque data to be | 1837 | | | | echoed back; signed | 1838 | | | | | 1839 | ECHO_RESPONSE_SIGNED | 961 | variable | Opaque data echoed | 1840 | | | | back by request; | 1841 | | | | signed | 1842 | | | | | 1843 | TRANSPORT_FORMAT_LIST | 2049 | Ordered | variable | 1844 | | | list of | | 1845 | | | preferred | | 1846 | | | HIP | | 1847 | | | transport | | 1848 | | | type | | 1849 | | | numbers | | 1850 | | | | | 1851 | HIP_MAC | 61505 | variable | HMAC-based message | 1852 | | | | authentication code, | 1853 | | | | with key material | 1854 | | | | from KEYMAT | 1855 | | | | | 1856 | HIP_MAC_2 | 61569 | variable | HMAC based message | 1857 | | | | authentication code, | 1858 | | | | with key material | 1859 | | | | from KEYMAT. Unlike | 1860 | | | | HIP_MAC, the HOST_ID | 1861 | | | | parameter is | 1862 | | | | included in | 1863 | | | | HIP_MAC_2 | 1864 | | | | calculation. | 1865 | | | | | 1866 | HIP_SIGNATURE_2 | 61633 | variable | Signature used in R1 | 1867 | | | | packet | 1868 | | | | | 1869 | HIP_SIGNATURE | 61697 | variable | Signature of the | 1870 | | | | packet | 1871 | | | | | 1872 | ECHO_REQUEST_UNSIGNED | 63661 | variable | Opaque data to be | 1873 | | | | echoed back; after | 1874 | | | | signature | 1875 | | | | | 1876 | ECHO_RESPONSE_UNSIGNED | 63425 | variable | Opaque data echoed | 1877 | | | | back by request; | 1878 | | | | after signature | 1879 +------------------------+-------+-----------+----------------------+ 1881 As the ordering (from lowest to highest) of HIP parameters is 1882 strictly enforced (see Section 5.2.1), the parameter type values for 1883 existing parameters have been spaced to allow for future protocol 1884 extensions. 1886 The following parameter type number ranges are defined. 1888 +---------------+---------------------------------------------------+ 1889 | Type Range | Purpose | 1890 +---------------+---------------------------------------------------+ 1891 | 0 - 1023 | Handshake | 1892 | | | 1893 | 1024 - 2047 | Reserved | 1894 | | | 1895 | 2048 - 4095 | Parameters related to HIP transport formats | 1896 | | | 1897 | 4096 - 8191 | Signed parameters allocated through specification | 1898 | | documents | 1899 | | | 1900 | 8192 - 32767 | Reserved | 1901 | | | 1902 | 32768 - 49151 | Free for experimentation. Signed parameters. | 1903 | | | 1904 | 41952 - 61439 | Reserved | 1905 | | | 1906 | 61440 - 64443 | Signatures and (signed) MACs | 1907 | | | 1908 | 62464 - 63487 | Parameters that are neither signed nor MACed | 1909 | | | 1910 | 63488 - 64511 | Rendezvous and relaying | 1911 | | | 1912 | 64512 - 65023 | Parameters that are neither signed nor MACed | 1913 | | | 1914 | 65024 - 65535 | Reserved | 1915 +---------------+---------------------------------------------------+ 1917 The process for defining new parameters is described in Section 5.2.2 1918 of this document. 1920 The range between 32768 (2^15) and 49151 (2^15 + 2^14) are free for 1921 experimentation. Types from this range SHOULD be selected in a 1922 random fashion to reduce the probability of collisions. 1924 5.2.1. TLV Format 1926 The TLV-encoded parameters are described in the following 1927 subsections. The type-field value also describes the order of these 1928 fields in the packet. The parameters MUST be included in the packet 1929 so that their types form an increasing order. If multiple parameters 1930 with the same type number are in one packet, the parameters with the 1931 same type MUST be consecutive in the packet. If the order does not 1932 follow this rule, the packet is considered to be malformed and it 1933 MUST be discarded. 1935 Parameters using type values from 2048 up to 4095 are related to 1936 transport formats. Currently, one transport format is defined: the 1937 ESP transport format [I-D.ietf-hip-rfc5202-bis]. 1939 All of the encoded TLV parameters have a length (that includes the 1940 Type and Length fields), which is a multiple of 8 bytes. When 1941 needed, padding MUST be added to the end of the parameter so that the 1942 total length is a multiple of 8 bytes. This rule ensures proper 1943 alignment of data. Any added padding bytes MUST be zeroed by the 1944 sender, and their values SHOULD NOT be checked by the receiver. 1946 The Length field indicates the length of the Contents field (in 1947 bytes). Consequently, the total length of the TLV parameter 1948 (including Type, Length, Contents, and Padding) is related to the 1949 Length field according to the following formula: 1951 Total Length = 11 + Length - (Length + 3) % 8; 1953 where % is the modulo operator 1955 0 1 2 3 1956 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 1957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1958 | Type |C| Length | 1959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1960 | | 1961 / Contents / 1962 / +-+-+-+-+-+-+-+-+ 1963 | | Padding | 1964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1966 Type Type code for the parameter. 16 bits long, C-bit 1967 being part of the Type code. 1968 C Critical. One if this parameter is critical, and 1969 MUST be recognized by the recipient, zero otherwise. 1970 The C bit is considered to be a part of the Type 1971 field. Consequently, critical parameters are always 1972 odd and non-critical ones have an even value. 1973 Length Length of the Contents, in bytes excluding Type, 1974 Length, and Padding. 1975 Contents Parameter specific, defined by Type 1976 Padding Padding, 0-7 bytes, added if needed 1978 Critical parameters (indicated by the odd type number) MUST be 1979 recognized by the recipient. If a recipient encounters a critical 1980 parameter that it does not recognize, it MUST NOT process the packet 1981 any further. It MAY send an ICMP or NOTIFY, as defined in 1982 Section 4.3. 1984 Non-critical parameters MAY be safely ignored. If a recipient 1985 encounters a non-critical parameter that it does not recognize, it 1986 SHOULD proceed as if the parameter was not present in the received 1987 packet. 1989 5.2.2. Defining New Parameters 1991 Future specifications may define new parameters as needed. When 1992 defining new parameters, care must be taken to ensure that the 1993 parameter type values are appropriate and leave suitable space for 1994 other future extensions. One must remember that the parameters MUST 1995 always be arranged in numerically increasing order by Type code, 1996 thereby limiting the order of parameters (see Section 5.2.1). 1998 The following rules MUST be followed when defining new parameters. 2000 1. The low-order bit C of the Type code is used to distinguish 2001 between critical and non-critical parameters. Hence, even 2002 parameter type numbers indicate non-critical parameters while odd 2003 parameter type numbers indicate critical parameters. 2005 2. A new parameter MAY be critical only if an old implementation 2006 that ignored it would cause security problems. In general, new 2007 parameters SHOULD be defined as non-critical, and expect a reply 2008 from the recipient. 2010 3. If a system implements a new critical parameter, it MUST provide 2011 the ability to set the associated feature off, such that the 2012 critical parameter is not sent at all. The configuration option 2013 MUST be well documented. Implementations operating in a mode 2014 adhering to this specification MUST disable the sending of new 2015 critical parameters by default. In other words, the management 2016 interface MUST allow vanilla standards-only mode as a default 2017 configuration setting, and MAY allow new critical payloads to be 2018 configured on (and off). 2020 4. See Section 9 for allocation rules regarding Type codes. 2022 5.2.3. R1_COUNTER 2024 0 1 2 3 2025 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 2026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2027 | Type | Length | 2028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2029 | Reserved, 4 bytes | 2030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2031 | R1 generation counter, 8 bytes | 2032 | | 2033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2035 Type 129 2036 Length 12 2037 R1 generation 2038 counter The current generation of valid puzzles 2040 The R1_COUNTER parameter contains a 64-bit unsigned integer in 2041 network-byte order, indicating the current generation of valid 2042 puzzles. The sender SHOULD increment this counter periodically. It 2043 is RECOMMENDED that the counter value is incremented at least as 2044 often as old PUZZLE values are deprecated so that SOLUTIONs to them 2045 are no longer accepted. 2047 Support for the R1_COUNTER parameter is mandatory. It SHOULD be 2048 included in the R1 (in which case, it is covered by the signature), 2049 and if present in the R1, it MUST be echoed (including the Reserved 2050 field verbatim) by the Initiator in the I2 packet. 2052 5.2.4. PUZZLE 2054 0 1 2 3 2055 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 2056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2057 | Type | Length | 2058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2059 | #K, 1 byte | Lifetime | Opaque, 2 bytes | 2060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2061 | Random #I, RHASH_len/8 bytes | 2062 / / 2063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2065 Type 257 2066 Length 4 + RHASH_len / 8 2067 #K #K is the number of verified bits 2068 Lifetime puzzle lifetime 2^(value-32) seconds 2069 Opaque data set by the Responder, indexing the puzzle 2070 Random #I random number of size RHASH_len bits 2072 Random #I is represented as a n-bit integer (where n is RHASH_len), 2073 #K and Lifetime as 8-bit integers, all in network byte order. 2075 The PUZZLE parameter contains the puzzle difficulty #K and a n-bit 2076 random integer #I. The Puzzle Lifetime indicates the time during 2077 which the puzzle solution is valid, and sets a time limit that should 2078 not be exceeded by the Initiator while it attempts to solve the 2079 puzzle. The lifetime is indicated as a power of 2 using the formula 2080 2^(Lifetime-32) seconds. A puzzle MAY be augmented with an 2081 ECHO_REQUEST_SIGNED or an ECHO_REQUEST_UNSIGNED parameter included in 2082 the R1; the contents of the echo request are then echoed back in the 2083 ECHO_RESPONSE_SIGNED or in the ECHO_RESPONSE_UNSIGNED parameter, 2084 allowing the Responder to use the included information as a part of 2085 its puzzle processing. 2087 The Opaque and Random #I field are not covered by the HIP_SIGNATURE_2 2088 parameter. 2090 5.2.5. SOLUTION 2092 0 1 2 3 2093 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 2094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2095 | Type | Length | 2096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2097 | #K, 1 byte | Reserved | Opaque, 2 bytes | 2098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2099 | Random #I, n bytes | 2100 / / 2101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2102 | Puzzle solution #J, RHASH_len/8 bytes | 2103 / / 2104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2106 Type 321 2107 Length 4 + RHASH_len /4 2108 #K #K is the number of verified bits 2109 Reserved zero when sent, ignored when received 2110 Opaque copied unmodified from the received PUZZLE 2111 parameter 2112 Random #I random number of size RHASH_len bits 2113 Puzzle solution #J random number of size RHASH_len bits 2115 Random #I and Random #J are represented as n-bit unsigned integers 2116 (where n is RHASH_len), #K as an 8-bit unsigned integer, all in 2117 network byte order. 2119 The SOLUTION parameter contains a solution to a puzzle. It also 2120 echoes back the random difficulty #K, the Opaque field, and the 2121 puzzle integer #I. 2123 5.2.6. DH_GROUP_LIST 2125 0 1 2 3 2126 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 2127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2128 | Type | Length | 2129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2130 | DH GROUP ID #1| DH GROUP ID #2| DH GROUP ID #3| DH GROUP ID #4| 2131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2132 | DH GROUP ID #n| Padding | 2133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2135 Type 511 2136 Length number of DH Group IDs 2137 DH GROUP ID defines a DH GROUP ID supported by the host. 2138 The list of IDs is ordered by preference of the 2139 host. The list of define DH Group IDs in the 2140 DIFFIE_HELLMAN parameter. Each DH Group ID is one 2141 octet long. 2143 The DH_GROUP_LIST parameter contains the list of supported DH Group 2144 IDs of a host. The Initiator sends the DH_GROUP_LIST in the I1 2145 packet, the Responder sends its own list in the signed part of the R1 2146 packet. The DH Group IDs in the DH_GROUP_LIST are listed in the 2147 order of their preference of the host sending the list. DH Group IDs 2148 that are listed first are preferred over the DH Group IDs listed 2149 later. The information in the DH_GROUP_LIST allows the Responder to 2150 select the DH group preferred by itself and supported by the 2151 Initiator. Based on the DH_GROUP_LIST in the R1 packet, the 2152 Initiator can determine if the Responder has selected the best 2153 possible choice based on the Initiator's and Responder's preferences. 2154 If the Responder's choice differs from the best choice, the Initiator 2155 can conclude that there was an attempted downgrade attack (see 2156 Section 4.1.7). 2158 When selecting the DH group for the DIFFIE_HELLMAN parameter in the 2159 R1 packet, the Responder MUST select the first DH Group ID in its 2160 DH_GROUP_LIST in the R1 packet that is compatible with one of the 2161 Suite IDs in the Initiator's DH_GROUP_LIST in the I1 packet. The 2162 Responder MUST NOT select any other DH Group ID that is contained in 2163 both lists because a downgrade attack cannot be detected then. 2165 In general, hosts SHOULD prefer stronger groups over weaker ones if 2166 the computation overhead is not prohibitively high for the intended 2167 application. 2169 5.2.7. DIFFIE_HELLMAN 2171 0 1 2 3 2172 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 2173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2174 | Type | Length | 2175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2176 | Group ID | Public Value Length | Public Value / 2177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2178 / | 2179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2180 / | Padding | 2181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2183 Type 513 2184 Length length in octets, excluding Type, Length, and 2185 Padding 2186 Group ID defines values for p and g as well as the KDF 2187 Public Value length of the following Public Value in octets 2188 Length 2189 Public Value the sender's public Diffie-Hellman key 2191 The following Group IDs have been defined: 2193 Group KDF Value 2194 Reserved 0 2195 DEPRECATED 1 2196 DEPRECATED 2 2197 1536-bit MODP group [RFC3526] HKDF [RFC5869] 3 2198 3072-bit MODP group [RFC3526] HKDF [RFC5869] 4 2199 DEPRECATED 5 2200 DEPRECATED 6 2201 NIST P-256 [RFC5903] HKDF [RFC5869] 7 2202 NIST P-384 [RFC5903] HKDF [RFC5869] 8 2203 NIST P-521 [RFC5903] HKDF [RFC5869] 9 2204 SECP160R1 [SECG] HKDF [RFC5869] 10 2206 The MODP Diffie-Hellman groups are defined in [RFC3526]. The ECDH 2207 groups 8 - 10 are defined in [RFC5903] and [RFC6090]. ECDH group 7 2208 is covered in Appendix D. 2210 The Group ID also defines the key derivation function that is to be 2211 used for deriving the symmstric keys for the HMAC and symmetric 2212 encryption from the keying material from the Diffie Hellman key 2213 exchange (see Section 6.5). 2215 A HIP implementation MUST implement Group ID 3. The 160-bit 2216 SECP160R1 group can be used when lower security is enough (e.g., web 2217 surfing) and when the equipment is not powerful enough (e.g., some 2218 PDAs). Implementations SHOULD implement Group IDs 4 and 8. 2220 To avoid unnecessary failures during the base exchange, the rest of 2221 the groups SHOULD be implemented in hosts where resources are 2222 adequate. 2224 5.2.8. HIP_CIPHER 2226 0 1 2 3 2227 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 2228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2229 | Type | Length | 2230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2231 | Cipher ID #1 | Cipher ID #2 | 2232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2233 | Cipher ID #n | Padding | 2234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2236 Type 579 2237 Length length in octets, excluding Type, Length, and 2238 Padding 2239 Cipher ID defines the cipher algorithm to be used for 2240 encrypting the contents of the ENCRYPTED parameter 2242 The following Cipher IDs are defined: 2244 Suite ID Value 2246 RESERVED 0 2247 NULL-ENCRYPT 1 ([RFC2410]) 2248 AES-128-CBC 2 ([RFC3602]) 2249 3DES-CBC 3 ([RFC2451]) 2250 AES-256-CBC 4 ([RFC3602]) 2252 The sender of a HIP_CIPHER parameter MUST make sure that there are no 2253 more than six (6) Cipher IDs in one HIP_CIPHER parameter. 2254 Conversely, a recipient MUST be prepared to handle received transport 2255 parameters that contain more than six Cipher IDs by accepting the 2256 first six Cipher IDs and dropping the rest. The limited number of 2257 transforms sets the maximum size of the HIP_CIPHER parameter. As the 2258 default configuration, the HIP_CIPHER parameter MUST contain at least 2259 one of the mandatory Cipher IDs. There MAY be a configuration option 2260 that allows the administrator to override this default. 2262 The Responder lists supported and desired Cipher IDs in order of 2263 preference in the R1, up to the maximum of six Cipher IDs. The 2264 Initiator MUST choose only one of the corresponding Cipher IDs. This 2265 Cipher ID will be used for generating the ENCRYPTED parameter. 2267 Mandatory implementation: AES-128-CBC. NULL-ENCRYPTION is included 2268 for testing purposes. 2270 5.2.9. HOST_ID 2272 0 1 2 3 2273 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 2274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2275 | Type | Length | 2276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2277 | HI Length |DI-type| DI Length | 2278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2279 | Algorithm | Host Identity / 2280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2281 / | Domain Identifier / 2282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2283 / | Padding | 2284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2286 Type 705 2287 Length length in octets, excluding Type, Length, and 2288 Padding 2289 HI Length length of the Host Identity in octets 2290 DI-type type of the following Domain Identifier field 2291 DI Length length of the Domain Identifier field in octets 2292 Algorithm index to the employed algorithm 2293 Host Identity actual Host Identity 2294 Domain Identifier the identifier of the sender 2296 The following DI-types have been defined: 2298 Type Value 2299 none included 0 2300 FQDN 1 2301 NAI 2 2303 FQDN Fully Qualified Domain Name, in binary format. 2304 NAI Network Access Identifier 2306 The format for the FQDN is defined in RFC 1035 [RFC1035] Section 3.1. 2307 The format for the NAI is defined in [RFC4282] 2309 If there is no Domain Identifier, i.e., the DI-type field is zero, 2310 the DI Length field is set to zero as well. 2312 The following HI Algorithms have been defined: 2314 Algorithm 2315 profiles Values 2317 RESERVED 0 2318 DSA 3 [RFC2536] (RECOMMENDED) 2319 RSA 5 [RFC3110] (REQUIRED) 2320 ECDSA 7 [RFC4754] (RECOMMENDED) 2321 ECDSA_LOW 9 [SECG] (RECOMMENDED) 2323 The Host Identity is derived from the DNSKEY format for RSA and DSA. 2324 For these, the Public Key field of the RDATA part from RFC 4034 2325 [RFC4034] is used. For ECC we distinguish two different profiles: 2326 ECDSA and ECDSA_LOW. ECC contains curves approved by NIST and 2327 defined in RFC 4754 [RFC4754]. ECDSA_LOW is defined for devices with 2328 low computational capabilities and uses shorter curves from SECG 2329 [SECG]. 2331 For ECDSA and ECDSA_LOW Host Identities are represented by the 2332 following fields: 2334 0 1 2 3 2335 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 2336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2337 | ECC Curve | / 2338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2339 / Public Key | 2340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2342 ECC Curve Curve label 2343 Public Key Represented in Octet-string format 2344 [RFC6090] 2346 For hosts that implement ECDSA as algorithm the following ECC curves 2347 are required: 2349 Algorithm Curve Values 2351 ECDSA RESERVED 0 2352 ECDSA NIST P-256 1 [RFC4754] 2353 ECDSA NIST P-384 2 [RFC4754] 2355 For hosts that implement the EDSA_LOW algorithm profile, the 2356 following curve is required: 2358 Algorithm Curve Values 2360 ECDSA_LOW RESERVED 0 2361 ECDSA_LOW SECP160R1 1 [SECG] 2363 5.2.10. HIT_SUITE_LIST 2365 The HIT_SUITE_LIST parameter contains a list of the supported HIT 2366 suite IDs of the Responder. The Responder sends the HIT_SUITE_LIST 2367 in the signed part of the R1 packet. Based on the HIT_SUITE_LIST, 2368 the Initiator can determine which source HITs are supported by the 2369 Responder. 2371 0 1 2 3 2372 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 2373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2374 | Type | Length | 2375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2376 | ID #1 | ID #2 | ID #3 | ID #4 | 2377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2378 | ID #n | Padding | 2379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2381 Type 715 2382 Length number of HIT Suite IDs 2383 ID defines a HIT Suite ID supported by the host. 2384 The list of IDs is ordered by preference of the 2385 host. Each HIT Suite ID is one octet long. The four 2386 higher-order bits of the ID field correspond to the 2387 HIT Suite ID in the ORCHID OGA field. The four 2388 lower-order bits are reserved and set to 0 and 2389 ignored by the receiver. 2391 The HIT Suite ID indexes a HIT Suite. HIT Suites are composed of 2392 signature algorithms as defined in Section 5.2.9 and hash functions. 2394 The ID field in the HIT_SUITE_LIST is defined as eight-bit field as 2395 opposed to the four-bit HIT Suite ID and OGA field in the ORCHID. 2396 This difference is a measure to accommodate larger HIT Suite IDs if 2397 the 16 available values prove insufficient. In that case, one of the 2398 16 values, zero, will be used to indicate that four additional bits 2399 of the ORCHID will be used to encode the HIT Suite ID. Hence, the 2400 current four-bit HIT Suite-IDs only use the four higher order bits in 2401 the ID field. Future documents may define the use of the four lower- 2402 order bits in the ID field. 2404 The following HIT Suites ID are defined: 2406 HIT Suite ID 2407 RESERVED 0 2408 RSA,DSA/SHA-1 1 (REQUIRED) 2409 ECDSA/SHA-384 2 (RECOMMENDED) 2410 ECDSA_LOW/SHA-1 3 (RECOMMENDED) 2412 5.2.11. TRANSPORT_FORMAT_LIST 2414 The TRANSPORT_FORMAT_LIST parameter contains a list of the supported 2415 HIP transport formats (TFs) of the Responder. The Responder sends 2416 the TRANSPORT_FORMAT_LIST in the signed part of the R1 packet. Based 2417 on the TRANSPORT_FORMAT_LIST, the Initiator chooses one suitable 2418 transport format and includes the respective HIP transport format 2419 parameter in its response packet. 2421 0 1 2 3 2422 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 2423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2424 | Type | Length | 2425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2426 | TF type #1 | TF type #2 / 2427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2428 / TF type #n | Padding | 2429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2431 Type 2049 2432 Length 2x number of TF types 2433 TF Type defines a transport format (TF) type supported by the 2434 host. The TF type numbers correspond to the HIP 2435 parameter type numbers of the respective transform 2436 parameters. The list of TF types is ordered by preference 2437 of the sender 2439 The TF type numbers index the respective HIP parameters for the 2440 transport formats in the type number range between 2050 to 4095. The 2441 parameters and their use is defined in separate documents. 2442 Currently, the only transport format defined is IPsec ESP 2443 [I-D.ietf-hip-rfc5202-bis]. 2445 For each listed TF type, the sender of the parameter MUST include the 2446 repective transport form parameter in the HIP packet. The TF type in 2447 the TRANSPORT_FORM_LIST MUST be ignored if no matching transport form 2448 parameter is present in the packet. 2450 5.2.12. HIP_MAC 2452 0 1 2 3 2453 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 2454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2455 | Type | Length | 2456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2457 | | 2458 | HMAC | 2459 / / 2460 / +-------------------------------+ 2461 | | Padding | 2462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2464 Type 61505 2465 Length length in octets, excluding Type, Length, and 2466 Padding 2467 HMAC HMAC computed over the HIP packet, excluding the 2468 HIP_MAC parameter and any following parameters, such 2469 as HIP_SIGNATURE, HIP_SIGNATURE_2, 2470 ECHO_REQUEST_UNSIGNED, or ECHO_RESPONSE_UNSIGNED. 2471 The checksum field MUST be set to zero and the HIP 2472 header length in the HIP common header MUST be 2473 calculated not to cover any excluded parameters 2474 when the HMAC is calculated. The size of the 2475 HMAC is the natural size of the hash computation 2476 output depending on the used hash function. 2478 The HMAC uses RHASH as hash algorithm. The calculation and 2479 verification process is presented in Section 6.4.1. 2481 5.2.13. HIP_MAC_2 2483 The HIP_MAC_2 is a MAC of the packet and the HOST_ID parameter of the 2484 sender while only the packet without HOST_ID of the sender is sent. 2485 The parameter structure is the same as in Section 5.2.12. The fields 2486 are: 2488 Type 61569 2489 Length length in octets, excluding Type, Length, and 2490 Padding 2491 HMAC HMAC computed over the HIP packet, excluding the 2492 HIP_MAC_2 parameter and any following parameters 2493 such as HIP_SIGNATURE, HIP_SIGNATURE_2, 2494 ECHO_REQUEST_UNSIGNED, or ECHO_RESPONSE_UNSIGNED, 2495 and including an additional sender's HOST_ID 2496 parameter during the HMAC calculation. The checksum 2497 field MUST be set to zero and the HIP header length 2498 in the HIP common header MUST be calculated not to 2499 cover any excluded parameters when the HMAC is 2500 calculated. The size of the HMAC is the natural 2501 size of the hash computation output depending on the 2502 used hash function. 2504 The HMAC uses RHASH as hash algorithm. The calculation and 2505 verification process is presented in Section 6.4.1. 2507 5.2.14. HIP_SIGNATURE 2509 0 1 2 3 2510 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 2511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2512 | Type | Length | 2513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2514 | SIG alg | Signature / 2515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2516 / | Padding | 2517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2519 Type 61697 2520 Length length in octets, excluding Type, Length, and 2521 Padding 2522 SIG alg signature algorithm 2523 Signature the signature is calculated over the HIP packet, 2524 excluding the HIP_SIGNATURE parameter and any 2525 parameters that follow the HIP_SIGNATURE parameter. 2526 When the signature is calculated the checksum field 2527 MUST be set to zero, and the HIP header length in 2528 the HIP common header MUST be calculated only up to 2529 the beginning of the HIP_SIGNATURE parameter. 2531 The signature algorithms are defined in Section 5.2.9. The signature 2532 in the Signature field is encoded using the method depending on the 2533 signature algorithm (e.g., according to [RFC3110] in case of RSA/ 2534 SHA-1, according to [RFC5702] in case of RSA/SHA-256, according to 2535 [RFC2536] in case of DSA, or according to [RFC6090] in case of 2536 ECDSA). 2538 The HIP_SIGNATURE calculation and verification process are presented 2539 in Section 6.4.2. 2541 5.2.15. HIP_SIGNATURE_2 2543 The HIP_SIGNATURE_2 excludes the variable parameters in the R1 packet 2544 to allow R1 pre-creation. The parameter structure is the same as in 2545 Section 5.2.14. The fields are: 2547 Type 61633 2548 Length length in octets, excluding Type, Length, and 2549 Padding 2550 SIG alg signature algorithm 2551 Signature Within the R1 packet that contains the 2552 HIP_SIGNATURE_2 parameter, the Initiator's HIT, the 2553 checksum field, and the Opaque and Random #I fields 2554 in the PUZZLE parameter MUST be set to zero while 2555 computing the HIP_SIGNATURE_2 signature. Further, 2556 the HIP packet length in the HIP header MUST be 2557 adjusted as if the HIP_SIGNATURE_2 was not in the 2558 packet during the signature calculation, i.e., the 2559 HIP packet length points to the beginning of 2560 the HIP_SIGNATURE_2 parameter during signing and 2561 verification. 2563 Zeroing the Initiator's HIT makes it possible to create R1 packets 2564 beforehand, to minimize the effects of possible DoS attacks. Zeroing 2565 the Random #I and Opaque fields within the PUZZLE parameter allows 2566 these fields to be populated dynamically on precomputed R1s. 2568 Signature calculation and verification follows the process defined in 2569 Section 6.4.2. 2571 5.2.16. SEQ 2573 0 1 2 3 2574 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 2575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2576 | Type | Length | 2577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2578 | Update ID | 2579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2580 Type 385 2581 Length 8 2582 Update ID 32-bit sequence number 2584 The Update ID is an unsigned number in network byte order, 2585 initialized by a host to zero upon moving to ESTABLISHED state. The 2586 Update ID has scope within a single HIP association, and not across 2587 multiple associations or multiple hosts. The Update ID is 2588 incremented by one before each new UPDATE that is sent by the host; 2589 the first UPDATE packet originated by a host has an Update ID of 0. 2591 5.2.17. ACK 2593 0 1 2 3 2594 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2596 | Type | Length | 2597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2598 | peer Update ID 1 | 2599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2600 / peer Update ID n | 2601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2603 Type 449 2604 Length length in octets, excluding Type and Length 2605 peer Update ID 32-bit sequence number corresponding to the 2606 Update ID being ACKed. 2608 The ACK parameter includes one or more Update IDs that have been 2609 received from the peer. The number of peer Update IDs can be 2610 inferred from the length by dividing it by 4. 2612 5.2.18. ENCRYPTED 2614 0 1 2 3 2615 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2617 | Type | Length | 2618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2619 | Reserved | 2620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2621 | IV / 2622 / / 2623 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 2625 / Encrypted data / 2626 / / 2627 / +-------------------------------+ 2628 / | Padding | 2629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2631 Type 641 2632 Length length in octets, excluding Type, Length, and 2633 Padding 2634 Reserved zero when sent, ignored when received 2635 IV Initialization vector, if needed, otherwise 2636 nonexistent. The length of the IV is inferred from 2637 the HIP_CIPHER. 2638 Encrypted The data is encrypted using the encryption algorithm 2639 data defined in the HIP_CIPHER parameter. 2641 The ENCRYPTED parameter encapsulates other parameters, the encrypted 2642 data, which holds one or more HIP parameters in block encrypted form. 2644 Consequently, the first fields in the encapsulated parameter(s) are 2645 Type and Length of the first such parameter, allowing the contents to 2646 be easily parsed after decryption. 2648 The field labeled "Encrypted data" consists of the output of one or 2649 more HIP parameters concatenated together that have been passed 2650 through an encryption algorithm. Each of these inner parameters is 2651 padded according to the rules of Section 5.2.1 for padding individual 2652 parameters. As a result, the concatenated parameters will be a block 2653 of data that is 8-byte aligned. 2655 Some encryption algorithms require that the data to be encrypted must 2656 be a multiple of the cipher algorithm block size. In this case, the 2657 above block of data MUST include additional padding, as specified by 2658 the encryption algorithm. The size of the extra padding is selected 2659 so that the length of the unencrypted data block is a multiple of the 2660 cipher block size. The encryption algorithm may specify padding 2661 bytes other than zero; for example, AES [FIPS.197.2001] uses the 2662 PKCS5 padding scheme (see section 6.1.1 of [RFC2898]) where the 2663 remaining n bytes to fill the block each have the value of n. This 2664 yields an "unencrypted data" block that is transformed to an 2665 "encrypted data" block by the cipher suite. This extra padding added 2666 to the set of parameters to satisfy the cipher block alignment rules 2667 is not counted in HIP TLV length fields, and this extra padding 2668 should be removed by the cipher suite upon decryption. 2670 Note that the length of the cipher suite output may be smaller or 2671 larger than the length of the set of parameters to be encrypted, 2672 since the encryption process may compress the data or add additional 2673 padding to the data. 2675 Once this encryption process is completed, the Encrypted data field 2676 is ready for inclusion in the parameter. If necessary, additional 2677 Padding for 8-byte alignment is then added according to the rules of 2678 Section 5.2.1. 2680 5.2.19. NOTIFICATION 2682 The NOTIFICATION parameter is used to transmit informational data, 2683 such as error conditions and state transitions, to a HIP peer. A 2684 NOTIFICATION parameter may appear in NOTIFY packets. The use of the 2685 NOTIFICATION parameter in other packet types is for further study. 2687 0 1 2 3 2688 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 2689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2690 | Type | Length | 2691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2692 | Reserved | Notify Message Type | 2693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2694 | / 2695 / Notification Data / 2696 / +---------------+ 2697 / | Padding | 2698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2700 Type 832 2701 Length length in octets, excluding Type, Length, and 2702 Padding 2703 Reserved zero when sent, ignored when received 2704 Notify Message specifies the type of notification 2705 Type 2706 Notification informational or error data transmitted in addition 2707 Data to the Notify Message Type. Values for this field 2708 are type specific (see below). 2709 multiple of 8 bytes. 2711 Notification information can be error messages specifying why an HIP 2712 Security Association could not be established. It can also be status 2713 data that a HIP implementation wishes to communicate with a peer 2714 process. The table below lists the notification messages and their 2715 Notification Message Types. HIP packets MAY contain multiple 2716 NOTIFICATION parameters if several problems exist or several 2717 independent pieces of information must be transmitted. 2719 To avoid certain types of attacks, a Responder SHOULD avoid sending a 2720 NOTIFICATION to any host with which it has not successfully verified 2721 a puzzle solution. 2723 Notify Message Types in the range 0-16383 are intended for reporting 2724 errors and in the range 16384-65535 for other status information. An 2725 implementation that receives a NOTIFY packet with a Notify Message 2726 Type that indicates an error in response to a request packet (e.g., 2727 I1, I2, UPDATE) SHOULD assume that the corresponding request has 2728 failed entirely. Unrecognized error types MUST be ignored except 2729 that they SHOULD be logged. 2731 As currently defined, Notify Message Type values 1-10 are used for 2732 informing about errors in packet structures, values 11-20 for 2733 informing about problems in parameters. 2735 Notification Data in NOTIFICATION parameters with status Notify 2736 Message Types MUST be ignored if not recognized. 2738 Notify Message Types - Errors Value 2739 ----------------------------- ----- 2741 UNSUPPORTED_CRITICAL_PARAMETER_TYPE 1 2743 Sent if the parameter type has the "critical" bit set and the 2744 parameter type is not recognized. Notification Data contains the 2745 two-octet parameter type. 2747 INVALID_SYNTAX 7 2749 Indicates that the HIP message received was invalid because some 2750 type, length, or value was out of range or because the request 2751 was otherwise malformed. To avoid a denial- of-service 2752 attack using forged messages, this status may only be returned 2753 for packets whose HIP_MAC (if present) and SIGNATURE have been 2754 verified. This status MUST be sent in response to any error not 2755 covered by one of the other status types, and SHOULD NOT contain 2756 details to avoid leaking information to someone probing a node. 2757 To aid debugging, more detailed error information SHOULD be 2758 written to a console or log. 2760 NO_DH_PROPOSAL_CHOSEN 14 2762 None of the proposed group IDs was acceptable. 2764 INVALID_DH_CHOSEN 15 2766 The DH Group ID field does not correspond to one offered 2767 by the Responder. 2769 NO_HIP_PROPOSAL_CHOSEN 16 2771 None of the proposed HIT Suites or HIP Encryption Algorithms was 2772 acceptable. 2774 INVALID_HIP_CIPHER_CHOSEN 17 2776 The HIP_CIPHER Crypto ID does not correspond to one offered by 2777 the Responder. 2779 UNSUPPORTED_HIT_SUITE 20 2781 Sent in response to an I1 or R1 packet for which the HIT suite 2782 is not supported. 2784 AUTHENTICATION_FAILED 24 2786 Sent in response to a HIP signature failure, except when 2787 the signature verification fails in a NOTIFY message. 2789 CHECKSUM_FAILED 26 2791 Sent in response to a HIP checksum failure. 2793 HIP_MAC_FAILED 28 2795 Sent in response to a HIP HMAC failure. 2797 ENCRYPTION_FAILED 32 2799 The Responder could not successfully decrypt the 2800 ENCRYPTED parameter. 2802 INVALID_HIT 40 2804 Sent in response to a failure to validate the peer's 2805 HIT from the corresponding HI. 2807 BLOCKED_BY_POLICY 42 2809 The Responder is unwilling to set up an association 2810 for some policy reason (e.g., received HIT is NULL 2811 and policy does not allow opportunistic mode). 2813 RESPONDER_BUSY_PLEASE_RETRY 44 2815 The Responder is unwilling to set up an association as it is 2816 suffering under some kind of overload and has chosen to shed load 2817 by rejecting the Initiator's request. The Initiator may retry; 2818 however, the Initiator MUST find another (different) puzzle 2819 solution for any such retries. Note that the Initiator may need 2820 to obtain a new puzzle with a new I1/R1 exchange. 2822 Notify Message Types - Status Value 2823 ----------------------------- ----- 2825 I2_ACKNOWLEDGEMENT 16384 2827 The Responder has an I2 packet from the Initiator but had to 2828 queue the I2 packet for processing. The puzzle was correctly 2829 solved and the Responder is willing to set up an association but 2830 currently has a number of I2 packets in the processing queue. 2831 The R2 packet is sent after the I2 packet was processed. 2833 5.2.20. ECHO_REQUEST_SIGNED 2835 0 1 2 3 2836 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 2837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2838 | Type | Length | 2839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2840 | Opaque data (variable length) | 2841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2843 Type 897 2844 Length length of the opaque data in octets 2845 Opaque data opaque data, supposed to be meaningful only to the 2846 node that sends ECHO_REQUEST_SIGNED and receives a 2847 corresponding ECHO_RESPONSE_SIGNED or 2848 ECHO_RESPONSE_UNSIGNED. 2850 The ECHO_REQUEST_SIGNED parameter contains an opaque blob of data 2851 that the sender wants to get echoed back in the corresponding reply 2852 packet. 2854 The ECHO_REQUEST_SIGNED and corresponding echo response parameters 2855 MAY be used for any purpose where a node wants to carry some state in 2856 a request packet and get it back in a response packet. The 2857 ECHO_REQUEST_SIGNED is covered by the HIP_MAC and SIGNATURE. A HIP 2858 packet can contain only one ECHO_REQUEST_SIGNED parameter and MAY 2859 contain multiple ECHO_REQUEST_UNSIGNED parameter. The 2860 ECHO_REQUEST_SIGNED parameter MUST be responded to with an 2861 ECHO_RESPONSE_SIGNED. 2863 5.2.21. ECHO_REQUEST_UNSIGNED 2865 0 1 2 3 2866 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 2867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2868 | Type | Length | 2869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2870 | Opaque data (variable length) | 2871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2873 Type 63661 2874 Length length of the opaque data in octets 2875 Opaque data opaque data, supposed to be meaningful only to the 2876 node that sends ECHO_REQUEST_UNSIGNED and receives a 2877 corresponding ECHO_RESPONSE_UNSIGNED. 2879 The ECHO_REQUEST_UNSIGNED parameter contains an opaque blob of data 2880 that the sender wants to get echoed back in the corresponding reply 2881 packet. 2883 The ECHO_REQUEST_UNSIGNED and corresponding echo response parameters 2884 MAY be used for any purpose where a node wants to carry some state in 2885 a request packet and get it back in a response packet. The 2886 ECHO_REQUEST_UNSIGNED is not covered by the HIP_MAC and SIGNATURE. A 2887 HIP packet can contain one or more ECHO_REQUEST_UNSIGNED parameters. 2888 It is possible that middleboxes add ECHO_REQUEST_UNSIGNED parameters 2889 in HIP packets passing by. The creator of the ECHO_REQUEST_UNSIGNED 2890 (end-host or middlebox) has to create the Opaque field so that it can 2891 later identify and remove the corresponding ECHO_RESPONSE_UNSIGNED 2892 parameter. 2894 The ECHO_REQUEST_UNSIGNED parameter MUST be responded to with an 2895 ECHO_RESPONSE_UNSIGNED parameter. 2897 5.2.22. ECHO_RESPONSE_SIGNED 2899 0 1 2 3 2900 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 2901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2902 | Type | Length | 2903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2904 | Opaque data (variable length) | 2905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2907 Type 961 2908 Length length of the opaque data in octets 2909 Opaque data opaque data, copied unmodified from the 2910 ECHO_REQUEST_SIGNED or ECHO_REQUEST_UNSIGNED 2911 parameter that triggered this response. 2913 The ECHO_RESPONSE_SIGNED parameter contains an opaque blob of data 2914 that the sender of the ECHO_REQUEST_SIGNED wants to get echoed back. 2915 The opaque data is copied unmodified from the ECHO_REQUEST_SIGNED 2916 parameter. 2918 The ECHO_REQUEST_SIGNED and ECHO_RESPONSE_SIGNED parameters MAY be 2919 used for any purpose where a node wants to carry some state in a 2920 request packet and get it back in a response packet. The 2921 ECHO_RESPONSE_SIGNED is covered by the HIP_MAC and SIGNATURE. 2923 5.2.23. ECHO_RESPONSE_UNSIGNED 2925 0 1 2 3 2926 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 2927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2928 | Type | Length | 2929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2930 | Opaque data (variable length) | 2931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2933 Type 63425 2934 Length length of the opaque data in octets 2935 Opaque data opaque data, copied unmodified from the 2936 ECHO_REQUEST_SIGNED or ECHO_REQUEST_UNSIGNED 2937 parameter that triggered this response. 2939 The ECHO_RESPONSE_UNSIGNED parameter contains an opaque blob of data 2940 that the sender of the ECHO_REQUEST_SIGNED or ECHO_REQUEST_UNSIGNED 2941 wants to get echoed back. The opaque data is copied unmodified from 2942 the corresponding echo request parameter. 2944 The echo request and ECHO_RESPONSE_UNSIGNED parameters MAY be used 2945 for any purpose where a node wants to carry some state in a request 2946 packet and get it back in a response packet. The 2947 ECHO_RESPONSE_UNSIGNED is not covered by the HIP_MAC and SIGNATURE. 2949 5.3. HIP Packets 2951 There are eight basic HIP packets (see Table 10). Four are for the 2952 HIP base exchange, one is for updating, one is for sending 2953 notifications, and two are for closing a HIP association. 2955 +------------------+------------------------------------------------+ 2956 | Packet type | Packet name | 2957 +------------------+------------------------------------------------+ 2958 | 1 | I1 - the HIP Initiator Packet | 2959 | | | 2960 | 2 | R1 - the HIP Responder Packet | 2961 | | | 2962 | 3 | I2 - the Second HIP Initiator Packet | 2963 | | | 2964 | 4 | R2 - the Second HIP Responder Packet | 2965 | | | 2966 | 16 | UPDATE - the HIP Update Packet | 2967 | | | 2968 | 17 | NOTIFY - the HIP Notify Packet | 2969 | | | 2970 | 18 | CLOSE - the HIP Association Closing Packet | 2971 | | | 2972 | 19 | CLOSE_ACK - the HIP Closing Acknowledgment | 2973 | | Packet | 2974 +------------------+------------------------------------------------+ 2976 Table 10: HIP packets and packet type values 2978 Packets consist of the fixed header as described in Section 5.1, 2979 followed by the parameters. The parameter part, in turn, consists of 2980 zero or more TLV-coded parameters. 2982 In addition to the base packets, other packet types may be defined 2983 later in separate specifications. For example, support for mobility 2984 and multi-homing is not included in this specification. 2986 See Notation (Section 2.2) for the notation used in the operations. 2988 In the future, an optional upper-layer payload MAY follow the HIP 2989 header. The Next Header field in the header indicates if there is 2990 additional data following the HIP header. The HIP packet, however, 2991 MUST NOT be fragmented. This limits the size of the possible 2992 additional data in the packet. 2994 5.3.1. I1 - the HIP Initiator Packet 2996 The HIP header values for the I1 packet: 2998 Header: 2999 Packet Type = 1 3000 SRC HIT = Initiator's HIT 3001 DST HIT = Responder's HIT, or NULL 3003 IP ( HIP ( DH_GROUP_LIST ) ) 3005 The I1 packet contains the fixed HIP header and the Initiator's 3006 DH_GROUP_LIST. 3008 Valid control bits: none 3010 The Initiator receives the Responder's HIT either from a DNS lookup 3011 of the Responder's FQDN (see 5205-bis), from some other repository, 3012 or from a local table. If the Initiator does not know the 3013 Responder's HIT, it may attempt to use opportunistic mode by using 3014 NULL (all zeros) as the Responder's HIT. See also "HIP Opportunistic 3015 Mode" (Section 4.1.8). 3017 Since the I1 packet is so easy to spoof even if it were signed, no 3018 attempt is made to add to its generation or processing cost. 3020 The Initiator includes a DH_GROUP_LIST parameter in the I1 packet to 3021 inform the Responder of its preferred DH Group IDs. Note that the 3022 DH_GROUP_LIST in the I1 packet is not protected by a signature. 3024 Implementations MUST be able to handle a storm of received I1 3025 packets, discarding those with common content that arrive within a 3026 small time delta. 3028 5.3.2. R1 - the HIP Responder Packet 3030 The HIP header values for the R1 packet: 3032 Header: 3033 Packet Type = 2 3034 SRC HIT = Responder's HIT 3035 DST HIT = Initiator's HIT 3037 IP ( HIP ( [ R1_COUNTER, ] 3038 PUZZLE, 3039 DIFFIE_HELLMAN, 3040 HIP_CIPHER, 3041 HOST_ID, 3042 HIT_SUITE_LIST, 3043 DH_GROUP_LIST, 3044 [ ECHO_REQUEST_SIGNED, ] 3045 HIP_SIGNATURE_2 ) 3046 <, ECHO_REQUEST_UNSIGNED >i) 3048 Valid control bits: A 3050 If the Responder's HI is an anonymous one, the A control MUST be set. 3052 The Initiator's HIT MUST match the one received in the I1 packet if 3053 the R1 is a response to an I1. If the Responder has multiple HIs, 3054 the Responder's HIT used MUST match Initiator's request. If the 3055 Initiator used opportunistic mode, the Responder may select freely 3056 among its HIs. See also "HIP Opportunistic Mode" (Section 4.1.8). 3058 The R1 packet generation counter is used to determine the currently 3059 valid generation of puzzles. The value is increased periodically, 3060 and it is RECOMMENDED that it is increased at least as often as 3061 solutions to old puzzles are no longer accepted. 3063 The Puzzle contains a Random #I and the difficulty #K. The 3064 difficulty #K indicates the number of lower-order bits, in the puzzle 3065 hash result, that must be zeros; see Section 4.1.2. The Random #I is 3066 not covered by the signature and must be zeroed during the signature 3067 calculation, allowing the sender to select and set the #I into a 3068 precomputed R1 packet just prior sending it to the peer. 3070 The Responder selects the Diffie-Hellman public value based on the 3071 Initiator's preference expressed in the DH_GROUP_LIST parameter in 3072 the I1 packet. The Responder sends back its own preference based on 3073 which it chose the DH public value as DH_GROUP_LIST. This allows the 3074 Initiator to determine whether its own DH_GROUP_LIST in the sent I1 3075 packet was manipulated by an attacker. 3077 The Diffie-Hellman public value is ephemeral, and values SHOULD NOT 3078 be reused across different HIP sessions. Once the Responder has 3079 received a valid response to an R1 packet, that Diffie-Hellman value 3080 SHOULD be deprecated. It it is possible that the Responder has sent 3081 the same Diffie-Hellman value to different hosts simultaneously in 3082 corresponding R1 packets and those responses should also be accepted. 3083 However, as a defense against I1 packet storms, an implementation MAY 3084 propose, and re-use unless avoidable, the same Diffie-Hellman value 3085 for a period of time, for example, 15 minutes. By using a small 3086 number of different puzzles for a given Diffie-Hellman value, the R1 3087 packets can be precomputed and delivered as quickly as I1 packets 3088 arrive. A scavenger process should clean up unused Diffie-Hellman 3089 values and puzzles. 3091 Re-using Diffie-Hellman public values opens up the potential security 3092 risk of more than one Initiator ending up with the same keying 3093 material (due to faulty random number generators). Also, more than 3094 one Initiator using the same Responder public key half may lead to 3095 potentially easier cryptographic attacks and to imperfect forward 3096 security. 3098 However, these risks involved in re-using the same public value are 3099 statistical; that is, the authors are not aware of any mechanism that 3100 would allow manipulation of the protocol so that the risk of the re- 3101 use of any given Responder Diffie-Hellman public key would differ 3102 from the base probability. Consequently, it is RECOMMENDED that 3103 Responders avoid re-using the same DH key with multiple Initiators, 3104 but because the risk is considered statistical and not known to be 3105 manipulable, the implementations MAY re-use a key in order to ease 3106 resource-constrained implementations and to increase the probability 3107 of successful communication with legitimate clients even under an I1 3108 packet storm. In particular, when it is too expensive to generate 3109 enough precomputed R1 packets to supply each potential Initiator with 3110 a different DH key, the Responder MAY send the same DH key to several 3111 Initiators, thereby creating the possibility of multiple legitimate 3112 Initiators ending up using the same Responder-side public key. 3113 However, as soon as the Responder knows that it will use a particular 3114 DH key, it SHOULD stop offering it. This design is aimed to allow 3115 resource-constrained Responders to offer services under I1 packet 3116 storms and to simultaneously make the probability of DH key re-use 3117 both statistical and as low as possible. 3119 If a future version of this protocol is considered, we strongly 3120 recommend that these issues be studied again. Especially, the 3121 current design allows hosts to become potentially more vulnerable to 3122 a statistical, low-probability problem during I1 packet storm attacks 3123 than what they are if no attack is taking place; whether this is 3124 acceptable or not should be reconsidered in the light of any new 3125 experience gained. 3127 The HIP_CIPHER contains the encryption algorithms supported by the 3128 Responder to encrypt the contents of the ENCRYPTED parameter, in the 3129 order of preference. All implementations MUST support AES [RFC3602]. 3131 The HIT_SUITE_LIST parameter is an ordered list of the Responder's 3132 preferred and supported HIT Suites. The list allows the Initiator to 3133 determine whether its own source HIT matches any suite supported by 3134 the Responder. 3136 The ECHO_REQUEST_SIGNED and ECHO_REQUEST_UNSIGNED parameters contain 3137 data that the sender wants to receive unmodified in the corresponding 3138 response packet in the ECHO_RESPONSE_SIGNED or ECHO_RESPONSE_UNSIGNED 3139 parameter. The R1 packet may contain zero or more 3140 ECHO_REQUEST_UNSIGNED parameters as described in Section 3141 Section 5.2.21. 3143 The signature is calculated over the whole HIP packet, after setting 3144 the Initiator's HIT, header checksum, as well as the Opaque field and 3145 the Random #I in the PUZZLE parameter temporarily to zero, and 3146 excluding any parameters that follow the signature, as described in 3147 Section 5.2.15. This allows the Responder to use precomputed R1s. 3149 The Initiator SHOULD validate this signature. It MUST check that the 3150 Responder's HI matches with the one expected, if any. 3152 5.3.3. I2 - the Second HIP Initiator Packet 3154 The HIP header values for the I2 packet: 3156 Header: 3157 Type = 3 3158 SRC HIT = Initiator's HIT 3159 DST HIT = Responder's HIT 3161 IP ( HIP ( [R1_COUNTER,] 3162 SOLUTION, 3163 DIFFIE_HELLMAN, 3164 HIP_CIPHER, 3165 ENCRYPTED { HOST_ID } or HOST_ID, 3166 [ ECHO_RESPONSE_SIGNED ,] 3167 HIP_MAC, 3168 HIP_SIGNATURE 3169 <, ECHO_RESPONSE_UNSIGNED>i ) ) 3171 Valid control bits: A 3173 The HITs used MUST match the ones used in the R1. 3175 If the Initiator's HI is an anonymous one, the A control MUST be set. 3177 If present in the I1 packet, the Initiator MUST include an unmodified 3178 copy of the R1_COUNTER parameter received in the corresponding R1 3179 packet into the I2 packet. 3181 The Solution contains the Random #I from R1 and the computed #J. The 3182 low-order #K bits of the RHASH(I | ... | J) MUST be zero. 3184 The Diffie-Hellman value is ephemeral. If precomputed, a scavenger 3185 process should clean up unused Diffie-Hellman values. The Responder 3186 MAY re-use Diffie-Hellman values under some conditions as specified 3187 in Section 5.3.2. 3189 The HIP_CIPHER contains the single encryption transform selected by 3190 the Initiator, that it uses to encrypt the ENCRYPTED parameters. The 3191 chosen cipher MUST correspond to one of the ciphers offered by the 3192 Responder in the R1. All implementations MUST support AES [RFC3602]. 3194 The Initiator's HI MAY be encrypted using the HIP_CIPHER encryption 3195 algorithm. The keying material is derived from the Diffie-Hellman 3196 exchanged as defined in Section 6.5. 3198 The ECHO_RESPONSE_SIGNED and ECHO_RESPONSE_UNSIGNED contain the 3199 unmodified Opaque data copied from the corresponding echo request 3200 parameter(s). 3202 The HMAC value in the HIP_MAC parameter is calculated over the whole 3203 HIP packet, excluding any parameters after the HIP_MAC, as described 3204 in Section 6.4.1. The Responder MUST validate the HIP_MAC. 3206 The signature is calculated over the whole HIP packet, excluding any 3207 parameters after the HIP_SIGNATURE, as described in Section 5.2.14. 3208 The Responder MUST validate this signature. The Responder uses the 3209 HI in the packet or a HI acquired by some other means for verifying 3210 the signature. 3212 5.3.4. R2 - the Second HIP Responder Packet 3214 The HIP header values for the R2 packet: 3216 Header: 3217 Packet Type = 4 3218 SRC HIT = Responder's HIT 3219 DST HIT = Initiator's HIT 3221 IP ( HIP ( HIP_MAC_2, HIP_SIGNATURE ) ) 3223 Valid control bits: none 3225 The HIP_MAC_2 is calculated over the whole HIP packet, with 3226 Responder's HOST_ID parameter concatenated with the HIP packet. The 3227 HOST_ID parameter is removed after the HMAC calculation. The 3228 procedure is described in Section 6.4.1. 3230 The signature is calculated over the whole HIP packet. 3232 The Initiator MUST validate both the HIP_MAC and the signature. 3234 5.3.5. UPDATE - the HIP Update Packet 3236 Support for the UPDATE packet is MANDATORY. 3238 The HIP header values for the UPDATE packet: 3240 Header: 3241 Packet Type = 16 3242 SRC HIT = Sender's HIT 3243 DST HIT = Recipient's HIT 3245 IP ( HIP ( [SEQ, ACK, ] HIP_MAC, HIP_SIGNATURE ) ) 3247 Valid control bits: None 3249 The UPDATE packet contains mandatory HIP_MAC and HIP_SIGNATURE 3250 parameters, and other optional parameters. 3252 The UPDATE packet contains zero or one SEQ parameter. The presence 3253 of a SEQ parameter indicates that the receiver MUST acknowledge the 3254 the UPDATE. An UPDATE that does not contain a SEQ but only an ACK 3255 parameter is simply an acknowledgment of a previous UPDATE and itself 3256 MUST NOT be acknowledged by a separate ACK. Such UPDATE packets 3257 containing only an ACK parameter do not require processing in 3258 relative order to other UPDATE packets. An UPDATE packet without 3259 either a SEQ or an ACK parameter is invalid; such unacknowledged 3260 updates MUST instead use a NOTIFY packet. 3262 An UPDATE packet contains zero or one ACK parameters. The ACK 3263 parameter echoes the SEQ sequence number of the UPDATE packet being 3264 ACKed. A host MAY choose to acknowledge more than one UPDATE packet 3265 at a time; e.g., the ACK may contain the last two SEQ values 3266 received, for resilience against ACK loss. ACK values are not 3267 cumulative; each received unique SEQ value requires at least one 3268 corresponding ACK value in reply. Received ACKs that are redundant 3269 are ignored. Hosts MUST implement the processing of ACKs with 3270 multiple SEQ numbers even if they do not implement sending ACKs with 3271 multiple SEQ numbers. 3273 The UPDATE packet may contain both a SEQ and an ACK parameter. In 3274 this case, the ACK is being piggybacked on an outgoing UPDATE. In 3275 general, UPDATEs carrying SEQ SHOULD be ACKed upon completion of the 3276 processing of the UPDATE. A host MAY choose to hold the UPDATE 3277 carrying ACK for a short period of time to allow for the possibility 3278 of piggybacking the ACK parameter, in a manner similar to TCP delayed 3279 acknowledgments. 3281 A sender MAY choose to forgo reliable transmission of a particular 3282 UPDATE (e.g., it becomes overcome by events). The semantics are such 3283 that the receiver MUST acknowledge the UPDATE, but the sender MAY 3284 choose to not care about receiving the ACK. 3286 UPDATEs MAY be retransmitted without incrementing SEQ. If the same 3287 subset of parameters is included in multiple UPDATEs with different 3288 SEQs, the host MUST ensure that the receiver's processing of the 3289 parameters multiple times will not result in a protocol error. 3291 5.3.6. NOTIFY - the HIP Notify Packet 3293 Implementing the NOTIFY packet is optional. The NOTIFY packet MAY be 3294 used to provide information to a peer. Typically, NOTIFY is used to 3295 indicate some type of protocol error or negotiation failure. NOTIFY 3296 packets are unacknowledged. The receiver can handle the packet only 3297 as informational, and SHOULD NOT change its HIP state (see 3298 Section 4.4.2) based purely on a received NOTIFY packet. 3300 The HIP header values for the NOTIFY packet: 3302 Header: 3303 Packet Type = 17 3304 SRC HIT = Sender's HIT 3305 DST HIT = Recipient's HIT, or zero if unknown 3307 IP ( HIP (i, [HOST_ID, ] HIP_SIGNATURE) ) 3309 Valid control bits: None 3311 The NOTIFY packet is used to carry one or more NOTIFICATION 3312 parameters. 3314 5.3.7. CLOSE - the HIP Association Closing Packet 3316 The HIP header values for the CLOSE packet: 3318 Header: 3319 Packet Type = 18 3320 SRC HIT = Sender's HIT 3321 DST HIT = Recipient's HIT 3323 IP ( HIP ( ECHO_REQUEST_SIGNED, HIP_MAC, HIP_SIGNATURE ) ) 3325 Valid control bits: none 3327 The sender MUST include an ECHO_REQUEST_SIGNED used to validate 3328 CLOSE_ACK received in response, and both a HIP_MAC and a signature 3329 (calculated over the whole HIP packet). 3331 The receiver peer MUST reply with a CLOSE_ACK containing an 3332 ECHO_RESPONSE_SIGNED corresponding to the received 3333 ECHO_REQUEST_SIGNED. 3335 5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet 3337 The HIP header values for the CLOSE_ACK packet: 3339 Header: 3340 Packet Type = 19 3341 SRC HIT = Sender's HIT 3342 DST HIT = Recipient's HIT 3344 IP ( HIP ( ECHO_RESPONSE_SIGNED, HIP_MAC, HIP_SIGNATURE ) ) 3346 Valid control bits: none 3348 The sender MUST include both an HMAC and signature (calculated over 3349 the whole HIP packet). 3351 The receiver peer MUST validate the ECHO_RESPONSE_SIGNED and validate 3352 both the HIP_MAC and the signature if the receiver has state for a 3353 HIP association. 3355 5.4. ICMP Messages 3357 When a HIP implementation detects a problem with an incoming packet, 3358 and it either cannot determine the identity of the sender of the 3359 packet or does not have any existing HIP association with the sender 3360 of the packet, it MAY respond with an ICMP packet. Any such replies 3361 MUST be rate-limited as described in [RFC4443]. In most cases, the 3362 ICMP packet has the Parameter Problem type (12 for ICMPv4, 4 for 3363 ICMPv6), with the Pointer field pointing to the field that caused the 3364 ICMP message to be generated. 3366 5.4.1. Invalid Version 3368 If a HIP implementation receives a HIP packet that has an 3369 unrecognized HIP version number, it SHOULD respond, rate-limited, 3370 with an ICMP packet with type Parameter Problem, with the Pointer 3371 pointing to the Version/RES. byte in the HIP header. 3373 5.4.2. Other Problems with the HIP Header and Packet Structure 3375 If a HIP implementation receives a HIP packet that has other 3376 unrecoverable problems in the header or packet format, it MAY 3377 respond, rate-limited, with an ICMP packet with type Parameter 3378 Problem, the Pointer pointing to the field that failed to pass the 3379 format checks. However, an implementation MUST NOT send an ICMP 3380 message if the checksum fails; instead, it MUST silently drop the 3381 packet. 3383 5.4.3. Invalid Puzzle Solution 3385 If a HIP implementation receives an I2 packet that has an invalid 3386 puzzle solution, the behavior depends on the underlying version of 3387 IP. If IPv6 is used, the implementation SHOULD respond with an ICMP 3388 packet with type Parameter Problem, the Pointer pointing to the 3389 beginning of the Puzzle solution #J field in the SOLUTION payload in 3390 the HIP message. 3392 If IPv4 is used, the implementation MAY respond with an ICMP packet 3393 with the type Parameter Problem, copying enough of bytes from the I2 3394 message so that the SOLUTION parameter fits into the ICMP message, 3395 the Pointer pointing to the beginning of the Puzzle solution #J 3396 field, as in the IPv6 case. Note, however, that the resulting ICMPv4 3397 message exceeds the typical ICMPv4 message size as defined in 3398 [RFC0792]. 3400 5.4.4. Non-Existing HIP Association 3402 If a HIP implementation receives a CLOSE or UPDATE packet, or any 3403 other packet whose handling requires an existing association, that 3404 has either a Receiver or Sender HIT that does not match with any 3405 existing HIP association, the implementation MAY respond, rate- 3406 limited, with an ICMP packet with the type Parameter Problem. The 3407 Pointer of the ICMP Parameter Problem packet is set pointing to the 3408 beginning of the first HIT that does not match. 3410 A host MUST NOT reply with such an ICMP if it receives any of the 3411 following messages: I1, R2, I2, R2, and NOTIFY packet. When 3412 introducing new packet types, a specification SHOULD define the 3413 appropriate rules for sending or not sending this kind of ICMP reply. 3415 6. Packet Processing 3417 Each host is assumed to have a single HIP protocol implementation 3418 that manages the host's HIP associations and handles requests for new 3419 ones. Each HIP association is governed by a conceptual state 3420 machine, with states defined above in Section 4.4. The HIP 3421 implementation can simultaneously maintain HIP associations with more 3422 than one host. Furthermore, the HIP implementation may have more 3423 than one active HIP association with another host; in this case, HIP 3424 associations are distinguished by their respective HITs. It is not 3425 possible to have more than one HIP association between any given pair 3426 of HITs. Consequently, the only way for two hosts to have more than 3427 one parallel association is to use different HITs, at least at one 3428 end. 3430 The processing of packets depends on the state of the HIP 3431 association(s) with respect to the authenticated or apparent 3432 originator of the packet. A HIP implementation determines whether it 3433 has an active association with the originator of the packet based on 3434 the HITs. In the case of user data carried in a specific transport 3435 format, the transport format document specifies how the incoming 3436 packets are matched with the active associations. 3438 6.1. Processing Outgoing Application Data 3440 In a HIP host, an application can send application-level data using 3441 an identifier specified via the underlying API. The API can be a 3442 backwards-compatible API (see [RFC5338]), using identifiers that look 3443 similar to IP addresses, or a completely new API, providing enhanced 3444 services related to Host Identities. Depending on the HIP 3445 implementation, the identifier provided to the application may be 3446 different; for example, it can be a HIT or an IP address. 3448 The exact format and method for transferring the user data from the 3449 source HIP host to the destination HIP host is defined in the 3450 corresponding transport format document. The actual data is 3451 transferred in the network using the appropriate source and 3452 destination IP addresses. 3454 In this document, conceptual processing rules are defined only for 3455 the base case where both hosts have only single usable IP addresses; 3456 the multi-address multi-homing case is specified separately. 3458 The following conceptual algorithm describes the steps that are 3459 required for handling outgoing datagrams destined to a HIT. 3461 1. If the datagram has a specified source address, it MUST be a HIT. 3462 If it is not, the implementation MAY replace the source address 3463 with a HIT. Otherwise, it MUST drop the packet. 3465 2. If the datagram has an unspecified source address, the 3466 implementation MUST choose a suitable source HIT for the 3467 datagram. Selecting the source HIT is subject to local policy. 3469 3. If there is no active HIP association with the given HIT pair, one MUST be created by running the base 3471 exchange. While waiting for the base exchange to complete, the 3472 implementation SHOULD queue at least one packet per HIP 3473 association to be formed, and it MAY queue more than one. 3475 4. Once there is an active HIP association for the given HIT pair, the outgoing datagram is passed to 3477 transport handling. The possible transport formats are defined 3478 in separate documents, of which the ESP transport format for HIP 3479 is mandatory for all HIP implementations. 3481 5. Before sending the packet, the HITs in the datagram are replaced 3482 with suitable IP addresses. For IPv6, the rules defined in 3483 [RFC3484] SHOULD be followed. Note that this HIT-to-IP-address 3484 conversion step MAY also be performed at some other point in the 3485 stack, e.g., before wrapping the packet into the output format. 3487 6.2. Processing Incoming Application Data 3489 The following conceptual algorithm describes the incoming datagram 3490 handling when HITs are used at the receiving host as application- 3491 level identifiers. More detailed steps for processing packets are 3492 defined in corresponding transport format documents. 3494 1. The incoming datagram is mapped to an existing HIP association, 3495 typically using some information from the packet. For example, 3496 such mapping may be based on the ESP Security Parameter Index 3497 (SPI). 3499 2. The specific transport format is unwrapped, in a way depending on 3500 the transport format, yielding a packet that looks like a 3501 standard (unencrypted) IP packet. If possible, this step SHOULD 3502 also verify that the packet was indeed (once) sent by the remote 3503 HIP host, as identified by the HIP association. 3505 Depending on the used transport mode, the verification method can 3506 vary. While the HI (as well as HIT) is used as the higher-layer 3507 identifier, the verification method has to verify that the data 3508 packet was sent by the correct node identity and that the actual 3509 identity maps to this particular HIT. When using ESP transport 3510 format [I-D.ietf-hip-rfc5202-bis], the verification is done using 3511 the SPI value in the data packet to find the corresponding SA 3512 with associated HIT and key, and decrypting the packet with that 3513 associated key. 3515 3. The IP addresses in the datagram are replaced with the HITs 3516 associated with the HIP association. Note that this IP-address- 3517 to-HIT conversion step MAY also be performed at some other point 3518 in the stack. 3520 4. The datagram is delivered to the upper layer (e.g., UDP or TCP). 3521 When demultiplexing the datagram, the right upper-layer socket is 3522 selected based on the HITs. 3524 6.3. Solving the Puzzle 3526 This subsection describes the details for solving the puzzle. 3528 In the R1 packet, the values #I and #K are sent in network byte 3529 order. Similarly, in the I2 packet, the values #I and #J are sent in 3530 network byte order. The hash is created by concatenating, in network 3531 byte order, the following data, in the following order and using the 3532 RHASH algorithm: 3534 n-bit random value #I (where n is RHASH_len), in network byte 3535 order, as appearing in the R1 and I2 packets. 3537 128-bit Initiator's HIT, in network byte order, as appearing in 3538 the HIP Payload in the R1 and I2 packets. 3540 128-bit Responder's HIT, in network byte order, as appearing in 3541 the HIP Payload in the R1 and I2 packets. 3543 n-bit random value #J (where n is RHASH_len), in network byte 3544 order, as appearing in the I2 packet. 3546 In a valid response puzzle, the #K low-order bits of the resulting 3547 RHASH digest MUST be zero. 3549 Notes: 3551 i) The length of the data to be hashed is variable depending on 3552 the output length of the Responder's hash function RHASH. 3554 ii) All the data in the hash input MUST be in network byte order. 3556 iii) The order of the Initiator's and Responder's HITs are 3557 different in the R1 and I2 packets; see Section 5.1. Care must be 3558 taken to copy the values in the right order to the hash input. 3560 iv) For a puzzle #I, there may exist multiple valid puzzle 3561 solutions #J. 3563 The following procedure describes the processing steps involved, 3564 assuming that the Responder chooses to precompute the R1 packets: 3566 Precomputation by the Responder: 3567 Sets up the puzzle difficulty #K. 3568 Creates a signed R1 and caches it. 3570 Responder: 3571 Selects a suitable cached R1. 3572 Generates a random number #I. 3573 Sends #I and #K in an R1. 3574 Saves #I and #K for a Delta time. 3576 Initiator: 3577 Generates repeated attempts to solve the puzzle until a matching 3578 #J is found: 3579 Ltrunc( RHASH( #I | HIT-I | HIT-R | #J ), #K ) == 0 3580 Sends #I and #J in an I2. 3582 Responder: 3583 Verifies that the received #I is a saved one. 3584 Finds the right #K based on #I. 3585 Computes V := Ltrunc( RHASH( #I | HIT-I | HIT-R | #J ), #K ) 3586 Rejects if V != 0 3587 Accept if V == 0 3589 6.4. HIP_MAC and SIGNATURE Calculation and Verification 3591 The following subsections define the actions for processing HIP_MAC, 3592 HIP_MAC_2, HIP_SIGNATURE and HIP_SIGNATURE_2 parameters. The 3593 HIP_MAC_2 parameter is contained in the R2 packet. The 3594 HIP_SIGNATURE_2 parameter is contained in the R1 packet. The 3595 HIP_SIGNATURE and HIP_MAC parameter are contained in other HIP 3596 control packets. 3598 6.4.1. HMAC Calculation 3600 The HMAC uses RHASH as underlying hash function. The type of RHASH 3601 depends on the HIT Suite of the Responder. Hence, HMAC-SHA-1 3602 [RFC2404] is used for HIT Suites RSA/DSA/SHA-1 and ECDSA_LOW/SHA-1 3603 and HMAC-SHA-256 [RFC4868] for ECDSA/SHA-384. 3605 The following process applies both to the HIP_MAC and HIP_MAC_2 3606 parameters. When processing HIP_MAC_2, the difference is that the 3607 HIP_MAC calculation includes a pseudo HOST_ID field containing the 3608 Responder's information as sent in the R1 packet earlier. 3610 Both the Initiator and the Responder should take some care when 3611 verifying or calculating the HIP_MAC_2. Specifically, the Initiator 3612 has to preserve the HOST_ID exactly as it was received in the R1 3613 packet until it receives the HIP_MAC_2 in the R2 packet. 3615 The scope of the calculation for HIP_MAC is: 3617 HMAC: { HIP header | [ Parameters ] } 3619 where Parameters include all HIP parameters of the packet that is 3620 being calculated with Type values ranging from 1 to (HIP_MAC's Type 3621 value - 1) and exclude parameters with Type values greater or equal 3622 to HIP_MAC's Type value. 3624 During HIP_MAC calculation, the following applies: 3626 o In the HIP header, the Checksum field is set to zero. 3628 o In the HIP header, the Header Length field value is calculated to 3629 the beginning of the HIP_MAC parameter. 3631 Parameter order is described in Section 5.2.1. 3633 The scope of the calculation for HIP_MAC_2 is: 3635 HIP_MAC_2: { HIP header | [ Parameters ] | HOST_ID } 3637 where Parameters include all HIP parameters for the packet that is 3638 being calculated with Type values from 1 to (HIP_MAC_2's Type value - 3639 1) and exclude parameters with Type values greater or equal to 3640 HIP_MAC_2's Type value. 3642 During HIP_MAC_2 calculation, the following applies: 3644 o In the HIP header, the Checksum field is set to zero. 3646 o In the HIP header, the Header Length field value is calculated to 3647 the beginning of the HIP_MAC_2 parameter and increased by the 3648 length of the concatenated HOST_ID parameter length (including 3649 type and length fields). 3651 o HOST_ID parameter is exactly in the form it was received in the R1 3652 packet from the Responder. 3654 Parameter order is described in Section 5.2.1, except that the 3655 HOST_ID parameter in this calculation is added to the end. 3657 The HIP_MAC parameter is defined in Section 5.2.12 and the HIP_MAC_2 3658 parameter in Section 5.2.13. The HMAC calculation and verification 3659 process (the process applies both to HIP_MAC and HIP_MAC_2 except 3660 where HIP_MAC_2 is mentioned separately) is as follows: 3662 Packet sender: 3664 1. Create the HIP packet, without the HIP_MAC, HIP_SIGNATURE, 3665 HIP_SIGNATURE_2, or any other parameter with greater Type value 3666 than the HIP_MAC parameter has. 3668 2. In case of HIP_MAC_2 calculation, add a HOST_ID (Responder) 3669 parameter to the end of the packet. 3671 3. Calculate the Header Length field in the HIP header including the 3672 added HOST_ID parameter in case of HIP_MAC_2. 3674 4. Compute the HMAC using either HIP-gl or HIP-lg integrity key 3675 retrieved from KEYMAT as defined in Section 6.5. 3677 5. In case of HIP_MAC_2, remove the HOST_ID parameter from the 3678 packet. 3680 6. Add the HIP_MAC parameter to the packet and any parameter with 3681 greater Type value than the HIP_MAC's (HIP_MAC_2's) that may 3682 follow, including possible HIP_SIGNATURE or HIP_SIGNATURE_2 3683 parameters 3685 7. Recalculate the Length field in the HIP header. 3687 Packet receiver: 3689 1. Verify the HIP header Length field. 3691 2. Remove the HIP_MAC or HIP_MAC_2 parameter, as well as all other 3692 parameters that follow it with greater Type value including 3693 possible HIP_SIGNATURE or HIP_SIGNATURE_2 fields, saving the 3694 contents if they are needed later. 3696 3. In case of HIP_MAC_2, build and add a HOST_ID parameter (with 3697 Responder information) to the packet. The HOST_ID parameter 3698 should be identical to the one previously received from the 3699 Responder. 3701 4. Recalculate the HIP packet length in the HIP header and clear the 3702 Checksum field (set it to all zeros). In case of HIP_MAC_2, the 3703 length is calculated with the added HOST_ID parameter. 3705 5. Compute the HMAC using either HIP-gl or HIP-lg integrity key as 3706 defined in Section 6.5 and verify it against the received HMAC. 3708 6. Set Checksum and Header Length field in the HIP header to 3709 original values. Note that the checksum and length fields 3710 contain incorrect values after this step. 3712 7. In case of HIP_MAC_2, remove the HOST_ID parameter from the 3713 packet before further processing. 3715 6.4.2. Signature Calculation 3717 The following process applies both to the HIP_SIGNATURE and 3718 HIP_SIGNATURE_2 parameters. When processing the HIP_SIGNATURE_2, the 3719 only difference is that instead of the HIP_SIGNATURE parameter, the 3720 HIP_SIGNATURE_2 parameter is used, and the Initiator's HIT and PUZZLE 3721 Opaque and Random #I fields are cleared (set to all zeros) before 3722 computing the signature. The HIP_SIGNATURE parameter is defined in 3723 Section 5.2.14 and the HIP_SIGNATURE_2 parameter in Section 5.2.15. 3725 The scope of the calculation for HIP_SIGNATURE and HIP_SIGNATURE_2 3726 is: 3728 HIP_SIGNATURE: { HIP header | [ Parameters ] } 3730 where Parameters include all HIP parameters for the packet that is 3731 being calculated with Type values from 1 to (HIP_SIGNATURE's Type 3732 value - 1). 3734 During signature calculation, the following applies: 3736 o In the HIP header, the Checksum field is set to zero. 3738 o In the HIP header, the Header Length field value is calculated to 3739 the beginning of the HIP_SIGNATURE parameter. 3741 The parameter order is described in Section 5.2.1. 3743 HIP_SIGNATURE_2: { HIP header | [ Parameters ] } 3745 where Parameters include all HIP parameters for the packet that is 3746 being calculated with Type values ranging from 1 to 3747 (HIP_SIGNATURE_2's Type value - 1). 3749 During signature calculation, the following apply: 3751 o In the HIP header, the Initiator's HIT field and Checksum fields 3752 are set to zero. 3754 o In the HIP header, the Header Length field value is calculated to 3755 the beginning of the HIP_SIGNATURE_2 parameter. 3757 o PUZZLE parameter's Opaque and Random #I fields are set to zero. 3759 Parameter order is described in Section 5.2.1. 3761 The signature calculation and verification process (the process 3762 applies both to HIP_SIGNATURE and HIP_SIGNATURE_2 except in the case 3763 where HIP_SIGNATURE_2 is separately mentioned) is as follows: 3765 Packet sender: 3767 1. Create the HIP packet without the HIP_SIGNATURE parameter or any 3768 other parameters that follow the HIP_SIGNATURE parameter. 3770 2. Calculate the Length field and zero the Checksum field in the HIP 3771 header. In case of HIP_SIGNATURE_2, set Initiator's HIT field in 3772 the HIP header as well as PUZZLE parameter's Opaque and Random #I 3773 fields to zero. 3775 3. Compute the signature using the private key corresponding to the 3776 Host Identifier (public key). 3778 4. Add the HIP_SIGNATURE parameter to the packet. 3780 5. Add any parameters that follow the HIP_SIGNATURE parameter. 3782 6. Recalculate the Length field in the HIP header, and calculate the 3783 Checksum field. 3785 Packet receiver: 3787 1. Verify the HIP header Length field and checksum. 3789 2. Save the contents of the HIP_SIGNATURE parameter and any other 3790 parameters following the HIP_SIGNATURE parameter and remove them 3791 from the packet. 3793 3. Recalculate the HIP packet Length in the HIP header and clear the 3794 Checksum field (set it to all zeros). In case of 3795 HIP_SIGNATURE_2, set Initiator's HIT field in the HIP header as 3796 well as PUZZLE parameter's Opaque and Random #I fields to zero. 3798 4. Compute the signature and verify it against the received 3799 signature using the packet sender's Host Identity (public key). 3801 5. Restore the original packet by adding removed parameters (in step 3802 2) and resetting the values that were set to zero (in step 3). 3804 The verification can use either the HI received from a HIP packet, 3805 the HI from a DNS query, if the FQDN has been received in the HOST_ID 3806 packet or one received by some other means. 3808 6.5. HIP KEYMAT Generation 3810 HIP keying material is derived from the Diffie-Hellman session key, 3811 Kij, produced during the HIP base exchange (see Section 4.1.3). The 3812 Initiator has Kij during the creation of the I2 packet, and the 3813 Responder has Kij once it receives the I2 packet. This is why I2 can 3814 already contain encrypted information. 3816 The KEYMAT is derived by feeding Kij into the key derivation function 3817 defined by the DH Group ID. Currently the only key derivation 3818 function defied in this document is the Hash-based Key Derivation 3819 Function (HKDF) [RFC5869] using the RHASH hash function. Other 3820 documents may define new DH Group IDs and corresponding key 3821 distribution functions. 3823 In the following we provide the details for deriving the keying 3824 material using HKDF. 3826 where 3828 info = sort(HIT-I | HIT-R) 3829 salt = #I | #J 3831 Sort(HIT-I | HIT-R) is defined as the network byte order 3832 concatenation of the two HITs, with the smaller HIT preceding the 3833 larger HIT, resulting from the numeric comparison of the two HITs 3834 interpreted as positive (unsigned) 128-bit integers in network byte 3835 order. The #I and #J values are from the puzzle and its solution 3836 that were exchanged in R1 and I2 messages when this HIP association 3837 was set up. Both hosts have to store #I and #J values for the HIP 3838 association for future use. 3840 The initial keys are drawn sequentially in the order that is 3841 determined by the numeric comparison of the two HITs, with comparison 3842 method described in the previous paragraph. HOST_g denotes the host 3843 with the greater HIT value, and HOST_l the host with the lower HIT 3844 value. 3846 The drawing order for the four initial keys is as follows: 3848 HIP-gl encryption key for HOST_g's ENCRYPTED parameter 3850 HIP-gl integrity (HMAC) key for HOST_g's outgoing HIP packets 3852 HIP-lg encryption key for HOST_l's ENCRYPTED parameter 3854 HIP-lg integrity (HMAC) key for HOST_l's outgoing HIP packets 3856 The number of bits drawn for a given algorithm is the "natural" size 3857 of the keys. For the mandatory algorithms, the following sizes 3858 apply: 3860 AES 128 or 256 bits 3862 SHA-1 160 bits 3864 SHA-256 256 bits 3866 SHA-384 384 bits 3868 NULL 0 bits 3870 If other key sizes are used, they MUST be treated as different 3871 encryption algorithms and defined separately. 3873 6.6. Initiation of a HIP Base Exchange 3875 An implementation may originate a HIP base exchange to another host 3876 based on a local policy decision, usually triggered by an application 3877 datagram, in much the same way that an IPsec IKE key exchange can 3878 dynamically create a Security Association. Alternatively, a system 3879 may initiate a HIP exchange if it has rebooted or timed out, or 3880 otherwise lost its HIP state, as described in Section 4.5.4. 3882 The implementation prepares an I1 packet and sends it to the IP 3883 address that corresponds to the peer host. The IP address of the 3884 peer host may be obtained via conventional mechanisms, such as DNS 3885 lookup. The I1 packet contents are specified in Section 5.3.1. The 3886 selection of which source or destination Host Identity to use, if a 3887 Initiator or Responder has more than one to choose from, is typically 3888 a policy decision. 3890 The following steps define the conceptual processing rules for 3891 initiating a HIP base exchange: 3893 1. The Initiator receives one or more of the Responder's HITs and 3894 one or more addresses either from a DNS lookup of the Responder's 3895 FQDN, from some other repository, or from a local database. If 3896 the Initiator does not know the Responder's HIT, it may attempt 3897 opportunistic mode by using NULL (all zeros) as the Responder's 3898 HIT (see also "HIP Opportunistic Mode" (Section 4.1.8)). If the 3899 Initiator can choose from multiple Responder HITs, it selects a 3900 HIT for which the Initiator supports the HIT Suite. 3902 2. The Initiator sends an I1 packet to one of the Responder's 3903 addresses. The selection of which address to use is a local 3904 policy decision. 3906 3. The Initiator includes the DH_GROUP_LIST in the I1 packet. The 3907 selection and order of DH Group IDs in the DH_GROUP_LIST MUST be 3908 stored by the Initiator because this list is needed for later R1 3909 processing. In most cases, the preferences regarding the DH 3910 Groups will be static, so no per-association storage is 3911 necessary. 3913 4. Upon sending an I1 packet, the sender transitions to state I1- 3914 SENT, starts a timer for which the timeout value SHOULD be larger 3915 than the worst-case anticipated RTT. The sender SHOULD also 3916 increment the timeout counter associated with the I1. 3918 5. Upon timeout, the sender SHOULD retransmit the I1 packet and 3919 restart the timer, up to a maximum of I1_RETRIES_MAX tries. 3921 6.6.1. Sending Multiple I1 Packets in Parallel 3923 For the sake of minimizing the session establishment latency, an 3924 implementation MAY send the same I1 packet to more than one of the 3925 Responder's addresses. However, it MUST NOT send to more than three 3926 (3) Responder addresses in parallel. Furthermore, upon timeout, the 3927 implementation MUST refrain from sending the same I1 packet to 3928 multiple addresses. That is, if it retries to initialize the 3929 connection after a timeout, it MUST NOT send the I1 packet to more 3930 than one destination address. These limitations are placed in order 3931 to avoid congestion of the network, and potential DoS attacks that 3932 might occur, e.g., because someone's claim to have hundreds or 3933 thousands of addresses could generate a huge number of I1 packets 3934 from the Initiator. 3936 As the Responder is not guaranteed to distinguish the duplicate I1 3937 packets it receives at several of its addresses (because it avoids 3938 storing states when it answers back an R1 packet), the Initiator may 3939 receive several duplicate R1 packets. 3941 The Initiator SHOULD then select the initial preferred destination 3942 address using the source address of the selected received R1, and use 3943 the preferred address as a source address for the I2 packet. 3944 Processing rules for received R1s are discussed in Section 6.8. 3946 6.6.2. Processing Incoming ICMP Protocol Unreachable Messages 3948 A host may receive an ICMP 'Destination Protocol Unreachable' message 3949 as a response to sending a HIP I1 packet. Such a packet may be an 3950 indication that the peer does not support HIP, or it may be an 3951 attempt to launch an attack by making the Initiator believe that the 3952 Responder does not support HIP. 3954 When a system receives an ICMP 'Destination Protocol Unreachable' 3955 message while it is waiting for an R1 packet, it MUST NOT terminate 3956 waiting. It MAY continue as if it had not received the ICMP message, 3957 and send a few more I1 packets. Alternatively, it MAY take the ICMP 3958 message as a hint that the peer most probably does not support HIP, 3959 and return to state UNASSOCIATED earlier than otherwise. However, at 3960 minimum, it MUST continue waiting for an R1 packet for a reasonable 3961 time before returning to UNASSOCIATED. 3963 6.7. Processing Incoming I1 Packets 3965 An implementation SHOULD reply to an I1 with an R1 packet, unless the 3966 implementation is unable or unwilling to set up a HIP association. 3967 If the implementation is unable to set up a HIP association, the host 3968 SHOULD send an ICMP Destination Protocol Unreachable, 3969 Administratively Prohibited, message to the I1 packet source IP 3970 address. If the implementation is unwilling to set up a HIP 3971 association, the host MAY ignore the I1 packet. This latter case may 3972 occur during a DoS attack such as an I1 packet flood. 3974 The implementation SHOULD be able to handle a storm of received I1 3975 packets, discarding those with common content that arrive within a 3976 small time delta. 3978 A spoofed I1 packet can result in an R1 attack on a system. An R1 3979 packet sender MUST have a mechanism to rate-limit R1 packets sent to 3980 an address. 3982 It is RECOMMENDED that the HIP state machine does not transition upon 3983 sending an R1 packet. 3985 The following steps define the conceptual processing rules for 3986 responding to an I1 packet: 3988 1. The Responder MUST check that the Responder's HIT in the received 3989 I1 packet is either one of its own HITs or NULL. Otherwise it 3990 must drop the packet. 3992 2. If the Responder is in ESTABLISHED state, the Responder MAY 3993 respond to this with an R1 packet, prepare to drop an existing 3994 HIP security association with the peer, and stay at ESTABLISHED 3995 state. 3997 3. If the Responder is in I1-SENT state, it MUST make a comparison 3998 between the sender's HIT and its own (i.e., the receiver's) HIT. 3999 If the sender's HIT is greater than its own HIT, it should drop 4000 the I1 packet and stay at I1-SENT. If the sender's HIT is 4001 smaller than its own HIT, it SHOULD send the R1 packet and stay 4002 at I1-SENT. The HIT comparison is performed as defined in 4003 Section 6.5. 4005 4. If the implementation chooses to respond to the I1 packet with an 4006 R1 packet, it creates a new R1 or selects a precomputed R1 4007 according to the format described in Section 5.3.2. It creates 4008 or chooses an R1 that contains its most preferred DH public value 4009 that is also contained in the DH_GROUP_LIST in the I1 packet. If 4010 no suitable DH Group ID was contained in the DH_GROUP_LIST in the 4011 I1 packet, it sends an R1 with any suitable DH public key. 4013 5. If the received Responder's HIT in the I1 is NULL, the Responder 4014 selects a HIT with a the same HIT Suite as the Initiator's HIT. 4015 If this HIT Suite is not supported by the Responder, it SHOULD 4016 select a REQUIRED HIT Suite from Section 5.2.10, which is 4017 currently RSA/DSA/SHA-1. Other than that, selecting the HIT is a 4018 local policy matter. 4020 6. The responder expresses its supported HIP transport formats in 4021 the TRANSPORT_FORMAT_LIST as described in Section 5.2.10. The 4022 Responder MUST at least provide one payload transport format 4023 type. 4025 7. The Responder sends the R1 packet to the source IP address of the 4026 I1 packet. 4028 6.7.1. R1 Management 4030 All compliant implementations MUST be able to produce R1 packets. An 4031 R1 packet MAY be precomputed. An R1 packet MAY be reused for time 4032 Delta T, which is implementation dependent, and SHOULD be deprecated 4033 and not used once a valid response I2 packet has been received from 4034 an Initiator. During an I1 message storm, an R1 packet MAY be re- 4035 used beyond this limit. R1 information MUST NOT be discarded until 4036 Delta S after T. Time S is the delay needed for the last I2 packet 4037 to arrive back to the Responder. 4039 Implementations that support multiple DH groups MAY pre-compute R1 4040 packets for each supported group so that incoming I1 packets with 4041 different DH Group IDs in the DH_GROUP_LIST can be served quickly. 4043 An implementation MAY keep state about received I1 packets and match 4044 the received I2 packets against the state, as discussed in 4045 Section 4.1.1. 4047 6.7.2. Handling Malformed Messages 4049 If an implementation receives a malformed I1 packet, it SHOULD NOT 4050 respond with a NOTIFY message, as such practice could open up a 4051 potential denial-of-service threat. Instead, it MAY respond with an 4052 ICMP packet, as defined in Section 5.4. 4054 6.8. Processing Incoming R1 Packets 4056 A system receiving an R1 packet MUST first check to see if it has 4057 sent an I1 packet to the originator of the R1 packet (i.e., it is in 4058 state I1-SENT). If so, it SHOULD process the R1 as described below, 4059 send an I2 packet, and transition to state I2-SENT, setting a timer 4060 to protect the I2 packet. If the system is in state I2-SENT, it MAY 4061 respond to the R1 packet if the R1 packet has a larger R1 generation 4062 counter; if so, it should drop its state due to processing the 4063 previous R1 packet and start over from state I1-SENT. If the system 4064 is in any other state with respect to that host, the system SHOULD 4065 silently drop the R1 packet. 4067 When sending multiple I1 packets, an Initiator SHOULD wait for a 4068 small amount of time after the first R1 reception to allow possibly 4069 multiple R1 packets to arrive, and it SHOULD respond to an R1 packet 4070 among the set with the largest R1 generation counter. 4072 The following steps define the conceptual processing rules for 4073 responding to an R1 packet: 4075 1. A system receiving an R1 MUST first check to see if it has sent 4076 an I1 packet to the originator of the R1 packet (i.e., it has a 4077 HIP association that is in state I1-SENT and that is associated 4078 with the HITs in the R1). Unless the I1 packet was sent in 4079 opportunistic mode (see Section 4.1.8), the IP addresses in the 4080 received R1 packet SHOULD be ignored by the R1 processing and, 4081 when looking up the right HIP association, the received R1 4082 packet SHOULD be matched against the associations using only the 4083 HITs. If a match exists, the system should process the R1 4084 packet as described below. 4086 2. Otherwise, if the system is in any other state than I1-SENT or 4087 I2-SENT with respect to the HITs included in the R1 packet, it 4088 SHOULD silently drop the R1 packet and remain in the current 4089 state. 4091 3. If the HIP association state is I1-SENT or I2-SENT, the received 4092 Initiator's HIT MUST correspond to the HIT used in the original 4093 I1. Also, the Responder's HIT MUST correspond to the one used 4094 in the I1, unless the I1 packet contained a NULL HIT. 4096 4. The system SHOULD validate the R1 signature before applying 4097 further packet processing, according to Section 5.2.15. 4099 5. If the HIP association state is I1-SENT, and multiple valid R1 4100 packets are present, the system MUST select from among the R1 4101 packets with the largest R1 generation counter. 4103 6. The system MUST check that the Initiator HIT Suite is contained 4104 in the HIT_SUITE_LIST parameter in the R1 packet (i.e., the 4105 Initiator's HIT Suite is supported by the Responder). If the 4106 HIT Suite is supported by the Responder, the system proceeds 4107 normally. Otherwise, the system MAY stay in state I1-sent and 4108 restart the BEX by sending a new I1 packet with an Initiator HIT 4109 that is supported by the Responder and hence is contained in the 4110 HIT_SUITE_LIST in the R1 packet. The system MAY abort the BEX 4111 if no suitable source HIT is available. The system SHOULD wait 4112 for an acceptable time span to allow further R1 packets with 4113 higher R1 generation counters or different HIT and HIT Suites to 4114 arrive before restarting or aborting the BEX. 4116 7. The system MUST check that the DH Group ID in the DIFFIE_HELLMAN 4117 parameter in the R1 matches the first DH Suite ID in the 4118 Responder's DH_GROUP_LIST in the R1 packet that was also 4119 contained in the Initiator's DH_GROUP_LIST in the I1 packet. If 4120 the DH Group ID of the DIFFIE_HELLMAN parameter does not express 4121 the Responder's best choice, the Initiator can conclude that the 4122 DH_GROUP_LIST in the I1 packet was adversely modified. In such 4123 case, the Initiator MAY send a new I1 packet, however, it SHOULD 4124 NOT change its preference in the DH_GROUP_LIST in the new I1 4125 packet. Alternatively, the Initiator MAY abort the HIP base 4126 exchange. 4128 8. If the HIP association state is I2-SENT, the system MAY re-enter 4129 state I1-SENT and process the received R1 packet if it has a 4130 larger R1 generation counter than the R1 packet responded to 4131 previously. 4133 9. The R1 packet may have the A bit set -- in this case, the system 4134 MAY choose to refuse it by dropping the R1 packet and returning 4135 to state UNASSOCIATED. The system SHOULD consider dropping the 4136 R1 packet only if it used a NULL HIT in I1 packet. If the A bit 4137 is set, the Responder's HIT is anonymous and SHOULD NOT be 4138 stored permanently. 4140 10. The system SHOULD attempt to validate the HIT against the 4141 received Host Identity by using the received Host Identity to 4142 construct a HIT and verify that it matches the Sender's HIT. 4144 11. The system MUST store the received R1 generation counter for 4145 future reference. 4147 12. The system attempts to solve the puzzle in the R1 packet. The 4148 system MUST terminate the search after exceeding the remaining 4149 lifetime of the puzzle. If the puzzle is not successfully 4150 solved, the implementation MAY either resend the I1 packet 4151 within the retry bounds or abandon the HIP base exchange. 4153 13. The system computes standard Diffie-Hellman keying material 4154 according to the public value and Group ID provided in the 4155 DIFFIE_HELLMAN parameter. The Diffie-Hellman keying material 4156 Kij is used for key extraction as specified in Section 6.5. 4158 14. The system selects the HIP_CIPHER ID from the choices presented 4159 in the R1 packet and uses the selected values subsequently when 4160 generating and using encryption keys, and when sending the I2 4161 packet. If the proposed alternatives are not acceptable to the 4162 system, it may either resend an I1 within the retry bounds or 4163 abandon the HIP base exchange. 4165 15. The system chooses one suitable transport format from the 4166 TRANSPORT_FORMAT_LIST and includes the respective transport 4167 format parameter in the subsequent I2 packet. 4169 16. The system initializes the remaining variables in the associated 4170 state, including Update ID counters. 4172 17. The system prepares and sends an I2 packet, as described in 4173 Section 5.3.3. 4175 18. The system SHOULD start a timer whose timeout value SHOULD be 4176 larger than the worst-case anticipated RTT, and MUST increment a 4177 timeout counter associated with the I2 packet. The sender 4178 SHOULD retransmit the I2 packet upon a timeout and restart the 4179 timer, up to a maximum of I2_RETRIES_MAX tries. 4181 19. If the system is in state I1-SENT, it SHALL transition to state 4182 I2-SENT. If the system is in any other state, it remains in the 4183 current state. 4185 6.8.1. Handling of Malformed Messages 4187 If an implementation receives a malformed R1 message, it MUST 4188 silently drop the packet. Sending a NOTIFY or ICMP would not help, 4189 as the sender of the R1 packet typically doesn't have any state. An 4190 implementation SHOULD wait for some more time for a possibly well- 4191 formed R1, after which it MAY try again by sending a new I1 packet. 4193 6.9. Processing Incoming I2 Packets 4195 Upon receipt of an I2 packet, the system MAY perform initial checks 4196 to determine whether the I2 packet corresponds to a recent R1 packet 4197 that has been sent out, if the Responder keeps such state. For 4198 example, the sender could check whether the I2 packet is from an 4199 address or HIT for which the Responder has recently received an I1. 4200 The R1 packet may have had Opaque data included that was echoed back 4201 in the I2 packet. If the I2 packet is considered to be suspect, it 4202 MAY be silently discarded by the system. 4204 Otherwise, the HIP implementation SHOULD process the I2 packet. This 4205 includes validation of the puzzle solution, generating the Diffie- 4206 Hellman key, possibly decrypting the Initiator's Host Identity, 4207 verifying the signature, creating state, and finally sending an R2 4208 packet. 4210 The following steps define the conceptual processing rules for 4211 responding to an I2 packet: 4213 1. The system MAY perform checks to verify that the I2 packet 4214 corresponds to a recently sent R1 packet. Such checks are 4215 implementation dependent. See Appendix A for a description of 4216 an example implementation. 4218 2. The system MUST check that the Responder's HIT corresponds to 4219 one of its own HITs and MUST drop the packet otherwise. 4221 3. The system MUST further check that the Initiator's HIT Suite is 4222 supported. The Responder SHOULD silently drop I2 packets with 4223 unsupported Initiator HITs. 4225 4. If the system's state machine is in the R2-SENT state, the 4226 system MAY check if the newly received I2 packet is similar to 4227 the one that triggered moving to R2-SENT. If so, it MAY 4228 retransmit a previously sent R2 packet, reset the R2-SENT timer, 4229 and the state machine stays in R2-SENT. 4231 5. If the system's state machine is in the I2-SENT state, the 4232 system makes a comparison between its local and sender's HITs 4233 (similarly as in Section 6.5). If the local HIT is smaller than 4234 the sender's HIT, it should drop the I2 packet, use the peer 4235 Diffie-Hellman key and nonce #I from the R1 packet received 4236 earlier, and get the local Diffie-Hellman key and nonce #J from 4237 the I2 packet sent to the peer earlier. Otherwise, the system 4238 should process the received I2 packet and drop any previously 4239 derived Diffie-Hellman keying material Kij it might have formed 4240 upon sending the I2 packet previously. The peer Diffie-Hellman 4241 key and the nonce #J are taken from the just arrived I2 packet. 4242 The local Diffie-Hellman key and the nonce I are the ones that 4243 were sent earlier in the R1 packet. 4245 6. If the system's state machine is in the I1-SENT state, and the 4246 HITs in the I2 packet match those used in the previously sent I1 4247 packet, the system uses this received I2 packet as the basis for 4248 the HIP association it was trying to form, and stops 4249 retransmitting I1 packets (provided that the I2 packet passes 4250 the additional checks below). 4252 7. If the system's state machine is in any other state than R2- 4253 SENT, the system SHOULD check that the echoed R1 generation 4254 counter in the I2 packet is within the acceptable range if the 4255 counter is included. Implementations MUST accept puzzles from 4256 the current generation and MAY accept puzzles from earlier 4257 generations. If the generation counter in the newly received I2 4258 packet is outside the accepted range, the I2 packet is stale 4259 (and perhaps replayed) and SHOULD be dropped. 4261 8. The system MUST validate the solution to the puzzle by computing 4262 the hash described in Section 5.3.3 using the same RHASH 4263 algorithm. 4265 9. The I2 packet MUST have a single value in the HIP_CIPHER 4266 parameter, which MUST match one of the values offered to the 4267 Initiator in the R1 packet. 4269 10. The system must derive Diffie-Hellman keying material Kij based 4270 on the public value and Group ID in the DIFFIE_HELLMAN 4271 parameter. This key is used to derive the HIP association keys, 4272 as described in Section 6.5. If the Diffie-Hellman Group ID is 4273 unsupported, the I2 packet is silently dropped. 4275 11. The encrypted HOST_ID is decrypted by the Initiator's encryption 4276 key defined in Section 6.5. If the decrypted data is not a 4277 HOST_ID parameter, the I2 packet is silently dropped. 4279 12. The implementation SHOULD also verify that the Initiator's HIT 4280 in the I2 packet corresponds to the Host Identity sent in the I2 4281 packet. (Note: some middleboxes may not able to make this 4282 verification.) 4284 13. The system MUST verify the HIP_MAC according to the procedures 4285 in Section 5.2.12. 4287 14. The system MUST verify the HIP_SIGNATURE according to 4288 Section 5.2.14 and Section 5.3.3. 4290 15. If the checks above are valid, then the system proceeds with 4291 further I2 processing; otherwise, it discards the I2 and its 4292 state machine remains in the same state. 4294 16. The I2 packet may have the A bit set -- in this case, the system 4295 MAY choose to refuse it by dropping the I2 and the state machine 4296 returns to state UNASSOCIATED. If the A bit is set, the 4297 Initiator's HIT is anonymous and should not be stored 4298 permanently. 4300 17. The system initializes the remaining variables in the associated 4301 state, including Update ID counters. 4303 18. Upon successful processing of an I2 message when the system's 4304 state machine is in state UNASSOCIATED, I1-SENT, I2-SENT, or R2- 4305 SENT, an R2 packet is sent and the system's state machine 4306 transitions to state R2-SENT. 4308 19. Upon successful processing of an I2 packet when the system's 4309 state machine is in state ESTABLISHED, the old HIP association 4310 is dropped and a new one is installed, an R2 packet is sent, and 4311 the system's state machine transitions to R2-SENT. 4313 20. Upon the system's state machine transitioning to R2-SENT, the 4314 system starts a timer. The state machine transitions to 4315 ESTABLISHED if some data has been received on the incoming HIP 4316 association, or an UPDATE packet has been received (or some 4317 other packet that indicates that the peer system's state machine 4318 has moved to ESTABLISHED). If the timer expires (allowing for 4319 maximal amount of retransmissions of I2 packets), the state 4320 machine transitions to ESTABLISHED. 4322 6.9.1. Handling of Malformed Messages 4324 If an implementation receives a malformed I2 message, the behavior 4325 SHOULD depend on how many checks the message has already passed. If 4326 the puzzle solution in the message has already been checked, the 4327 implementation SHOULD report the error by responding with a NOTIFY 4328 packet. Otherwise, the implementation MAY respond with an ICMP 4329 message as defined in Section 5.4. 4331 6.10. Processing of Incoming R2 Packets 4333 An R2 packet received in states UNASSOCIATED, I1-SENT, or ESTABLISHED 4334 results in the R2 packet being dropped and the state machine staying 4335 in the same state. If an R2 packet is received in state I2-SENT, it 4336 MUST be processed. 4338 The following steps define the conceptual processing rules for an 4339 incoming R2 packet: 4341 1. If the system is in any other state than I2-SENT, the R2 packet 4342 is silently dropped. 4344 2. The system MUST verify that the HITs in use correspond to the 4345 HITs that were received in the R1 packet that caused the 4346 transition to the I1-SENT state. 4348 3. The system MUST verify the HIP_MAC_2 according to the procedures 4349 in Section 5.2.13. 4351 4. The system MUST verify the HIP signature according to the 4352 procedures in Section 5.2.14. 4354 5. If any of the checks above fail, there is a high probability of 4355 an ongoing man-in-the-middle or other security attack. The 4356 system SHOULD act accordingly, based on its local policy. 4358 6. Upon successful processing of the R2 packet, the state machine 4359 transitions to state ESTABLISHED. 4361 6.11. Sending UPDATE Packets 4363 A host sends an UPDATE packet when it intends to update some 4364 information related to a HIP association. There are a number of 4365 possible scenarios when this can occur, e.g., mobility management and 4366 rekeying of an existing ESP Security Association. The following 4367 paragraphs define the conceptual rules for sending an UPDATE packet 4368 to the peer. Additional steps can be defined in other documents 4369 where the UPDATE packet is used. 4371 The sequence of UPDATE messages is indicated by their SEQ parameter. 4372 Before sending an UPDATE message, the system first determines whether 4373 there are any outstanding UPDATE messages that may conflict with the 4374 new UPDATE message under consideration. When multiple UPDATEs are 4375 outstanding (not yet acknowledged), the sender must assume that such 4376 UPDATEs may be processed in an arbitrary order by the receiver. 4377 Therefore, any new UPDATEs that depend on a previous outstanding 4378 UPDATE being successfully received and acknowledged MUST be postponed 4379 until reception of the necessary ACK(s) occurs. One way to prevent 4380 any conflicts is to only allow one outstanding UPDATE at a time. 4381 However, allowing multiple UPDATEs may improve the performance of 4382 mobility and multihoming protocols. 4384 The following steps define the conceptual processing rules for 4385 sending UPDATE packets. 4387 1. The first UPDATE packet is sent with Update ID of zero. 4388 Otherwise, the system increments its own Update ID value by one 4389 before continuing the steps below. 4391 2. The system creates an UPDATE packet that contains a SEQ parameter 4392 with the current value of Update ID. The UPDATE packet MAY also 4393 include zero or more ACKs of the peer's Update ID(s) from 4394 previously received UPDATE SEQ parameter(s) 4396 3. The system sends the created UPDATE packet and starts an UPDATE 4397 timer. The default value for the timer is 2 * RTT estimate. If 4398 multiple UPDATEs are outstanding, multiple timers are in effect. 4400 4. If the UPDATE timer expires, the UPDATE is resent. The UPDATE 4401 can be resent UPDATE_RETRY_MAX times. The UPDATE timer SHOULD be 4402 exponentially backed off for subsequent retransmissions. If no 4403 acknowledgment is received from the peer after UPDATE_RETRY_MAX 4404 times, the HIP association is considered to be broken and the 4405 state machine SHOULD move from state ESTABLISHED to state CLOSING 4406 as depicted in Section 4.4.4. The UPDATE timer is cancelled upon 4407 receiving an ACK from the peer that acknowledges receipt of the 4408 UPDATE. 4410 6.12. Receiving UPDATE Packets 4412 When a system receives an UPDATE packet, its processing depends on 4413 the state of the HIP association and the presence and values of the 4414 SEQ and ACK parameters. Typically, an UPDATE message also carries 4415 optional parameters whose handling is defined in separate documents. 4417 For each association, a host stores the peer's next expected in- 4418 sequence Update ID ("peer Update ID"). Initially, this value is 4419 zero. Update ID comparisons of "less than" and "greater than" are 4420 performed with respect to a circular sequence number space. Hence, a 4421 wrap around after 2^32 updates has to be expected and MUST be handled 4422 accordingly. 4424 The sender MAY send multiple outstanding UPDATE messages. These 4425 messages are processed in the order in which they are received at the 4426 receiver (i.e., no re-sequencing is performed). When processing 4427 UPDATEs out-of-order, the receiver MUST keep track of which UPDATEs 4428 were previously processed, so that duplicates or retransmissions are 4429 ACKed and not reprocessed. A receiver MAY choose to define a receive 4430 window of Update IDs that it is willing to process at any given time, 4431 and discard received UPDATEs falling outside of that window. 4433 The following steps define the conceptual processing rules for 4434 receiving UPDATE packets. 4436 1. If there is no corresponding HIP association, the implementation 4437 MAY reply with an ICMP Parameter Problem, as specified in 4438 Section 5.4.4. 4440 2. If the association is in the ESTABLISHED state and the SEQ (but 4441 not ACK) parameter is present, the UPDATE is processed and 4442 replied to as described in Section 6.12.1. 4444 3. If the association is in the ESTABLISHED state and the ACK (but 4445 not SEQ) parameter is present, the UPDATE is processed as 4446 described in Section 6.12.2. 4448 4. If the association is in the ESTABLISHED state and there is both 4449 an ACK and SEQ in the UPDATE, the ACK is first processed as 4450 described in Section 6.12.2, and then the rest of the UPDATE is 4451 processed as described in Section 6.12.1. 4453 6.12.1. Handling a SEQ Parameter in a Received UPDATE Message 4455 The following steps define the conceptual processing rules for 4456 handling a SEQ parameter in a received UPDATE packet. 4458 1. If the Update ID in the received SEQ is not the next in the 4459 sequence of Update IDs and is greater than the receiver's window 4460 for new UPDATEs, the packet MUST be dropped. 4462 2. If the Update ID in the received SEQ corresponds to an UPDATE 4463 that has recently been processed, the packet is treated as a 4464 retransmission. The HIP_MAC verification (next step) MUST NOT be 4465 skipped. (A byte-by-byte comparison of the received and a stored 4466 packet would be acceptable, though.) It is recommended that a 4467 host caches UPDATE packets sent with ACKs to avoid the cost of 4468 generating a new ACK packet to respond to a replayed UPDATE. The 4469 system MUST acknowledge, again, such (apparent) UPDATE message 4470 retransmissions but SHOULD also consider rate-limiting such 4471 retransmission responses to guard against replay attacks. 4473 3. The system MUST verify the HIP_MAC in the UPDATE packet. If the 4474 verification fails, the packet MUST be dropped. 4476 4. The system MAY verify the SIGNATURE in the UPDATE packet. If the 4477 verification fails, the packet SHOULD be dropped and an error 4478 message logged. 4480 5. If a new SEQ parameter is being processed, the parameters in the 4481 UPDATE are then processed. The system MUST record the Update ID 4482 in the received SEQ parameter, for replay protection. 4484 6. An UPDATE acknowledgment packet with ACK parameter is prepared 4485 and sent to the peer. This ACK parameter MAY be included in a 4486 separate UPDATE or piggybacked in an UPDATE with SEQ parameter, 4487 as described in Section 5.3.5. The ACK parameter MAY acknowledge 4488 more than one of the peer's Update IDs. 4490 6.12.2. Handling an ACK Parameter in a Received UPDATE Packet 4492 The following steps define the conceptual processing rules for 4493 handling an ACK parameter in a received UPDATE packet. 4495 1. The sequence number reported in the ACK must match with an UPDATE 4496 packet sent earlier that has not already been acknowledged. If 4497 no match is found or if the ACK does not acknowledge a new 4498 UPDATE, the packet MUST either be dropped if no SEQ parameter is 4499 present, or the processing steps in Section 6.12.1 are followed. 4501 2. The system MUST verify the HIP_MAC in the UPDATE packet. If the 4502 verification fails, the packet MUST be dropped. 4504 3. The system MAY verify the SIGNATURE in the UPDATE packet. If the 4505 verification fails, the packet SHOULD be dropped and an error 4506 message logged. 4508 4. The corresponding UPDATE timer is stopped (see Section 6.11) so 4509 that the now acknowledged UPDATE is no longer retransmitted. If 4510 multiple UPDATEs are acknowledged, multiple timers are stopped. 4512 6.13. Processing of NOTIFY Packets 4514 Processing of NOTIFY packets is OPTIONAL. If processed, any errors 4515 in a received NOTIFICATION parameter SHOULD be logged. Received 4516 errors MUST be considered only as informational, and the receiver 4517 SHOULD NOT change its HIP state (see Section 4.4.2) purely based on 4518 the received NOTIFY message. 4520 6.14. Processing CLOSE Packets 4522 When the host receives a CLOSE message, it responds with a CLOSE_ACK 4523 message and moves to CLOSED state. (The authenticity of the CLOSE 4524 message is verified using both HIP_MAC and SIGNATURE). This 4525 processing applies whether or not the HIP association state is 4526 CLOSING in order to handle simultaneous CLOSE messages from both ends 4527 that cross in flight. 4529 The HIP association is not discarded before the host moves to the 4530 UNASSOCIATED state. 4532 Once the closing process has started, any new need to send data 4533 packets triggers creating and establishing of a new HIP association, 4534 starting with sending of an I1 packet. 4536 If there is no corresponding HIP association, the CLOSE packet is 4537 dropped. 4539 6.15. Processing CLOSE_ACK Packets 4541 When a host receives a CLOSE_ACK message, it verifies that it is in 4542 CLOSING or CLOSED state and that the CLOSE_ACK was in response to the 4543 CLOSE. A host can map CLOSE_ACK messages to CLOSE messages by 4544 comparing the value of ECHO_REQUEST_SIGNED (in the CLOSE packet) to 4545 the value of ECHO_RESPONSE_SIGNED (in the CLOSE_ACK packet). 4547 The CLOSE_ACK contains the HIP_MAC and the SIGNATURE parameters for 4548 verification. The state is discarded when the state changes to 4549 UNASSOCIATED and, after that, the host MAY respond with an ICMP 4550 Parameter Problem to an incoming CLOSE message (see Section 5.4.4). 4552 6.16. Handling State Loss 4554 In the case of a system crash and unanticipated state loss, the 4555 system SHOULD delete the corresponding HIP state, including the 4556 keying material. That is, the state SHOULD NOT be stored in long- 4557 term storage. If the implementation does drop the state (as 4558 RECOMMENDED), it MUST also drop the peer's R1 generation counter 4559 value, unless a local policy explicitly defines that the value of 4560 that particular host is stored. An implementation MUST NOT store a 4561 peer's R1 generation counters by default, but storing R1 generation 4562 counter values, if done, MUST be configured by explicit HITs. 4564 7. HIP Policies 4566 There are a number of variables that will influence the HIP base 4567 exchanges that each host must support. All HIP implementations MUST 4568 support more than one simultaneous HI, at least one of which SHOULD 4569 be reserved for anonymous usage. Although anonymous HIs will be 4570 rarely used as Responders' HIs, they will be common for Initiators. 4571 Support for more than two HIs is RECOMMENDED. 4573 Initiators MAY use a different HI for different Responders to provide 4574 basic privacy. Whether such private HIs are used repeatedly with the 4575 same Responder and how long these HIs are used is decided by local 4576 policy and depends on the privacy requirements of the Initiator. 4578 The value of #K used in the HIP R1 must be chosen with care. Too 4579 high numbers of #K will exclude clients with weak CPUs because these 4580 devices cannot solve the puzzle within reasonable time. #K should 4581 only be raised if a Responder is under high load, i.e., it cannot 4582 process all incoming HIP handshakes any more. If a responder is not 4583 under high load, K SHOULD be 0. 4585 Responders that only respond to selected Initiators require an ACL, 4586 representing for which hosts they accept HIP base exchanges, and the 4587 preferred transform and local lifetimes. Wildcarding SHOULD be 4588 supported for such ACLs, and also for Responders that offer public or 4589 anonymous services. 4591 8. Security Considerations 4593 HIP is designed to provide secure authentication of hosts. HIP also 4594 attempts to limit the exposure of the host to various denial-of- 4595 service and man-in-the-middle (MitM) attacks. In doing so, HIP 4596 itself is subject to its own DoS and MitM attacks that potentially 4597 could be more damaging to a host's ability to conduct business as 4598 usual. 4600 Denial-of-service attacks often take advantage of asymmetries in the 4601 cost of an starting an association. One example of such asymmetry is 4602 the need of a Responder to store local state while a malicious 4603 Initiator can stay stateless. HIP makes no attempt to increase the 4604 cost of the start of state at the Initiator, but makes an effort to 4605 reduce the cost for the Responder. This is accomplished by having 4606 the Responder start the 3-way exchange instead of the Initiator, 4607 making the HIP protocol 4 packets long. In doing this, the first 4608 packet from the Responder, R1, becomes a 'stock' packet that the 4609 Responder MAY use many times, until some Initiator has provided a 4610 valid response to such an R1 packet. During an I1 packet storm, the 4611 host may reuse the same DH value also even if some Initiator has 4612 provided a valid response using that particular DH value. However, 4613 such behavior is discouraged and should be avoided. Using the same 4614 Diffie-Hellman values and random puzzle #I value has some risks. 4615 This risk needs to be balanced against a potential storm of HIP I1 4616 packets. 4618 This shifting of the start of state cost to the Initiator in creating 4619 the I2 HIP packet presents another DoS attack. The attacker can 4620 spoof the I1 packet and the Responder sends out the R1 HIP packet. 4621 This could conceivably tie up the 'Initiator' with evaluating the R1 4622 HIP packet, and creating the I2 packet. The defense against this 4623 attack is to simply ignore any R1 packet where a corresponding I1 4624 packet was not sent (as defined in Section 6.8 step 1). 4626 The R1 packet is considerably larger than the I1 packet. This 4627 asymmetry can be exploited in an reflection attack. A malicious 4628 attacker could spoof the IP address of a victim and send a flood of 4629 I1 messages to a powerful Responder. For each small I1 packet, the 4630 Responder would send a larger R1 packet to the victim. The 4631 difference in packet sizes can further amplify a flooding attack 4632 against the victim. To avoid such reflection attacks, the Responder 4633 SHOULD rate limit the sending of R1 packets in general or SHOULD rate 4634 limit the sending of R1 packets to a specific IP address. 4636 Floods of forged I2 packets form a second kind of DoS attack. Once 4637 the attacking Initiator has solved the puzzle, it can send packets 4638 with spoofed IP source addresses with either an invalid HIP signature 4639 or invalid encrypted HIP payload (in the ENCRYPTED parameter). This 4640 would take resources in the Responder's part to reach the point to 4641 discover that the I2 packet cannot be completely processed. The 4642 defense against this attack is after N bad I2 packets with the same 4643 puzzle solution, the Responder would discard any I2 packets that 4644 contain the given solution. This will shut down the attack. The 4645 attacker would have to request another R1 packet and use that to 4646 launch a new attack. The Responder could increase the value of #K 4647 while under attack. Keeping a list of solutions from malformed 4648 packets requires that the Responder keeps state for these malformed 4649 I2 packets. This state has to be kept until the R1 counter is 4650 increased. As malformed packets are generally filtered by their 4651 checksum before signature verification, only solutions in packets 4652 that are forged to pass the checksum and puzzle are put to the 4653 blacklist. In addition, a valid puzzle is required before a new list 4654 entry is created. Hence, attackers that intend to flood the 4655 blacklist must solve puzzles first. 4657 A third form of DoS attack is emulating the restart of state after a 4658 reboot of one of the peers. A restarting host would send an I1 4659 packet to the peers, which would respond with an R1 packet even if it 4660 were in the ESTABLISHED state. If the I1 packet were spoofed, the 4661 resulting R1 packet would be received unexpectedly by the spoofed 4662 host and would be dropped, as in the first case above. 4664 A fourth form of DoS attack is emulating closing of the HIP 4665 association. HIP relies on timers and a CLOSE/CLOSE_ACK handshake to 4666 explicitly signal the end of a HIP association. Because both CLOSE 4667 and CLOSE_ACK messages contain a HIP_MAC, an outsider cannot close a 4668 connection. The presence of an additional SIGNATURE allows 4669 middleboxes to inspect these messages and discard the associated 4670 state (for e.g., firewalling, SPI-based NATing, etc.). However, the 4671 optional behavior of replying to CLOSE with an ICMP Parameter Problem 4672 packet (as described in Section 5.4.4) might allow an attacker 4673 spoofing the source IP address to send CLOSE messages to launch 4674 reflection attacks. 4676 A fifth form of DoS attack is replaying R1s to cause the Initiator to 4677 solve stale puzzles and become out of synchronization with the 4678 Responder. The R1 generation counter is a monotonically increasing 4679 counter designed to protect against this attack, as described in 4680 Section 4.1.4. 4682 Man-in-the-middle attacks are difficult to defend against, without 4683 third-party authentication. A skillful MitM could easily handle all 4684 parts of HIP, but HIP indirectly provides the following protection 4685 from a MitM attack. If the Responder's HI is retrieved from a signed 4686 DNS zone, a certificate, or through some other secure means, the 4687 Initiator can use this to validate the R1 HIP packet. 4689 Likewise, if the Initiator's HI is in a secure DNS zone, a trusted 4690 certificate, or otherwise securely available, the Responder can 4691 retrieve the HI (after having got the I2 HIP packet) and verify that 4692 the HI indeed can be trusted. 4694 The HIP Opportunistic Mode concept has been introduced in this 4695 document, but this document does not specify what the semantics of 4696 such a connection setup are for applications. There are certain 4697 concerns with opportunistic mode, as discussed in Section 4.1.8. 4699 NOTIFY messages are used only for informational purposes and they are 4700 unacknowledged. A HIP implementation cannot rely solely on the 4701 information received in a NOTIFY message because the packet may have 4702 been replayed. An implementation SHOULD NOT change any state 4703 information purely based on a received NOTIFY message. 4705 Since not all hosts will ever support HIP, ICMP 'Destination Protocol 4706 Unreachable' messages are to be expected and may be used for a DoS 4707 attack. Against an Initiator, the attack would look like the 4708 Responder does not support HIP, but shortly after receiving the ICMP 4709 message, the Initiator would receive a valid R1 HIP packet. Thus, to 4710 protect from this attack, an Initiator SHOULD NOT react to an ICMP 4711 message until a reasonable delta time to get the real Responder's R1 4712 HIP packet. A similar attack against the Responder is more involved. 4713 Normally, if an I1 message received by a Responder was a bogus one 4714 sent by an attacker, the Responder may receive an ICMP message from 4715 the IP address the R1 message was sent to. However, a sophisticated 4716 attacker can try to take advantage of such a behavior and try to 4717 break up the HIP base exchange by sending such an ICMP message to the 4718 Responder before the Initiator has a chance to send a valid I2 4719 message. Hence, the Responder SHOULD NOT act on such an ICMP 4720 message. Especially, it SHOULD NOT remove any minimal state created 4721 when it sent the R1 HIP packet (if it did create one), but wait for 4722 either a valid I2 HIP packet or the natural timeout (that is, if R1 4723 packets are tracked at all). Likewise, the Initiator SHOULD ignore 4724 any ICMP message while waiting for an R2 HIP packet, and SHOULD 4725 delete any pending state only after a natural timeout. 4727 9. IANA Considerations 4729 IANA has reserved protocol number 139 for the Host Identity Protocol. 4731 This document defines a new 128-bit value under the CGA Message Type 4732 namespace [RFC3972], 0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA, to be 4733 used for HIT generation as specified in ORCHID 4734 [I-D.ietf-hip-rfc4843-bis]. 4736 This document uses HIP version number 2 for the four-bit Version 4737 field in a HIP protocol packet defined in [RFC5201]. 4739 This document also creates a set of new namespaces. These are 4740 described below. 4742 Packet Type 4744 The 7-bit Packet Type field in a HIP protocol packet describes the 4745 type of a HIP protocol message. It is defined in Section 5.1. 4746 The current values are defined in Sections 5.3.1 through 5.3.8. 4748 New values are assigned through IETF Review [RFC5226]. 4750 HIT Suite 4752 The four-bit HIT Suite ID uses the OGA field in the ORCHID to 4753 express the type of the HIT. This document defines two HIT Suites 4754 (see Appendix E). 4756 The HIT Suite ID is also carried in the four higher-order bits of 4757 the ID field in the HIT_SUITE_LIST parameter. The four lower- 4758 order bits are reserved for future extensions of the HIT Suite ID 4759 space beyond 16 values. 4761 At the time being, the HIT Suite uses only four bits because these 4762 bits have to be carried in the HIT. Using more bits for the HIT 4763 Suite ID reduces the cryptographic strength of the HIT. HIT Suite 4764 IDs must be allocated carefully to avoid namespace exhaustion. 4765 Moreover, deprecated IDs should be reused after an appropriate 4766 time span. If 16 Suite IDs prove insufficient and more HIT Suite 4767 IDs are needed concurrently, more bits can be used for the HIT 4768 Suite ID by using one HIT Suite ID (0) to indicate that more bits 4769 should be used. The HIT_SUITE_LIST parameter already supports 4770 8-bit HIT Suite IDs, should longer IDs be needed. Possible 4771 extensions of the HIT Suite ID space to accommodate eight bits and 4772 new HIT Suite IDs are defined through IETF Review or IESG 4773 Approval. 4775 Parameter Type 4777 The 16-bit Type field in a HIP parameter describes the type of the 4778 parameter. It is defined in Section 5.2.1. The current values 4779 are defined in Sections 5.2.3 through 5.2.23. 4781 With the exception of the assigned Type codes, the Type codes 0 4782 through 1023 and 61440 through 65535 are reserved for future base 4783 protocol extensions, and are assigned through IETF Review or IESG 4784 Approval. 4786 The Type codes 32768 through 49151 are reserved for 4787 experimentation. Types SHOULD be selected in a random fashion 4788 from this range, thereby reducing the probability of collisions. 4789 A method employing genuine randomness (such as flipping a coin) 4790 SHOULD be used. 4792 All other Type codes are assigned through First Come First Served, 4793 with Specification Required [RFC5226]. 4795 Group ID 4797 The eight-bit Group ID values appear in the DIFFIE_HELLMAN 4798 parameter and the DH_GROUP_LIST parameter and are defined in 4799 Section 5.2.7. New values are assigned through IETF Review or 4800 IESG Approval. 4802 HIP Cipher ID 4804 The 16-bit Cipher ID values in a HIP_CIPHER parameter are defined 4805 in Section 5.2.8. New values either from the reserved or 4806 unassigned space are assigned through IETF Review or IESG 4807 Approval. 4809 DI-Type 4811 The four-bit DI-Type values in a HOST_ID parameter are defined in 4812 Section 5.2.9. New values are assigned through IETF Review or 4813 IESG Approval. 4815 Notify Message Type 4817 The 16-bit Notify Message Type values in a NOTIFICATION parameter 4818 are defined in Section 5.2.19. 4820 Notify Message Type values 1-10 are used for informing about 4821 errors in packet structures, values 11-20 for informing about 4822 problems in parameters containing cryptographic related material, 4823 values 21-30 for informing about problems in authentication or 4824 packet integrity verification. Parameter numbers above 30 can be 4825 used for informing about other types of errors or events. Values 4826 51-8191 are error types reserved to be allocated by IANA. Values 4827 8192-16383 are error types for experimentation. Values 16385- 4828 40959 are status types to be allocated by IANA, and values 40960- 4829 65535 are status types for experimentation. New values in ranges 4830 51-8191 and 16385-40959 are assigned through First Come First 4831 Served, with Specification Required. 4833 10. Acknowledgments 4835 The drive to create HIP came to being after attending the MALLOC 4836 meeting at the 43rd IETF meeting. Baiju Patel and Hilarie Orman 4837 really gave the original author, Bob Moskowitz, the assist to get HIP 4838 beyond 5 paragraphs of ideas. It has matured considerably since the 4839 early versions thanks to extensive input from IETFers. Most 4840 importantly, its design goals are articulated and are different from 4841 other efforts in this direction. Particular mention goes to the 4842 members of the NameSpace Research Group of the IRTF. Noel Chiappa 4843 provided valuable input at early stages of discussions about 4844 identifier handling and Keith Moore the impetus to provide 4845 resolvability. Steve Deering provided encouragement to keep working, 4846 as a solid proposal can act as a proof of ideas for a research group. 4848 Many others contributed; extensive security tips were provided by 4849 Steve Bellovin. Rob Austein kept the DNS parts on track. Paul 4850 Kocher taught Bob Moskowitz how to make the puzzle exchange expensive 4851 for the Initiator to respond, but easy for the Responder to validate. 4852 Bill Sommerfeld supplied the Birthday concept, which later evolved 4853 into the R1 generation counter, to simplify reboot management. Erik 4854 Nordmark supplied the CLOSE-mechanism for closing connections. 4855 Rodney Thayer and Hugh Daniels provided extensive feedback. In the 4856 early times of this document, John Gilmore kept Bob Moskowitz 4857 challenged to provide something of value. 4859 During the later stages of this document, when the editing baton was 4860 transferred to Pekka Nikander, the input from the early implementors 4861 was invaluable. Without having actual implementations, this document 4862 would not be on the level it is now. 4864 In the usual IETF fashion, a large number of people have contributed 4865 to the actual text or ideas. The list of these people include Jeff 4866 Ahrenholz, Francis Dupont, Derek Fawcus, George Gross, Andrew 4867 McGregor, Julien Laganier, Miika Komu, Mika Kousa, Jan Melen, Henrik 4868 Petander, Michael Richardson, Rene Hummen, Tim Shepard, Jorma Wall, 4869 and Jukka Ylitalo. Our apologies to anyone whose name is missing. 4871 Once the HIP Working Group was founded in early 2004, a number of 4872 changes were introduced through the working group process. Most 4873 notably, the original document was split in two, one containing the 4874 base exchange and the other one defining how to use ESP. Some 4875 modifications to the protocol proposed by Aura, et al., [AUR03] were 4876 added at a later stage. 4878 11. Changes from RFC 5201 4880 This section summarizes the changes made from [RFC5201]. 4882 11.1. Changes from draft-ietf-hip-rfc5201-bis-06 4884 o Made echoing the R1_COUNTER in the I2 mandatory if the R1 contains 4885 an R1_COUNTER. This required to make the R1 counter a critical 4886 parameter. Hence, the parameter type number of the R1_COUNTER 4887 changed from 128 to 129. 4889 o Made KDF dependent on DH Group to enable negotiation of the KDF. 4891 11.2. Changes from draft-ietf-hip-rfc5201-bis-05 4893 o Changed type number of DH_GROUP_LIST from 2151 to 511 because it 4894 was in the number space that is reserved for the HIP transport 4895 mode negotiations. 4897 o Added transport form type list parameter. Transport forms are now 4898 negotiated with this list instead of by their order in the HIP 4899 packet. This allows to remove the exception of the transport 4900 format parameters that were ordered by their preference instead of 4901 by their type number. This should remove complexity from 4902 implementations. 4904 o Clarify that in HIP signature processing, the restored checksum 4905 and length fields have been rendered invalid by the previous 4906 steps. 4908 o Clarify behavior for when UPDATE does not contain SEQ or ACQ 4909 (disallow this). 4911 o For namespace changes, changed "IETF Review" to "IETF Review or 4912 IESG Approval". 4914 o Addressed IESG comment about ignoring packet IP addresses. 4916 o Permit using Anonymous HI control in packets other than R1/I2. 4918 o Fixed minor reference error (RFC2418, RFC2410). 4920 o Deleted comment that NULL-ENCRYPTION SHOULD NOT be configurable 4921 via the UI. 4923 o Editorial changes. 4925 11.3. Changes from draft-ietf-hip-rfc5201-bis-04 4927 o Clarifications of the Security Considerations section. One DoS 4928 defense mechanism was changed to be more effective and less prone 4929 to misuse. 4931 o Minor clarifications of the state machine. 4933 o Clarified text on HIP puzzle. 4935 o Added names and references for figures. 4937 o Extended the definitions section. 4939 o Added a reference to the HIP Version 1 certificate document. 4941 o Added Initiator, Responder, HIP association, and signed data to 4942 the definitions section. 4944 o Changed parameter figure for PUZZLE and SOLUTION to use 4945 RHASH_len/8 instead of n-byte. 4947 o Replaced occurrences of SHOULD not with SHOULD NOT. 4949 o Changed text to reflect the fact that several 4950 ECHO_REQUEST_UNSIGNED parameters may be present in an R1 and 4951 several ECHO_RESPONSE parameters may be present in an I2. 4953 o Added text on verifying the ECHO_RESPONSE_SIGNED parameter in 4954 CLOSE_ACK. 4956 o Changed wording from HMAC to HIP_MAC in Section 5.3.8. 4958 o Reflected fact that the UPDATE packet MAY include zero or more 4959 ACKs. 4961 o Added BEX to Definitions section. 4963 o Changed HIP_SIGNATURE algorithm field from 8 bit to 16 bit to 4964 achieve alignment with the HOST_ID parameters. 4966 o Fixed the wrong figures of the SEQ and ACK parameters. SEQ always 4967 contains ONE update ID. ACK may acknowledge SEVERAL update IDs. 4969 o Added wording that several NOTIFY parameters may be present in a 4970 HIP packet. 4972 o Changed wording for the ECHO_RESPONSE_SIGNED parameter. Also 4973 lifted the restriction that only one ECHO_RESPONSE_UNSIGNED 4974 parameter MUST be present in each HIP control packet. This did 4975 contradict the definition of the ECHO_RESPONSE_UNSIGNED parameter. 4977 o Changed IETF Consensus to IETF Review or IESG Approval in IANA 4978 section. 4980 o Aligned use of I, J, and K. Now I is #I, J is #J and K is #K 4981 throughout the document. 4983 o Updated references. 4985 o Editorial changes. 4987 11.4. Changes from draft-ietf-hip-rfc5201-bis-03 4989 o Editorial changes to improve clarity and readability. 4991 o Removed obsoleted (not applicable) attack from security 4992 consideration section. 4994 o Added a requirement that hosts MUST support processing of ACK 4995 parameters with several SEQ numbers even when they do not support 4996 sending such parameters. 4998 o Removed note on memory bound puzzles. The use of memory bound 4999 puzzles was reconsidered but no convincing arguments for inclusion 5000 in this document have been made on the list. 5002 o Changed references to reference the new bis documents. 5004 o Specified the ECC curves and the hashes used for these. 5006 o Specified representation of ECC curves in the HI. 5008 o Added text on the dependency between RHASH and HMAC. 5010 o Rephrased part of the security considerations to make them 5011 clearer. 5013 o Clarified the use of HITs in opportunistic mode. 5015 o Clarified the difference between HIP_MAC and HIP_MAC_2 as well as 5016 between SIGNATURE and SIGNATURE_2. 5018 o Changed NOTIFY name for value 44 from SERVER_BUSY_PLEASE_RETRY to 5019 RESPONDER_BUSY_PLEASE_RETRY. 5021 o Mentioned that there are multiple valid puzzle solutions. 5023 11.5. Changes from draft-ietf-hip-rfc5201-bis-02 5025 o Added recommendation to not use puzzle #I twice for the same host 5026 to avoid identical key material. 5028 o Revised state machine and added missing event handling. 5030 o Added UNSUPPORTED_HIT_SUITE to NOTIFY to indicate unsupported HIT 5031 suites. 5033 o Revised parameter type numbers (corresponding to IANA allocations) 5034 and added missing "free for experimentation" range to the 5035 description. 5037 o Clarifying note on the use of the C bit in the parameter type 5038 numbers. 5040 11.6. Changes from draft-ietf-hip-rfc5201-bis-01 5042 o Changed RHASH-len to RHASH_len to avoid confusion in calculations 5043 (- could be minus) 5045 o Added RHASH_len to list of abbreviations 5047 o Fixed length of puzzle #I and #J to be 1*RHASH_len 5049 o Changed RHASH-len to RHASH_len to avoid confusion in calculations 5050 (- could be minus) 5052 o Added RHASH_len to list of abbreviations 5054 o Fixed length of puzzle #I and #J to be 1*RHASH_len 5056 o Included HIT_SUITEs. 5058 o Added DH negotiation to I1 and R1. 5060 o Added DH_LIST parameter. 5062 o Added text for DH Group negotiation. 5064 o Removed second DH public value from DH parameter. 5066 o Added ECC to HI generation. 5068 o Added Responder HIT selection to opportunistic mode. 5070 o Added ECDSA HI text and references (not complete yet). 5072 o Added separate section on aborting BEX. 5074 o Added separate section on downgrade attack prevention. 5076 o Added text about DH Group selection for use cases without I1. 5078 o Removed type range allocation for parameters related to HIP 5079 transform types. 5081 o New type range allocation for parameters that are only covered by 5082 a signature if a signature is present (Applies to DH_GROUP_LIST). 5084 o Renamed HIP_TRANSFORM to HIP_CIPHER and removed hashes from it - 5085 hashes are determined by RHASH. 5087 o The length of #I and #J for the puzzle now depends on RHASH. 5089 o New keymat generation. 5091 o Puzzle seed and solution now use RHASH and have variable length. 5093 o Moved timing definitions closer to state machine. 5095 o Simplified text regarding puzzle lifetime. 5097 o Clarified the description of the use of #I in the puzzle 5099 o Removed "Opportunistic mode" description from general definitions. 5101 o More consistency across the old RFC5201 text. Aligned 5102 capitalization and abbreviations. 5104 o Extended protocol overview to include restart option. 5106 o Extended state machine to include restart option because of 5107 unsupported Algorithms. 5109 o Replaced SHA-1 with SHA-256 for required implementation. 5111 o Added OGA list parameter (715) for detecting the Responder's set 5112 of OGAs. 5114 o Added Appendix on ORCHID use in HITs. 5116 o Added truncated SHA-256 option for HITs. 5118 o Added truncated SHA-1 option for HITs. 5120 o Added text about new ORCHID structure to HIT overview. 5122 o Moved Editor role to Robert Moskowitz. 5124 o Added SHA-256 to puzzle parameter. 5126 o Generalized LTRUNC to be hash-function agnostic. 5128 o Added text about RHASH depending on OGA. 5130 11.7. Changes from draft-ietf-hip-rfc5201-bis-00 5132 o Added reasoning why BIS document is needed. 5134 11.8. Contents of draft-ietf-hip-rfc5201-bis-00 5136 o RFC5201 was submitted as draft-RFC. 5138 12. References 5140 12.1. Normative References 5142 [FIPS.180-2.2002] National Institute of Standards and 5143 Technology, "Secure Hash Standard", 5144 FIPS PUB 180-2, August 2002, . 5148 [I-D.ietf-hip-rfc4843-bis] Laganier, J. and F. Dupont, "An IPv6 5149 Prefix for Overlay Routable Cryptographic 5150 Hash Identifiers (ORCHID)", 5151 draft-ietf-hip-rfc4843-bis-00 (work in 5152 progress), August 2010. 5154 [I-D.ietf-hip-rfc5202-bis] Jokela, P., Moskowitz, R., Nikander, P., 5155 and J. Melen, "Using the Encapsulating 5156 Security Payload (ESP) Transport Format 5157 with the Host Identity Protocol (HIP)", 5158 draft-ietf-hip-rfc5202-bis-00 (work in 5159 progress), September 2010. 5161 [RFC0768] Postel, J., "User Datagram Protocol", 5162 STD 6, RFC 768, August 1980. 5164 [RFC1035] Mockapetris, P., "Domain names - 5165 implementation and specification", 5166 STD 13, RFC 1035, November 1987. 5168 [RFC2119] Bradner, S., "Key words for use in RFCs 5169 to Indicate Requirement Levels", BCP 14, 5170 RFC 2119, March 1997. 5172 [RFC2404] Madson, C. and R. Glenn, "The Use of 5173 HMAC-SHA-1-96 within ESP and AH", 5174 RFC 2404, November 1998. 5176 [RFC2410] Glenn, R. and S. Kent, "The NULL 5177 Encryption Algorithm and Its Use With 5178 IPsec", RFC 2410, November 1998. 5180 [RFC2451] Pereira, R. and R. Adams, "The ESP CBC- 5181 Mode Cipher Algorithms", RFC 2451, 5182 November 1998. 5184 [RFC2460] Deering, S. and R. Hinden, "Internet 5185 Protocol, Version 6 (IPv6) 5186 Specification", RFC 2460, December 1998. 5188 [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the 5189 Domain Name System (DNS)", RFC 2536, 5190 March 1999. 5192 [RFC2898] Kaliski, B., "PKCS #5: Password-Based 5193 Cryptography Specification Version 2.0", 5194 RFC 2898, September 2000. 5196 [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA 5197 KEYs in the Domain Name System (DNS)", 5198 RFC 3110, May 2001. 5200 [RFC3484] Draves, R., "Default Address Selection 5201 for Internet Protocol version 6 (IPv6)", 5202 RFC 3484, February 2003. 5204 [RFC3526] Kivinen, T. and M. Kojo, "More Modular 5205 Exponential (MODP) Diffie-Hellman groups 5206 for Internet Key Exchange (IKE)", 5207 RFC 3526, May 2003. 5209 [RFC3602] Frankel, S., Glenn, R., and S. Kelly, 5210 "The AES-CBC Cipher Algorithm and Its Use 5211 with IPsec", RFC 3602, September 2003. 5213 [RFC3972] Aura, T., "Cryptographically Generated 5214 Addresses (CGA)", RFC 3972, March 2005. 5216 [RFC4034] Arends, R., Austein, R., Larson, M., 5217 Massey, D., and S. Rose, "Resource 5218 Records for the DNS Security Extensions", 5219 RFC 4034, March 2005. 5221 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. 5222 Eronen, "The Network Access Identifier", 5223 RFC 4282, December 2005. 5225 [RFC4443] Conta, A., Deering, S., and M. Gupta, 5226 "Internet Control Message Protocol 5227 (ICMPv6) for the Internet Protocol 5228 Version 6 (IPv6) Specification", 5229 RFC 4443, March 2006. 5231 [RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 5232 Authentication Using the Elliptic Curve 5233 Digital Signature Algorithm (ECDSA)", 5234 RFC 4754, January 2007. 5236 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC- 5237 SHA-256, HMAC-SHA-384, and HMAC-SHA-512 5238 with IPsec", RFC 4868, May 2007. 5240 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., 5241 and T. Henderson, "Host Identity 5242 Protocol", RFC 5201, April 2008. 5244 [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with 5245 RSA in DNSKEY and RRSIG Resource Records 5246 for DNSSEC", RFC 5702, October 2009. 5248 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based 5249 Extract-and-Expand Key Derivation 5250 Function (HKDF)", RFC 5869, May 2010. 5252 [RFC5903] Fu, D. and J. Solinas, "Elliptic Curve 5253 Groups modulo a Prime (ECP Groups) for 5254 IKE and IKEv2", RFC 5903, June 2010. 5256 [RFC6090] McGrew, D., Igoe, K., and M. Salter, 5257 "Fundamental Elliptic Curve Cryptography 5258 Algorithms", RFC 6090, February 2011. 5260 12.2. Informative References 5262 [AUR03] Aura, T., Nagarajan, A., and A. Gurtov, 5263 "Analysis of the HIP Base Exchange 5264 Protocol", in Proceedings of 10th 5265 Australasian Conference on Information 5266 Security and Privacy, July 2003. 5268 [CRO03] Crosby, SA. and DS. Wallach, "Denial of 5269 Service via Algorithmic Complexity 5270 Attacks", in Proceedings of Usenix 5271 Security Symposium 2003, Washington, 5272 DC., August 2003. 5274 [DIF76] Diffie, W. and M. Hellman, "New 5275 Directions in Cryptography", IEEE 5276 Transactions on Information Theory vol. 5277 IT-22, number 6, pages 644-654, Nov 1976. 5279 [FIPS.197.2001] National Institute of Standards and 5280 Technology, "Advanced Encryption Standard 5281 (AES)", FIPS PUB 197, November 2001, . 5285 [I-D.ietf-btns-c-api] Richardson, M., Williams, N., Komu, M., 5286 and S. Tarkoma, "C-Bindings for IPsec 5287 Application Programming Interfaces", 5288 draft-ietf-btns-c-api-04 (work in 5289 progress), March 2009. 5291 [I-D.ietf-hip-cert] Heer, T. and S. Varjonen, "Host Identity 5292 Protocol Certificates", 5293 draft-ietf-hip-cert-09 (work in 5294 progress), January 2011. 5296 [I-D.ietf-hip-rfc4423-bis] Moskowitz, R., "Host Identity Protocol 5297 Architecture", 5298 draft-ietf-hip-rfc4423-bis-02 (work in 5299 progress), February 2011. 5301 [I-D.ietf-hip-rfc5204-bis] Laganier, J. and L. Eggert, "Host 5302 Identity Protocol (HIP) Rendezvous 5303 Extension", draft-ietf-hip-rfc5204-bis-00 5304 (work in progress), August 2010. 5306 [I-D.ietf-hip-rfc5205-bis] Laganier, J., "Host Identity Protocol 5307 (HIP) Domain Name System (DNS) 5308 Extension", draft-ietf-hip-rfc5205-bis-00 5309 (work in progress), August 2010. 5311 [I-D.ietf-hip-rfc5206-bis] Nikander, P., Henderson, T., Vogt, C., 5312 and J. Arkko, "Host Mobility with the 5313 Host Identity Protocol", 5314 draft-ietf-hip-rfc5206-bis-01 (work in 5315 progress), October 2010. 5317 [KAU03] Kaufman, C., Perlman, R., and B. 5318 Sommerfeld, "DoS protection for UDP-based 5319 protocols", ACM Conference on Computer 5320 and Communications Security , Oct 2003. 5322 [KRA03] Krawczyk, H., "SIGMA: The 'SIGn-and-MAc' 5323 Approach to Authenticated Diffie-Hellman 5324 and Its Use in the IKE-Protocols", in 5325 Proceedings of CRYPTO 2003, pages 400- 5326 425, August 2003. 5328 [RFC0792] Postel, J., "Internet Control Message 5329 Protocol", STD 5, RFC 792, 5330 September 1981. 5332 [RFC4306] Kaufman, C., "Internet Key Exchange 5333 (IKEv2) Protocol", RFC 4306, 5334 December 2005. 5336 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines 5337 for Writing an IANA Considerations 5338 Section in RFCs", BCP 26, RFC 5226, 5339 May 2008. 5341 [RFC5338] Henderson, T., Nikander, P., and M. Komu, 5342 "Using the Host Identity Protocol with 5343 Legacy Applications", RFC 5338, 5344 September 2008. 5346 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: 5347 Level 3 Multihoming Shim Protocol for 5348 IPv6", RFC 5533, June 2009. 5350 [SECG] SECG, "Recommended Elliptic Curve Domain 5351 Parameters", SEC 2 , 2000, 5352 . 5354 Appendix A. Using Responder Puzzles 5356 As mentioned in Section 4.1.1, the Responder may delay state creation 5357 and still reject most spoofed I2 packets by using a number of pre- 5358 calculated R1 packets and a local selection function. This appendix 5359 defines one possible implementation in detail. The purpose of this 5360 appendix is to give the implementors an idea on how to implement the 5361 mechanism. If the implementation is based on this appendix, it MAY 5362 contain some local modification that makes an attacker's task harder. 5364 The Responder creates a secret value S, that it regenerates 5365 periodically. The Responder needs to remember the two latest values 5366 of S. Each time the S is regenerated, the R1 generation counter 5367 value is incremented by one. 5369 The Responder generates a pre-signed R1 packet. The signature for 5370 pre-generated R1s must be recalculated when the Diffie-Hellman key is 5371 recomputed or when the R1_COUNTER value changes due to S value 5372 regeneration. 5374 When the Initiator sends the I1 packet for initializing a connection, 5375 the Responder receives the HIT and IP address from the packet, and 5376 generates an #I value for the puzzle. The #I value is set to the 5377 pre-signed R1 packet. 5379 #I value calculation: 5380 #I = Ltrunc( RHASH ( S | HIT-I | HIT-R | IP-I | IP-R ), n) 5381 where n = RHASH_len 5383 The RHASH algorithm is the same that is used to generate the 5384 Responder's HIT value. 5386 From an incoming I2 packet, the Responder receives the required 5387 information to validate the puzzle: HITs, IP addresses, and the 5388 information of the used S value from the R1_COUNTER. Using these 5389 values, the Responder can regenerate the #I, and verify it against 5390 the #I received in the I2 packet. If the #I values match, it can 5391 verify the solution using #I, #J, and difficulty #K. If the #I values 5392 do not match, the I2 is dropped. 5394 puzzle_check: 5395 V := Ltrunc( RHASH( I2.I | I2.hit_i | I2.hit_r | I2.J ), #K ) 5396 if V != 0, drop the packet 5398 If the puzzle solution is correct, the #I and #J values are stored 5399 for later use. They are used as input material when keying material 5400 is generated. 5402 Keeping state about failed puzzle solutions depends on the 5403 implementation. Although it is possible for the Responder not to 5404 keep any state information, it still may do so to protect itself 5405 against certain attacks (see Section 4.1.1). 5407 Appendix B. Generating a Public Key Encoding from an HI 5409 The following pseudo-code illustrates the process to generate a 5410 public key encoding from an HI for both RSA and DSA. 5412 The symbol := denotes assignment; the symbol += denotes appending. 5413 The pseudo-function encode_in_network_byte_order takes two 5414 parameters, an integer (bignum) and a length in bytes, and returns 5415 the integer encoded into a byte string of the given length. 5417 switch ( HI.algorithm ) 5418 { 5420 case RSA: 5421 buffer := encode_in_network_byte_order ( HI.RSA.e_len, 5422 ( HI.RSA.e_len > 255 ) ? 3 : 1 ) 5423 buffer += encode_in_network_byte_order ( HI.RSA.e, HI.RSA.e_len ) 5424 buffer += encode_in_network_byte_order ( HI.RSA.n, HI.RSA.n_len ) 5425 break; 5427 case DSA: 5428 buffer := encode_in_network_byte_order ( HI.DSA.T , 1 ) 5429 buffer += encode_in_network_byte_order ( HI.DSA.Q , 20 ) 5430 buffer += encode_in_network_byte_order ( HI.DSA.P , 64 + 5431 8 * HI.DSA.T ) 5432 buffer += encode_in_network_byte_order ( HI.DSA.G , 64 + 5433 8 * HI.DSA.T ) 5434 buffer += encode_in_network_byte_order ( HI.DSA.Y , 64 + 5435 8 * HI.DSA.T ) 5436 break; 5438 } 5440 Appendix C. Example Checksums for HIP Packets 5442 The HIP checksum for HIP packets is specified in Section 5.1.1. 5443 Checksums for TCP and UDP packets running over HIP-enabled security 5444 associations are specified in Section 3.5. The examples below use IP 5445 addresses of 192.0.2.1 and 192.0.2.2 (and their respective IPv4- 5446 compatible IPv6 formats), and HITs with the prefix of 2001:10 5447 followed by zeros, followed by a decimal 1 or 2, respectively. 5449 The following example is defined only for testing the checksum 5450 calculation. The address format for the IPv4-compatible IPv6 address 5451 is not a valid one, but using these IPv6 addresses when testing an 5452 IPv6 implementation gives the same checksum output as an IPv4 5453 implementation with the corresponding IPv4 addresses. 5455 C.1. IPv6 HIP Example (I1 packet) 5457 Source Address: ::192.0.2.1 5458 Destination Address: ::192.0.2.2 5459 Upper-Layer Packet Length: 40 0x28 5460 Next Header: 139 0x8b 5461 Payload Protocol: 59 0x3b 5462 Header Length: 4 0x4 5463 Packet Type: 1 0x1 5464 Version: 1 0x1 5465 Reserved: 1 0x1 5466 Control: 0 0x0 5467 Checksum: 446 0x1be 5468 Sender's HIT : 2001:10::1 5469 Receiver's HIT: 2001:10::2 5471 C.2. IPv4 HIP Packet (I1 packet) 5473 The IPv4 checksum value for the example I1 packet equals the IPv6 5474 checksum value (since the checksum components due to the IPv4 and 5475 IPv6 pseudo-header are the same). . 5477 C.3. TCP Segment 5479 Regardless of whether IPv6 or IPv4 is used, the TCP and UDP sockets 5480 use the IPv6 pseudo-header format [RFC2460], with the HITs used in 5481 place of the IPv6 addresses. 5483 Sender's HIT: 2001:10::1 5484 Receiver's HIT: 2001:10::2 5485 Upper-Layer Packet Length: 20 0x14 5486 Next Header: 6 0x06 5487 Source port: 65500 0xffdc 5488 Destination port: 22 0x0016 5489 Sequence number: 1 0x00000001 5490 Acknowledgment number: 0 0x00000000 5491 Header length: 20 0x14 5492 Flags: SYN 0x02 5493 Window size: 65535 0xffff 5494 Checksum: 28618 0x6fca 5495 Urgent pointer: 0 0x0000 5497 0x0000: 6000 0000 0014 0640 2001 0010 0000 0000 5498 0x0010: 0000 0000 0000 0001 2001 0010 0000 0000 5499 0x0020: 0000 0000 0000 0002 ffdc 0016 0000 0001 5500 0x0030: 0000 0000 5002 ffff 6fca 0000 5502 Appendix D. ECDH and ECDSA 160 Bit Groups 5504 The ECDH and ECDSA 160-bit group SECP160R1 is rated at 80 bits 5505 symmetric strength. Once this was considered appropriate for one 5506 year of security. Today these groups should be used only when the 5507 host is not powerful enough (e.g., some embedded devices) and when 5508 security requirements are low (e.g., long-term confidentiality is not 5509 required). 5511 Appendix E. HIT Suites and HIT Generation 5513 The HIT as an ORCHID [I-D.ietf-hip-rfc4843-bis] consists of three 5514 parts: A 28-bit prefix, a 4-bit encoding of the ORCHID generation 5515 algorithm (OGA) and the representation of the public key. The OGA is 5516 an index pointing to the specific algorithm by which the public key 5517 and the 96-bit hashed encoding is generated. The OGA is protocol 5518 specific and is to be interpreted as defined below for all protocols 5519 that use the same context ID as HIP. HIP groups sets of valid 5520 combinations of signature and hash algorithms into HIT Suites. These 5521 HIT suites are addressed by an index, which is transmitted in the OGA 5522 field of the ORCHID. 5524 The set of used HIT Suites will be extended to counter the progress 5525 in computation capabilities and vulnerabilities in the employed 5526 algorithms. The intended use of the HIT Suites is to introduce a new 5527 HIT Suite and phase out an old one before it becomes insecure. Since 5528 the 4-bit OGA field only permits 15 HIT Suites (the HIT Suite with ID 5529 0 is reserved) to be used in parallel, phased-out HIT Suites must be 5530 reused at some point. In such a case, there will be a rollover of 5531 the HIT Suite ID and the next newly introduced HIT Suite will start 5532 with a lower HIT Suite index than the previously introduced one. The 5533 rollover effectively deprecates the reused HIT Suite. For a smooth 5534 transition, the HIT Suite should be deprecated a considerable time 5535 before the HIT Suite index is reused. 5537 Since the number of HIT Suites is tightly limited to 16, the HIT 5538 Suites must be assigned carefully. Hence, sets of suitable 5539 algorithms are grouped in a HIT Suite. 5541 The HIT Suite of the Responder's HIT determines the RHASH and the 5542 hash function to be used for the HMAC in HIP control packets as well 5543 as the signature algorithm family used for generating the HI. The 5544 list of HIT Suites is defined in Table 11. 5546 The following HIT Suites are defined for HIT generation. The input 5547 for each generation algorithm is the encoding of the HI as defined in 5548 Section 3.2. The output is 96 bits long and is directly used in the 5549 ORCHID. 5551 +-------+----------+--------------+-------------+-------------------+ 5552 | Index | Hash | HMAC | Signature | Description | 5553 | | function | | algorithm | | 5554 | | | | family | | 5555 +-------+----------+--------------+-------------+-------------------+ 5556 | 0 | | | | Reserved | 5557 | 1 | SHA-1 | HMAC-SHA-1 | RSA, DSA | RSA or DSA HI | 5558 | | | | | hashed with | 5559 | | | | | SHA-1, truncated | 5560 | | | | | to 96 bits | 5561 | 2 | SHA-384 | HMAC-SHA-384 | ECDSA | ECDSA HI hashed | 5562 | | | | | with SHA-384, | 5563 | | | | | truncated to 96 | 5564 | | | | | bits | 5565 | 3 | SHA-1 | HMAC-SHA-1 | ECDSA_LOW | ECDSA_LOW HI | 5566 | | | | | hashed with | 5567 | | | | | SHA-1, truncated | 5568 | | | | | to 96 bits | 5569 +-------+----------+--------------+-------------+-------------------+ 5571 Table 11: HIT Suites 5573 The hash of the responder as defined in the HIT Suite determines the 5574 HMAC to be used for the HMAC parameter. The HMACs currently defined 5575 here are SHA-1 [RFC2404] and HMAC-SHA-384 [RFC4868]. 5577 Authors' Addresses 5579 Robert Moskowitz (editor) 5580 Verizon Telcom and Business 5581 1000 Bent Creek Blvd, Suite 200 5582 Mechanicsburg, PA 5583 USA 5585 EMail: robert.moskowitz@verizonbusiness.com 5587 Tobias Heer 5588 RWTH Aachen University, Communication and Distributed Systems Group 5589 Ahornstrasse 55 5590 Aachen 52062 5591 Germany 5593 EMail: heer@cs.rwth-aachen.de 5594 URI: http://www.comsys.rwth-aachen.de/team/tobias-heer/ 5596 Petri Jokela 5597 Ericsson Research NomadicLab 5598 JORVAS FIN-02420 5599 FINLAND 5601 Phone: +358 9 299 1 5602 EMail: petri.jokela@nomadiclab.com 5604 Thomas R. Henderson 5605 The Boeing Company 5606 P.O. Box 3707 5607 Seattle, WA 5608 USA 5610 EMail: thomas.r.henderson@boeing.com