idnits 2.17.1 draft-ietf-hip-rfc5201-bis-10.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 3 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 2186 has weird spacing: '...c Value leng...' == Line 2188 has weird spacing: '...c Value the ...' == Line 2713 has weird spacing: '...ication info...' == Line 2852 has weird spacing: '...ue data opaqu...' == Line 2882 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 (November 23, 2012) is 4165 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) == Missing Reference: 'FIPS 186-3' is mentioned on line 2320, but not defined == Outdated reference: A later version (-08) exists of draft-ietf-hip-rfc4843-bis-02 == Outdated reference: A later version (-07) exists of draft-ietf-hip-rfc5202-bis-01 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Downref: Normative reference to an Informational RFC: RFC 2785 ** Obsolete normative reference: RFC 2898 (Obsoleted by RFC 8018) ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) ** 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 (-20) exists of draft-ietf-hip-rfc4423-bis-05 == Outdated reference: A later version (-08) exists of draft-ietf-hip-rfc5204-bis-02 == Outdated reference: A later version (-10) exists of draft-ietf-hip-rfc5205-bis-02 == Outdated reference: A later version (-14) exists of draft-ietf-hip-rfc5206-bis-04 -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 6253 (Obsoleted by RFC 8002) Summary: 11 errors (**), 0 flaws (~~), 17 warnings (==), 6 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 27, 2013 Communication and Distributed 7 Systems Group 8 P. Jokela 9 Ericsson Research NomadicLab 10 T. Henderson 11 The Boeing Company 12 November 23, 2012 14 Host Identity Protocol Version 2 (HIPv2) 15 draft-ietf-hip-rfc5201-bis-10 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 27, 2013. 53 Copyright Notice 55 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . . . . 24 106 4.4. HIP State Machine . . . . . . . . . . . . . . . . . . . 25 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 . . . . . . . . . . . . 34 111 4.5. User Data Considerations . . . . . . . . . . . . . . . . 36 112 4.5.1. TCP and UDP Pseudo-Header Computation for User Data . 36 113 4.5.2. Sending Data on HIP Packets . . . . . . . . . . . . . 36 114 4.5.3. Transport Formats . . . . . . . . . . . . . . . . . . 36 115 4.5.4. Reboot, Timeout, and Restart of HIP . . . . . . . . . 36 116 4.6. Certificate Distribution . . . . . . . . . . . . . . . . 37 117 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 37 118 5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 37 119 5.1.1. Checksum . . . . . . . . . . . . . . . . . . . . . . 38 120 5.1.2. HIP Controls . . . . . . . . . . . . . . . . . . . . 39 121 5.1.3. HIP Fragmentation Support . . . . . . . . . . . . . . 39 122 5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 40 123 5.2.1. TLV Format . . . . . . . . . . . . . . . . . . . . . 43 124 5.2.2. Defining New Parameters . . . . . . . . . . . . . . . 45 125 5.2.3. R1_COUNTER . . . . . . . . . . . . . . . . . . . . . 46 126 5.2.4. PUZZLE . . . . . . . . . . . . . . . . . . . . . . . 47 127 5.2.5. SOLUTION . . . . . . . . . . . . . . . . . . . . . . 48 128 5.2.6. DH_GROUP_LIST . . . . . . . . . . . . . . . . . . . . 49 129 5.2.7. DIFFIE_HELLMAN . . . . . . . . . . . . . . . . . . . 50 130 5.2.8. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . 51 131 5.2.9. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 52 132 5.2.10. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 54 133 5.2.11. TRANSPORT_FORMAT_LIST . . . . . . . . . . . . . . . . 55 134 5.2.12. HIP_MAC . . . . . . . . . . . . . . . . . . . . . . . 56 135 5.2.13. HIP_MAC_2 . . . . . . . . . . . . . . . . . . . . . . 56 136 5.2.14. HIP_SIGNATURE . . . . . . . . . . . . . . . . . . . . 57 137 5.2.15. HIP_SIGNATURE_2 . . . . . . . . . . . . . . . . . . . 58 138 5.2.16. SEQ . . . . . . . . . . . . . . . . . . . . . . . . . 58 139 5.2.17. ACK . . . . . . . . . . . . . . . . . . . . . . . . . 59 140 5.2.18. ENCRYPTED . . . . . . . . . . . . . . . . . . . . . . 60 141 5.2.19. NOTIFICATION . . . . . . . . . . . . . . . . . . . . 61 142 5.2.20. ECHO_REQUEST_SIGNED . . . . . . . . . . . . . . . . . 65 143 5.2.21. ECHO_REQUEST_UNSIGNED . . . . . . . . . . . . . . . . 65 144 5.2.22. ECHO_RESPONSE_SIGNED . . . . . . . . . . . . . . . . 66 145 5.2.23. ECHO_RESPONSE_UNSIGNED . . . . . . . . . . . . . . . 67 146 5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . 67 147 5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 68 148 5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 69 149 5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 72 150 5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 73 151 5.3.5. UPDATE - the HIP Update Packet . . . . . . . . . . . 73 152 5.3.6. NOTIFY - the HIP Notify Packet . . . . . . . . . . . 74 153 5.3.7. CLOSE - the HIP Association Closing Packet . . . . . 75 154 5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet . . 75 155 5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . 76 156 5.4.1. Invalid Version . . . . . . . . . . . . . . . . . . . 76 157 5.4.2. Other Problems with the HIP Header and Packet 158 Structure . . . . . . . . . . . . . . . . . . . . . . 76 159 5.4.3. Invalid Puzzle Solution . . . . . . . . . . . . . . . 76 160 5.4.4. Non-Existing HIP Association . . . . . . . . . . . . 77 161 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 77 162 6.1. Processing Outgoing Application Data . . . . . . . . . . 78 163 6.2. Processing Incoming Application Data . . . . . . . . . . 79 164 6.3. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 79 165 6.4. HIP_MAC and SIGNATURE Calculation and Verification . . . 81 166 6.4.1. HMAC Calculation . . . . . . . . . . . . . . . . . . 81 167 6.4.2. Signature Calculation . . . . . . . . . . . . . . . . 84 168 6.5. HIP KEYMAT Generation . . . . . . . . . . . . . . . . . 86 169 6.6. Initiation of a HIP Base Exchange . . . . . . . . . . . 87 170 6.6.1. Sending Multiple I1 Packets in Parallel . . . . . . . 88 171 6.6.2. Processing Incoming ICMP Protocol Unreachable 172 Messages . . . . . . . . . . . . . . . . . . . . . . 88 173 6.7. Processing Incoming I1 Packets . . . . . . . . . . . . . 89 174 6.7.1. R1 Management . . . . . . . . . . . . . . . . . . . . 90 175 6.7.2. Handling Malformed Messages . . . . . . . . . . . . . 91 176 6.8. Processing Incoming R1 Packets . . . . . . . . . . . . . 91 177 6.8.1. Handling of Malformed Messages . . . . . . . . . . . 93 178 6.9. Processing Incoming I2 Packets . . . . . . . . . . . . . 94 179 6.9.1. Handling of Malformed Messages . . . . . . . . . . . 96 180 6.10. Processing of Incoming R2 Packets . . . . . . . . . . . 96 181 6.11. Sending UPDATE Packets . . . . . . . . . . . . . . . . . 97 182 6.12. Receiving UPDATE Packets . . . . . . . . . . . . . . . . 98 183 6.12.1. Handling a SEQ Parameter in a Received UPDATE 184 Message . . . . . . . . . . . . . . . . . . . . . . . 99 185 6.12.2. Handling an ACK Parameter in a Received UPDATE 186 Packet . . . . . . . . . . . . . . . . . . . . . . . 100 187 6.13. Processing of NOTIFY Packets . . . . . . . . . . . . . . 100 188 6.14. Processing CLOSE Packets . . . . . . . . . . . . . . . . 100 189 6.15. Processing CLOSE_ACK Packets . . . . . . . . . . . . . . 101 190 6.16. Handling State Loss . . . . . . . . . . . . . . . . . . 101 191 7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 101 192 8. Security Considerations . . . . . . . . . . . . . . . . . . . 102 193 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 105 194 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 107 195 11. Changes from RFC 5201 . . . . . . . . . . . . . . . . . . . . 108 196 11.1. Changes from draft-ietf-hip-rfc5201-bis-09 . . . . . . . 108 197 11.2. Changes from draft-ietf-hip-rfc5201-bis-08 . . . . . . . 108 198 11.3. Changes from draft-ietf-hip-rfc5201-bis-07 . . . . . . . 108 199 11.4. Changes from draft-ietf-hip-rfc5201-bis-06 . . . . . . . 108 200 11.5. Changes from draft-ietf-hip-rfc5201-bis-05 . . . . . . . 109 201 11.6. Changes from draft-ietf-hip-rfc5201-bis-04 . . . . . . . 109 202 11.7. Changes from draft-ietf-hip-rfc5201-bis-03 . . . . . . . 111 203 11.8. Changes from draft-ietf-hip-rfc5201-bis-02 . . . . . . . 111 204 11.9. Changes from draft-ietf-hip-rfc5201-bis-01 . . . . . . . 112 205 11.10. Changes from draft-ietf-hip-rfc5201-bis-00 . . . . . . . 114 206 11.11. Contents of draft-ietf-hip-rfc5201-bis-00 . . . . . . . 114 207 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 114 208 12.1. Normative References . . . . . . . . . . . . . . . . . . 114 209 12.2. Informative References . . . . . . . . . . . . . . . . . 117 210 Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 119 211 Appendix B. Generating a Public Key Encoding from an HI . . . . 120 212 Appendix C. Example Checksums for HIP Packets . . . . . . . . . 120 213 C.1. IPv6 HIP Example (I1 packet) . . . . . . . . . . . . . . 121 214 C.2. IPv4 HIP Packet (I1 packet) . . . . . . . . . . . . . . 121 215 C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . 122 216 Appendix D. ECDH and ECDSA 160 Bit Groups . . . . . . . . . . . 122 217 Appendix E. HIT Suites and HIT Generation . . . . . . . . . . . 122 219 1. Introduction 221 This document specifies the details of the Host Identity Protocol 222 (HIP). A high-level description of the protocol and the underlying 223 architectural thinking is available in the separate HIP architecture 224 description [I-D.ietf-hip-rfc4423-bis]. Briefly, the HIP 225 architecture proposes an alternative to the dual use of IP addresses 226 as "locators" (routing labels) and "identifiers" (endpoint, or host, 227 identifiers). In HIP, public cryptographic keys, of a public/private 228 key pair, are used as Host Identifiers, to which higher layer 229 protocols are bound instead of an IP address. By using public keys 230 (and their representations) as host identifiers, dynamic changes to 231 IP address sets can be directly authenticated between hosts, and if 232 desired, strong authentication between hosts at the TCP/IP stack 233 level can be obtained. 235 This memo specifies the base HIP protocol ("base exchange") used 236 between hosts to establish an IP-layer communications context, called 237 a HIP association, prior to communications. It also defines a packet 238 format and procedures for updating an active HIP association. Other 239 elements of the HIP architecture are specified in other documents, 240 such as: 242 o "Using the Encapsulating Security Payload (ESP) transport format 243 with the Host Identity Protocol (HIP)" [I-D.ietf-hip-rfc5202-bis]: 244 how to use the Encapsulating Security Payload (ESP) for integrity 245 protection and optional encryption 247 o "Host Mobility with the Host Identity Protocol" 248 [I-D.ietf-hip-rfc5206-bis]: how to support host mobility in HIP 250 o "Host Identity Protocol (HIP) Domain Name System (DNS) Extensions" 251 [I-D.ietf-hip-rfc5205-bis]: how to extend DNS to contain Host 252 Identity information 254 o "Host Identity Protocol (HIP) Rendezvous Extension" 255 [I-D.ietf-hip-rfc5204-bis]: using a rendezvous mechanism to 256 contact mobile HIP hosts 258 Since the HIP Base Exchange was first developed, there have been a 259 few advances in cryptography and attacks against cryptographic 260 systems. As a result, all cryptographic protocols need to be agile. 261 That is, it should be a part of the protocol to be able to switch 262 from one cryptographic primitive to another. It is important to 263 support a reasonable set of mainstream algorithms to cater for 264 different use cases and allow moving away from algorithms that are 265 later discovered to be vulnerable This update to the Base Exchange 266 includes this needed cryptographic agility while addressing the 267 downgrade attacks that such flexibility introduces. In particular, 268 Elliptic Curve support by Elliptic Curve DSA (ECDSA) and Elliptic 269 Curve Diffie-Hellman (ECDH) and alternative hash functions have been 270 added. 272 1.1. A New Namespace and Identifiers 274 The Host Identity Protocol introduces a new namespace, the Host 275 Identity namespace. Some ramifications of this new namespace are 276 explained in the HIP architecture description 277 [I-D.ietf-hip-rfc4423-bis]. 279 There are two main representations of the Host Identity, the full 280 Host Identity (HI) and the Host Identity Tag (HIT). The HI is a 281 public key and directly represents the Identity of a host. Since 282 there are different public key algorithms that can be used with 283 different key lengths, the HI, as such, is unsuitable for use as a 284 packet identifier, or as an index into the various state-related 285 implementation structures needed to support HIP. Consequently, a 286 hash of the HI, the Host Identity Tag (HIT), is used as the 287 operational representation. The HIT is 128 bits long and is used in 288 the HIP headers and to index the corresponding state in the end 289 hosts. The HIT has an important security property in that it is 290 self-certifying (see Section 3). 292 1.2. The HIP Base Exchange (BEX) 294 The HIP base exchange is a two-party cryptographic protocol used to 295 establish communications context between hosts. The base exchange is 296 a SIGMA-compliant [KRA03] four-packet exchange. The first party is 297 called the Initiator and the second party the Responder. The 298 protocol exchanges Diffie-Hellman [DIF76] keys in the 2nd and 3rd 299 packets, and authenticates the parties in the 3rd and 4th packets. 300 The four-packet design helps to make HIP DoS resilient. It allows 301 the Responder to stay stateless until the IP address and the 302 cryptographic puzzle is verified. The Responder starts the puzzle 303 exchange in the 2nd packet, with the Initiator completing it in the 304 3rd packet before the Responder stores any state from the exchange. 306 The exchange can use the Diffie-Hellman output to encrypt the Host 307 Identity of the Initiator in the 3rd packet (although Aura, et al., 308 [AUR03] notes that such operation may interfere with packet- 309 inspecting middleboxes), or the Host Identity may instead be sent 310 unencrypted. The Responder's Host Identity is not protected. It 311 should be noted, however, that both the Initiator's and the 312 Responder's HITs are transported as such (in cleartext) in the 313 packets, allowing an eavesdropper with a priori knowledge about the 314 parties to identify them by their HITs. Hence, encrypting the HI of 315 any party does not provide privacy against such attacker. 317 Data packets start to flow after the 4th packet. The 3rd and 4th HIP 318 packets may carry a data payload in the future. However, the details 319 of this may be defined later. 321 An existing HIP association can be updated using the update mechanism 322 defined in this document, and when the association is no longer 323 needed, it can be closed using the defined closing mechanism. 325 Finally, HIP is designed as an end-to-end authentication and key 326 establishment protocol, to be used with Encapsulated Security Payload 327 (ESP) [I-D.ietf-hip-rfc5202-bis] and other end-to-end security 328 protocols. The base protocol does not cover all the fine-grained 329 policy control found in Internet Key Exchange (IKE) [RFC4306] that 330 allows IKE to support complex gateway policies. Thus, HIP is not a 331 complete replacement for IKE. 333 1.3. Memo Structure 335 The rest of this memo is structured as follows. Section 2 defines 336 the central keywords, notation, and terms used throughout the rest of 337 the document. Section 3 defines the structure of the Host Identity 338 and its various representations. Section 4 gives an overview of the 339 HIP base exchange protocol. Sections 5 and 6 define the detailed 340 packet formats and rules for packet processing. Finally, Sections 7, 341 8, and 9 discuss policy, security, and IANA considerations, 342 respectively. 344 2. Terms and Definitions 346 2.1. Requirements Terminology 348 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 349 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 350 document are to be interpreted as described in RFC 2119 [RFC2119]. 352 2.2. Notation 354 [x] indicates that x is optional. 356 {x} indicates that x is encrypted. 358 X(y) indicates that y is a parameter of X. 360 i indicates that x exists i times. 362 --> signifies "Initiator to Responder" communication (requests). 364 <-- signifies "Responder to Initiator" communication (replies). 366 | signifies concatenation of information (e.g., X | Y is the 367 concatenation of X with Y). 369 Ltrunc (H(x), K) denotes the lowest order #K bits of the result of 370 the hash function H on the input x. 372 2.3. Definitions 374 HIP Base Exchange (BEX): the handshake for establishing a new HIP 375 association. 377 Host Identity (HI): The public key of the signature algorithm that 378 represents the identity of the host. In HIP, a host proves its 379 identity by creating a signature with the private key belonging to 380 its HI (c.f. Section 3). 382 Host Identity Tag (HIT): A shorthand for the HI in IPv6 format. It 383 is generated by hashing the HI (c.f. Section 3.1). 385 HIT Suite: A HIT Suite groups all cryptographic algorithms that are 386 required to generate and use an HI and its HIT. In particular, 387 these algorithms are: 1) the public key signature algorithm and 2) 388 the hash function, 3) the truncation (c.f. Appendix E). 390 HIP association: The shared state between two peers after 391 completion of the BEX. 393 Initiator: The host that initiates the BEX. This role is typically 394 forgotten once the BEX is completed. 396 Responder: The host that responds to the Initiator in the BEX. 397 This role is typically forgotten once the BEX is completed. 399 Responder's HIT Hash Algorithm (RHASH): The Hash algorithm used for 400 various hash calculations in this document. The algorithm is the 401 same as is used to generate the Responder's HIT. The RHASH is the 402 hash function defined by the HIT Suite of the Responder's HIT 403 (c.f. Appendix E). 405 Length of the Responder's HIT Hash Algorithm (RHASH_len): The 406 natural output length of RHASH in bits. 408 Signed data: Data that is signed is protected by a digital 409 signature that was created by the sender of the data by using the 410 private key of its HI. 412 KDF: The Key Derivation Function (KDF) is used for deriving the 413 symmetric keys from the Diffie-Hellman key exchange. 415 KEYMAT: The keying material derived from the Diffie-Hellman key 416 exchange by using the KDF. Symmetric keys for encryption and 417 integrity protection of HIP control and payload packets are drawn 418 from this keying material. 420 3. Host Identity (HI) and its Structure 422 In this section, the properties of the Host Identity and Host 423 Identity Tag are discussed, and the exact format for them is defined. 424 In HIP, the public key of an asymmetric key pair is used as the Host 425 Identity (HI). Correspondingly, the host itself is defined as the 426 entity that holds the private key of the key pair. See the HIP 427 architecture specification [I-D.ietf-hip-rfc4423-bis] for more 428 details on the difference between an identity and the corresponding 429 identifier. 431 HIP implementations MUST support the Rivest Shamir Adelman (RSA) 432 [RFC3110] public key algorithm and the Elliptic Curve Digital 433 Signature Algorithm (ECDSA) for generating the HI as defined in 434 Section 5.2.9. Additional algorithms MAY be supported. 436 A hashed encoding of the HI, the Host Identity Tag (HIT), is used in 437 protocols to represent the Host Identity. The HIT is 128 bits long 438 and has the following three key properties: i) it is the same length 439 as an IPv6 address and can be used in fixed address-sized fields in 440 APIs and protocols, ii) it is self-certifying (i.e., given a HIT, it 441 is computationally hard to find a Host Identity key that matches the 442 HIT), and iii) the probability of a HIT collision between two hosts 443 is very low, hence, it is infeasible for an attacker to find a 444 collision with a HIT that is in use. For details on the security 445 properties of the HIT see [I-D.ietf-hip-rfc4423-bis]. 447 The structure of the HIT is defined in [I-D.ietf-hip-rfc4843-bis]. 448 The HIT is an Overlay Routable Cryptographic Hash Identifier (ORCHID) 449 and consists of three parts: first, an IANA assigned prefix to 450 distinguish it from other IPv6 addresses. Second, a four-bit 451 encoding of the algorithms that were used for generating the HI and 452 the hashed representation of HI. Third, a 96-bit hashed 453 representation of the Host Identity. The encoding of the ORCHID 454 generation algorithm and the exact algorithm for generating the 455 hashed representation is specified in Appendix E. 457 Carrying HIs and HITs in the header of user data packets would 458 increase the overhead of packets. Thus, it is not expected that they 459 are carried in every packet, but other methods are used to map the 460 data packets to the corresponding HIs. In some cases, this makes it 461 possible to use HIP without any additional headers in the user data 462 packets. For example, if ESP is used to protect data traffic, the 463 Security Parameter Index (SPI) carried in the ESP header can be used 464 to map the encrypted data packet to the correct HIP association. 466 3.1. Host Identity Tag (HIT) 468 The Host Identity Tag is a 128-bit value -- a hashed encoding of the 469 Host Identifier. There are two advantages of using a hashed encoding 470 over the actual variable-sized Host Identity public key in protocols. 471 First, the fixed length of the HIT keeps packet sizes manageable and 472 eases protocol coding. Second, it presents a consistent format for 473 the protocol, independent of the underlying identity technology in 474 use. 476 RFC 4843-bis [I-D.ietf-hip-rfc4843-bis] specifies 128-bit hash-based 477 identifiers, called Overlay Routable Cryptographic Hash Identifiers, 478 ORCHIDs. Their prefix, allocated from the IPv6 address block, is 479 defined in [I-D.ietf-hip-rfc4843-bis]. The Host Identity Tag is one 480 type of an ORCHID. 482 This document extends the original, experimental HIP specification 483 [RFC5201] with measures to support crypto agility. One of these 484 measures is to allow different hash functions for creating a HIT. 485 HIT Suites group the sets of algorithms that are required to generate 486 and use a particular HIT. The Suites are encoded in HIT Suite IDs. 487 These HIT Suite IDs are transmitted in the ORCHID Generation 488 Algorithm (OGA) field in the ORCHID. With the HIT Suite ID in the 489 OGA field, a hosts can tell from another host's HIT, whether it 490 supports the necessary hash and signature algorithms to establish a 491 HIP association with that host. 493 3.2. Generating a HIT from an HI 495 The HIT MUST be generated according to the ORCHID generation method 496 described in [I-D.ietf-hip-rfc4843-bis] using a context ID value of 497 0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA (this tag value has been 498 generated randomly by the editor of this specification), and an input 499 that encodes the Host Identity field (see Section 5.2.9) present in a 500 HIP payload packet. The set of hash function, signature algorithm, 501 and the algorithm used for generating the HIT from the HI depends on 502 the HIT Suite (see Appendix E) and is indicated by the four bits of 503 the ORCHID Generation Algorithm (OGA) field in the ORCHID. 504 Currently, truncated SHA-1, truncated SHA-384, and truncated SHA-256 505 [FIPS.180-2.2002] are defined as hashes for generating a HIT. 507 For identities that are either RSA, Digital Signature Algorithm 508 (DSA), or Elliptic Curve DSA (ECDSA) public keys, the ORCHID input 509 consists of the public key encoding as specified for the Host 510 Identity field of the HOST_ID parameter (see Section 5.2.9). This 511 document defines four algorithm profiles: RSA, DSA, ECDSA, and 512 ECDSA_LOW. The ECDSA_LOW profile is meant for devices with low 513 computational capabilities. Hence, one 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 1242 System behavior in state UNASSOCIATED, Table 2. 1244 +---------------------+---------------------------------------------+ 1245 | Trigger | Action | 1246 +---------------------+---------------------------------------------+ 1247 | User data to send, | Send I1 and go to I1-SENT | 1248 | requiring a new HIP | | 1249 | association | | 1250 | | | 1251 | Receive I1 | Send R1 and stay at UNASSOCIATED | 1252 | | | 1253 | Receive I2, process | If successful, send R2 and go to R2-SENT | 1254 | | | 1255 | | If fail, stay at UNASSOCIATED | 1256 | | | 1257 | Receive user data | Optionally send ICMP as defined in | 1258 | for an unknown HIP | Section 5.4 and stay at UNASSOCIATED | 1259 | association | | 1260 | | | 1261 | Receive CLOSE | Optionally send ICMP Parameter Problem and | 1262 | | stay at UNASSOCIATED | 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 [RFC6253]. A 1627 parameter type value, meant to be used for carrying certificates, is 1628 reserved, though: CERT, Type 768; see Section 5.2. 1630 5. Packet Formats 1632 5.1. Payload Format 1634 All HIP packets start with a fixed header. 1636 0 1 2 3 1637 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 1638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1639 | Next Header | Header Length |0| Packet Type |Version| RES.|1| 1640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1641 | Checksum | Controls | 1642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1643 | Sender's Host Identity Tag (HIT) | 1644 | | 1645 | | 1646 | | 1647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1648 | Receiver's Host Identity Tag (HIT) | 1649 | | 1650 | | 1651 | | 1652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1653 | | 1654 / HIP Parameters / 1655 / / 1656 | | 1657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1658 The HIP header is logically an IPv6 extension header. However, this 1659 document does not describe processing for Next Header values other 1660 than decimal 59, IPPROTO_NONE, the IPv6 'no next header' value. 1661 Future documents MAY define behavior for also other values. However, 1662 current implementations MUST ignore trailing data if an unimplemented 1663 Next Header value is received. 1665 The Header Length field contains the combined length of the HIP 1666 Header and HIP parameters in 8-byte units, excluding the first 8 1667 bytes. Since all HIP headers MUST contain the sender's and 1668 receiver's HIT fields, the minimum value for this field is 4, and 1669 conversely, the maximum length of the HIP Parameters field is 1670 (255*8)-32 = 2008 bytes. Note: this sets an additional limit for 1671 sizes of parameters included in the Parameters field, independent of 1672 the individual parameter maximum lengths. 1674 The Packet Type indicates the HIP packet type. The individual packet 1675 types are defined in the relevant sections. If a HIP host receives a 1676 HIP packet that contains an unrecognized packet type, it MUST drop 1677 the packet. 1679 The HIP Version field is four bits. The version defined in this 1680 document is 2. The version number is expected to be incremented only 1681 if there are incompatible changes to the protocol. Most extensions 1682 can be handled by defining new packet types, new parameter types, or 1683 new Controls (see Section 5.1.2) . 1685 The following three bits are reserved for future use. They MUST be 1686 zero when sent, and they SHOULD be ignored when handling a received 1687 packet. 1689 The two fixed bits in the header are reserved for SHIM6 compatibility 1690 [RFC5533], Section 5.3. For implementations adhering (only) to this 1691 specification, they MUST be set as shown when sending and MUST be 1692 ignored when receiving. This is to ensure optimal forward 1693 compatibility. Note that for implementations that implement other 1694 compatible specifications in addition to this specification, the 1695 corresponding rules may well be different. For example, an 1696 implementation that implements both this specification and the SHIM6 1697 protocol may need to check these bits in order to determine how to 1698 handle the packet. 1700 The HIT fields are always 128 bits (16 bytes) long. 1702 5.1.1. Checksum 1704 Since the checksum covers the source and destination addresses in the 1705 IP header, it MUST be recomputed on HIP-aware NAT devices. 1707 If IPv6 is used to carry the HIP packet, the pseudo-header [RFC2460] 1708 contains the source and destination IPv6 addresses, HIP packet length 1709 in the pseudo-header length field, a zero field, and the HIP protocol 1710 number (see Section 4) in the Next Header field. The length field is 1711 in bytes and can be calculated from the HIP header length field: (HIP 1712 Header Length + 1) * 8. 1714 In case of using IPv4, the IPv4 UDP pseudo-header format [RFC0768] is 1715 used. In the pseudo-header, the source and destination addresses are 1716 those used in the IP header, the zero field is obviously zero, the 1717 protocol is the HIP protocol number (see Section 4), and the length 1718 is calculated as in the IPv6 case. 1720 5.1.2. HIP Controls 1722 The HIP Controls field conveys information about the structure of the 1723 packet and capabilities of the host. 1725 The following fields have been defined: 1727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1728 | | | | | | | | | | | | | | | |A| 1729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1731 A - Anonymous: If this is set, the sender's HI in this packet is 1732 anonymous, i.e., one not listed in a directory. Anonymous HIs 1733 SHOULD NOT be stored. This control is set in packets using 1734 anonymous sender HIs. The peer receiving an anonymous HI in an R1 1735 or I2 may choose to refuse it. 1737 The rest of the fields are reserved for future use and MUST be set to 1738 zero in sent packets and ignored in received packets. 1740 5.1.3. HIP Fragmentation Support 1742 A HIP implementation MUST support IP fragmentation/reassembly. 1743 Fragment reassembly MUST be implemented in both IPv4 and IPv6, but 1744 fragment generation is REQUIRED to be implemented in IPv4 (IPv4 1745 stacks and networks will usually do this by default) and RECOMMENDED 1746 to be implemented in IPv6. In IPv6 networks, the minimum MTU is 1747 larger, 1280 bytes, than in IPv4 networks. The larger MTU size is 1748 usually sufficient for most HIP packets, and therefore fragment 1749 generation may not be needed. If a host expects to send HIP packets 1750 that are larger than the minimum IPv6 MTU, it MUST implement fragment 1751 generation even for IPv6. 1753 In IPv4 networks, HIP packets may encounter low MTUs along their 1754 routed path. Since basic HIP, as defined in this document, does not 1755 provide a mechanism to use multiple IP datagrams for a single HIP 1756 packet, support for path MTU discovery does not bring any value to 1757 HIP in IPv4 networks. HIP-aware NAT devices SHOULD perform IPv4 1758 reassembly/fragmentation for HIP control packets. 1760 All HIP implementations have to be careful while employing a 1761 reassembly algorithm so that the algorithm is sufficiently resistant 1762 to DoS attacks. 1764 Certificate chains can cause the packet to be fragmented and 1765 fragmentation can open implementations to denial-of-service attacks 1766 [KAU03]. "Hash and URL" schemes as defined in [RFC6253] for HIP 1767 version 1 may be used to avoid fragmentation and mitigate resulting 1768 DoS attacks. 1770 5.2. HIP Parameters 1772 The HIP parameters carry information that is necessary for 1773 establishing and maintaining a HIP association. For example, the 1774 peer's public keys as well as the signaling for negotiating ciphers 1775 and payload handling are encapsulated in HIP parameters. Additional 1776 information, meaningful for end-hosts or middleboxes, may also be 1777 included in HIP parameters. The specification of the HIP parameters 1778 and their mapping to HIP packets and packet types is flexible to 1779 allow HIP extensions to define new parameters and new protocol 1780 behavior. 1782 In HIP packets, HIP parameters are ordered according to their numeric 1783 type number and encoded in TLV format. 1785 The following parameter types are currently defined. 1787 +------------------------+-------+-----------+----------------------+ 1788 | TLV | Type | Length | Data | 1789 +------------------------+-------+-----------+----------------------+ 1790 | R1_COUNTER | 129 | 12 | Puzzle generation | 1791 | | | | counter | 1792 | | | | | 1793 | PUZZLE | 257 | 12 | K and Random #I | 1794 | | | | | 1795 | SOLUTION | 321 | 20 | K, Random #I and | 1796 | | | | puzzle solution J | 1797 | | | | | 1798 | SEQ | 385 | 4 | UPDATE packet ID | 1799 | | | | number | 1800 | | | | | 1801 | ACK | 449 | variable | UPDATE packet ID | 1802 | | | | number | 1803 | | | | | 1804 | DH_GROUP_LIST | 511 | variable | Ordered list of DH | 1805 | | | | Group IDs supported | 1806 | | | | by a host | 1807 | | | | | 1808 | DIFFIE_HELLMAN | 513 | variable | public key | 1809 | | | | | 1810 | HIP_CIPHER | 579 | variable | List of HIP | 1811 | | | | encryption | 1812 | | | | algorithms | 1813 | | | | | 1814 | ENCRYPTED | 641 | variable | Encrypted part of a | 1815 | | | | HIP packet | 1816 | | | | | 1817 | HOST_ID | 705 | variable | Host Identity with | 1818 | | | | Fully-Qualified | 1819 | | | | Domain FQDN (Name) | 1820 | | | | or Network Access | 1821 | | | | Identifier (NAI) | 1822 | | | | | 1823 | HIT_SUITE_LIST | 715 | variable | Ordered list of the | 1824 | | | | HIT suites supported | 1825 | | | | by the Responder | 1826 | | | | | 1827 | CERT | 768 | variable | HI Certificate; used | 1828 | | | | to transfer | 1829 | | | | certificates. | 1830 | | | | Specified in a | 1831 | | | | separate docment. | 1832 | | | | | 1833 | NOTIFICATION | 832 | variable | Informational data | 1834 | | | | | 1835 | ECHO_REQUEST_SIGNED | 897 | variable | Opaque data to be | 1836 | | | | echoed back; signed | 1837 | | | | | 1838 | ECHO_RESPONSE_SIGNED | 961 | variable | Opaque data echoed | 1839 | | | | back by request; | 1840 | | | | signed | 1841 | | | | | 1842 | TRANSPORT_FORMAT_LIST | 2049 | Ordered | variable | 1843 | | | list of | | 1844 | | | preferred | | 1845 | | | HIP | | 1846 | | | transport | | 1847 | | | type | | 1848 | | | numbers | | 1849 | | | | | 1850 | HIP_MAC | 61505 | variable | HMAC-based message | 1851 | | | | authentication code, | 1852 | | | | with key material | 1853 | | | | from KEYMAT | 1854 | | | | | 1855 | HIP_MAC_2 | 61569 | variable | HMAC based message | 1856 | | | | authentication code, | 1857 | | | | with key material | 1858 | | | | from KEYMAT. Unlike | 1859 | | | | HIP_MAC, the HOST_ID | 1860 | | | | parameter is | 1861 | | | | included in | 1862 | | | | HIP_MAC_2 | 1863 | | | | calculation. | 1864 | | | | | 1865 | HIP_SIGNATURE_2 | 61633 | variable | Signature used in R1 | 1866 | | | | packet | 1867 | | | | | 1868 | HIP_SIGNATURE | 61697 | variable | Signature of the | 1869 | | | | packet | 1870 | | | | | 1871 | ECHO_REQUEST_UNSIGNED | 63661 | variable | Opaque data to be | 1872 | | | | echoed back; after | 1873 | | | | signature | 1874 | | | | | 1875 | ECHO_RESPONSE_UNSIGNED | 63425 | variable | Opaque data echoed | 1876 | | | | back by request; | 1877 | | | | after signature | 1878 +------------------------+-------+-----------+----------------------+ 1880 As the ordering (from lowest to highest) of HIP parameters is 1881 strictly enforced (see Section 5.2.1), the parameter type values for 1882 existing parameters have been spaced to allow for future protocol 1883 extensions. 1885 The following parameter type number ranges are defined. 1887 +---------------+---------------------------------------------------+ 1888 | Type Range | Purpose | 1889 +---------------+---------------------------------------------------+ 1890 | 0 - 1023 | Handshake | 1891 | | | 1892 | 1024 - 2047 | Reserved | 1893 | | | 1894 | 2048 - 4095 | Parameters related to HIP transport formats | 1895 | | | 1896 | 4096 - 8191 | Signed parameters allocated through specification | 1897 | | documents | 1898 | | | 1899 | 8192 - 32767 | Reserved | 1900 | | | 1901 | 32768 - 49151 | Free for experimentation. Signed parameters. | 1902 | | | 1903 | 41952 - 61439 | Reserved | 1904 | | | 1905 | 61440 - 64443 | Signatures and (signed) MACs | 1906 | | | 1907 | 62464 - 63487 | Parameters that are neither signed nor MACed | 1908 | | | 1909 | 63488 - 64511 | Rendezvous and relaying | 1910 | | | 1911 | 64512 - 65023 | Parameters that are neither signed nor MACed | 1912 | | | 1913 | 65024 - 65535 | Reserved | 1914 +---------------+---------------------------------------------------+ 1916 The process for defining new parameters is described in Section 5.2.2 1917 of this document. 1919 The range between 32768 (2^15) and 49151 (2^15 + 2^14) are free for 1920 experimentation. Types from this range SHOULD be selected in a 1921 random fashion to reduce the probability of collisions. 1923 5.2.1. TLV Format 1925 The TLV-encoded parameters are described in the following 1926 subsections. The type-field value also describes the order of these 1927 fields in the packet. The parameters MUST be included in the packet 1928 so that their types form an increasing order. If multiple parameters 1929 with the same type number are in one packet, the parameters with the 1930 same type MUST be consecutive in the packet. If the order does not 1931 follow this rule, the packet is considered to be malformed and it 1932 MUST be discarded. 1934 Parameters using type values from 2048 up to 4095 are related to 1935 transport formats. Currently, one transport format is defined: the 1936 ESP transport format [I-D.ietf-hip-rfc5202-bis]. 1938 All of the encoded TLV parameters have a length (that includes the 1939 Type and Length fields), which is a multiple of 8 bytes. When 1940 needed, padding MUST be added to the end of the parameter so that the 1941 total length is a multiple of 8 bytes. This rule ensures proper 1942 alignment of data. Any added padding bytes MUST be zeroed by the 1943 sender, and their values SHOULD NOT be checked by the receiver. 1945 The Length field indicates the length of the Contents field (in 1946 bytes). Consequently, the total length of the TLV parameter 1947 (including Type, Length, Contents, and Padding) is related to the 1948 Length field according to the following formula: 1950 Total Length = 11 + Length - (Length + 3) % 8; 1952 where % is the modulo operator 1954 0 1 2 3 1955 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 1956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1957 | Type |C| Length | 1958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1959 | | 1960 / Contents / 1961 / +-+-+-+-+-+-+-+-+ 1962 | | Padding | 1963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1965 Type Type code for the parameter. 16 bits long, C-bit 1966 being part of the Type code. 1967 C Critical. One if this parameter is critical, and 1968 MUST be recognized by the recipient, zero otherwise. 1969 The C bit is considered to be a part of the Type 1970 field. Consequently, critical parameters are always 1971 odd and non-critical ones have an even value. 1972 Length Length of the Contents, in bytes excluding Type, 1973 Length, and Padding. 1974 Contents Parameter specific, defined by Type 1975 Padding Padding, 0-7 bytes, added if needed 1977 Critical parameters (indicated by the odd type number) MUST be 1978 recognized by the recipient. If a recipient encounters a critical 1979 parameter that it does not recognize, it MUST NOT process the packet 1980 any further. It MAY send an ICMP or NOTIFY, as defined in 1981 Section 4.3. 1983 Non-critical parameters MAY be safely ignored. If a recipient 1984 encounters a non-critical parameter that it does not recognize, it 1985 SHOULD proceed as if the parameter was not present in the received 1986 packet. 1988 5.2.2. Defining New Parameters 1990 Future specifications may define new parameters as needed. When 1991 defining new parameters, care must be taken to ensure that the 1992 parameter type values are appropriate and leave suitable space for 1993 other future extensions. One must remember that the parameters MUST 1994 always be arranged in numerically increasing order by Type code, 1995 thereby limiting the order of parameters (see Section 5.2.1). 1997 The following rules MUST be followed when defining new parameters. 1999 1. The low-order bit C of the Type code is used to distinguish 2000 between critical and non-critical parameters. Hence, even 2001 parameter type numbers indicate non-critical parameters while odd 2002 parameter type numbers indicate critical parameters. 2004 2. A new parameter MAY be critical only if an old implementation 2005 that ignored it would cause security problems. In general, new 2006 parameters SHOULD be defined as non-critical, and expect a reply 2007 from the recipient. 2009 3. If a system implements a new critical parameter, it MUST provide 2010 the ability to set the associated feature off, such that the 2011 critical parameter is not sent at all. The configuration option 2012 MUST be well documented. Implementations operating in a mode 2013 adhering to this specification MUST disable the sending of new 2014 critical parameters by default. In other words, the management 2015 interface MUST allow vanilla standards-only mode as a default 2016 configuration setting, and MAY allow new critical payloads to be 2017 configured on (and off). 2019 4. See Section 9 for allocation rules regarding Type codes. 2021 5.2.3. R1_COUNTER 2023 0 1 2 3 2024 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 2025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2026 | Type | Length | 2027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2028 | Reserved, 4 bytes | 2029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2030 | R1 generation counter, 8 bytes | 2031 | | 2032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2034 Type 129 2035 Length 12 2036 R1 generation 2037 counter The current generation of valid puzzles 2039 The R1_COUNTER parameter contains a 64-bit unsigned integer in 2040 network-byte order, indicating the current generation of valid 2041 puzzles. The sender SHOULD increment this counter periodically. It 2042 is RECOMMENDED that the counter value is incremented at least as 2043 often as old PUZZLE values are deprecated so that SOLUTIONs to them 2044 are no longer accepted. 2046 Support for the R1_COUNTER parameter is mandatory. It SHOULD be 2047 included in the R1 (in which case, it is covered by the signature), 2048 and if present in the R1, it MUST be echoed (including the Reserved 2049 field verbatim) by the Initiator in the I2 packet. 2051 5.2.4. PUZZLE 2053 0 1 2 3 2054 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 2055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2056 | Type | Length | 2057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2058 | #K, 1 byte | Lifetime | Opaque, 2 bytes | 2059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2060 | Random #I, RHASH_len/8 bytes | 2061 / / 2062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2064 Type 257 2065 Length 4 + RHASH_len / 8 2066 #K #K is the number of verified bits 2067 Lifetime puzzle lifetime 2^(value-32) seconds 2068 Opaque data set by the Responder, indexing the puzzle 2069 Random #I random number of size RHASH_len bits 2071 Random #I is represented as a n-bit integer (where n is RHASH_len), 2072 #K and Lifetime as 8-bit integers, all in network byte order. 2074 The PUZZLE parameter contains the puzzle difficulty #K and a n-bit 2075 random integer #I. The Puzzle Lifetime indicates the time during 2076 which the puzzle solution is valid, and sets a time limit that should 2077 not be exceeded by the Initiator while it attempts to solve the 2078 puzzle. The lifetime is indicated as a power of 2 using the formula 2079 2^(Lifetime-32) seconds. A puzzle MAY be augmented with an 2080 ECHO_REQUEST_SIGNED or an ECHO_REQUEST_UNSIGNED parameter included in 2081 the R1; the contents of the echo request are then echoed back in the 2082 ECHO_RESPONSE_SIGNED or in the ECHO_RESPONSE_UNSIGNED parameter, 2083 allowing the Responder to use the included information as a part of 2084 its puzzle processing. 2086 The Opaque and Random #I field are not covered by the HIP_SIGNATURE_2 2087 parameter. 2089 5.2.5. SOLUTION 2091 0 1 2 3 2092 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 2093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2094 | Type | Length | 2095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2096 | #K, 1 byte | Reserved | Opaque, 2 bytes | 2097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2098 | Random #I, n bytes | 2099 / / 2100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2101 | Puzzle solution #J, RHASH_len/8 bytes | 2102 / / 2103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2105 Type 321 2106 Length 4 + RHASH_len /4 2107 #K #K is the number of verified bits 2108 Reserved zero when sent, ignored when received 2109 Opaque copied unmodified from the received PUZZLE 2110 parameter 2111 Random #I random number of size RHASH_len bits 2112 Puzzle solution #J random number of size RHASH_len bits 2114 Random #I and Random #J are represented as n-bit unsigned integers 2115 (where n is RHASH_len), #K as an 8-bit unsigned integer, all in 2116 network byte order. 2118 The SOLUTION parameter contains a solution to a puzzle. It also 2119 echoes back the random difficulty #K, the Opaque field, and the 2120 puzzle integer #I. 2122 5.2.6. DH_GROUP_LIST 2124 0 1 2 3 2125 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 2126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2127 | Type | Length | 2128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2129 | DH GROUP ID #1| DH GROUP ID #2| DH GROUP ID #3| DH GROUP ID #4| 2130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2131 | DH GROUP ID #n| Padding | 2132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2134 Type 511 2135 Length number of DH Group IDs 2136 DH GROUP ID defines a DH GROUP ID supported by the host. 2137 The list of IDs is ordered by preference of the 2138 host. The list of define DH Group IDs in the 2139 DIFFIE_HELLMAN parameter. Each DH Group ID is one 2140 octet long. 2142 The DH_GROUP_LIST parameter contains the list of supported DH Group 2143 IDs of a host. The Initiator sends the DH_GROUP_LIST in the I1 2144 packet, the Responder sends its own list in the signed part of the R1 2145 packet. The DH Group IDs in the DH_GROUP_LIST are listed in the 2146 order of their preference of the host sending the list. DH Group IDs 2147 that are listed first are preferred over the DH Group IDs listed 2148 later. The information in the DH_GROUP_LIST allows the Responder to 2149 select the DH group preferred by itself and supported by the 2150 Initiator. Based on the DH_GROUP_LIST in the R1 packet, the 2151 Initiator can determine if the Responder has selected the best 2152 possible choice based on the Initiator's and Responder's preferences. 2153 If the Responder's choice differs from the best choice, the Initiator 2154 can conclude that there was an attempted downgrade attack (see 2155 Section 4.1.7). 2157 When selecting the DH group for the DIFFIE_HELLMAN parameter in the 2158 R1 packet, the Responder MUST select the first DH Group ID in its 2159 DH_GROUP_LIST in the R1 packet that is compatible with one of the 2160 Suite IDs in the Initiator's DH_GROUP_LIST in the I1 packet. The 2161 Responder MUST NOT select any other DH Group ID that is contained in 2162 both lists because a downgrade attack cannot be detected then. 2164 In general, hosts SHOULD prefer stronger groups over weaker ones if 2165 the computation overhead is not prohibitively high for the intended 2166 application. 2168 5.2.7. DIFFIE_HELLMAN 2170 0 1 2 3 2171 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 2172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2173 | Type | Length | 2174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2175 | Group ID | Public Value Length | Public Value / 2176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2177 / | 2178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2179 / | Padding | 2180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2182 Type 513 2183 Length length in octets, excluding Type, Length, and 2184 Padding 2185 Group ID defines values for p and g as well as the KDF 2186 Public Value length of the following Public Value in octets 2187 Length 2188 Public Value the sender's public Diffie-Hellman key 2190 The following Group IDs have been defined: 2192 Group KDF Value 2193 Reserved 0 2194 DEPRECATED 1 2195 DEPRECATED 2 2196 1536-bit MODP group [RFC3526] HKDF [RFC5869] 3 2197 3072-bit MODP group [RFC3526] HKDF [RFC5869] 4 2198 DEPRECATED 5 2199 DEPRECATED 6 2200 NIST P-256 [RFC5903] HKDF [RFC5869] 7 2201 NIST P-384 [RFC5903] HKDF [RFC5869] 8 2202 NIST P-521 [RFC5903] HKDF [RFC5869] 9 2203 SECP160R1 [SECG] HKDF [RFC5869] 10 2205 The MODP Diffie-Hellman groups are defined in [RFC3526]. The ECDH 2206 groups 7 - 9 are defined in [RFC5903] and [RFC6090]. ECDH group 10 2207 is covered in Appendix D. Any ECDH used with HIP MUST have a co- 2208 factor of 1. 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 DEPRECATED 3 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 A host MAY optionally associate the Host Identity with a single 2310 Domain Identifier in the HOST_ID parameter. If there is no Domain 2311 Identifier, i.e., the DI-type field is zero, the DI Length field is 2312 set to zero as well. 2314 The following HI Algorithms have been defined: 2316 Algorithm 2317 profiles Values 2319 RESERVED 0 2320 DSA 3 [FIPS 186-3] (RECOMMENDED) 2321 RSA 5 [RFC3447] (REQUIRED) 2322 ECDSA 7 [RFC4754] (REQUIRED) 2323 ECDSA_LOW 9 [SECG] (RECOMMENDED) 2325 For DSA, RSA, and ECDSA key types, profiles containing at least 112 2326 bits of security strength (as defined by [NIST.800-131A.2011]) should 2327 be used. For RSA signature padding, the PSS method of padding 2328 [RFC3447] MUST be used. 2330 The Host Identity is derived from the DNSKEY format for RSA and DSA. 2331 For these, the Public Key field of the RDATA part from RFC 4034 2332 [RFC4034] is used. For ECC we distinguish two different profiles: 2333 ECDSA and ECDSA_LOW. ECC contains curves approved by NIST and 2334 defined in RFC 4754 [RFC4754]. ECDSA_LOW is defined for devices with 2335 low computational capabilities and uses shorter curves from SECG 2336 [SECG]. Any ECDSA used with HIP MUST have a co-factor of 1. 2338 For ECDSA and ECDSA_LOW Host Identities are represented by the 2339 following fields: 2341 0 1 2 3 2342 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 2343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2344 | ECC Curve | / 2345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2346 / Public Key | 2347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2349 ECC Curve Curve label 2350 Public Key Represented in Octet-string format 2351 [RFC6090] 2353 For hosts that implement ECDSA as algorithm the following ECC curves 2354 are required: 2356 Algorithm Curve Values 2358 ECDSA RESERVED 0 2359 ECDSA NIST P-256 1 [RFC4754] 2360 ECDSA NIST P-384 2 [RFC4754] 2362 For hosts that implement the EDSA_LOW algorithm profile, the 2363 following curve is required: 2365 Algorithm Curve Values 2367 ECDSA_LOW RESERVED 0 2368 ECDSA_LOW SECP160R1 1 [SECG] 2370 5.2.10. HIT_SUITE_LIST 2372 The HIT_SUITE_LIST parameter contains a list of the supported HIT 2373 suite IDs of the Responder. The Responder sends the HIT_SUITE_LIST 2374 in the signed part of the R1 packet. Based on the HIT_SUITE_LIST, 2375 the Initiator can determine which source HITs are supported by the 2376 Responder. 2378 0 1 2 3 2379 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 2380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2381 | Type | Length | 2382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2383 | ID #1 | ID #2 | ID #3 | ID #4 | 2384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2385 | ID #n | Padding | 2386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2388 Type 715 2389 Length number of HIT Suite IDs 2390 ID defines a HIT Suite ID supported by the host. 2391 The list of IDs is ordered by preference of the 2392 host. Each HIT Suite ID is one octet long. The four 2393 higher-order bits of the ID field correspond to the 2394 HIT Suite ID in the ORCHID OGA field. The four 2395 lower-order bits are reserved and set to 0 and 2396 ignored by the receiver. 2398 The HIT Suite ID indexes a HIT Suite. HIT Suites are composed of 2399 signature algorithms as defined in Section 5.2.9 and hash functions. 2401 The ID field in the HIT_SUITE_LIST is defined as eight-bit field as 2402 opposed to the four-bit HIT Suite ID and OGA field in the ORCHID. 2403 This difference is a measure to accommodate larger HIT Suite IDs if 2404 the 16 available values prove insufficient. In that case, one of the 2405 16 values, zero, will be used to indicate that four additional bits 2406 of the ORCHID will be used to encode the HIT Suite ID. Hence, the 2407 current four-bit HIT Suite-IDs only use the four higher order bits in 2408 the ID field. Future documents may define the use of the four lower- 2409 order bits in the ID field. 2411 The following HIT Suites ID are defined: 2413 HIT Suite ID 2414 RESERVED 0 2415 RSA,DSA/SHA-256 1 (REQUIRED) 2416 ECDSA/SHA-384 2 (RECOMMENDED) 2417 ECDSA_LOW/SHA-1 3 (RECOMMENDED) 2419 5.2.11. TRANSPORT_FORMAT_LIST 2421 The TRANSPORT_FORMAT_LIST parameter contains a list of the supported 2422 HIP transport formats (TFs) of the Responder. The Responder sends 2423 the TRANSPORT_FORMAT_LIST in the signed part of the R1 packet. Based 2424 on the TRANSPORT_FORMAT_LIST, the Initiator chooses one suitable 2425 transport format and includes the respective HIP transport format 2426 parameter in its response packet. 2428 0 1 2 3 2429 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 2430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2431 | Type | Length | 2432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2433 | TF type #1 | TF type #2 / 2434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2435 / TF type #n | Padding | 2436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2438 Type 2049 2439 Length 2x number of TF types 2440 TF Type defines a transport format (TF) type supported by the 2441 host. The TF type numbers correspond to the HIP 2442 parameter type numbers of the respective transform 2443 parameters. The list of TF types is ordered by preference 2444 of the sender 2446 The TF type numbers index the respective HIP parameters for the 2447 transport formats in the type number range between 2050 to 4095. The 2448 parameters and their use is defined in separate documents. 2449 Currently, the only transport format defined is IPsec ESP 2450 [I-D.ietf-hip-rfc5202-bis]. 2452 For each listed TF type, the sender of the parameter MUST include the 2453 repective transport form parameter in the HIP packet. The TF type in 2454 the TRANSPORT_FORM_LIST MUST be ignored if no matching transport form 2455 parameter is present in the packet. 2457 5.2.12. HIP_MAC 2459 0 1 2 3 2460 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 2461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2462 | Type | Length | 2463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2464 | | 2465 | HMAC | 2466 / / 2467 / +-------------------------------+ 2468 | | Padding | 2469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2471 Type 61505 2472 Length length in octets, excluding Type, Length, and 2473 Padding 2474 HMAC HMAC computed over the HIP packet, excluding the 2475 HIP_MAC parameter and any following parameters, such 2476 as HIP_SIGNATURE, HIP_SIGNATURE_2, 2477 ECHO_REQUEST_UNSIGNED, or ECHO_RESPONSE_UNSIGNED. 2478 The checksum field MUST be set to zero and the HIP 2479 header length in the HIP common header MUST be 2480 calculated not to cover any excluded parameters 2481 when the HMAC is calculated. The size of the 2482 HMAC is the natural size of the hash computation 2483 output depending on the used hash function. 2485 The HMAC uses RHASH as hash algorithm. The calculation and 2486 verification process is presented in Section 6.4.1. 2488 5.2.13. HIP_MAC_2 2490 The HIP_MAC_2 is a MAC of the packet and the HOST_ID parameter of the 2491 sender while only the packet without HOST_ID of the sender is sent. 2492 The parameter structure is the same as in Section 5.2.12. The fields 2493 are: 2495 Type 61569 2496 Length length in octets, excluding Type, Length, and 2497 Padding 2498 HMAC HMAC computed over the HIP packet, excluding the 2499 HIP_MAC_2 parameter and any following parameters 2500 such as HIP_SIGNATURE, HIP_SIGNATURE_2, 2501 ECHO_REQUEST_UNSIGNED, or ECHO_RESPONSE_UNSIGNED, 2502 and including an additional sender's HOST_ID 2503 parameter during the HMAC calculation. The checksum 2504 field MUST be set to zero and the HIP header length 2505 in the HIP common header MUST be calculated not to 2506 cover any excluded parameters when the HMAC is 2507 calculated. The size of the HMAC is the natural 2508 size of the hash computation output depending on the 2509 used hash function. 2511 The HMAC uses RHASH as hash algorithm. The calculation and 2512 verification process is presented in Section 6.4.1. 2514 5.2.14. HIP_SIGNATURE 2516 0 1 2 3 2517 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 2518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2519 | Type | Length | 2520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2521 | SIG alg | Signature / 2522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2523 / | Padding | 2524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2526 Type 61697 2527 Length length in octets, excluding Type, Length, and 2528 Padding 2529 SIG alg signature algorithm 2530 Signature the signature is calculated over the HIP packet, 2531 excluding the HIP_SIGNATURE parameter and any 2532 parameters that follow the HIP_SIGNATURE parameter. 2533 When the signature is calculated the checksum field 2534 MUST be set to zero, and the HIP header length in 2535 the HIP common header MUST be calculated only up to 2536 the beginning of the HIP_SIGNATURE parameter. 2538 The signature algorithms are defined in Section 5.2.9. The signature 2539 in the Signature field is encoded using the method depending on the 2540 signature algorithm (e.g., according to [RFC3110] in case of RSA/ 2541 SHA-1, according to [RFC5702] in case of RSA/SHA-256, according to 2542 [RFC2536] in case of DSA, or according to [RFC6090] in case of 2543 ECDSA). 2545 The HIP_SIGNATURE calculation and verification process are presented 2546 in Section 6.4.2. 2548 5.2.15. HIP_SIGNATURE_2 2550 The HIP_SIGNATURE_2 excludes the variable parameters in the R1 packet 2551 to allow R1 pre-creation. The parameter structure is the same as in 2552 Section 5.2.14. The fields are: 2554 Type 61633 2555 Length length in octets, excluding Type, Length, and 2556 Padding 2557 SIG alg signature algorithm 2558 Signature Within the R1 packet that contains the 2559 HIP_SIGNATURE_2 parameter, the Initiator's HIT, the 2560 checksum field, and the Opaque and Random #I fields 2561 in the PUZZLE parameter MUST be set to zero while 2562 computing the HIP_SIGNATURE_2 signature. Further, 2563 the HIP packet length in the HIP header MUST be 2564 adjusted as if the HIP_SIGNATURE_2 was not in the 2565 packet during the signature calculation, i.e., the 2566 HIP packet length points to the beginning of 2567 the HIP_SIGNATURE_2 parameter during signing and 2568 verification. 2570 Zeroing the Initiator's HIT makes it possible to create R1 packets 2571 beforehand, to minimize the effects of possible DoS attacks. Zeroing 2572 the Random #I and Opaque fields within the PUZZLE parameter allows 2573 these fields to be populated dynamically on precomputed R1s. 2575 Signature calculation and verification follows the process defined in 2576 Section 6.4.2. 2578 5.2.16. SEQ 2580 0 1 2 3 2581 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 2582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2583 | Type | Length | 2584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2585 | Update ID | 2586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2587 Type 385 2588 Length 8 2589 Update ID 32-bit sequence number 2591 The Update ID is an unsigned number in network byte order, 2592 initialized by a host to zero upon moving to ESTABLISHED state. The 2593 Update ID has scope within a single HIP association, and not across 2594 multiple associations or multiple hosts. The Update ID is 2595 incremented by one before each new UPDATE that is sent by the host; 2596 the first UPDATE packet originated by a host has an Update ID of 0. 2598 5.2.17. ACK 2600 0 1 2 3 2601 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 2602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2603 | Type | Length | 2604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2605 | peer Update ID 1 | 2606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2607 / peer Update ID n | 2608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2610 Type 449 2611 Length length in octets, excluding Type and Length 2612 peer Update ID 32-bit sequence number corresponding to the 2613 Update ID being ACKed. 2615 The ACK parameter includes one or more Update IDs that have been 2616 received from the peer. The number of peer Update IDs can be 2617 inferred from the length by dividing it by 4. 2619 5.2.18. ENCRYPTED 2621 0 1 2 3 2622 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 2623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2624 | Type | Length | 2625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2626 | Reserved | 2627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2628 | IV / 2629 / / 2630 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 2632 / Encrypted data / 2633 / / 2634 / +-------------------------------+ 2635 / | Padding | 2636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2638 Type 641 2639 Length length in octets, excluding Type, Length, and 2640 Padding 2641 Reserved zero when sent, ignored when received 2642 IV Initialization vector, if needed, otherwise 2643 nonexistent. The length of the IV is inferred from 2644 the HIP_CIPHER. 2645 Encrypted The data is encrypted using the encryption algorithm 2646 data defined in the HIP_CIPHER parameter. 2648 The ENCRYPTED parameter encapsulates other parameters, the encrypted 2649 data, which holds one or more HIP parameters in block encrypted form. 2651 Consequently, the first fields in the encapsulated parameter(s) are 2652 Type and Length of the first such parameter, allowing the contents to 2653 be easily parsed after decryption. 2655 The field labeled "Encrypted data" consists of the output of one or 2656 more HIP parameters concatenated together that have been passed 2657 through an encryption algorithm. Each of these inner parameters is 2658 padded according to the rules of Section 5.2.1 for padding individual 2659 parameters. As a result, the concatenated parameters will be a block 2660 of data that is 8-byte aligned. 2662 Some encryption algorithms require that the data to be encrypted must 2663 be a multiple of the cipher algorithm block size. In this case, the 2664 above block of data MUST include additional padding, as specified by 2665 the encryption algorithm. The size of the extra padding is selected 2666 so that the length of the unencrypted data block is a multiple of the 2667 cipher block size. The encryption algorithm may specify padding 2668 bytes other than zero; for example, AES [FIPS.197.2001] uses the 2669 PKCS5 padding scheme (see section 6.1.1 of [RFC2898]) where the 2670 remaining n bytes to fill the block each have the value of n. This 2671 yields an "unencrypted data" block that is transformed to an 2672 "encrypted data" block by the cipher suite. This extra padding added 2673 to the set of parameters to satisfy the cipher block alignment rules 2674 is not counted in HIP TLV length fields, and this extra padding 2675 should be removed by the cipher suite upon decryption. 2677 Note that the length of the cipher suite output may be smaller or 2678 larger than the length of the set of parameters to be encrypted, 2679 since the encryption process may compress the data or add additional 2680 padding to the data. 2682 Once this encryption process is completed, the Encrypted data field 2683 is ready for inclusion in the parameter. If necessary, additional 2684 Padding for 8-byte alignment is then added according to the rules of 2685 Section 5.2.1. 2687 5.2.19. NOTIFICATION 2689 The NOTIFICATION parameter is used to transmit informational data, 2690 such as error conditions and state transitions, to a HIP peer. A 2691 NOTIFICATION parameter may appear in NOTIFY packets. The use of the 2692 NOTIFICATION parameter in other packet types is for further study. 2694 0 1 2 3 2695 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 2696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2697 | Type | Length | 2698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2699 | Reserved | Notify Message Type | 2700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2701 | / 2702 / Notification Data / 2703 / +---------------+ 2704 / | Padding | 2705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2707 Type 832 2708 Length length in octets, excluding Type, Length, and 2709 Padding 2710 Reserved zero when sent, ignored when received 2711 Notify Message specifies the type of notification 2712 Type 2713 Notification informational or error data transmitted in addition 2714 Data to the Notify Message Type. Values for this field 2715 are type specific (see below). 2716 multiple of 8 bytes. 2718 Notification information can be error messages specifying why an HIP 2719 Security Association could not be established. It can also be status 2720 data that a HIP implementation wishes to communicate with a peer 2721 process. The table below lists the notification messages and their 2722 Notification Message Types. HIP packets MAY contain multiple 2723 NOTIFICATION parameters if several problems exist or several 2724 independent pieces of information must be transmitted. 2726 To avoid certain types of attacks, a Responder SHOULD avoid sending a 2727 NOTIFICATION to any host with which it has not successfully verified 2728 a puzzle solution. 2730 Notify Message Types in the range 0-16383 are intended for reporting 2731 errors and in the range 16384-65535 for other status information. An 2732 implementation that receives a NOTIFY packet with a Notify Message 2733 Type that indicates an error in response to a request packet (e.g., 2734 I1, I2, UPDATE) SHOULD assume that the corresponding request has 2735 failed entirely. Unrecognized error types MUST be ignored except 2736 that they SHOULD be logged. 2738 As currently defined, Notify Message Type values 1-10 are used for 2739 informing about errors in packet structures, values 11-20 for 2740 informing about problems in parameters. 2742 Notification Data in NOTIFICATION parameters with status Notify 2743 Message Types MUST be ignored if not recognized. 2745 Notify Message Types - Errors Value 2746 ----------------------------- ----- 2748 UNSUPPORTED_CRITICAL_PARAMETER_TYPE 1 2750 Sent if the parameter type has the "critical" bit set and the 2751 parameter type is not recognized. Notification Data contains the 2752 two-octet parameter type. 2754 INVALID_SYNTAX 7 2756 Indicates that the HIP message received was invalid because some 2757 type, length, or value was out of range or because the request 2758 was otherwise malformed. To avoid a denial- of-service 2759 attack using forged messages, this status may only be returned 2760 for packets whose HIP_MAC (if present) and SIGNATURE have been 2761 verified. This status MUST be sent in response to any error not 2762 covered by one of the other status types, and SHOULD NOT contain 2763 details to avoid leaking information to someone probing a node. 2764 To aid debugging, more detailed error information SHOULD be 2765 written to a console or log. 2767 NO_DH_PROPOSAL_CHOSEN 14 2769 None of the proposed group IDs was acceptable. 2771 INVALID_DH_CHOSEN 15 2773 The DH Group ID field does not correspond to one offered 2774 by the Responder. 2776 NO_HIP_PROPOSAL_CHOSEN 16 2778 None of the proposed HIT Suites or HIP Encryption Algorithms was 2779 acceptable. 2781 INVALID_HIP_CIPHER_CHOSEN 17 2783 The HIP_CIPHER Crypto ID does not correspond to one offered by 2784 the Responder. 2786 UNSUPPORTED_HIT_SUITE 20 2788 Sent in response to an I1 or R1 packet for which the HIT suite 2789 is not supported. 2791 AUTHENTICATION_FAILED 24 2793 Sent in response to a HIP signature failure, except when 2794 the signature verification fails in a NOTIFY message. 2796 CHECKSUM_FAILED 26 2798 Sent in response to a HIP checksum failure. 2800 HIP_MAC_FAILED 28 2802 Sent in response to a HIP HMAC failure. 2804 ENCRYPTION_FAILED 32 2806 The Responder could not successfully decrypt the 2807 ENCRYPTED parameter. 2809 INVALID_HIT 40 2811 Sent in response to a failure to validate the peer's 2812 HIT from the corresponding HI. 2814 BLOCKED_BY_POLICY 42 2816 The Responder is unwilling to set up an association 2817 for some policy reason (e.g., received HIT is NULL 2818 and policy does not allow opportunistic mode). 2820 RESPONDER_BUSY_PLEASE_RETRY 44 2822 The Responder is unwilling to set up an association as it is 2823 suffering under some kind of overload and has chosen to shed load 2824 by rejecting the Initiator's request. The Initiator may retry; 2825 however, the Initiator MUST find another (different) puzzle 2826 solution for any such retries. Note that the Initiator may need 2827 to obtain a new puzzle with a new I1/R1 exchange. 2829 Notify Message Types - Status Value 2830 ----------------------------- ----- 2832 I2_ACKNOWLEDGEMENT 16384 2834 The Responder has an I2 packet from the Initiator but had to 2835 queue the I2 packet for processing. The puzzle was correctly 2836 solved and the Responder is willing to set up an association but 2837 currently has a number of I2 packets in the processing queue. 2838 The R2 packet is sent after the I2 packet was processed. 2840 5.2.20. ECHO_REQUEST_SIGNED 2842 0 1 2 3 2843 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 2844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2845 | Type | Length | 2846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2847 | Opaque data (variable length) | 2848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2850 Type 897 2851 Length length of the opaque data in octets 2852 Opaque data opaque data, supposed to be meaningful only to the 2853 node that sends ECHO_REQUEST_SIGNED and receives a 2854 corresponding ECHO_RESPONSE_SIGNED or 2855 ECHO_RESPONSE_UNSIGNED. 2857 The ECHO_REQUEST_SIGNED parameter contains an opaque blob of data 2858 that the sender wants to get echoed back in the corresponding reply 2859 packet. 2861 The ECHO_REQUEST_SIGNED and corresponding echo response parameters 2862 MAY be used for any purpose where a node wants to carry some state in 2863 a request packet and get it back in a response packet. The 2864 ECHO_REQUEST_SIGNED is covered by the HIP_MAC and SIGNATURE. A HIP 2865 packet can contain only one ECHO_REQUEST_SIGNED parameter and MAY 2866 contain multiple ECHO_REQUEST_UNSIGNED parameter. The 2867 ECHO_REQUEST_SIGNED parameter MUST be responded to with an 2868 ECHO_RESPONSE_SIGNED. 2870 5.2.21. ECHO_REQUEST_UNSIGNED 2872 0 1 2 3 2873 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 2874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2875 | Type | Length | 2876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2877 | Opaque data (variable length) | 2878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2880 Type 63661 2881 Length length of the opaque data in octets 2882 Opaque data opaque data, supposed to be meaningful only to the 2883 node that sends ECHO_REQUEST_UNSIGNED and receives a 2884 corresponding ECHO_RESPONSE_UNSIGNED. 2886 The ECHO_REQUEST_UNSIGNED parameter contains an opaque blob of data 2887 that the sender wants to get echoed back in the corresponding reply 2888 packet. 2890 The ECHO_REQUEST_UNSIGNED and corresponding echo response parameters 2891 MAY be used for any purpose where a node wants to carry some state in 2892 a request packet and get it back in a response packet. The 2893 ECHO_REQUEST_UNSIGNED is not covered by the HIP_MAC and SIGNATURE. A 2894 HIP packet can contain one or more ECHO_REQUEST_UNSIGNED parameters. 2895 It is possible that middleboxes add ECHO_REQUEST_UNSIGNED parameters 2896 in HIP packets passing by. The creator of the ECHO_REQUEST_UNSIGNED 2897 (end-host or middlebox) has to create the Opaque field so that it can 2898 later identify and remove the corresponding ECHO_RESPONSE_UNSIGNED 2899 parameter. 2901 The ECHO_REQUEST_UNSIGNED parameter MUST be responded to with an 2902 ECHO_RESPONSE_UNSIGNED parameter. 2904 5.2.22. ECHO_RESPONSE_SIGNED 2906 0 1 2 3 2907 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 2908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2909 | Type | Length | 2910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2911 | Opaque data (variable length) | 2912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2914 Type 961 2915 Length length of the opaque data in octets 2916 Opaque data opaque data, copied unmodified from the 2917 ECHO_REQUEST_SIGNED or ECHO_REQUEST_UNSIGNED 2918 parameter that triggered this response. 2920 The ECHO_RESPONSE_SIGNED parameter contains an opaque blob of data 2921 that the sender of the ECHO_REQUEST_SIGNED wants to get echoed back. 2922 The opaque data is copied unmodified from the ECHO_REQUEST_SIGNED 2923 parameter. 2925 The ECHO_REQUEST_SIGNED and ECHO_RESPONSE_SIGNED parameters MAY be 2926 used for any purpose where a node wants to carry some state in a 2927 request packet and get it back in a response packet. The 2928 ECHO_RESPONSE_SIGNED is covered by the HIP_MAC and SIGNATURE. 2930 5.2.23. ECHO_RESPONSE_UNSIGNED 2932 0 1 2 3 2933 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 2934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2935 | Type | Length | 2936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2937 | Opaque data (variable length) | 2938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2940 Type 63425 2941 Length length of the opaque data in octets 2942 Opaque data opaque data, copied unmodified from the 2943 ECHO_REQUEST_SIGNED or ECHO_REQUEST_UNSIGNED 2944 parameter that triggered this response. 2946 The ECHO_RESPONSE_UNSIGNED parameter contains an opaque blob of data 2947 that the sender of the ECHO_REQUEST_SIGNED or ECHO_REQUEST_UNSIGNED 2948 wants to get echoed back. The opaque data is copied unmodified from 2949 the corresponding echo request parameter. 2951 The echo request and ECHO_RESPONSE_UNSIGNED parameters MAY be used 2952 for any purpose where a node wants to carry some state in a request 2953 packet and get it back in a response packet. The 2954 ECHO_RESPONSE_UNSIGNED is not covered by the HIP_MAC and SIGNATURE. 2956 5.3. HIP Packets 2958 There are eight basic HIP packets (see Table 10). Four are for the 2959 HIP base exchange, one is for updating, one is for sending 2960 notifications, and two are for closing a HIP association. 2962 +------------------+------------------------------------------------+ 2963 | Packet type | Packet name | 2964 +------------------+------------------------------------------------+ 2965 | 1 | I1 - the HIP Initiator Packet | 2966 | | | 2967 | 2 | R1 - the HIP Responder Packet | 2968 | | | 2969 | 3 | I2 - the Second HIP Initiator Packet | 2970 | | | 2971 | 4 | R2 - the Second HIP Responder Packet | 2972 | | | 2973 | 16 | UPDATE - the HIP Update Packet | 2974 | | | 2975 | 17 | NOTIFY - the HIP Notify Packet | 2976 | | | 2977 | 18 | CLOSE - the HIP Association Closing Packet | 2978 | | | 2979 | 19 | CLOSE_ACK - the HIP Closing Acknowledgment | 2980 | | Packet | 2981 +------------------+------------------------------------------------+ 2983 Table 10: HIP packets and packet type values 2985 Packets consist of the fixed header as described in Section 5.1, 2986 followed by the parameters. The parameter part, in turn, consists of 2987 zero or more TLV-coded parameters. 2989 In addition to the base packets, other packet types may be defined 2990 later in separate specifications. For example, support for mobility 2991 and multi-homing is not included in this specification. 2993 See Notation (Section 2.2) for the notation used in the operations. 2995 In the future, an optional upper-layer payload MAY follow the HIP 2996 header. The Next Header field in the header indicates if there is 2997 additional data following the HIP header. The HIP packet, however, 2998 MUST NOT be fragmented. This limits the size of the possible 2999 additional data in the packet. 3001 5.3.1. I1 - the HIP Initiator Packet 3003 The HIP header values for the I1 packet: 3005 Header: 3006 Packet Type = 1 3007 SRC HIT = Initiator's HIT 3008 DST HIT = Responder's HIT, or NULL 3010 IP ( HIP ( DH_GROUP_LIST ) ) 3012 The I1 packet contains the fixed HIP header and the Initiator's 3013 DH_GROUP_LIST. 3015 Valid control bits: none 3017 The Initiator receives the Responder's HIT either from a DNS lookup 3018 of the Responder's FQDN (see 5205-bis), from some other repository, 3019 or from a local table. If the Initiator does not know the 3020 Responder's HIT, it may attempt to use opportunistic mode by using 3021 NULL (all zeros) as the Responder's HIT. See also "HIP Opportunistic 3022 Mode" (Section 4.1.8). 3024 Since the I1 packet is so easy to spoof even if it were signed, no 3025 attempt is made to add to its generation or processing cost. 3027 The Initiator includes a DH_GROUP_LIST parameter in the I1 packet to 3028 inform the Responder of its preferred DH Group IDs. Note that the 3029 DH_GROUP_LIST in the I1 packet is not protected by a signature. 3031 Implementations MUST be able to handle a storm of received I1 3032 packets, discarding those with common content that arrive within a 3033 small time delta. 3035 5.3.2. R1 - the HIP Responder Packet 3037 The HIP header values for the R1 packet: 3039 Header: 3040 Packet Type = 2 3041 SRC HIT = Responder's HIT 3042 DST HIT = Initiator's HIT 3044 IP ( HIP ( [ R1_COUNTER, ] 3045 PUZZLE, 3046 DIFFIE_HELLMAN, 3047 HIP_CIPHER, 3048 HOST_ID, 3049 HIT_SUITE_LIST, 3050 DH_GROUP_LIST, 3051 [ ECHO_REQUEST_SIGNED, ] 3052 HIP_SIGNATURE_2 ) 3053 <, ECHO_REQUEST_UNSIGNED >i) 3055 Valid control bits: A 3057 If the Responder's HI is an anonymous one, the A control MUST be set. 3059 The Initiator's HIT MUST match the one received in the I1 packet if 3060 the R1 is a response to an I1. If the Responder has multiple HIs, 3061 the Responder's HIT used MUST match Initiator's request. If the 3062 Initiator used opportunistic mode, the Responder may select freely 3063 among its HIs. See also "HIP Opportunistic Mode" (Section 4.1.8). 3065 The R1 packet generation counter is used to determine the currently 3066 valid generation of puzzles. The value is increased periodically, 3067 and it is RECOMMENDED that it is increased at least as often as 3068 solutions to old puzzles are no longer accepted. 3070 The Puzzle contains a Random #I and the difficulty #K. The 3071 difficulty #K indicates the number of lower-order bits, in the puzzle 3072 hash result, that must be zeros; see Section 4.1.2. The Random #I is 3073 not covered by the signature and must be zeroed during the signature 3074 calculation, allowing the sender to select and set the #I into a 3075 precomputed R1 packet just prior sending it to the peer. 3077 The Responder selects the Diffie-Hellman public value based on the 3078 Initiator's preference expressed in the DH_GROUP_LIST parameter in 3079 the I1 packet. The Responder sends back its own preference based on 3080 which it chose the DH public value as DH_GROUP_LIST. This allows the 3081 Initiator to determine whether its own DH_GROUP_LIST in the sent I1 3082 packet was manipulated by an attacker. 3084 The Diffie-Hellman public value is ephemeral, and values SHOULD NOT 3085 be reused across different HIP sessions. Once the Responder has 3086 received a valid response to an R1 packet, that Diffie-Hellman value 3087 SHOULD be deprecated. It it is possible that the Responder has sent 3088 the same Diffie-Hellman value to different hosts simultaneously in 3089 corresponding R1 packets and those responses should also be accepted. 3090 However, as a defense against I1 packet storms, an implementation MAY 3091 propose, and re-use unless avoidable, the same Diffie-Hellman value 3092 for a period of time, for example, 15 minutes. By using a small 3093 number of different puzzles for a given Diffie-Hellman value, the R1 3094 packets can be precomputed and delivered as quickly as I1 packets 3095 arrive. A scavenger process should clean up unused Diffie-Hellman 3096 values and puzzles. 3098 Re-using Diffie-Hellman public values opens up the potential security 3099 risk of more than one Initiator ending up with the same keying 3100 material (due to faulty random number generators). Also, more than 3101 one Initiator using the same Responder public key half may lead to 3102 potentially easier cryptographic attacks and to imperfect forward 3103 security. 3105 However, these risks involved in re-using the same public value are 3106 statistical; that is, the authors are not aware of any mechanism that 3107 would allow manipulation of the protocol so that the risk of the re- 3108 use of any given Responder Diffie-Hellman public key would differ 3109 from the base probability. Consequently, it is RECOMMENDED that 3110 Responders avoid re-using the same DH key with multiple Initiators, 3111 but because the risk is considered statistical and not known to be 3112 manipulable, the implementations MAY re-use a key in order to ease 3113 resource-constrained implementations and to increase the probability 3114 of successful communication with legitimate clients even under an I1 3115 packet storm. In particular, when it is too expensive to generate 3116 enough precomputed R1 packets to supply each potential Initiator with 3117 a different DH key, the Responder MAY send the same DH key to several 3118 Initiators, thereby creating the possibility of multiple legitimate 3119 Initiators ending up using the same Responder-side public key. 3120 However, as soon as the Responder knows that it will use a particular 3121 DH key, it SHOULD stop offering it. This design is aimed to allow 3122 resource-constrained Responders to offer services under I1 packet 3123 storms and to simultaneously make the probability of DH key re-use 3124 both statistical and as low as possible. 3126 If the Responder uses the same DH keypair for multiple handshakes. 3127 It must take care to avoid small subgroup attacks [RFC2785]. To 3128 avoid these attacks, when receiving the I2 message, the Responder 3129 SHOULD validate the Initiators DH public key as described in 3130 [RFC2785] Section 3.1. In case the validation fails, the Responder 3131 MUST NOT generate a DH shared key and MUST silently abort the HIP 3132 BEX. 3134 The HIP_CIPHER contains the encryption algorithms supported by the 3135 Responder to encrypt the contents of the ENCRYPTED parameter, in the 3136 order of preference. All implementations MUST support AES [RFC3602]. 3138 The HIT_SUITE_LIST parameter is an ordered list of the Responder's 3139 preferred and supported HIT Suites. The list allows the Initiator to 3140 determine whether its own source HIT matches any suite supported by 3141 the Responder. 3143 The ECHO_REQUEST_SIGNED and ECHO_REQUEST_UNSIGNED parameters contain 3144 data that the sender wants to receive unmodified in the corresponding 3145 response packet in the ECHO_RESPONSE_SIGNED or ECHO_RESPONSE_UNSIGNED 3146 parameter. The R1 packet may contain zero or more 3147 ECHO_REQUEST_UNSIGNED parameters as described in Section 3148 Section 5.2.21. 3150 The signature is calculated over the whole HIP packet as described in 3151 Section 5.2.15. This allows the Responder to use precomputed R1s. 3152 The Initiator SHOULD validate this signature. It MUST check that the 3153 Responder's HI matches with the one expected, if any. 3155 5.3.3. I2 - the Second HIP Initiator Packet 3157 The HIP header values for the I2 packet: 3159 Header: 3160 Type = 3 3161 SRC HIT = Initiator's HIT 3162 DST HIT = Responder's HIT 3164 IP ( HIP ( [R1_COUNTER,] 3165 SOLUTION, 3166 DIFFIE_HELLMAN, 3167 HIP_CIPHER, 3168 ENCRYPTED { HOST_ID } or HOST_ID, 3169 [ ECHO_RESPONSE_SIGNED ,] 3170 HIP_MAC, 3171 HIP_SIGNATURE 3172 <, ECHO_RESPONSE_UNSIGNED>i ) ) 3174 Valid control bits: A 3176 The HITs used MUST match the ones used in the R1. 3178 If the Initiator's HI is an anonymous one, the A control MUST be set. 3180 If present in the I1 packet, the Initiator MUST include an unmodified 3181 copy of the R1_COUNTER parameter received in the corresponding R1 3182 packet into the I2 packet. 3184 The Solution contains the Random #I from R1 and the computed #J. The 3185 low-order #K bits of the RHASH(I | ... | J) MUST be zero. 3187 The Diffie-Hellman value is ephemeral. If precomputed, a scavenger 3188 process should clean up unused Diffie-Hellman values. The Responder 3189 MAY re-use Diffie-Hellman values under some conditions as specified 3190 in Section 5.3.2. 3192 The HIP_CIPHER contains the single encryption transform selected by 3193 the Initiator, that it uses to encrypt the ENCRYPTED parameters. The 3194 chosen cipher MUST correspond to one of the ciphers offered by the 3195 Responder in the R1. All implementations MUST support AES [RFC3602]. 3197 The Initiator's HI MAY be encrypted using the HIP_CIPHER encryption 3198 algorithm. The keying material is derived from the Diffie-Hellman 3199 exchanged as defined in Section 6.5. 3201 The ECHO_RESPONSE_SIGNED and ECHO_RESPONSE_UNSIGNED contain the 3202 unmodified Opaque data copied from the corresponding echo request 3203 parameter(s). 3205 The HMAC value in the HIP_MAC parameter is calculated over the whole 3206 HIP packet, excluding any parameters after the HIP_MAC, as described 3207 in Section 6.4.1. The Responder MUST validate the HIP_MAC. 3209 The signature is calculated over the whole HIP packet, excluding any 3210 parameters after the HIP_SIGNATURE, as described in Section 5.2.14. 3211 The Responder MUST validate this signature. The Responder uses the 3212 HI in the packet or a HI acquired by some other means for verifying 3213 the signature. 3215 5.3.4. R2 - the Second HIP Responder Packet 3217 The HIP header values for the R2 packet: 3219 Header: 3220 Packet Type = 4 3221 SRC HIT = Responder's HIT 3222 DST HIT = Initiator's HIT 3224 IP ( HIP ( HIP_MAC_2, HIP_SIGNATURE ) ) 3226 Valid control bits: none 3228 The HIP_MAC_2 is calculated over the whole HIP packet, with 3229 Responder's HOST_ID parameter concatenated with the HIP packet. The 3230 HOST_ID parameter is removed after the HMAC calculation. The 3231 procedure is described in Section 6.4.1. 3233 The signature is calculated over the whole HIP packet. 3235 The Initiator MUST validate both the HIP_MAC and the signature. 3237 5.3.5. UPDATE - the HIP Update Packet 3239 Support for the UPDATE packet is MANDATORY. 3241 The HIP header values for the UPDATE packet: 3243 Header: 3244 Packet Type = 16 3245 SRC HIT = Sender's HIT 3246 DST HIT = Recipient's HIT 3248 IP ( HIP ( [SEQ, ACK, ] HIP_MAC, HIP_SIGNATURE ) ) 3250 Valid control bits: None 3252 The UPDATE packet contains mandatory HIP_MAC and HIP_SIGNATURE 3253 parameters, and other optional parameters. 3255 The UPDATE packet contains zero or one SEQ parameter. The presence 3256 of a SEQ parameter indicates that the receiver MUST acknowledge the 3257 the UPDATE. An UPDATE that does not contain a SEQ but only an ACK 3258 parameter is simply an acknowledgment of a previous UPDATE and itself 3259 MUST NOT be acknowledged by a separate ACK. Such UPDATE packets 3260 containing only an ACK parameter do not require processing in 3261 relative order to other UPDATE packets. An UPDATE packet without 3262 either a SEQ or an ACK parameter is invalid; such unacknowledged 3263 updates MUST instead use a NOTIFY packet. 3265 An UPDATE packet contains zero or one ACK parameters. The ACK 3266 parameter echoes the SEQ sequence number of the UPDATE packet being 3267 ACKed. A host MAY choose to acknowledge more than one UPDATE packet 3268 at a time; e.g., the ACK may contain the last two SEQ values 3269 received, for resilience against ACK loss. ACK values are not 3270 cumulative; each received unique SEQ value requires at least one 3271 corresponding ACK value in reply. Received ACKs that are redundant 3272 are ignored. Hosts MUST implement the processing of ACKs with 3273 multiple SEQ numbers even if they do not implement sending ACKs with 3274 multiple SEQ numbers. 3276 The UPDATE packet may contain both a SEQ and an ACK parameter. In 3277 this case, the ACK is being piggybacked on an outgoing UPDATE. In 3278 general, UPDATEs carrying SEQ SHOULD be ACKed upon completion of the 3279 processing of the UPDATE. A host MAY choose to hold the UPDATE 3280 carrying ACK for a short period of time to allow for the possibility 3281 of piggybacking the ACK parameter, in a manner similar to TCP delayed 3282 acknowledgments. 3284 A sender MAY choose to forgo reliable transmission of a particular 3285 UPDATE (e.g., it becomes overcome by events). The semantics are such 3286 that the receiver MUST acknowledge the UPDATE, but the sender MAY 3287 choose to not care about receiving the ACK. 3289 UPDATEs MAY be retransmitted without incrementing SEQ. If the same 3290 subset of parameters is included in multiple UPDATEs with different 3291 SEQs, the host MUST ensure that the receiver's processing of the 3292 parameters multiple times will not result in a protocol error. 3294 5.3.6. NOTIFY - the HIP Notify Packet 3296 Implementing the NOTIFY packet is optional. The NOTIFY packet MAY be 3297 used to provide information to a peer. Typically, NOTIFY is used to 3298 indicate some type of protocol error or negotiation failure. NOTIFY 3299 packets are unacknowledged. The receiver can handle the packet only 3300 as informational, and SHOULD NOT change its HIP state (see 3301 Section 4.4.2) based purely on a received NOTIFY packet. 3303 The HIP header values for the NOTIFY packet: 3305 Header: 3306 Packet Type = 17 3307 SRC HIT = Sender's HIT 3308 DST HIT = Recipient's HIT, or zero if unknown 3310 IP ( HIP (i, [HOST_ID, ] HIP_SIGNATURE) ) 3312 Valid control bits: None 3314 The NOTIFY packet is used to carry one or more NOTIFICATION 3315 parameters. 3317 5.3.7. CLOSE - the HIP Association Closing Packet 3319 The HIP header values for the CLOSE packet: 3321 Header: 3322 Packet Type = 18 3323 SRC HIT = Sender's HIT 3324 DST HIT = Recipient's HIT 3326 IP ( HIP ( ECHO_REQUEST_SIGNED, HIP_MAC, HIP_SIGNATURE ) ) 3328 Valid control bits: none 3330 The sender MUST include an ECHO_REQUEST_SIGNED used to validate 3331 CLOSE_ACK received in response, and both a HIP_MAC and a signature 3332 (calculated over the whole HIP packet). 3334 The receiver peer MUST reply with a CLOSE_ACK containing an 3335 ECHO_RESPONSE_SIGNED corresponding to the received 3336 ECHO_REQUEST_SIGNED. 3338 5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet 3340 The HIP header values for the CLOSE_ACK packet: 3342 Header: 3343 Packet Type = 19 3344 SRC HIT = Sender's HIT 3345 DST HIT = Recipient's HIT 3347 IP ( HIP ( ECHO_RESPONSE_SIGNED, HIP_MAC, HIP_SIGNATURE ) ) 3349 Valid control bits: none 3351 The sender MUST include both an HMAC and signature (calculated over 3352 the whole HIP packet). 3354 The receiver peer MUST validate the ECHO_RESPONSE_SIGNED and validate 3355 both the HIP_MAC and the signature if the receiver has state for a 3356 HIP association. 3358 5.4. ICMP Messages 3360 When a HIP implementation detects a problem with an incoming packet, 3361 and it either cannot determine the identity of the sender of the 3362 packet or does not have any existing HIP association with the sender 3363 of the packet, it MAY respond with an ICMP packet. Any such replies 3364 MUST be rate-limited as described in [RFC4443]. In most cases, the 3365 ICMP packet has the Parameter Problem type (12 for ICMPv4, 4 for 3366 ICMPv6), with the Pointer field pointing to the field that caused the 3367 ICMP message to be generated. 3369 5.4.1. Invalid Version 3371 If a HIP implementation receives a HIP packet that has an 3372 unrecognized HIP version number, it SHOULD respond, rate-limited, 3373 with an ICMP packet with type Parameter Problem, with the Pointer 3374 pointing to the Version/RES. byte in the HIP header. 3376 5.4.2. Other Problems with the HIP Header and Packet Structure 3378 If a HIP implementation receives a HIP packet that has other 3379 unrecoverable problems in the header or packet format, it MAY 3380 respond, rate-limited, with an ICMP packet with type Parameter 3381 Problem, the Pointer pointing to the field that failed to pass the 3382 format checks. However, an implementation MUST NOT send an ICMP 3383 message if the checksum fails; instead, it MUST silently drop the 3384 packet. 3386 5.4.3. Invalid Puzzle Solution 3388 If a HIP implementation receives an I2 packet that has an invalid 3389 puzzle solution, the behavior depends on the underlying version of 3390 IP. If IPv6 is used, the implementation SHOULD respond with an ICMP 3391 packet with type Parameter Problem, the Pointer pointing to the 3392 beginning of the Puzzle solution #J field in the SOLUTION payload in 3393 the HIP message. 3395 If IPv4 is used, the implementation MAY respond with an ICMP packet 3396 with the type Parameter Problem, copying enough of bytes from the I2 3397 message so that the SOLUTION parameter fits into the ICMP message, 3398 the Pointer pointing to the beginning of the Puzzle solution #J 3399 field, as in the IPv6 case. Note, however, that the resulting ICMPv4 3400 message exceeds the typical ICMPv4 message size as defined in 3401 [RFC0792]. 3403 5.4.4. Non-Existing HIP Association 3405 If a HIP implementation receives a CLOSE or UPDATE packet, or any 3406 other packet whose handling requires an existing association, that 3407 has either a Receiver or Sender HIT that does not match with any 3408 existing HIP association, the implementation MAY respond, rate- 3409 limited, with an ICMP packet with the type Parameter Problem. The 3410 Pointer of the ICMP Parameter Problem packet is set pointing to the 3411 beginning of the first HIT that does not match. 3413 A host MUST NOT reply with such an ICMP if it receives any of the 3414 following messages: I1, R2, I2, R2, and NOTIFY packet. When 3415 introducing new packet types, a specification SHOULD define the 3416 appropriate rules for sending or not sending this kind of ICMP reply. 3418 6. Packet Processing 3420 Each host is assumed to have a single HIP protocol implementation 3421 that manages the host's HIP associations and handles requests for new 3422 ones. Each HIP association is governed by a conceptual state 3423 machine, with states defined above in Section 4.4. The HIP 3424 implementation can simultaneously maintain HIP associations with more 3425 than one host. Furthermore, the HIP implementation may have more 3426 than one active HIP association with another host; in this case, HIP 3427 associations are distinguished by their respective HITs. It is not 3428 possible to have more than one HIP association between any given pair 3429 of HITs. Consequently, the only way for two hosts to have more than 3430 one parallel association is to use different HITs, at least at one 3431 end. 3433 The processing of packets depends on the state of the HIP 3434 association(s) with respect to the authenticated or apparent 3435 originator of the packet. A HIP implementation determines whether it 3436 has an active association with the originator of the packet based on 3437 the HITs. In the case of user data carried in a specific transport 3438 format, the transport format document specifies how the incoming 3439 packets are matched with the active associations. 3441 6.1. Processing Outgoing Application Data 3443 In a HIP host, an application can send application-level data using 3444 an identifier specified via the underlying API. The API can be a 3445 backwards-compatible API (see [RFC5338]), using identifiers that look 3446 similar to IP addresses, or a completely new API, providing enhanced 3447 services related to Host Identities. Depending on the HIP 3448 implementation, the identifier provided to the application may be 3449 different; for example, it can be a HIT or an IP address. 3451 The exact format and method for transferring the user data from the 3452 source HIP host to the destination HIP host is defined in the 3453 corresponding transport format document. The actual data is 3454 transferred in the network using the appropriate source and 3455 destination IP addresses. 3457 In this document, conceptual processing rules are defined only for 3458 the base case where both hosts have only single usable IP addresses; 3459 the multi-address multi-homing case is specified separately. 3461 The following conceptual algorithm describes the steps that are 3462 required for handling outgoing datagrams destined to a HIT. 3464 1. If the datagram has a specified source address, it MUST be a HIT. 3465 If it is not, the implementation MAY replace the source address 3466 with a HIT. Otherwise, it MUST drop the packet. 3468 2. If the datagram has an unspecified source address, the 3469 implementation MUST choose a suitable source HIT for the 3470 datagram. Selecting the source HIT is subject to local policy. 3472 3. If there is no active HIP association with the given HIT pair, one MUST be created by running the base 3474 exchange. While waiting for the base exchange to complete, the 3475 implementation SHOULD queue at least one packet per HIP 3476 association to be formed, and it MAY queue more than one. 3478 4. Once there is an active HIP association for the given HIT pair, the outgoing datagram is passed to 3480 transport handling. The possible transport formats are defined 3481 in separate documents, of which the ESP transport format for HIP 3482 is mandatory for all HIP implementations. 3484 5. Before sending the packet, the HITs in the datagram are replaced 3485 with suitable IP addresses. For IPv6, the rules defined in 3487 [RFC3484] SHOULD be followed. Note that this HIT-to-IP-address 3488 conversion step MAY also be performed at some other point in the 3489 stack, e.g., before wrapping the packet into the output format. 3491 6.2. Processing Incoming Application Data 3493 The following conceptual algorithm describes the incoming datagram 3494 handling when HITs are used at the receiving host as application- 3495 level identifiers. More detailed steps for processing packets are 3496 defined in corresponding transport format documents. 3498 1. The incoming datagram is mapped to an existing HIP association, 3499 typically using some information from the packet. For example, 3500 such mapping may be based on the ESP Security Parameter Index 3501 (SPI). 3503 2. The specific transport format is unwrapped, in a way depending on 3504 the transport format, yielding a packet that looks like a 3505 standard (unencrypted) IP packet. If possible, this step SHOULD 3506 also verify that the packet was indeed (once) sent by the remote 3507 HIP host, as identified by the HIP association. 3509 Depending on the used transport mode, the verification method can 3510 vary. While the HI (as well as HIT) is used as the higher-layer 3511 identifier, the verification method has to verify that the data 3512 packet was sent by the correct node identity and that the actual 3513 identity maps to this particular HIT. When using ESP transport 3514 format [I-D.ietf-hip-rfc5202-bis], the verification is done using 3515 the SPI value in the data packet to find the corresponding SA 3516 with associated HIT and key, and decrypting the packet with that 3517 associated key. 3519 3. The IP addresses in the datagram are replaced with the HITs 3520 associated with the HIP association. Note that this IP-address- 3521 to-HIT conversion step MAY also be performed at some other point 3522 in the stack. 3524 4. The datagram is delivered to the upper layer (e.g., UDP or TCP). 3525 When demultiplexing the datagram, the right upper-layer socket is 3526 selected based on the HITs. 3528 6.3. Solving the Puzzle 3530 This subsection describes the details for solving the puzzle. 3532 In the R1 packet, the values #I and #K are sent in network byte 3533 order. Similarly, in the I2 packet, the values #I and #J are sent in 3534 network byte order. The hash is created by concatenating, in network 3535 byte order, the following data, in the following order and using the 3536 RHASH algorithm: 3538 n-bit random value #I (where n is RHASH_len), in network byte 3539 order, as appearing in the R1 and I2 packets. 3541 128-bit Initiator's HIT, in network byte order, as appearing in 3542 the HIP Payload in the R1 and I2 packets. 3544 128-bit Responder's HIT, in network byte order, as appearing in 3545 the HIP Payload in the R1 and I2 packets. 3547 n-bit random value #J (where n is RHASH_len), in network byte 3548 order, as appearing in the I2 packet. 3550 In a valid response puzzle, the #K low-order bits of the resulting 3551 RHASH digest MUST be zero. 3553 Notes: 3555 i) The length of the data to be hashed is variable depending on 3556 the output length of the Responder's hash function RHASH. 3558 ii) All the data in the hash input MUST be in network byte order. 3560 iii) The order of the Initiator's and Responder's HITs are 3561 different in the R1 and I2 packets; see Section 5.1. Care must be 3562 taken to copy the values in the right order to the hash input. 3564 iv) For a puzzle #I, there may exist multiple valid puzzle 3565 solutions #J. 3567 The following procedure describes the processing steps involved, 3568 assuming that the Responder chooses to precompute the R1 packets: 3570 Precomputation by the Responder: 3571 Sets up the puzzle difficulty #K. 3572 Creates a signed R1 and caches it. 3574 Responder: 3575 Selects a suitable cached R1. 3576 Generates a random number #I. 3577 Sends #I and #K in an R1. 3578 Saves #I and #K for a Delta time. 3580 Initiator: 3581 Generates repeated attempts to solve the puzzle until a matching 3582 #J is found: 3583 Ltrunc( RHASH( #I | HIT-I | HIT-R | #J ), #K ) == 0 3584 Sends #I and #J in an I2. 3586 Responder: 3587 Verifies that the received #I is a saved one. 3588 Finds the right #K based on #I. 3589 Computes V := Ltrunc( RHASH( #I | HIT-I | HIT-R | #J ), #K ) 3590 Rejects if V != 0 3591 Accept if V == 0 3593 6.4. HIP_MAC and SIGNATURE Calculation and Verification 3595 The following subsections define the actions for processing HIP_MAC, 3596 HIP_MAC_2, HIP_SIGNATURE and HIP_SIGNATURE_2 parameters. The 3597 HIP_MAC_2 parameter is contained in the R2 packet. The 3598 HIP_SIGNATURE_2 parameter is contained in the R1 packet. The 3599 HIP_SIGNATURE and HIP_MAC parameter are contained in other HIP 3600 control packets. 3602 6.4.1. HMAC Calculation 3604 The HMAC uses RHASH as underlying hash function. The type of RHASH 3605 depends on the HIT Suite of the Responder. Hence, HMAC-SHA-256 3606 [RFC4868] is used for HIT Suite RSA/DSA/SHA-256, HMAC-SHA-1 [RFC2404] 3607 is used for HIT Suite ECDSA_LOW/SHA-1, and HMAC-SHA-384 [RFC4868] for 3608 HIT Suite ECDSA/SHA-384. 3610 The following process applies both to the HIP_MAC and HIP_MAC_2 3611 parameters. When processing HIP_MAC_2, the difference is that the 3612 HIP_MAC calculation includes a pseudo HOST_ID field containing the 3613 Responder's information as sent in the R1 packet earlier. 3615 Both the Initiator and the Responder should take some care when 3616 verifying or calculating the HIP_MAC_2. Specifically, the Initiator 3617 has to preserve the HOST_ID exactly as it was received in the R1 3618 packet until it receives the HIP_MAC_2 in the R2 packet. 3620 The scope of the calculation for HIP_MAC is: 3622 HMAC: { HIP header | [ Parameters ] } 3624 where Parameters include all HIP parameters of the packet that is 3625 being calculated with Type values ranging from 1 to (HIP_MAC's Type 3626 value - 1) and exclude parameters with Type values greater or equal 3627 to HIP_MAC's Type value. 3629 During HIP_MAC calculation, the following applies: 3631 o In the HIP header, the Checksum field is set to zero. 3633 o In the HIP header, the Header Length field value is calculated to 3634 the beginning of the HIP_MAC parameter. 3636 Parameter order is described in Section 5.2.1. 3638 The scope of the calculation for HIP_MAC_2 is: 3640 HIP_MAC_2: { HIP header | [ Parameters ] | HOST_ID } 3642 where Parameters include all HIP parameters for the packet that is 3643 being calculated with Type values from 1 to (HIP_MAC_2's Type value - 3644 1) and exclude parameters with Type values greater or equal to 3645 HIP_MAC_2's Type value. 3647 During HIP_MAC_2 calculation, the following applies: 3649 o In the HIP header, the Checksum field is set to zero. 3651 o In the HIP header, the Header Length field value is calculated to 3652 the beginning of the HIP_MAC_2 parameter and increased by the 3653 length of the concatenated HOST_ID parameter length (including 3654 type and length fields). 3656 o HOST_ID parameter is exactly in the form it was received in the R1 3657 packet from the Responder. 3659 Parameter order is described in Section 5.2.1, except that the 3660 HOST_ID parameter in this calculation is added to the end. 3662 The HIP_MAC parameter is defined in Section 5.2.12 and the HIP_MAC_2 3663 parameter in Section 5.2.13. The HMAC calculation and verification 3664 process (the process applies both to HIP_MAC and HIP_MAC_2 except 3665 where HIP_MAC_2 is mentioned separately) is as follows: 3667 Packet sender: 3669 1. Create the HIP packet, without the HIP_MAC, HIP_SIGNATURE, 3670 HIP_SIGNATURE_2, or any other parameter with greater Type value 3671 than the HIP_MAC parameter has. 3673 2. In case of HIP_MAC_2 calculation, add a HOST_ID (Responder) 3674 parameter to the end of the packet. 3676 3. Calculate the Header Length field in the HIP header including the 3677 added HOST_ID parameter in case of HIP_MAC_2. 3679 4. Compute the HMAC using either HIP-gl or HIP-lg integrity key 3680 retrieved from KEYMAT as defined in Section 6.5. 3682 5. In case of HIP_MAC_2, remove the HOST_ID parameter from the 3683 packet. 3685 6. Add the HIP_MAC parameter to the packet and any parameter with 3686 greater Type value than the HIP_MAC's (HIP_MAC_2's) that may 3687 follow, including possible HIP_SIGNATURE or HIP_SIGNATURE_2 3688 parameters 3690 7. Recalculate the Length field in the HIP header. 3692 Packet receiver: 3694 1. Verify the HIP header Length field. 3696 2. Remove the HIP_MAC or HIP_MAC_2 parameter, as well as all other 3697 parameters that follow it with greater Type value including 3698 possible HIP_SIGNATURE or HIP_SIGNATURE_2 fields, saving the 3699 contents if they are needed later. 3701 3. In case of HIP_MAC_2, build and add a HOST_ID parameter (with 3702 Responder information) to the packet. The HOST_ID parameter 3703 should be identical to the one previously received from the 3704 Responder. 3706 4. Recalculate the HIP packet length in the HIP header and clear the 3707 Checksum field (set it to all zeros). In case of HIP_MAC_2, the 3708 length is calculated with the added HOST_ID parameter. 3710 5. Compute the HMAC using either HIP-gl or HIP-lg integrity key as 3711 defined in Section 6.5 and verify it against the received HMAC. 3713 6. Set Checksum and Header Length field in the HIP header to 3714 original values. Note that the checksum and length fields 3715 contain incorrect values after this step. 3717 7. In case of HIP_MAC_2, remove the HOST_ID parameter from the 3718 packet before further processing. 3720 6.4.2. Signature Calculation 3722 The following process applies both to the HIP_SIGNATURE and 3723 HIP_SIGNATURE_2 parameters. When processing the HIP_SIGNATURE_2, the 3724 only difference is that instead of the HIP_SIGNATURE parameter, the 3725 HIP_SIGNATURE_2 parameter is used, and the Initiator's HIT and PUZZLE 3726 Opaque and Random #I fields are cleared (set to all zeros) before 3727 computing the signature. The HIP_SIGNATURE parameter is defined in 3728 Section 5.2.14 and the HIP_SIGNATURE_2 parameter in Section 5.2.15. 3730 The scope of the calculation for HIP_SIGNATURE and HIP_SIGNATURE_2 3731 is: 3733 HIP_SIGNATURE: { HIP header | [ Parameters ] } 3735 where Parameters include all HIP parameters for the packet that is 3736 being calculated with Type values from 1 to (HIP_SIGNATURE's Type 3737 value - 1). 3739 During signature calculation, the following applies: 3741 o In the HIP header, the Checksum field is set to zero. 3743 o In the HIP header, the Header Length field value is calculated to 3744 the beginning of the HIP_SIGNATURE parameter. 3746 The parameter order is described in Section 5.2.1. 3748 HIP_SIGNATURE_2: { HIP header | [ Parameters ] } 3750 where Parameters include all HIP parameters for the packet that is 3751 being calculated with Type values ranging from 1 to 3752 (HIP_SIGNATURE_2's Type value - 1). 3754 During signature calculation, the following apply: 3756 o In the HIP header, the Initiator's HIT field and Checksum fields 3757 are set to zero. 3759 o In the HIP header, the Header Length field value is calculated to 3760 the beginning of the HIP_SIGNATURE_2 parameter. 3762 o PUZZLE parameter's Opaque and Random #I fields are set to zero. 3764 Parameter order is described in Section 5.2.1. 3766 The signature calculation and verification process (the process 3767 applies both to HIP_SIGNATURE and HIP_SIGNATURE_2 except in the case 3768 where HIP_SIGNATURE_2 is separately mentioned) is as follows: 3770 Packet sender: 3772 1. Create the HIP packet without the HIP_SIGNATURE parameter or any 3773 other parameters that follow the HIP_SIGNATURE parameter. 3775 2. Calculate the Length field and zero the Checksum field in the HIP 3776 header. In case of HIP_SIGNATURE_2, set Initiator's HIT field in 3777 the HIP header as well as PUZZLE parameter's Opaque and Random #I 3778 fields to zero. 3780 3. Compute the signature using the private key corresponding to the 3781 Host Identifier (public key). 3783 4. Add the HIP_SIGNATURE parameter to the packet. 3785 5. Add any parameters that follow the HIP_SIGNATURE parameter. 3787 6. Recalculate the Length field in the HIP header, and calculate the 3788 Checksum field. 3790 Packet receiver: 3792 1. Verify the HIP header Length field and checksum. 3794 2. Save the contents of the HIP_SIGNATURE parameter and any other 3795 parameters following the HIP_SIGNATURE parameter and remove them 3796 from the packet. 3798 3. Recalculate the HIP packet Length in the HIP header and clear the 3799 Checksum field (set it to all zeros). In case of 3800 HIP_SIGNATURE_2, set Initiator's HIT field in the HIP header as 3801 well as PUZZLE parameter's Opaque and Random #I fields to zero. 3803 4. Compute the signature and verify it against the received 3804 signature using the packet sender's Host Identity (public key). 3806 5. Restore the original packet by adding removed parameters (in step 3807 2) and resetting the values that were set to zero (in step 3). 3809 The verification can use either the HI received from a HIP packet, 3810 the HI from a DNS query, if the FQDN has been received in the HOST_ID 3811 packet or one received by some other means. 3813 6.5. HIP KEYMAT Generation 3815 HIP keying material is derived from the Diffie-Hellman session key, 3816 Kij, produced during the HIP base exchange (see Section 4.1.3). The 3817 Initiator has Kij during the creation of the I2 packet, and the 3818 Responder has Kij once it receives the I2 packet. This is why I2 can 3819 already contain encrypted information. 3821 The KEYMAT is derived by feeding Kij into the key derivation function 3822 defined by the DH Group ID. Currently the only key derivation 3823 function defied in this document is the Hash-based Key Derivation 3824 Function (HKDF) [RFC5869] using the RHASH hash function. Other 3825 documents may define new DH Group IDs and corresponding key 3826 distribution functions. 3828 In the following we provide the details for deriving the keying 3829 material using HKDF. 3831 where 3833 info = sort(HIT-I | HIT-R) 3834 salt = #I | #J 3836 Sort(HIT-I | HIT-R) is defined as the network byte order 3837 concatenation of the two HITs, with the smaller HIT preceding the 3838 larger HIT, resulting from the numeric comparison of the two HITs 3839 interpreted as positive (unsigned) 128-bit integers in network byte 3840 order. The #I and #J values are from the puzzle and its solution 3841 that were exchanged in R1 and I2 messages when this HIP association 3842 was set up. Both hosts have to store #I and #J values for the HIP 3843 association for future use. 3845 The initial keys are drawn sequentially in the order that is 3846 determined by the numeric comparison of the two HITs, with comparison 3847 method described in the previous paragraph. HOST_g denotes the host 3848 with the greater HIT value, and HOST_l the host with the lower HIT 3849 value. 3851 The drawing order for the four initial keys is as follows: 3853 HIP-gl encryption key for HOST_g's ENCRYPTED parameter 3855 HIP-gl integrity (HMAC) key for HOST_g's outgoing HIP packets 3857 HIP-lg encryption key for HOST_l's ENCRYPTED parameter 3859 HIP-lg integrity (HMAC) key for HOST_l's outgoing HIP packets 3861 The number of bits drawn for a given algorithm is the "natural" size 3862 of the keys. For the mandatory algorithms, the following sizes 3863 apply: 3865 AES 128 or 256 bits 3867 SHA-1 160 bits 3869 SHA-256 256 bits 3871 SHA-384 384 bits 3873 NULL 0 bits 3875 If other key sizes are used, they MUST be treated as different 3876 encryption algorithms and defined separately. 3878 6.6. Initiation of a HIP Base Exchange 3880 An implementation may originate a HIP base exchange to another host 3881 based on a local policy decision, usually triggered by an application 3882 datagram, in much the same way that an IPsec IKE key exchange can 3883 dynamically create a Security Association. Alternatively, a system 3884 may initiate a HIP exchange if it has rebooted or timed out, or 3885 otherwise lost its HIP state, as described in Section 4.5.4. 3887 The implementation prepares an I1 packet and sends it to the IP 3888 address that corresponds to the peer host. The IP address of the 3889 peer host may be obtained via conventional mechanisms, such as DNS 3890 lookup. The I1 packet contents are specified in Section 5.3.1. The 3891 selection of which source or destination Host Identity to use, if a 3892 Initiator or Responder has more than one to choose from, is typically 3893 a policy decision. 3895 The following steps define the conceptual processing rules for 3896 initiating a HIP base exchange: 3898 1. The Initiator receives one or more of the Responder's HITs and 3899 one or more addresses either from a DNS lookup of the Responder's 3900 FQDN, from some other repository, or from a local database. If 3901 the Initiator does not know the Responder's HIT, it may attempt 3902 opportunistic mode by using NULL (all zeros) as the Responder's 3903 HIT (see also "HIP Opportunistic Mode" (Section 4.1.8)). If the 3904 Initiator can choose from multiple Responder HITs, it selects a 3905 HIT for which the Initiator supports the HIT Suite. 3907 2. The Initiator sends an I1 packet to one of the Responder's 3908 addresses. The selection of which address to use is a local 3909 policy decision. 3911 3. The Initiator includes the DH_GROUP_LIST in the I1 packet. The 3912 selection and order of DH Group IDs in the DH_GROUP_LIST MUST be 3913 stored by the Initiator because this list is needed for later R1 3914 processing. In most cases, the preferences regarding the DH 3915 Groups will be static, so no per-association storage is 3916 necessary. 3918 4. Upon sending an I1 packet, the sender transitions to state I1- 3919 SENT, starts a timer for which the timeout value SHOULD be larger 3920 than the worst-case anticipated RTT. The sender SHOULD also 3921 increment the timeout counter associated with the I1. 3923 5. Upon timeout, the sender SHOULD retransmit the I1 packet and 3924 restart the timer, up to a maximum of I1_RETRIES_MAX tries. 3926 6.6.1. Sending Multiple I1 Packets in Parallel 3928 For the sake of minimizing the session establishment latency, an 3929 implementation MAY send the same I1 packet to more than one of the 3930 Responder's addresses. However, it MUST NOT send to more than three 3931 (3) Responder addresses in parallel. Furthermore, upon timeout, the 3932 implementation MUST refrain from sending the same I1 packet to 3933 multiple addresses. That is, if it retries to initialize the 3934 connection after a timeout, it MUST NOT send the I1 packet to more 3935 than one destination address. These limitations are placed in order 3936 to avoid congestion of the network, and potential DoS attacks that 3937 might occur, e.g., because someone's claim to have hundreds or 3938 thousands of addresses could generate a huge number of I1 packets 3939 from the Initiator. 3941 As the Responder is not guaranteed to distinguish the duplicate I1 3942 packets it receives at several of its addresses (because it avoids 3943 storing states when it answers back an R1 packet), the Initiator may 3944 receive several duplicate R1 packets. 3946 The Initiator SHOULD then select the initial preferred destination 3947 address using the source address of the selected received R1, and use 3948 the preferred address as a source address for the I2 packet. 3949 Processing rules for received R1s are discussed in Section 6.8. 3951 6.6.2. Processing Incoming ICMP Protocol Unreachable Messages 3953 A host may receive an ICMP 'Destination Protocol Unreachable' message 3954 as a response to sending a HIP I1 packet. Such a packet may be an 3955 indication that the peer does not support HIP, or it may be an 3956 attempt to launch an attack by making the Initiator believe that the 3957 Responder does not support HIP. 3959 When a system receives an ICMP 'Destination Protocol Unreachable' 3960 message while it is waiting for an R1 packet, it MUST NOT terminate 3961 waiting. It MAY continue as if it had not received the ICMP message, 3962 and send a few more I1 packets. Alternatively, it MAY take the ICMP 3963 message as a hint that the peer most probably does not support HIP, 3964 and return to state UNASSOCIATED earlier than otherwise. However, at 3965 minimum, it MUST continue waiting for an R1 packet for a reasonable 3966 time before returning to UNASSOCIATED. 3968 6.7. Processing Incoming I1 Packets 3970 An implementation SHOULD reply to an I1 with an R1 packet, unless the 3971 implementation is unable or unwilling to set up a HIP association. 3972 If the implementation is unable to set up a HIP association, the host 3973 SHOULD send an ICMP Destination Protocol Unreachable, 3974 Administratively Prohibited, message to the I1 packet source IP 3975 address. If the implementation is unwilling to set up a HIP 3976 association, the host MAY ignore the I1 packet. This latter case may 3977 occur during a DoS attack such as an I1 packet flood. 3979 The implementation SHOULD be able to handle a storm of received I1 3980 packets, discarding those with common content that arrive within a 3981 small time delta. 3983 A spoofed I1 packet can result in an R1 attack on a system. An R1 3984 packet sender MUST have a mechanism to rate-limit R1 packets sent to 3985 an address. 3987 It is RECOMMENDED that the HIP state machine does not transition upon 3988 sending an R1 packet. 3990 The following steps define the conceptual processing rules for 3991 responding to an I1 packet: 3993 1. The Responder MUST check that the Responder's HIT in the received 3994 I1 packet is either one of its own HITs or NULL. Otherwise it 3995 must drop the packet. 3997 2. If the Responder is in ESTABLISHED state, the Responder MAY 3998 respond to this with an R1 packet, prepare to drop an existing 3999 HIP security association with the peer, and stay at ESTABLISHED 4000 state. 4002 3. If the Responder is in I1-SENT state, it MUST make a comparison 4003 between the sender's HIT and its own (i.e., the receiver's) HIT. 4004 If the sender's HIT is greater than its own HIT, it should drop 4005 the I1 packet and stay at I1-SENT. If the sender's HIT is 4006 smaller than its own HIT, it SHOULD send the R1 packet and stay 4007 at I1-SENT. The HIT comparison is performed as defined in 4008 Section 6.5. 4010 4. If the implementation chooses to respond to the I1 packet with an 4011 R1 packet, it creates a new R1 or selects a precomputed R1 4012 according to the format described in Section 5.3.2. It creates 4013 or chooses an R1 that contains its most preferred DH public value 4014 that is also contained in the DH_GROUP_LIST in the I1 packet. If 4015 no suitable DH Group ID was contained in the DH_GROUP_LIST in the 4016 I1 packet, it sends an R1 with any suitable DH public key. 4018 5. If the received Responder's HIT in the I1 is NULL, the Responder 4019 selects a HIT with a the same HIT Suite as the Initiator's HIT. 4020 If this HIT Suite is not supported by the Responder, it SHOULD 4021 select a REQUIRED HIT Suite from Section 5.2.10, which is 4022 currently RSA/DSA/SHA-256. Other than that, selecting the HIT is 4023 a local policy matter. 4025 6. The responder expresses its supported HIP transport formats in 4026 the TRANSPORT_FORMAT_LIST as described in Section 5.2.10. The 4027 Responder MUST at least provide one payload transport format 4028 type. 4030 7. The Responder sends the R1 packet to the source IP address of the 4031 I1 packet. 4033 6.7.1. R1 Management 4035 All compliant implementations MUST be able to produce R1 packets. An 4036 R1 packet MAY be precomputed. An R1 packet MAY be reused for time 4037 Delta T, which is implementation dependent, and SHOULD be deprecated 4038 and not used once a valid response I2 packet has been received from 4039 an Initiator. During an I1 message storm, an R1 packet MAY be re- 4040 used beyond this limit. R1 information MUST NOT be discarded until 4041 Delta S after T. Time S is the delay needed for the last I2 packet 4042 to arrive back to the Responder. 4044 Implementations that support multiple DH groups MAY pre-compute R1 4045 packets for each supported group so that incoming I1 packets with 4046 different DH Group IDs in the DH_GROUP_LIST can be served quickly. 4048 An implementation MAY keep state about received I1 packets and match 4049 the received I2 packets against the state, as discussed in 4050 Section 4.1.1. 4052 6.7.2. Handling Malformed Messages 4054 If an implementation receives a malformed I1 packet, it SHOULD NOT 4055 respond with a NOTIFY message, as such practice could open up a 4056 potential denial-of-service threat. Instead, it MAY respond with an 4057 ICMP packet, as defined in Section 5.4. 4059 6.8. Processing Incoming R1 Packets 4061 A system receiving an R1 packet MUST first check to see if it has 4062 sent an I1 packet to the originator of the R1 packet (i.e., it is in 4063 state I1-SENT). If so, it SHOULD process the R1 as described below, 4064 send an I2 packet, and transition to state I2-SENT, setting a timer 4065 to protect the I2 packet. If the system is in state I2-SENT, it MAY 4066 respond to the R1 packet if the R1 packet has a larger R1 generation 4067 counter; if so, it should drop its state due to processing the 4068 previous R1 packet and start over from state I1-SENT. If the system 4069 is in any other state with respect to that host, the system SHOULD 4070 silently drop the R1 packet. 4072 When sending multiple I1 packets, an Initiator SHOULD wait for a 4073 small amount of time after the first R1 reception to allow possibly 4074 multiple R1 packets to arrive, and it SHOULD respond to an R1 packet 4075 among the set with the largest R1 generation counter. 4077 The following steps define the conceptual processing rules for 4078 responding to an R1 packet: 4080 1. A system receiving an R1 MUST first check to see if it has sent 4081 an I1 packet to the originator of the R1 packet (i.e., it has a 4082 HIP association that is in state I1-SENT and that is associated 4083 with the HITs in the R1). Unless the I1 packet was sent in 4084 opportunistic mode (see Section 4.1.8), the IP addresses in the 4085 received R1 packet SHOULD be ignored by the R1 processing and, 4086 when looking up the right HIP association, the received R1 4087 packet SHOULD be matched against the associations using only the 4088 HITs. If a match exists, the system should process the R1 4089 packet as described below. 4091 2. Otherwise, if the system is in any other state than I1-SENT or 4092 I2-SENT with respect to the HITs included in the R1 packet, it 4093 SHOULD silently drop the R1 packet and remain in the current 4094 state. 4096 3. If the HIP association state is I1-SENT or I2-SENT, the received 4097 Initiator's HIT MUST correspond to the HIT used in the original 4098 I1. Also, the Responder's HIT MUST correspond to the one used 4099 in the I1, unless the I1 packet contained a NULL HIT. 4101 4. The system SHOULD validate the R1 signature before applying 4102 further packet processing, according to Section 5.2.15. 4104 5. If the HIP association state is I1-SENT, and multiple valid R1 4105 packets are present, the system MUST select from among the R1 4106 packets with the largest R1 generation counter. 4108 6. The system MUST check that the Initiator HIT Suite is contained 4109 in the HIT_SUITE_LIST parameter in the R1 packet (i.e., the 4110 Initiator's HIT Suite is supported by the Responder). If the 4111 HIT Suite is supported by the Responder, the system proceeds 4112 normally. Otherwise, the system MAY stay in state I1-sent and 4113 restart the BEX by sending a new I1 packet with an Initiator HIT 4114 that is supported by the Responder and hence is contained in the 4115 HIT_SUITE_LIST in the R1 packet. The system MAY abort the BEX 4116 if no suitable source HIT is available. The system SHOULD wait 4117 for an acceptable time span to allow further R1 packets with 4118 higher R1 generation counters or different HIT and HIT Suites to 4119 arrive before restarting or aborting the BEX. 4121 7. The system MUST check that the DH Group ID in the DIFFIE_HELLMAN 4122 parameter in the R1 matches the first DH Suite ID in the 4123 Responder's DH_GROUP_LIST in the R1 packet that was also 4124 contained in the Initiator's DH_GROUP_LIST in the I1 packet. If 4125 the DH Group ID of the DIFFIE_HELLMAN parameter does not express 4126 the Responder's best choice, the Initiator can conclude that the 4127 DH_GROUP_LIST in the I1 packet was adversely modified. In such 4128 case, the Initiator MAY send a new I1 packet, however, it SHOULD 4129 NOT change its preference in the DH_GROUP_LIST in the new I1 4130 packet. Alternatively, the Initiator MAY abort the HIP base 4131 exchange. 4133 8. If the HIP association state is I2-SENT, the system MAY re-enter 4134 state I1-SENT and process the received R1 packet if it has a 4135 larger R1 generation counter than the R1 packet responded to 4136 previously. 4138 9. The R1 packet may have the A bit set -- in this case, the system 4139 MAY choose to refuse it by dropping the R1 packet and returning 4140 to state UNASSOCIATED. The system SHOULD consider dropping the 4141 R1 packet only if it used a NULL HIT in I1 packet. If the A bit 4142 is set, the Responder's HIT is anonymous and SHOULD NOT be 4143 stored permanently. 4145 10. The system SHOULD attempt to validate the HIT against the 4146 received Host Identity by using the received Host Identity to 4147 construct a HIT and verify that it matches the Sender's HIT. 4149 11. The system MUST store the received R1 generation counter for 4150 future reference. 4152 12. The system attempts to solve the puzzle in the R1 packet. The 4153 system MUST terminate the search after exceeding the remaining 4154 lifetime of the puzzle. If the puzzle is not successfully 4155 solved, the implementation MAY either resend the I1 packet 4156 within the retry bounds or abandon the HIP base exchange. 4158 13. The system computes standard Diffie-Hellman keying material 4159 according to the public value and Group ID provided in the 4160 DIFFIE_HELLMAN parameter. The Diffie-Hellman keying material 4161 Kij is used for key extraction as specified in Section 6.5. 4163 14. The system selects the HIP_CIPHER ID from the choices presented 4164 in the R1 packet and uses the selected values subsequently when 4165 generating and using encryption keys, and when sending the I2 4166 packet. If the proposed alternatives are not acceptable to the 4167 system, it may either resend an I1 within the retry bounds or 4168 abandon the HIP base exchange. 4170 15. The system chooses one suitable transport format from the 4171 TRANSPORT_FORMAT_LIST and includes the respective transport 4172 format parameter in the subsequent I2 packet. 4174 16. The system initializes the remaining variables in the associated 4175 state, including Update ID counters. 4177 17. The system prepares and sends an I2 packet, as described in 4178 Section 5.3.3. 4180 18. The system SHOULD start a timer whose timeout value SHOULD be 4181 larger than the worst-case anticipated RTT, and MUST increment a 4182 timeout counter associated with the I2 packet. The sender 4183 SHOULD retransmit the I2 packet upon a timeout and restart the 4184 timer, up to a maximum of I2_RETRIES_MAX tries. 4186 19. If the system is in state I1-SENT, it SHALL transition to state 4187 I2-SENT. If the system is in any other state, it remains in the 4188 current state. 4190 6.8.1. Handling of Malformed Messages 4192 If an implementation receives a malformed R1 message, it MUST 4193 silently drop the packet. Sending a NOTIFY or ICMP would not help, 4194 as the sender of the R1 packet typically doesn't have any state. An 4195 implementation SHOULD wait for some more time for a possibly well- 4196 formed R1, after which it MAY try again by sending a new I1 packet. 4198 6.9. Processing Incoming I2 Packets 4200 Upon receipt of an I2 packet, the system MAY perform initial checks 4201 to determine whether the I2 packet corresponds to a recent R1 packet 4202 that has been sent out, if the Responder keeps such state. For 4203 example, the sender could check whether the I2 packet is from an 4204 address or HIT for which the Responder has recently received an I1. 4205 The R1 packet may have had Opaque data included that was echoed back 4206 in the I2 packet. If the I2 packet is considered to be suspect, it 4207 MAY be silently discarded by the system. 4209 Otherwise, the HIP implementation SHOULD process the I2 packet. This 4210 includes validation of the puzzle solution, generating the Diffie- 4211 Hellman key, possibly decrypting the Initiator's Host Identity, 4212 verifying the signature, creating state, and finally sending an R2 4213 packet. 4215 The following steps define the conceptual processing rules for 4216 responding to an I2 packet: 4218 1. The system MAY perform checks to verify that the I2 packet 4219 corresponds to a recently sent R1 packet. Such checks are 4220 implementation dependent. See Appendix A for a description of 4221 an example implementation. 4223 2. The system MUST check that the Responder's HIT corresponds to 4224 one of its own HITs and MUST drop the packet otherwise. 4226 3. The system MUST further check that the Initiator's HIT Suite is 4227 supported. The Responder SHOULD silently drop I2 packets with 4228 unsupported Initiator HITs. 4230 4. If the system's state machine is in the R2-SENT state, the 4231 system MAY check if the newly received I2 packet is similar to 4232 the one that triggered moving to R2-SENT. If so, it MAY 4233 retransmit a previously sent R2 packet, reset the R2-SENT timer, 4234 and the state machine stays in R2-SENT. 4236 5. If the system's state machine is in the I2-SENT state, the 4237 system makes a comparison between its local and sender's HITs 4238 (similarly as in Section 6.5). If the local HIT is smaller than 4239 the sender's HIT, it should drop the I2 packet, use the peer 4240 Diffie-Hellman key and nonce #I from the R1 packet received 4241 earlier, and get the local Diffie-Hellman key and nonce #J from 4242 the I2 packet sent to the peer earlier. Otherwise, the system 4243 should process the received I2 packet and drop any previously 4244 derived Diffie-Hellman keying material Kij it might have formed 4245 upon sending the I2 packet previously. The peer Diffie-Hellman 4246 key and the nonce #J are taken from the just arrived I2 packet. 4247 The local Diffie-Hellman key and the nonce I are the ones that 4248 were sent earlier in the R1 packet. 4250 6. If the system's state machine is in the I1-SENT state, and the 4251 HITs in the I2 packet match those used in the previously sent I1 4252 packet, the system uses this received I2 packet as the basis for 4253 the HIP association it was trying to form, and stops 4254 retransmitting I1 packets (provided that the I2 packet passes 4255 the additional checks below). 4257 7. If the system's state machine is in any other state than R2- 4258 SENT, the system SHOULD check that the echoed R1 generation 4259 counter in the I2 packet is within the acceptable range if the 4260 counter is included. Implementations MUST accept puzzles from 4261 the current generation and MAY accept puzzles from earlier 4262 generations. If the generation counter in the newly received I2 4263 packet is outside the accepted range, the I2 packet is stale 4264 (and perhaps replayed) and SHOULD be dropped. 4266 8. The system MUST validate the solution to the puzzle by computing 4267 the hash described in Section 5.3.3 using the same RHASH 4268 algorithm. 4270 9. The I2 packet MUST have a single value in the HIP_CIPHER 4271 parameter, which MUST match one of the values offered to the 4272 Initiator in the R1 packet. 4274 10. The system must derive Diffie-Hellman keying material Kij based 4275 on the public value and Group ID in the DIFFIE_HELLMAN 4276 parameter. This key is used to derive the HIP association keys, 4277 as described in Section 6.5. If the Diffie-Hellman Group ID is 4278 unsupported, the I2 packet is silently dropped. 4280 11. The encrypted HOST_ID is decrypted by the Initiator's encryption 4281 key defined in Section 6.5. If the decrypted data is not a 4282 HOST_ID parameter, the I2 packet is silently dropped. 4284 12. The implementation SHOULD also verify that the Initiator's HIT 4285 in the I2 packet corresponds to the Host Identity sent in the I2 4286 packet. (Note: some middleboxes may not able to make this 4287 verification.) 4289 13. The system MUST verify the HIP_MAC according to the procedures 4290 in Section 5.2.12. 4292 14. The system MUST verify the HIP_SIGNATURE according to 4293 Section 5.2.14 and Section 5.3.3. 4295 15. If the checks above are valid, then the system proceeds with 4296 further I2 processing; otherwise, it discards the I2 and its 4297 state machine remains in the same state. 4299 16. The I2 packet may have the A bit set -- in this case, the system 4300 MAY choose to refuse it by dropping the I2 and the state machine 4301 returns to state UNASSOCIATED. If the A bit is set, the 4302 Initiator's HIT is anonymous and should not be stored 4303 permanently. 4305 17. The system initializes the remaining variables in the associated 4306 state, including Update ID counters. 4308 18. Upon successful processing of an I2 message when the system's 4309 state machine is in state UNASSOCIATED, I1-SENT, I2-SENT, or R2- 4310 SENT, an R2 packet is sent and the system's state machine 4311 transitions to state R2-SENT. 4313 19. Upon successful processing of an I2 packet when the system's 4314 state machine is in state ESTABLISHED, the old HIP association 4315 is dropped and a new one is installed, an R2 packet is sent, and 4316 the system's state machine transitions to R2-SENT. 4318 20. Upon the system's state machine transitioning to R2-SENT, the 4319 system starts a timer. The state machine transitions to 4320 ESTABLISHED if some data has been received on the incoming HIP 4321 association, or an UPDATE packet has been received (or some 4322 other packet that indicates that the peer system's state machine 4323 has moved to ESTABLISHED). If the timer expires (allowing for 4324 maximal amount of retransmissions of I2 packets), the state 4325 machine transitions to ESTABLISHED. 4327 6.9.1. Handling of Malformed Messages 4329 If an implementation receives a malformed I2 message, the behavior 4330 SHOULD depend on how many checks the message has already passed. If 4331 the puzzle solution in the message has already been checked, the 4332 implementation SHOULD report the error by responding with a NOTIFY 4333 packet. Otherwise, the implementation MAY respond with an ICMP 4334 message as defined in Section 5.4. 4336 6.10. Processing of Incoming R2 Packets 4338 An R2 packet received in states UNASSOCIATED, I1-SENT, or ESTABLISHED 4339 results in the R2 packet being dropped and the state machine staying 4340 in the same state. If an R2 packet is received in state I2-SENT, it 4341 MUST be processed. 4343 The following steps define the conceptual processing rules for an 4344 incoming R2 packet: 4346 1. If the system is in any other state than I2-SENT, the R2 packet 4347 is silently dropped. 4349 2. The system MUST verify that the HITs in use correspond to the 4350 HITs that were received in the R1 packet that caused the 4351 transition to the I1-SENT state. 4353 3. The system MUST verify the HIP_MAC_2 according to the procedures 4354 in Section 5.2.13. 4356 4. The system MUST verify the HIP signature according to the 4357 procedures in Section 5.2.14. 4359 5. If any of the checks above fail, there is a high probability of 4360 an ongoing man-in-the-middle or other security attack. The 4361 system SHOULD act accordingly, based on its local policy. 4363 6. Upon successful processing of the R2 packet, the state machine 4364 transitions to state ESTABLISHED. 4366 6.11. Sending UPDATE Packets 4368 A host sends an UPDATE packet when it intends to update some 4369 information related to a HIP association. There are a number of 4370 possible scenarios when this can occur, e.g., mobility management and 4371 rekeying of an existing ESP Security Association. The following 4372 paragraphs define the conceptual rules for sending an UPDATE packet 4373 to the peer. Additional steps can be defined in other documents 4374 where the UPDATE packet is used. 4376 The sequence of UPDATE messages is indicated by their SEQ parameter. 4377 Before sending an UPDATE message, the system first determines whether 4378 there are any outstanding UPDATE messages that may conflict with the 4379 new UPDATE message under consideration. When multiple UPDATEs are 4380 outstanding (not yet acknowledged), the sender must assume that such 4381 UPDATEs may be processed in an arbitrary order by the receiver. 4382 Therefore, any new UPDATEs that depend on a previous outstanding 4383 UPDATE being successfully received and acknowledged MUST be postponed 4384 until reception of the necessary ACK(s) occurs. One way to prevent 4385 any conflicts is to only allow one outstanding UPDATE at a time. 4386 However, allowing multiple UPDATEs may improve the performance of 4387 mobility and multihoming protocols. 4389 The following steps define the conceptual processing rules for 4390 sending UPDATE packets. 4392 1. The first UPDATE packet is sent with Update ID of zero. 4393 Otherwise, the system increments its own Update ID value by one 4394 before continuing the steps below. 4396 2. The system creates an UPDATE packet that contains a SEQ parameter 4397 with the current value of Update ID. The UPDATE packet MAY also 4398 include zero or more ACKs of the peer's Update ID(s) from 4399 previously received UPDATE SEQ parameter(s) 4401 3. The system sends the created UPDATE packet and starts an UPDATE 4402 timer. The default value for the timer is 2 * RTT estimate. If 4403 multiple UPDATEs are outstanding, multiple timers are in effect. 4405 4. If the UPDATE timer expires, the UPDATE is resent. The UPDATE 4406 can be resent UPDATE_RETRY_MAX times. The UPDATE timer SHOULD be 4407 exponentially backed off for subsequent retransmissions. If no 4408 acknowledgment is received from the peer after UPDATE_RETRY_MAX 4409 times, the HIP association is considered to be broken and the 4410 state machine SHOULD move from state ESTABLISHED to state CLOSING 4411 as depicted in Section 4.4.4. The UPDATE timer is cancelled upon 4412 receiving an ACK from the peer that acknowledges receipt of the 4413 UPDATE. 4415 6.12. Receiving UPDATE Packets 4417 When a system receives an UPDATE packet, its processing depends on 4418 the state of the HIP association and the presence and values of the 4419 SEQ and ACK parameters. Typically, an UPDATE message also carries 4420 optional parameters whose handling is defined in separate documents. 4422 For each association, a host stores the peer's next expected in- 4423 sequence Update ID ("peer Update ID"). Initially, this value is 4424 zero. Update ID comparisons of "less than" and "greater than" are 4425 performed with respect to a circular sequence number space. Hence, a 4426 wrap around after 2^32 updates has to be expected and MUST be handled 4427 accordingly. 4429 The sender MAY send multiple outstanding UPDATE messages. These 4430 messages are processed in the order in which they are received at the 4431 receiver (i.e., no re-sequencing is performed). When processing 4432 UPDATEs out-of-order, the receiver MUST keep track of which UPDATEs 4433 were previously processed, so that duplicates or retransmissions are 4434 ACKed and not reprocessed. A receiver MAY choose to define a receive 4435 window of Update IDs that it is willing to process at any given time, 4436 and discard received UPDATEs falling outside of that window. 4438 The following steps define the conceptual processing rules for 4439 receiving UPDATE packets. 4441 1. If there is no corresponding HIP association, the implementation 4442 MAY reply with an ICMP Parameter Problem, as specified in 4443 Section 5.4.4. 4445 2. If the association is in the ESTABLISHED state and the SEQ (but 4446 not ACK) parameter is present, the UPDATE is processed and 4447 replied to as described in Section 6.12.1. 4449 3. If the association is in the ESTABLISHED state and the ACK (but 4450 not SEQ) parameter is present, the UPDATE is processed as 4451 described in Section 6.12.2. 4453 4. If the association is in the ESTABLISHED state and there is both 4454 an ACK and SEQ in the UPDATE, the ACK is first processed as 4455 described in Section 6.12.2, and then the rest of the UPDATE is 4456 processed as described in Section 6.12.1. 4458 6.12.1. Handling a SEQ Parameter in a Received UPDATE Message 4460 The following steps define the conceptual processing rules for 4461 handling a SEQ parameter in a received UPDATE packet. 4463 1. If the Update ID in the received SEQ is not the next in the 4464 sequence of Update IDs and is greater than the receiver's window 4465 for new UPDATEs, the packet MUST be dropped. 4467 2. If the Update ID in the received SEQ corresponds to an UPDATE 4468 that has recently been processed, the packet is treated as a 4469 retransmission. The HIP_MAC verification (next step) MUST NOT be 4470 skipped. (A byte-by-byte comparison of the received and a stored 4471 packet would be acceptable, though.) It is recommended that a 4472 host caches UPDATE packets sent with ACKs to avoid the cost of 4473 generating a new ACK packet to respond to a replayed UPDATE. The 4474 system MUST acknowledge, again, such (apparent) UPDATE message 4475 retransmissions but SHOULD also consider rate-limiting such 4476 retransmission responses to guard against replay attacks. 4478 3. The system MUST verify the HIP_MAC in the UPDATE packet. If the 4479 verification fails, the packet MUST be dropped. 4481 4. The system MAY verify the SIGNATURE in the UPDATE packet. If the 4482 verification fails, the packet SHOULD be dropped and an error 4483 message logged. 4485 5. If a new SEQ parameter is being processed, the parameters in the 4486 UPDATE are then processed. The system MUST record the Update ID 4487 in the received SEQ parameter, for replay protection. 4489 6. An UPDATE acknowledgment packet with ACK parameter is prepared 4490 and sent to the peer. This ACK parameter MAY be included in a 4491 separate UPDATE or piggybacked in an UPDATE with SEQ parameter, 4492 as described in Section 5.3.5. The ACK parameter MAY acknowledge 4493 more than one of the peer's Update IDs. 4495 6.12.2. Handling an ACK Parameter in a Received UPDATE Packet 4497 The following steps define the conceptual processing rules for 4498 handling an ACK parameter in a received UPDATE packet. 4500 1. The sequence number reported in the ACK must match with an UPDATE 4501 packet sent earlier that has not already been acknowledged. If 4502 no match is found or if the ACK does not acknowledge a new 4503 UPDATE, the packet MUST either be dropped if no SEQ parameter is 4504 present, or the processing steps in Section 6.12.1 are followed. 4506 2. The system MUST verify the HIP_MAC in the UPDATE packet. If the 4507 verification fails, the packet MUST be dropped. 4509 3. The system MAY verify the SIGNATURE in the UPDATE packet. If the 4510 verification fails, the packet SHOULD be dropped and an error 4511 message logged. 4513 4. The corresponding UPDATE timer is stopped (see Section 6.11) so 4514 that the now acknowledged UPDATE is no longer retransmitted. If 4515 multiple UPDATEs are acknowledged, multiple timers are stopped. 4517 6.13. Processing of NOTIFY Packets 4519 Processing of NOTIFY packets is OPTIONAL. If processed, any errors 4520 in a received NOTIFICATION parameter SHOULD be logged. Received 4521 errors MUST be considered only as informational, and the receiver 4522 SHOULD NOT change its HIP state (see Section 4.4.2) purely based on 4523 the received NOTIFY message. 4525 6.14. Processing CLOSE Packets 4527 When the host receives a CLOSE message, it responds with a CLOSE_ACK 4528 message and moves to CLOSED state. (The authenticity of the CLOSE 4529 message is verified using both HIP_MAC and SIGNATURE). This 4530 processing applies whether or not the HIP association state is 4531 CLOSING in order to handle simultaneous CLOSE messages from both ends 4532 that cross in flight. 4534 The HIP association is not discarded before the host moves to the 4535 UNASSOCIATED state. 4537 Once the closing process has started, any new need to send data 4538 packets triggers creating and establishing of a new HIP association, 4539 starting with sending of an I1 packet. 4541 If there is no corresponding HIP association, the CLOSE packet is 4542 dropped. 4544 6.15. Processing CLOSE_ACK Packets 4546 When a host receives a CLOSE_ACK message, it verifies that it is in 4547 CLOSING or CLOSED state and that the CLOSE_ACK was in response to the 4548 CLOSE. A host can map CLOSE_ACK messages to CLOSE messages by 4549 comparing the value of ECHO_REQUEST_SIGNED (in the CLOSE packet) to 4550 the value of ECHO_RESPONSE_SIGNED (in the CLOSE_ACK packet). 4552 The CLOSE_ACK contains the HIP_MAC and the SIGNATURE parameters for 4553 verification. The state is discarded when the state changes to 4554 UNASSOCIATED and, after that, the host MAY respond with an ICMP 4555 Parameter Problem to an incoming CLOSE message (see Section 5.4.4). 4557 6.16. Handling State Loss 4559 In the case of a system crash and unanticipated state loss, the 4560 system SHOULD delete the corresponding HIP state, including the 4561 keying material. That is, the state SHOULD NOT be stored in long- 4562 term storage. If the implementation does drop the state (as 4563 RECOMMENDED), it MUST also drop the peer's R1 generation counter 4564 value, unless a local policy explicitly defines that the value of 4565 that particular host is stored. An implementation MUST NOT store a 4566 peer's R1 generation counters by default, but storing R1 generation 4567 counter values, if done, MUST be configured by explicit HITs. 4569 7. HIP Policies 4571 There are a number of variables that will influence the HIP base 4572 exchanges that each host must support. All HIP implementations MUST 4573 support more than one simultaneous HI, at least one of which SHOULD 4574 be reserved for anonymous usage. Although anonymous HIs will be 4575 rarely used as Responders' HIs, they will be common for Initiators. 4576 Support for more than two HIs is RECOMMENDED. 4578 Initiators MAY use a different HI for different Responders to provide 4579 basic privacy. Whether such private HIs are used repeatedly with the 4580 same Responder and how long these HIs are used is decided by local 4581 policy and depends on the privacy requirements of the Initiator. 4583 The value of #K used in the HIP R1 must be chosen with care. Too 4584 high numbers of #K will exclude clients with weak CPUs because these 4585 devices cannot solve the puzzle within reasonable time. #K should 4586 only be raised if a Responder is under high load, i.e., it cannot 4587 process all incoming HIP handshakes any more. If a responder is not 4588 under high load, K SHOULD be 0. 4590 Responders that only respond to selected Initiators require an ACL, 4591 representing for which hosts they accept HIP base exchanges, and the 4592 preferred transform and local lifetimes. Wildcarding SHOULD be 4593 supported for such ACLs, and also for Responders that offer public or 4594 anonymous services. 4596 8. Security Considerations 4598 HIP is designed to provide secure authentication of hosts. HIP also 4599 attempts to limit the exposure of the host to various denial-of- 4600 service and man-in-the-middle (MitM) attacks. In doing so, HIP 4601 itself is subject to its own DoS and MitM attacks that potentially 4602 could be more damaging to a host's ability to conduct business as 4603 usual. 4605 Denial-of-service attacks often take advantage of asymmetries in the 4606 cost of an starting an association. One example of such asymmetry is 4607 the need of a Responder to store local state while a malicious 4608 Initiator can stay stateless. HIP makes no attempt to increase the 4609 cost of the start of state at the Initiator, but makes an effort to 4610 reduce the cost for the Responder. This is accomplished by having 4611 the Responder start the 3-way exchange instead of the Initiator, 4612 making the HIP protocol 4 packets long. In doing this, the first 4613 packet from the Responder, R1, becomes a 'stock' packet that the 4614 Responder MAY use many times, until some Initiator has provided a 4615 valid response to such an R1 packet. During an I1 packet storm, the 4616 host may reuse the same DH value also even if some Initiator has 4617 provided a valid response using that particular DH value. However, 4618 such behavior is discouraged and should be avoided. Using the same 4619 Diffie-Hellman values and random puzzle #I value has some risks. 4620 This risk needs to be balanced against a potential storm of HIP I1 4621 packets. 4623 This shifting of the start of state cost to the Initiator in creating 4624 the I2 HIP packet presents another DoS attack. The attacker can 4625 spoof the I1 packet and the Responder sends out the R1 HIP packet. 4626 This could conceivably tie up the 'Initiator' with evaluating the R1 4627 HIP packet, and creating the I2 packet. The defense against this 4628 attack is to simply ignore any R1 packet where a corresponding I1 4629 packet was not sent (as defined in Section 6.8 step 1). 4631 The R1 packet is considerably larger than the I1 packet. This 4632 asymmetry can be exploited in an reflection attack. A malicious 4633 attacker could spoof the IP address of a victim and send a flood of 4634 I1 messages to a powerful Responder. For each small I1 packet, the 4635 Responder would send a larger R1 packet to the victim. The 4636 difference in packet sizes can further amplify a flooding attack 4637 against the victim. To avoid such reflection attacks, the Responder 4638 SHOULD rate limit the sending of R1 packets in general or SHOULD rate 4639 limit the sending of R1 packets to a specific IP address. 4641 Floods of forged I2 packets form a second kind of DoS attack. Once 4642 the attacking Initiator has solved the puzzle, it can send packets 4643 with spoofed IP source addresses with either an invalid HIP signature 4644 or invalid encrypted HIP payload (in the ENCRYPTED parameter). This 4645 would take resources in the Responder's part to reach the point to 4646 discover that the I2 packet cannot be completely processed. The 4647 defense against this attack is after N bad I2 packets with the same 4648 puzzle solution, the Responder would discard any I2 packets that 4649 contain the given solution. This will shut down the attack. The 4650 attacker would have to request another R1 packet and use that to 4651 launch a new attack. The Responder could increase the value of #K 4652 while under attack. Keeping a list of solutions from malformed 4653 packets requires that the Responder keeps state for these malformed 4654 I2 packets. This state has to be kept until the R1 counter is 4655 increased. As malformed packets are generally filtered by their 4656 checksum before signature verification, only solutions in packets 4657 that are forged to pass the checksum and puzzle are put to the 4658 blacklist. In addition, a valid puzzle is required before a new list 4659 entry is created. Hence, attackers that intend to flood the 4660 blacklist must solve puzzles first. 4662 A third form of DoS attack is emulating the restart of state after a 4663 reboot of one of the peers. A restarting host would send an I1 4664 packet to the peers, which would respond with an R1 packet even if it 4665 were in the ESTABLISHED state. If the I1 packet were spoofed, the 4666 resulting R1 packet would be received unexpectedly by the spoofed 4667 host and would be dropped, as in the first case above. 4669 A fourth form of DoS attack is emulating closing of the HIP 4670 association. HIP relies on timers and a CLOSE/CLOSE_ACK handshake to 4671 explicitly signal the end of a HIP association. Because both CLOSE 4672 and CLOSE_ACK messages contain a HIP_MAC, an outsider cannot close a 4673 connection. The presence of an additional SIGNATURE allows 4674 middleboxes to inspect these messages and discard the associated 4675 state (for e.g., firewalling, SPI-based NATing, etc.). However, the 4676 optional behavior of replying to CLOSE with an ICMP Parameter Problem 4677 packet (as described in Section 5.4.4) might allow an attacker 4678 spoofing the source IP address to send CLOSE messages to launch 4679 reflection attacks. 4681 A fifth form of DoS attack is replaying R1s to cause the Initiator to 4682 solve stale puzzles and become out of synchronization with the 4683 Responder. The R1 generation counter is a monotonically increasing 4684 counter designed to protect against this attack, as described in 4685 Section 4.1.4. 4687 Man-in-the-middle attacks are difficult to defend against, without 4688 third-party authentication. A skillful MitM could easily handle all 4689 parts of HIP, but HIP indirectly provides the following protection 4690 from a MitM attack. If the Responder's HI is retrieved from a signed 4691 DNS zone, a certificate, or through some other secure means, the 4692 Initiator can use this to validate the R1 HIP packet. 4694 Likewise, if the Initiator's HI is in a secure DNS zone, a trusted 4695 certificate, or otherwise securely available, the Responder can 4696 retrieve the HI (after having got the I2 HIP packet) and verify that 4697 the HI indeed can be trusted. 4699 The HIP Opportunistic Mode concept has been introduced in this 4700 document, but this document does not specify what the semantics of 4701 such a connection setup are for applications. There are certain 4702 concerns with opportunistic mode, as discussed in Section 4.1.8. 4704 NOTIFY messages are used only for informational purposes and they are 4705 unacknowledged. A HIP implementation cannot rely solely on the 4706 information received in a NOTIFY message because the packet may have 4707 been replayed. An implementation SHOULD NOT change any state 4708 information purely based on a received NOTIFY message. 4710 Since not all hosts will ever support HIP, ICMP 'Destination Protocol 4711 Unreachable' messages are to be expected and may be used for a DoS 4712 attack. Against an Initiator, the attack would look like the 4713 Responder does not support HIP, but shortly after receiving the ICMP 4714 message, the Initiator would receive a valid R1 HIP packet. Thus, to 4715 protect from this attack, an Initiator SHOULD NOT react to an ICMP 4716 message until a reasonable delta time to get the real Responder's R1 4717 HIP packet. A similar attack against the Responder is more involved. 4718 Normally, if an I1 message received by a Responder was a bogus one 4719 sent by an attacker, the Responder may receive an ICMP message from 4720 the IP address the R1 message was sent to. However, a sophisticated 4721 attacker can try to take advantage of such a behavior and try to 4722 break up the HIP base exchange by sending such an ICMP message to the 4723 Responder before the Initiator has a chance to send a valid I2 4724 message. Hence, the Responder SHOULD NOT act on such an ICMP 4725 message. Especially, it SHOULD NOT remove any minimal state created 4726 when it sent the R1 HIP packet (if it did create one), but wait for 4727 either a valid I2 HIP packet or the natural timeout (that is, if R1 4728 packets are tracked at all). Likewise, the Initiator SHOULD ignore 4729 any ICMP message while waiting for an R2 HIP packet, and SHOULD 4730 delete any pending state only after a natural timeout. 4732 9. IANA Considerations 4734 IANA has reserved protocol number 139 for the Host Identity Protocol. 4736 This document defines a new 128-bit value under the CGA Message Type 4737 namespace [RFC3972], 0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA, to be 4738 used for HIT generation as specified in ORCHID 4739 [I-D.ietf-hip-rfc4843-bis]. 4741 This document uses HIP version number 2 for the four-bit Version 4742 field in a HIP protocol packet defined in [RFC5201]. 4744 This document also creates a set of new namespaces. These are 4745 described below. 4747 Packet Type 4749 The 7-bit Packet Type field in a HIP protocol packet describes the 4750 type of a HIP protocol message. It is defined in Section 5.1. 4751 The current values are defined in Sections 5.3.1 through 5.3.8. 4753 New values are assigned through IETF Review or IESG Approval 4754 [RFC5226]. 4756 HIT Suite 4758 The four-bit HIT Suite ID uses the OGA field in the ORCHID to 4759 express the type of the HIT. This document defines two HIT Suites 4760 (see Appendix E). 4762 The HIT Suite ID is also carried in the four higher-order bits of 4763 the ID field in the HIT_SUITE_LIST parameter. The four lower- 4764 order bits are reserved for future extensions of the HIT Suite ID 4765 space beyond 16 values. 4767 At the time being, the HIT Suite uses only four bits because these 4768 bits have to be carried in the HIT. Using more bits for the HIT 4769 Suite ID reduces the cryptographic strength of the HIT. HIT Suite 4770 IDs must be allocated carefully to avoid namespace exhaustion. 4771 Moreover, deprecated IDs should be reused after an appropriate 4772 time span. If 16 Suite IDs prove insufficient and more HIT Suite 4773 IDs are needed concurrently, more bits can be used for the HIT 4774 Suite ID by using one HIT Suite ID (0) to indicate that more bits 4775 should be used. The HIT_SUITE_LIST parameter already supports 4776 8-bit HIT Suite IDs, should longer IDs be needed. Possible 4777 extensions of the HIT Suite ID space to accommodate eight bits and 4778 new HIT Suite IDs are defined through IETF Review or IESG 4779 Approval. 4781 Parameter Type 4783 The 16-bit Type field in a HIP parameter describes the type of the 4784 parameter. It is defined in Section 5.2.1. The current values 4785 are defined in Sections 5.2.3 through 5.2.23. 4787 With the exception of the assigned Type codes, the Type codes 0 4788 through 1023 and 61440 through 65535 are reserved for future base 4789 protocol extensions, and are assigned through IETF Review or IESG 4790 Approval. 4792 The Type codes 32768 through 49151 are reserved for 4793 experimentation. Types SHOULD be selected in a random fashion 4794 from this range, thereby reducing the probability of collisions. 4795 A method employing genuine randomness (such as flipping a coin) 4796 SHOULD be used. 4798 All other Type codes are assigned through First Come First Served, 4799 with Specification Required [RFC5226]. 4801 Group ID 4803 The eight-bit Group ID values appear in the DIFFIE_HELLMAN 4804 parameter and the DH_GROUP_LIST parameter and are defined in 4805 Section 5.2.7. New values are assigned through IETF Review or 4806 IESG Approval. 4808 HIP Cipher ID 4810 The 16-bit Cipher ID values in a HIP_CIPHER parameter are defined 4811 in Section 5.2.8. New values either from the reserved or 4812 unassigned space are assigned through IETF Review or IESG 4813 Approval. 4815 DI-Type 4817 The four-bit DI-Type values in a HOST_ID parameter are defined in 4818 Section 5.2.9. New values are assigned through IETF Review or 4819 IESG Approval. 4821 Notify Message Type 4823 The 16-bit Notify Message Type values in a NOTIFICATION parameter 4824 are defined in Section 5.2.19. 4826 Notify Message Type values 1-10 are used for informing about 4827 errors in packet structures, values 11-20 for informing about 4828 problems in parameters containing cryptographic related material, 4829 values 21-30 for informing about problems in authentication or 4830 packet integrity verification. Parameter numbers above 30 can be 4831 used for informing about other types of errors or events. Values 4832 51-8191 are error types reserved to be allocated by IANA. Values 4833 8192-16383 are error types for experimentation. Values 16385- 4834 40959 are status types to be allocated by IANA, and values 40960- 4835 65535 are status types for experimentation. New values in ranges 4836 51-8191 and 16385-40959 are assigned through First Come First 4837 Served, with Specification Required. 4839 10. Acknowledgments 4841 The drive to create HIP came to being after attending the MALLOC 4842 meeting at the 43rd IETF meeting. Baiju Patel and Hilarie Orman 4843 really gave the original author, Bob Moskowitz, the assist to get HIP 4844 beyond 5 paragraphs of ideas. It has matured considerably since the 4845 early versions thanks to extensive input from IETFers. Most 4846 importantly, its design goals are articulated and are different from 4847 other efforts in this direction. Particular mention goes to the 4848 members of the NameSpace Research Group of the IRTF. Noel Chiappa 4849 provided valuable input at early stages of discussions about 4850 identifier handling and Keith Moore the impetus to provide 4851 resolvability. Steve Deering provided encouragement to keep working, 4852 as a solid proposal can act as a proof of ideas for a research group. 4854 Many others contributed; extensive security tips were provided by 4855 Steve Bellovin. Rob Austein kept the DNS parts on track. Paul 4856 Kocher taught Bob Moskowitz how to make the puzzle exchange expensive 4857 for the Initiator to respond, but easy for the Responder to validate. 4858 Bill Sommerfeld supplied the Birthday concept, which later evolved 4859 into the R1 generation counter, to simplify reboot management. Erik 4860 Nordmark supplied the CLOSE-mechanism for closing connections. 4861 Rodney Thayer and Hugh Daniels provided extensive feedback. In the 4862 early times of this document, John Gilmore kept Bob Moskowitz 4863 challenged to provide something of value. 4865 During the later stages of this document, when the editing baton was 4866 transferred to Pekka Nikander, the input from the early implementors 4867 was invaluable. Without having actual implementations, this document 4868 would not be on the level it is now. 4870 In the usual IETF fashion, a large number of people have contributed 4871 to the actual text or ideas. The list of these people include Jeff 4872 Ahrenholz, Francis Dupont, Derek Fawcus, George Gross, Andrew 4873 McGregor, Julien Laganier, Miika Komu, Mika Kousa, Jan Melen, Henrik 4874 Petander, Michael Richardson, Rene Hummen, Tim Shepard, Jorma Wall, 4875 Xin Gu, and Jukka Ylitalo. Our apologies to anyone whose name is 4876 missing. 4878 Once the HIP Working Group was founded in early 2004, a number of 4879 changes were introduced through the working group process. Most 4880 notably, the original document was split in two, one containing the 4881 base exchange and the other one defining how to use ESP. Some 4882 modifications to the protocol proposed by Aura, et al., [AUR03] were 4883 added at a later stage. 4885 11. Changes from RFC 5201 4887 This section summarizes the changes made from [RFC5201]. 4889 11.1. Changes from draft-ietf-hip-rfc5201-bis-09 4891 o Editorial changes based on working group last call. 4893 11.2. Changes from draft-ietf-hip-rfc5201-bis-08 4895 o Issue 29: Use different RSA mode OEAP/PSS, elevate ECDSA to 4896 REQUIRED status 4898 o Issue 35: limiting ECC cofactor to 1 4900 o Changed text regarding issue 33 reusing DH values 4902 o Fix tracker issue 32 on Domain Identifier normative text 4904 11.3. Changes from draft-ietf-hip-rfc5201-bis-07 4906 o Removed lingering references to SHA-1 as the mandatory hash 4907 algorithm (which was changed to SHA-256 in the -02 draft version). 4909 o For parameter type number changes, changed "IETF Review" to "IETF 4910 Review or IESG Approval". 4912 o Updated Appendix C checksum examples to conform to HIPv2 packets. 4914 11.4. Changes from draft-ietf-hip-rfc5201-bis-06 4916 o Made echoing the R1_COUNTER in the I2 mandatory if the R1 contains 4917 an R1_COUNTER. This required to make the R1 counter a critical 4918 parameter. Hence, the parameter type number of the R1_COUNTER 4919 changed from 128 to 129. 4921 o Made KDF dependent on DH Group to enable negotiation of the KDF. 4923 11.5. Changes from draft-ietf-hip-rfc5201-bis-05 4925 o Changed type number of DH_GROUP_LIST from 2151 to 511 because it 4926 was in the number space that is reserved for the HIP transport 4927 mode negotiations. 4929 o Added transport form type list parameter. Transport forms are now 4930 negotiated with this list instead of by their order in the HIP 4931 packet. This allows to remove the exception of the transport 4932 format parameters that were ordered by their preference instead of 4933 by their type number. This should remove complexity from 4934 implementations. 4936 o Clarify that in HIP signature processing, the restored checksum 4937 and length fields have been rendered invalid by the previous 4938 steps. 4940 o Clarify behavior for when UPDATE does not contain SEQ or ACQ 4941 (disallow this). 4943 o For namespace changes, changed "IETF Review" to "IETF Review or 4944 IESG Approval". 4946 o Addressed IESG comment about ignoring packet IP addresses. 4948 o Permit using Anonymous HI control in packets other than R1/I2. 4950 o Fixed minor reference error (RFC2418, RFC2410). 4952 o Deleted comment that NULL-ENCRYPTION SHOULD NOT be configurable 4953 via the UI. 4955 o Editorial changes. 4957 11.6. Changes from draft-ietf-hip-rfc5201-bis-04 4959 o Clarifications of the Security Considerations section. One DoS 4960 defense mechanism was changed to be more effective and less prone 4961 to misuse. 4963 o Minor clarifications of the state machine. 4965 o Clarified text on HIP puzzle. 4967 o Added names and references for figures. 4969 o Extended the definitions section. 4971 o Added a reference to the HIP Version 1 certificate document. 4973 o Added Initiator, Responder, HIP association, and signed data to 4974 the definitions section. 4976 o Changed parameter figure for PUZZLE and SOLUTION to use 4977 RHASH_len/8 instead of n-byte. 4979 o Replaced occurrences of SHOULD not with SHOULD NOT. 4981 o Changed text to reflect the fact that several 4982 ECHO_REQUEST_UNSIGNED parameters may be present in an R1 and 4983 several ECHO_RESPONSE parameters may be present in an I2. 4985 o Added text on verifying the ECHO_RESPONSE_SIGNED parameter in 4986 CLOSE_ACK. 4988 o Changed wording from HMAC to HIP_MAC in Section 5.3.8. 4990 o Reflected fact that the UPDATE packet MAY include zero or more 4991 ACKs. 4993 o Added BEX to Definitions section. 4995 o Changed HIP_SIGNATURE algorithm field from 8 bit to 16 bit to 4996 achieve alignment with the HOST_ID parameters. 4998 o Fixed the wrong figures of the SEQ and ACK parameters. SEQ always 4999 contains ONE update ID. ACK may acknowledge SEVERAL update IDs. 5001 o Added wording that several NOTIFY parameters may be present in a 5002 HIP packet. 5004 o Changed wording for the ECHO_RESPONSE_SIGNED parameter. Also 5005 lifted the restriction that only one ECHO_RESPONSE_UNSIGNED 5006 parameter MUST be present in each HIP control packet. This did 5007 contradict the definition of the ECHO_RESPONSE_UNSIGNED parameter. 5009 o Changed IETF Consensus to IETF Review or IESG Approval in IANA 5010 section. 5012 o Aligned use of I, J, and K. Now I is #I, J is #J and K is #K 5013 throughout the document. 5015 o Updated references. 5017 o Editorial changes. 5019 11.7. Changes from draft-ietf-hip-rfc5201-bis-03 5021 o Editorial changes to improve clarity and readability. 5023 o Removed obsoleted (not applicable) attack from security 5024 consideration section. 5026 o Added a requirement that hosts MUST support processing of ACK 5027 parameters with several SEQ numbers even when they do not support 5028 sending such parameters. 5030 o Removed note on memory bound puzzles. The use of memory bound 5031 puzzles was reconsidered but no convincing arguments for inclusion 5032 in this document have been made on the list. 5034 o Changed references to reference the new bis documents. 5036 o Specified the ECC curves and the hashes used for these. 5038 o Specified representation of ECC curves in the HI. 5040 o Added text on the dependency between RHASH and HMAC. 5042 o Rephrased part of the security considerations to make them 5043 clearer. 5045 o Clarified the use of HITs in opportunistic mode. 5047 o Clarified the difference between HIP_MAC and HIP_MAC_2 as well as 5048 between SIGNATURE and SIGNATURE_2. 5050 o Changed NOTIFY name for value 44 from SERVER_BUSY_PLEASE_RETRY to 5051 RESPONDER_BUSY_PLEASE_RETRY. 5053 o Mentioned that there are multiple valid puzzle solutions. 5055 11.8. Changes from draft-ietf-hip-rfc5201-bis-02 5057 o Added recommendation to not use puzzle #I twice for the same host 5058 to avoid identical key material. 5060 o Revised state machine and added missing event handling. 5062 o Added UNSUPPORTED_HIT_SUITE to NOTIFY to indicate unsupported HIT 5063 suites. 5065 o Revised parameter type numbers (corresponding to IANA allocations) 5066 and added missing "free for experimentation" range to the 5067 description. 5069 o Clarifying note on the use of the C bit in the parameter type 5070 numbers. 5072 11.9. Changes from draft-ietf-hip-rfc5201-bis-01 5074 o Changed RHASH-len to RHASH_len to avoid confusion in calculations 5075 (- could be minus) 5077 o Added RHASH_len to list of abbreviations 5079 o Fixed length of puzzle #I and #J to be 1*RHASH_len 5081 o Changed RHASH-len to RHASH_len to avoid confusion in calculations 5082 (- could be minus) 5084 o Added RHASH_len to list of abbreviations 5086 o Fixed length of puzzle #I and #J to be 1*RHASH_len 5088 o Included HIT_SUITEs. 5090 o Added DH negotiation to I1 and R1. 5092 o Added DH_LIST parameter. 5094 o Added text for DH Group negotiation. 5096 o Removed second DH public value from DH parameter. 5098 o Added ECC to HI generation. 5100 o Added Responder HIT selection to opportunistic mode. 5102 o Added ECDSA HI text and references (not complete yet). 5104 o Added separate section on aborting BEX. 5106 o Added separate section on downgrade attack prevention. 5108 o Added text about DH Group selection for use cases without I1. 5110 o Removed type range allocation for parameters related to HIP 5111 transform types. 5113 o New type range allocation for parameters that are only covered by 5114 a signature if a signature is present (Applies to DH_GROUP_LIST). 5116 o Renamed HIP_TRANSFORM to HIP_CIPHER and removed hashes from it - 5117 hashes are determined by RHASH. 5119 o The length of #I and #J for the puzzle now depends on RHASH. 5121 o New keymat generation. 5123 o Puzzle seed and solution now use RHASH and have variable length. 5125 o Moved timing definitions closer to state machine. 5127 o Simplified text regarding puzzle lifetime. 5129 o Clarified the description of the use of #I in the puzzle 5131 o Removed "Opportunistic mode" description from general definitions. 5133 o More consistency across the old RFC5201 text. Aligned 5134 capitalization and abbreviations. 5136 o Extended protocol overview to include restart option. 5138 o Extended state machine to include restart option because of 5139 unsupported Algorithms. 5141 o Replaced SHA-1 with SHA-256 for required implementation. 5143 o Added OGA list parameter (715) for detecting the Responder's set 5144 of OGAs. 5146 o Added Appendix on ORCHID use in HITs. 5148 o Added truncated SHA-256 option for HITs. 5150 o Added truncated SHA-1 option for HITs. 5152 o Added text about new ORCHID structure to HIT overview. 5154 o Moved Editor role to Robert Moskowitz. 5156 o Added SHA-256 to puzzle parameter. 5158 o Generalized LTRUNC to be hash-function agnostic. 5160 o Added text about RHASH depending on OGA. 5162 11.10. Changes from draft-ietf-hip-rfc5201-bis-00 5164 o Added reasoning why BIS document is needed. 5166 11.11. Contents of draft-ietf-hip-rfc5201-bis-00 5168 o RFC5201 was submitted as draft-RFC. 5170 12. References 5172 12.1. Normative References 5174 [FIPS.180-2.2002] National Institute of Standards and 5175 Technology, "Secure Hash Standard", 5176 FIPS PUB 180-2, August 2002, . 5180 [I-D.ietf-hip-rfc4843-bis] Laganier, J. and F. Dupont, "An IPv6 5181 Prefix for Overlay Routable Cryptographic 5182 Hash Identifiers Version 2 (ORCHIDv2)", 5183 draft-ietf-hip-rfc4843-bis-02 (work in 5184 progress), September 2012. 5186 [I-D.ietf-hip-rfc5202-bis] Jokela, P., Moskowitz, R., and J. Melen, 5187 "Using the Encapsulating Security Payload 5188 (ESP) Transport Format with the Host 5189 Identity Protocol (HIP)", 5190 draft-ietf-hip-rfc5202-bis-01 (work in 5191 progress), September 2012. 5193 [NIST.800-131A.2011] National Institute of Standards and 5194 Technology, "Transitions: Recommendation 5195 for Transitioning the Use of 5196 Cryptographic Algorithms and Key 5197 Lengths", NIST 800-131A, January 2011. 5199 [RFC0768] Postel, J., "User Datagram Protocol", 5200 STD 6, RFC 768, August 1980. 5202 [RFC1035] Mockapetris, P., "Domain names - 5203 implementation and specification", 5204 STD 13, RFC 1035, November 1987. 5206 [RFC2119] Bradner, S., "Key words for use in RFCs 5207 to Indicate Requirement Levels", BCP 14, 5208 RFC 2119, March 1997. 5210 [RFC2404] Madson, C. and R. Glenn, "The Use of 5211 HMAC-SHA-1-96 within ESP and AH", 5212 RFC 2404, November 1998. 5214 [RFC2410] Glenn, R. and S. Kent, "The NULL 5215 Encryption Algorithm and Its Use With 5216 IPsec", RFC 2410, November 1998. 5218 [RFC2460] Deering, S. and R. Hinden, "Internet 5219 Protocol, Version 6 (IPv6) 5220 Specification", RFC 2460, December 1998. 5222 [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the 5223 Domain Name System (DNS)", RFC 2536, 5224 March 1999. 5226 [RFC2785] Zuccherato, R., "Methods for Avoiding the 5227 "Small-Subgroup" Attacks on the Diffie- 5228 Hellman Key Agreement Method for S/MIME", 5229 RFC 2785, March 2000. 5231 [RFC2898] Kaliski, B., "PKCS #5: Password-Based 5232 Cryptography Specification Version 2.0", 5233 RFC 2898, September 2000. 5235 [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA 5236 KEYs in the Domain Name System (DNS)", 5237 RFC 3110, May 2001. 5239 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key 5240 Cryptography Standards (PKCS) #1: RSA 5241 Cryptography Specifications Version 2.1", 5242 RFC 3447, February 2003. 5244 [RFC3484] Draves, R., "Default Address Selection 5245 for Internet Protocol version 6 (IPv6)", 5246 RFC 3484, February 2003. 5248 [RFC3526] Kivinen, T. and M. Kojo, "More Modular 5249 Exponential (MODP) Diffie-Hellman groups 5250 for Internet Key Exchange (IKE)", 5251 RFC 3526, May 2003. 5253 [RFC3602] Frankel, S., Glenn, R., and S. Kelly, 5254 "The AES-CBC Cipher Algorithm and Its Use 5255 with IPsec", RFC 3602, September 2003. 5257 [RFC3972] Aura, T., "Cryptographically Generated 5258 Addresses (CGA)", RFC 3972, March 2005. 5260 [RFC4034] Arends, R., Austein, R., Larson, M., 5261 Massey, D., and S. Rose, "Resource 5262 Records for the DNS Security Extensions", 5263 RFC 4034, March 2005. 5265 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. 5266 Eronen, "The Network Access Identifier", 5267 RFC 4282, December 2005. 5269 [RFC4443] Conta, A., Deering, S., and M. Gupta, 5270 "Internet Control Message Protocol 5271 (ICMPv6) for the Internet Protocol 5272 Version 6 (IPv6) Specification", 5273 RFC 4443, March 2006. 5275 [RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 5276 Authentication Using the Elliptic Curve 5277 Digital Signature Algorithm (ECDSA)", 5278 RFC 4754, January 2007. 5280 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC- 5281 SHA-256, HMAC-SHA-384, and HMAC-SHA-512 5282 with IPsec", RFC 4868, May 2007. 5284 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., 5285 and T. Henderson, "Host Identity 5286 Protocol", RFC 5201, April 2008. 5288 [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with 5289 RSA in DNSKEY and RRSIG Resource Records 5290 for DNSSEC", RFC 5702, October 2009. 5292 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based 5293 Extract-and-Expand Key Derivation 5294 Function (HKDF)", RFC 5869, May 2010. 5296 [RFC5903] Fu, D. and J. Solinas, "Elliptic Curve 5297 Groups modulo a Prime (ECP Groups) for 5298 IKE and IKEv2", RFC 5903, June 2010. 5300 [RFC6090] McGrew, D., Igoe, K., and M. Salter, 5301 "Fundamental Elliptic Curve Cryptography 5302 Algorithms", RFC 6090, February 2011. 5304 12.2. Informative References 5306 [AUR03] Aura, T., Nagarajan, A., and A. Gurtov, 5307 "Analysis of the HIP Base Exchange 5308 Protocol", in Proceedings of 10th 5309 Australasian Conference on Information 5310 Security and Privacy, July 2003. 5312 [CRO03] Crosby, SA. and DS. Wallach, "Denial of 5313 Service via Algorithmic Complexity 5314 Attacks", in Proceedings of Usenix 5315 Security Symposium 2003, Washington, 5316 DC., August 2003. 5318 [DIF76] Diffie, W. and M. Hellman, "New 5319 Directions in Cryptography", IEEE 5320 Transactions on Information Theory vol. 5321 IT-22, number 6, pages 644-654, Nov 1976. 5323 [FIPS.197.2001] National Institute of Standards and 5324 Technology, "Advanced Encryption Standard 5325 (AES)", FIPS PUB 197, November 2001, . 5329 [I-D.ietf-btns-c-api] Richardson, M., Williams, N., Komu, M., 5330 and S. Tarkoma, "C-Bindings for IPsec 5331 Application Programming Interfaces", 5332 draft-ietf-btns-c-api-04 (work in 5333 progress), March 2009. 5335 [I-D.ietf-hip-rfc4423-bis] Moskowitz, R., "Host Identity Protocol 5336 Architecture", 5337 draft-ietf-hip-rfc4423-bis-05 (work in 5338 progress), September 2012. 5340 [I-D.ietf-hip-rfc5204-bis] Laganier, J. and L. Eggert, "Host 5341 Identity Protocol (HIP) Rendezvous 5342 Extension", draft-ietf-hip-rfc5204-bis-02 5343 (work in progress), September 2012. 5345 [I-D.ietf-hip-rfc5205-bis] Laganier, J., "Host Identity Protocol 5346 (HIP) Domain Name System (DNS) 5347 Extension", draft-ietf-hip-rfc5205-bis-02 5348 (work in progress), September 2012. 5350 [I-D.ietf-hip-rfc5206-bis] Henderson, T., Vogt, C., and J. Arkko, 5351 "Host Mobility with the Host Identity 5352 Protocol", draft-ietf-hip-rfc5206-bis-04 5353 (work in progress), July 2012. 5355 [KAU03] Kaufman, C., Perlman, R., and B. 5356 Sommerfeld, "DoS protection for UDP-based 5357 protocols", ACM Conference on Computer 5358 and Communications Security , Oct 2003. 5360 [KRA03] Krawczyk, H., "SIGMA: The 'SIGn-and-MAc' 5361 Approach to Authenticated Diffie-Hellman 5362 and Its Use in the IKE-Protocols", in 5363 Proceedings of CRYPTO 2003, pages 400- 5364 425, August 2003. 5366 [RFC0792] Postel, J., "Internet Control Message 5367 Protocol", STD 5, RFC 792, 5368 September 1981. 5370 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 5371 Address Prefix Reserved for 5372 Documentation", RFC 3849, July 2004. 5374 [RFC4306] Kaufman, C., "Internet Key Exchange 5375 (IKEv2) Protocol", RFC 4306, 5376 December 2005. 5378 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines 5379 for Writing an IANA Considerations 5380 Section in RFCs", BCP 26, RFC 5226, 5381 May 2008. 5383 [RFC5338] Henderson, T., Nikander, P., and M. Komu, 5384 "Using the Host Identity Protocol with 5385 Legacy Applications", RFC 5338, 5386 September 2008. 5388 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: 5389 Level 3 Multihoming Shim Protocol for 5390 IPv6", RFC 5533, June 2009. 5392 [RFC5747] Wu, J., Cui, Y., Li, X., Xu, M., and C. 5393 Metz, "4over6 Transit Solution Using IP 5394 Encapsulation and MP-BGP Extensions", 5395 RFC 5747, March 2010. 5397 [RFC6253] Heer, T. and S. Varjonen, "Host Identity 5398 Protocol Certificates", RFC 6253, 5399 May 2011. 5401 [SECG] SECG, "Recommended Elliptic Curve Domain 5402 Parameters", SEC 2 , 2000, 5403 . 5405 Appendix A. Using Responder Puzzles 5407 As mentioned in Section 4.1.1, the Responder may delay state creation 5408 and still reject most spoofed I2 packets by using a number of pre- 5409 calculated R1 packets and a local selection function. This appendix 5410 defines one possible implementation in detail. The purpose of this 5411 appendix is to give the implementors an idea on how to implement the 5412 mechanism. If the implementation is based on this appendix, it MAY 5413 contain some local modification that makes an attacker's task harder. 5415 The Responder creates a secret value S, that it regenerates 5416 periodically. The Responder needs to remember the two latest values 5417 of S. Each time the S is regenerated, the R1 generation counter 5418 value is incremented by one. 5420 The Responder generates a pre-signed R1 packet. The signature for 5421 pre-generated R1s must be recalculated when the Diffie-Hellman key is 5422 recomputed or when the R1_COUNTER value changes due to S value 5423 regeneration. 5425 When the Initiator sends the I1 packet for initializing a connection, 5426 the Responder receives the HIT and IP address from the packet, and 5427 generates an #I value for the puzzle. The #I value is set to the 5428 pre-signed R1 packet. 5430 #I value calculation: 5431 #I = Ltrunc( RHASH ( S | HIT-I | HIT-R | IP-I | IP-R ), n) 5432 where n = RHASH_len 5434 The RHASH algorithm is the same that is used to generate the 5435 Responder's HIT value. 5437 From an incoming I2 packet, the Responder receives the required 5438 information to validate the puzzle: HITs, IP addresses, and the 5439 information of the used S value from the R1_COUNTER. Using these 5440 values, the Responder can regenerate the #I, and verify it against 5441 the #I received in the I2 packet. If the #I values match, it can 5442 verify the solution using #I, #J, and difficulty #K. If the #I values 5443 do not match, the I2 is dropped. 5445 puzzle_check: 5446 V := Ltrunc( RHASH( I2.I | I2.hit_i | I2.hit_r | I2.J ), #K ) 5447 if V != 0, drop the packet 5449 If the puzzle solution is correct, the #I and #J values are stored 5450 for later use. They are used as input material when keying material 5451 is generated. 5453 Keeping state about failed puzzle solutions depends on the 5454 implementation. Although it is possible for the Responder not to 5455 keep any state information, it still may do so to protect itself 5456 against certain attacks (see Section 4.1.1). 5458 Appendix B. Generating a Public Key Encoding from an HI 5460 The following pseudo-code illustrates the process to generate a 5461 public key encoding from an HI for both RSA and DSA. 5463 The symbol := denotes assignment; the symbol += denotes appending. 5464 The pseudo-function encode_in_network_byte_order takes two 5465 parameters, an integer (bignum) and a length in bytes, and returns 5466 the integer encoded into a byte string of the given length. 5468 switch ( HI.algorithm ) 5469 { 5471 case RSA: 5472 buffer := encode_in_network_byte_order ( HI.RSA.e_len, 5473 ( HI.RSA.e_len > 255 ) ? 3 : 1 ) 5474 buffer += encode_in_network_byte_order ( HI.RSA.e, HI.RSA.e_len ) 5475 buffer += encode_in_network_byte_order ( HI.RSA.n, HI.RSA.n_len ) 5476 break; 5478 case DSA: 5479 buffer := encode_in_network_byte_order ( HI.DSA.T , 1 ) 5480 buffer += encode_in_network_byte_order ( HI.DSA.Q , 20 ) 5481 buffer += encode_in_network_byte_order ( HI.DSA.P , 64 + 5482 8 * HI.DSA.T ) 5483 buffer += encode_in_network_byte_order ( HI.DSA.G , 64 + 5484 8 * HI.DSA.T ) 5485 buffer += encode_in_network_byte_order ( HI.DSA.Y , 64 + 5486 8 * HI.DSA.T ) 5487 break; 5489 } 5491 Appendix C. Example Checksums for HIP Packets 5493 The HIP checksum for HIP packets is specified in Section 5.1.1. 5494 Checksums for TCP and UDP packets running over HIP-enabled security 5495 associations are specified in Section 3.5. The examples below use 5496 [RFC3849] and [RFC5747] addresses, and HITs with the prefix of 5497 2001:10 followed by zeros, followed by a decimal 1 or 2, 5498 respectively. 5500 The following example is defined only for testing the checksum 5501 calculation. 5503 C.1. IPv6 HIP Example (I1 packet) 5505 Source Address: 2001:d88::1 5506 Destination Address: 2001:d88::2 5507 Upper-Layer Packet Length: 48 0x30 5508 Next Header: 139 0x8b 5509 Payload Protocol: 59 0x3b 5510 Header Length: 4 0x4 5511 Packet Type: 1 0x1 5512 Version: 2 0x2 5513 Reserved: 1 0x1 5514 Control: 0 0x0 5515 Checksum: 6878 0x1ade 5516 Sender's HIT : 2001:10::1 5517 Receiver's HIT: 2001:10::2 5518 DH_GROUP_LIST type: 511 0x1ff 5519 DH_GROUP_LIST length: 3 0x3 5520 DH_GROUP_LIST group IDs: 3,4,8 5522 C.2. IPv4 HIP Packet (I1 packet) 5524 The IPv4 checksum value for the example I1 packet is shown below. 5526 Source Address: 192.0.2.1 5527 Destination Address: 192.0.2.2 5528 Upper-Layer Packet Length: 48 0x30 5529 Next Header: 139 0x8b 5530 Payload Protocol: 59 0x3b 5531 Header Length: 4 0x4 5532 Packet Type: 1 0x1 5533 Version: 2 0x2 5534 Reserved: 1 0x1 5535 Control: 0 0x0 5536 Checksum: 61934 0xf1ee 5537 Sender's HIT : 2001:10::1 5538 Receiver's HIT: 2001:10::2 5539 DH_GROUP_LIST type: 511 0x1ff 5540 DH_GROUP_LIST length: 3 0x3 5541 DH_GROUP_LIST group IDs: 3,4,8 5543 C.3. TCP Segment 5545 Regardless of whether IPv6 or IPv4 is used, the TCP and UDP sockets 5546 use the IPv6 pseudo-header format [RFC2460], with the HITs used in 5547 place of the IPv6 addresses. 5549 Sender's HIT: 2001:10::1 5550 Receiver's HIT: 2001:10::2 5551 Upper-Layer Packet Length: 20 0x14 5552 Next Header: 6 0x06 5553 Source port: 65500 0xffdc 5554 Destination port: 22 0x0016 5555 Sequence number: 1 0x00000001 5556 Acknowledgment number: 0 0x00000000 5557 Header length: 20 0x14 5558 Flags: SYN 0x02 5559 Window size: 65535 0xffff 5560 Checksum: 28618 0x6fca 5561 Urgent pointer: 0 0x0000 5563 0x0000: 6000 0000 0014 0640 2001 0010 0000 0000 5564 0x0010: 0000 0000 0000 0001 2001 0010 0000 0000 5565 0x0020: 0000 0000 0000 0002 ffdc 0016 0000 0001 5566 0x0030: 0000 0000 5002 ffff 6fca 0000 5568 Appendix D. ECDH and ECDSA 160 Bit Groups 5570 The ECDH and ECDSA 160-bit group SECP160R1 is rated at 80 bits 5571 symmetric strength. Once this was considered appropriate for one 5572 year of security. Today these groups should be used only when the 5573 host is not powerful enough (e.g., some embedded devices) and when 5574 security requirements are low (e.g., long-term confidentiality is not 5575 required). 5577 Appendix E. HIT Suites and HIT Generation 5579 The HIT as an ORCHID [I-D.ietf-hip-rfc4843-bis] consists of three 5580 parts: A 28-bit prefix, a 4-bit encoding of the ORCHID generation 5581 algorithm (OGA) and the representation of the public key. The OGA is 5582 an index pointing to the specific algorithm by which the public key 5583 and the 96-bit hashed encoding is generated. The OGA is protocol 5584 specific and is to be interpreted as defined below for all protocols 5585 that use the same context ID as HIP. HIP groups sets of valid 5586 combinations of signature and hash algorithms into HIT Suites. These 5587 HIT suites are addressed by an index, which is transmitted in the OGA 5588 field of the ORCHID. 5590 The set of used HIT Suites will be extended to counter the progress 5591 in computation capabilities and vulnerabilities in the employed 5592 algorithms. The intended use of the HIT Suites is to introduce a new 5593 HIT Suite and phase out an old one before it becomes insecure. Since 5594 the 4-bit OGA field only permits 15 HIT Suites (the HIT Suite with ID 5595 0 is reserved) to be used in parallel, phased-out HIT Suites must be 5596 reused at some point. In such a case, there will be a rollover of 5597 the HIT Suite ID and the next newly introduced HIT Suite will start 5598 with a lower HIT Suite index than the previously introduced one. The 5599 rollover effectively deprecates the reused HIT Suite. For a smooth 5600 transition, the HIT Suite should be deprecated a considerable time 5601 before the HIT Suite index is reused. 5603 Since the number of HIT Suites is tightly limited to 16, the HIT 5604 Suites must be assigned carefully. Hence, sets of suitable 5605 algorithms are grouped in a HIT Suite. 5607 The HIT Suite of the Responder's HIT determines the RHASH and the 5608 hash function to be used for the HMAC in HIP control packets as well 5609 as the signature algorithm family used for generating the HI. The 5610 list of HIT Suites is defined in Table 11. 5612 The following HIT Suites are defined for HIT generation. The input 5613 for each generation algorithm is the encoding of the HI as defined in 5614 Section 3.2. The output is 96 bits long and is directly used in the 5615 ORCHID. 5617 +-------+----------+--------------+------------+--------------------+ 5618 | Index | Hash | HMAC | Signature | Description | 5619 | | function | | algorithm | | 5620 | | | | family | | 5621 +-------+----------+--------------+------------+--------------------+ 5622 | 0 | | | | Reserved | 5623 | 1 | SHA-256 | HMAC-SHA-256 | RSA, DSA | RSA or DSA HI | 5624 | | | | | hashed with | 5625 | | | | | SHA-256, truncated | 5626 | | | | | to 96 bits | 5627 | 2 | SHA-384 | HMAC-SHA-384 | ECDSA | ECDSA HI hashed | 5628 | | | | | with SHA-384, | 5629 | | | | | truncated to 96 | 5630 | | | | | bits | 5631 | 3 | SHA-1 | HMAC-SHA-1 | ECDSA_LOW | ECDSA_LOW HI | 5632 | | | | | hashed with SHA-1, | 5633 | | | | | truncated to 96 | 5634 | | | | | bits | 5635 +-------+----------+--------------+------------+--------------------+ 5637 Table 11: HIT Suites 5639 The hash of the responder as defined in the HIT Suite determines the 5640 HMAC to be used for the HMAC parameter. The HMACs currently defined 5641 here are HMAC-SHA-256 [RFC4868], HMAC-SHA-384 [RFC4868], and HMAC- 5642 SHA-1 [RFC2404]. 5644 Authors' Addresses 5646 Robert Moskowitz (editor) 5647 Verizon Telcom and Business 5648 1000 Bent Creek Blvd, Suite 200 5649 Mechanicsburg, PA 5650 USA 5652 EMail: robert.moskowitz@verizonbusiness.com 5654 Tobias Heer 5655 RWTH Aachen University, Communication and Distributed Systems Group 5656 Ahornstrasse 55 5657 Aachen 52062 5658 Germany 5660 EMail: heer@cs.rwth-aachen.de 5661 URI: http://www.comsys.rwth-aachen.de/team/tobias-heer/ 5663 Petri Jokela 5664 Ericsson Research NomadicLab 5665 JORVAS FIN-02420 5666 FINLAND 5668 Phone: +358 9 299 1 5669 EMail: petri.jokela@nomadiclab.com 5671 Thomas R. Henderson 5672 The Boeing Company 5673 P.O. Box 3707 5674 Seattle, WA 5675 USA 5677 EMail: thomas.r.henderson@boeing.com