idnits 2.17.1 draft-ietf-hip-rfc5201-bis-12.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 2187 has weird spacing: '...c Value leng...' == Line 2189 has weird spacing: '...c Value the ...' == Line 2714 has weird spacing: '...ication info...' == Line 2853 has weird spacing: '...ue data opaqu...' == Line 2883 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 (June 30, 2013) is 3946 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 2321, 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-02 ** 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 Hirschmann Automation and 6 Expires: January 1, 2014 Control 7 P. Jokela 8 Ericsson Research NomadicLab 9 T. Henderson 10 The Boeing Company 11 June 30, 2013 13 Host Identity Protocol Version 2 (HIPv2) 14 draft-ietf-hip-rfc5201-bis-12 16 Abstract 18 This document specifies the details of the Host Identity Protocol 19 (HIP). HIP allows consenting hosts to securely establish and 20 maintain shared IP-layer state, allowing separation of the identifier 21 and locator roles of IP addresses, thereby enabling continuity of 22 communications across IP address changes. HIP is based on a SIGMA- 23 compliant Diffie-Hellman key exchange, using public key identifiers 24 from a new Host Identity namespace for mutual peer authentication. 25 The protocol is designed to be resistant to denial-of-service (DoS) 26 and man-in-the-middle (MitM) attacks. When used together with 27 another suitable security protocol, such as the Encapsulated Security 28 Payload (ESP), it provides integrity protection and optional 29 encryption for upper-layer protocols, such as TCP and UDP. 31 This document obsoletes RFC 5201 and addresses the concerns raised by 32 the IESG, particularly that of crypto agility. It also incorporates 33 lessons learned from the implementations of RFC 5201. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on January 1, 2014. 51 Copyright Notice 53 Copyright (c) 2013 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 This document may contain material from IETF Documents or IETF 67 Contributions published or made publicly available before November 68 10, 2008. The person(s) controlling the copyright in some of this 69 material may not have granted the IETF Trust the right to allow 70 modifications of such material outside the IETF Standards Process. 71 Without obtaining an adequate license from the person(s) controlling 72 the copyright in such materials, this document may not be modified 73 outside the IETF Standards Process, and derivative works of it may 74 not be created outside the IETF Standards Process, except to format 75 it for publication as an RFC or to translate it into languages other 76 than English. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 81 1.1. A New Namespace and Identifiers . . . . . . . . . . . . 7 82 1.2. The HIP Base Exchange (BEX) . . . . . . . . . . . . . . 7 83 1.3. Memo Structure . . . . . . . . . . . . . . . . . . . . . 8 84 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 8 85 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 8 86 2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 8 87 2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . 9 88 3. Host Identity (HI) and its Structure . . . . . . . . . . . . 10 89 3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . 11 90 3.2. Generating a HIT from an HI . . . . . . . . . . . . . . 11 91 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 12 92 4.1. Creating a HIP Association . . . . . . . . . . . . . . . 13 93 4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . 14 94 4.1.2. Puzzle Exchange . . . . . . . . . . . . . . . . . . . 15 95 4.1.3. Authenticated Diffie-Hellman Protocol with DH 96 Group Negotiation . . . . . . . . . . . . . . . . . . 17 98 4.1.4. HIP Replay Protection . . . . . . . . . . . . . . . . 18 99 4.1.5. Refusing a HIP Base Exchange . . . . . . . . . . . . 19 100 4.1.6. Aborting a HIP Base Exchange . . . . . . . . . . . . 20 101 4.1.7. HIP Downgrade Protection . . . . . . . . . . . . . . 20 102 4.1.8. HIP Opportunistic Mode . . . . . . . . . . . . . . . 21 103 4.2. Updating a HIP Association . . . . . . . . . . . . . . . 24 104 4.3. Error Processing . . . . . . . . . . . . . . . . . . . . 24 105 4.4. HIP State Machine . . . . . . . . . . . . . . . . . . . 25 106 4.4.1. State Machine Terminology . . . . . . . . . . . . . . 26 107 4.4.2. HIP States . . . . . . . . . . . . . . . . . . . . . 27 108 4.4.3. HIP State Processes . . . . . . . . . . . . . . . . . 27 109 4.4.4. Simplified HIP State Diagram . . . . . . . . . . . . 34 110 4.5. User Data Considerations . . . . . . . . . . . . . . . . 36 111 4.5.1. TCP and UDP Pseudo-Header Computation for User Data . 36 112 4.5.2. Sending Data on HIP Packets . . . . . . . . . . . . . 36 113 4.5.3. Transport Formats . . . . . . . . . . . . . . . . . . 36 114 4.5.4. Reboot, Timeout, and Restart of HIP . . . . . . . . . 36 115 4.6. Certificate Distribution . . . . . . . . . . . . . . . . 37 116 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 37 117 5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 37 118 5.1.1. Checksum . . . . . . . . . . . . . . . . . . . . . . 38 119 5.1.2. HIP Controls . . . . . . . . . . . . . . . . . . . . 39 120 5.1.3. HIP Fragmentation Support . . . . . . . . . . . . . . 39 121 5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 40 122 5.2.1. TLV Format . . . . . . . . . . . . . . . . . . . . . 43 123 5.2.2. Defining New Parameters . . . . . . . . . . . . . . . 45 124 5.2.3. R1_COUNTER . . . . . . . . . . . . . . . . . . . . . 46 125 5.2.4. PUZZLE . . . . . . . . . . . . . . . . . . . . . . . 47 126 5.2.5. SOLUTION . . . . . . . . . . . . . . . . . . . . . . 48 127 5.2.6. DH_GROUP_LIST . . . . . . . . . . . . . . . . . . . . 49 128 5.2.7. DIFFIE_HELLMAN . . . . . . . . . . . . . . . . . . . 50 129 5.2.8. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . 51 130 5.2.9. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 52 131 5.2.10. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 54 132 5.2.11. TRANSPORT_FORMAT_LIST . . . . . . . . . . . . . . . . 55 133 5.2.12. HIP_MAC . . . . . . . . . . . . . . . . . . . . . . . 56 134 5.2.13. HIP_MAC_2 . . . . . . . . . . . . . . . . . . . . . . 56 135 5.2.14. HIP_SIGNATURE . . . . . . . . . . . . . . . . . . . . 57 136 5.2.15. HIP_SIGNATURE_2 . . . . . . . . . . . . . . . . . . . 58 137 5.2.16. SEQ . . . . . . . . . . . . . . . . . . . . . . . . . 58 138 5.2.17. ACK . . . . . . . . . . . . . . . . . . . . . . . . . 59 139 5.2.18. ENCRYPTED . . . . . . . . . . . . . . . . . . . . . . 60 140 5.2.19. NOTIFICATION . . . . . . . . . . . . . . . . . . . . 61 141 5.2.20. ECHO_REQUEST_SIGNED . . . . . . . . . . . . . . . . . 65 142 5.2.21. ECHO_REQUEST_UNSIGNED . . . . . . . . . . . . . . . . 65 143 5.2.22. ECHO_RESPONSE_SIGNED . . . . . . . . . . . . . . . . 66 144 5.2.23. ECHO_RESPONSE_UNSIGNED . . . . . . . . . . . . . . . 67 145 5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . 67 146 5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 68 147 5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 69 148 5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 72 149 5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 73 150 5.3.5. UPDATE - the HIP Update Packet . . . . . . . . . . . 74 151 5.3.6. NOTIFY - the HIP Notify Packet . . . . . . . . . . . 75 152 5.3.7. CLOSE - the HIP Association Closing Packet . . . . . 75 153 5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet . . 76 154 5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . 76 155 5.4.1. Invalid Version . . . . . . . . . . . . . . . . . . . 76 156 5.4.2. Other Problems with the HIP Header and Packet 157 Structure . . . . . . . . . . . . . . . . . . . . . . 76 158 5.4.3. Invalid Puzzle Solution . . . . . . . . . . . . . . . 77 159 5.4.4. Non-Existing HIP Association . . . . . . . . . . . . 77 160 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 77 161 6.1. Processing Outgoing Application Data . . . . . . . . . . 78 162 6.2. Processing Incoming Application Data . . . . . . . . . . 79 163 6.3. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 80 164 6.4. HIP_MAC and SIGNATURE Calculation and Verification . . . 81 165 6.4.1. HMAC Calculation . . . . . . . . . . . . . . . . . . 81 166 6.4.2. Signature Calculation . . . . . . . . . . . . . . . . 84 167 6.5. HIP KEYMAT Generation . . . . . . . . . . . . . . . . . 86 168 6.6. Initiation of a HIP Base Exchange . . . . . . . . . . . 87 169 6.6.1. Sending Multiple I1 Packets in Parallel . . . . . . . 88 170 6.6.2. Processing Incoming ICMP Protocol Unreachable 171 Messages . . . . . . . . . . . . . . . . . . . . . . 89 172 6.7. Processing Incoming I1 Packets . . . . . . . . . . . . . 89 173 6.7.1. R1 Management . . . . . . . . . . . . . . . . . . . . 90 174 6.7.2. Handling Malformed Messages . . . . . . . . . . . . . 91 175 6.8. Processing Incoming R1 Packets . . . . . . . . . . . . . 91 176 6.8.1. Handling of Malformed Messages . . . . . . . . . . . 94 177 6.9. Processing Incoming I2 Packets . . . . . . . . . . . . . 94 178 6.9.1. Handling of Malformed Messages . . . . . . . . . . . 97 179 6.10. Processing of Incoming R2 Packets . . . . . . . . . . . 97 180 6.11. Sending UPDATE Packets . . . . . . . . . . . . . . . . . 97 181 6.12. Receiving UPDATE Packets . . . . . . . . . . . . . . . . 98 182 6.12.1. Handling a SEQ Parameter in a Received UPDATE 183 Message . . . . . . . . . . . . . . . . . . . . . . . 99 184 6.12.2. Handling an ACK Parameter in a Received UPDATE 185 Packet . . . . . . . . . . . . . . . . . . . . . . . 100 186 6.13. Processing of NOTIFY Packets . . . . . . . . . . . . . . 101 187 6.14. Processing CLOSE Packets . . . . . . . . . . . . . . . . 101 188 6.15. Processing CLOSE_ACK Packets . . . . . . . . . . . . . . 101 189 6.16. Handling State Loss . . . . . . . . . . . . . . . . . . 101 190 7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 102 191 8. Security Considerations . . . . . . . . . . . . . . . . . . . 102 192 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 105 193 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 107 194 11. Changes from RFC 5201 . . . . . . . . . . . . . . . . . . . . 108 195 11.1. Changes from draft-ietf-hip-rfc5201-bis-11 . . . . . . . 108 196 11.2. Changes from draft-ietf-hip-rfc5201-bis-10 . . . . . . . 109 197 11.3. Changes from draft-ietf-hip-rfc5201-bis-09 . . . . . . . 109 198 11.4. Changes from draft-ietf-hip-rfc5201-bis-08 . . . . . . . 109 199 11.5. Changes from draft-ietf-hip-rfc5201-bis-07 . . . . . . . 109 200 11.6. Changes from draft-ietf-hip-rfc5201-bis-06 . . . . . . . 109 201 11.7. Changes from draft-ietf-hip-rfc5201-bis-05 . . . . . . . 109 202 11.8. Changes from draft-ietf-hip-rfc5201-bis-04 . . . . . . . 110 203 11.9. Changes from draft-ietf-hip-rfc5201-bis-03 . . . . . . . 111 204 11.10. Changes from draft-ietf-hip-rfc5201-bis-02 . . . . . . . 112 205 11.11. Changes from draft-ietf-hip-rfc5201-bis-01 . . . . . . . 113 206 11.12. Changes from draft-ietf-hip-rfc5201-bis-00 . . . . . . . 114 207 11.13. Contents of draft-ietf-hip-rfc5201-bis-00 . . . . . . . 115 208 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 115 209 12.1. Normative References . . . . . . . . . . . . . . . . . . 115 210 12.2. Informative References . . . . . . . . . . . . . . . . . 117 211 Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 120 212 Appendix B. Generating a Public Key Encoding from an HI . . . . 121 213 Appendix C. Example Checksums for HIP Packets . . . . . . . . . 121 214 C.1. IPv6 HIP Example (I1 packet) . . . . . . . . . . . . . . 122 215 C.2. IPv4 HIP Packet (I1 packet) . . . . . . . . . . . . . . 122 216 C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . 122 217 Appendix D. ECDH and ECDSA 160 Bit Groups . . . . . . . . . . . 123 218 Appendix E. HIT Suites and HIT Generation . . . . . . . . . . . 123 220 1. Introduction 222 This document specifies the details of the Host Identity Protocol 223 (HIP). A high-level description of the protocol and the underlying 224 architectural thinking is available in the separate HIP architecture 225 description [I-D.ietf-hip-rfc4423-bis]. Briefly, the HIP 226 architecture proposes an alternative to the dual use of IP addresses 227 as "locators" (routing labels) and "identifiers" (endpoint, or host, 228 identifiers). In HIP, public cryptographic keys, of a public/private 229 key pair, are used as Host Identifiers, to which higher layer 230 protocols are bound instead of an IP address. By using public keys 231 (and their representations) as host identifiers, dynamic changes to 232 IP address sets can be directly authenticated between hosts, and if 233 desired, strong authentication between hosts at the TCP/IP stack 234 level can be obtained. 236 This memo specifies the base HIP protocol ("base exchange") used 237 between hosts to establish an IP-layer communications context, called 238 a HIP association, prior to communications. It also defines a packet 239 format and procedures for updating an active HIP association. Other 240 elements of the HIP architecture are specified in other documents, 241 such as: 243 o "Using the Encapsulating Security Payload (ESP) transport format 244 with the Host Identity Protocol (HIP)" [I-D.ietf-hip-rfc5202-bis]: 245 how to use the Encapsulating Security Payload (ESP) for integrity 246 protection and optional encryption 248 o "Host Mobility with the Host Identity Protocol" 249 [I-D.ietf-hip-rfc5206-bis]: how to support host mobility in HIP 251 o "Host Identity Protocol (HIP) Domain Name System (DNS) Extensions" 252 [I-D.ietf-hip-rfc5205-bis]: how to extend DNS to contain Host 253 Identity information 255 o "Host Identity Protocol (HIP) Rendezvous Extension" 256 [I-D.ietf-hip-rfc5204-bis]: using a rendezvous mechanism to 257 contact mobile HIP hosts 259 Since the HIP Base Exchange was first developed, there have been a 260 few advances in cryptography and attacks against cryptographic 261 systems. As a result, all cryptographic protocols need to be agile. 262 That is, it should be a part of the protocol to be able to switch 263 from one cryptographic primitive to another. It is important to 264 support a reasonable set of mainstream algorithms to cater for 265 different use cases and allow moving away from algorithms that are 266 later discovered to be vulnerable This update to the Base Exchange 267 includes this needed cryptographic agility while addressing the 268 downgrade attacks that such flexibility introduces. In particular, 269 Elliptic Curve support by Elliptic Curve DSA (ECDSA) and Elliptic 270 Curve Diffie-Hellman (ECDH) and alternative hash functions have been 271 added. 273 1.1. A New Namespace and Identifiers 275 The Host Identity Protocol introduces a new namespace, the Host 276 Identity namespace. Some ramifications of this new namespace are 277 explained in the HIP architecture description 278 [I-D.ietf-hip-rfc4423-bis]. 280 There are two main representations of the Host Identity, the full 281 Host Identity (HI) and the Host Identity Tag (HIT). The HI is a 282 public key and directly represents the Identity of a host. Since 283 there are different public key algorithms that can be used with 284 different key lengths, the HI, as such, is unsuitable for use as a 285 packet identifier, or as an index into the various state-related 286 implementation structures needed to support HIP. Consequently, a 287 hash of the HI, the Host Identity Tag (HIT), is used as the 288 operational representation. The HIT is 128 bits long and is used in 289 the HIP headers and to index the corresponding state in the end 290 hosts. The HIT has an important security property in that it is 291 self-certifying (see Section 3). 293 1.2. The HIP Base Exchange (BEX) 295 The HIP base exchange is a two-party cryptographic protocol used to 296 establish communications context between hosts. The base exchange is 297 a SIGMA-compliant [KRA03] four-packet exchange. The first party is 298 called the Initiator and the second party the Responder. The 299 protocol exchanges Diffie-Hellman [DIF76] keys in the 2nd and 3rd 300 packets, and authenticates the parties in the 3rd and 4th packets. 301 The four-packet design helps to make HIP DoS resilient. It allows 302 the Responder to stay stateless until the IP address and the 303 cryptographic puzzle is verified. The Responder starts the puzzle 304 exchange in the 2nd packet, with the Initiator completing it in the 305 3rd packet before the Responder stores any state from the exchange. 307 The exchange can use the Diffie-Hellman output to encrypt the Host 308 Identity of the Initiator in the 3rd packet (although Aura, et al., 309 [AUR03] notes that such operation may interfere with packet- 310 inspecting middleboxes), or the Host Identity may instead be sent 311 unencrypted. The Responder's Host Identity is not protected. It 312 should be noted, however, that both the Initiator's and the 313 Responder's HITs are transported as such (in cleartext) in the 314 packets, allowing an eavesdropper with a priori knowledge about the 315 parties to identify them by their HITs. Hence, encrypting the HI of 316 any party does not provide privacy against such attacker. 318 Data packets start to flow after the 4th packet. The 3rd and 4th HIP 319 packets may carry a data payload in the future. However, the details 320 of this may be defined later. 322 An existing HIP association can be updated using the update mechanism 323 defined in this document, and when the association is no longer 324 needed, it can be closed using the defined closing mechanism. 326 Finally, HIP is designed as an end-to-end authentication and key 327 establishment protocol, to be used with Encapsulated Security Payload 328 (ESP) [I-D.ietf-hip-rfc5202-bis] and other end-to-end security 329 protocols. The base protocol does not cover all the fine-grained 330 policy control found in Internet Key Exchange (IKE) [RFC4306] that 331 allows IKE to support complex gateway policies. Thus, HIP is not a 332 complete replacement for IKE. 334 1.3. Memo Structure 336 The rest of this memo is structured as follows. Section 2 defines 337 the central keywords, notation, and terms used throughout the rest of 338 the document. Section 3 defines the structure of the Host Identity 339 and its various representations. Section 4 gives an overview of the 340 HIP base exchange protocol. Sections 5 and 6 define the detailed 341 packet formats and rules for packet processing. Finally, Sections 7, 342 8, and 9 discuss policy, security, and IANA considerations, 343 respectively. 345 2. Terms and Definitions 347 2.1. Requirements Terminology 349 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 350 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 351 document are to be interpreted as described in RFC 2119 [RFC2119]. 353 2.2. Notation 355 [x] indicates that x is optional. 357 {x} indicates that x is encrypted. 359 X(y) indicates that y is a parameter of X. 361 i indicates that x exists i times. 363 --> signifies "Initiator to Responder" communication (requests). 365 <-- signifies "Responder to Initiator" communication (replies). 367 | signifies concatenation of information (e.g., X | Y is the 368 concatenation of X with Y). 370 Ltrunc (H(x), K) denotes the lowest order #K bits of the result of 371 the hash function H on the input x. 373 2.3. Definitions 375 HIP Base Exchange (BEX): the handshake for establishing a new HIP 376 association. 378 Host Identity (HI): The public key of the signature algorithm that 379 represents the identity of the host. In HIP, a host proves its 380 identity by creating a signature with the private key belonging to 381 its HI (c.f. Section 3). 383 Host Identity Tag (HIT): A shorthand for the HI in IPv6 format. It 384 is generated by hashing the HI (c.f. Section 3.1). 386 HIT Suite: A HIT Suite groups all cryptographic algorithms that are 387 required to generate and use an HI and its HIT. In particular, 388 these algorithms are: 1) the public key signature algorithm and 2) 389 the hash function, 3) the truncation (c.f. Appendix E). 391 HIP association: The shared state between two peers after 392 completion of the BEX. 394 Initiator: The host that initiates the BEX. This role is typically 395 forgotten once the BEX is completed. 397 Responder: The host that responds to the Initiator in the BEX. 398 This role is typically forgotten once the BEX is completed. 400 Responder's HIT Hash Algorithm (RHASH): The Hash algorithm used for 401 various hash calculations in this document. The algorithm is the 402 same as is used to generate the Responder's HIT. The RHASH is the 403 hash function defined by the HIT Suite of the Responder's HIT 404 (c.f. Appendix E). 406 Length of the Responder's HIT Hash Algorithm (RHASH_len): The 407 natural output length of RHASH in bits. 409 Signed data: Data that is signed is protected by a digital 410 signature that was created by the sender of the data by using the 411 private key of its HI. 413 KDF: The Key Derivation Function (KDF) is used for deriving the 414 symmetric keys from the Diffie-Hellman key exchange. 416 KEYMAT: The keying material derived from the Diffie-Hellman key 417 exchange by using the KDF. Symmetric keys for encryption and 418 integrity protection of HIP control and payload packets are drawn 419 from this keying material. 421 3. Host Identity (HI) and its Structure 423 In this section, the properties of the Host Identity and Host 424 Identity Tag are discussed, and the exact format for them is defined. 425 In HIP, the public key of an asymmetric key pair is used as the Host 426 Identity (HI). Correspondingly, the host itself is defined as the 427 entity that holds the private key of the key pair. See the HIP 428 architecture specification [I-D.ietf-hip-rfc4423-bis] for more 429 details on the difference between an identity and the corresponding 430 identifier. 432 HIP implementations MUST support the Rivest Shamir Adelman (RSA) 433 [RFC3110] public key algorithm and the Elliptic Curve Digital 434 Signature Algorithm (ECDSA) for generating the HI as defined in 435 Section 5.2.9. Additional algorithms MAY be supported. 437 A hashed encoding of the HI, the Host Identity Tag (HIT), is used in 438 protocols to represent the Host Identity. The HIT is 128 bits long 439 and has the following three key properties: i) it is the same length 440 as an IPv6 address and can be used in fixed address-sized fields in 441 APIs and protocols, ii) it is self-certifying (i.e., given a HIT, it 442 is computationally hard to find a Host Identity key that matches the 443 HIT), and iii) the probability of a HIT collision between two hosts 444 is very low, hence, it is infeasible for an attacker to find a 445 collision with a HIT that is in use. For details on the security 446 properties of the HIT see [I-D.ietf-hip-rfc4423-bis]. 448 The structure of the HIT is defined in [I-D.ietf-hip-rfc4843-bis]. 449 The HIT is an Overlay Routable Cryptographic Hash Identifier (ORCHID) 450 and consists of three parts: first, an IANA assigned prefix to 451 distinguish it from other IPv6 addresses. Second, a four-bit 452 encoding of the algorithms that were used for generating the HI and 453 the hashed representation of HI. Third, a 96-bit hashed 454 representation of the Host Identity. The encoding of the ORCHID 455 generation algorithm and the exact algorithm for generating the 456 hashed representation is specified in Appendix E. 458 Carrying HIs and HITs in the header of user data packets would 459 increase the overhead of packets. Thus, it is not expected that they 460 are carried in every packet, but other methods are used to map the 461 data packets to the corresponding HIs. In some cases, this makes it 462 possible to use HIP without any additional headers in the user data 463 packets. For example, if ESP is used to protect data traffic, the 464 Security Parameter Index (SPI) carried in the ESP header can be used 465 to map the encrypted data packet to the correct HIP association. 467 3.1. Host Identity Tag (HIT) 469 The Host Identity Tag is a 128-bit value -- a hashed encoding of the 470 Host Identifier. There are two advantages of using a hashed encoding 471 over the actual variable-sized Host Identity public key in protocols. 472 First, the fixed length of the HIT keeps packet sizes manageable and 473 eases protocol coding. Second, it presents a consistent format for 474 the protocol, independent of the underlying identity technology in 475 use. 477 RFC 4843-bis [I-D.ietf-hip-rfc4843-bis] specifies 128-bit hash-based 478 identifiers, called Overlay Routable Cryptographic Hash Identifiers, 479 ORCHIDs. Their prefix, allocated from the IPv6 address block, is 480 defined in [I-D.ietf-hip-rfc4843-bis]. The Host Identity Tag is one 481 type of an ORCHID. 483 This document extends the original, experimental HIP specification 484 [RFC5201] with measures to support crypto agility. One of these 485 measures is to allow different hash functions for creating a HIT. 486 HIT Suites group the sets of algorithms that are required to generate 487 and use a particular HIT. The Suites are encoded in HIT Suite IDs. 488 These HIT Suite IDs are transmitted in the ORCHID Generation 489 Algorithm (OGA) field in the ORCHID. With the HIT Suite ID in the 490 OGA field, a hosts can tell from another host's HIT, whether it 491 supports the necessary hash and signature algorithms to establish a 492 HIP association with that host. 494 3.2. Generating a HIT from an HI 496 The HIT MUST be generated according to the ORCHID generation method 497 described in [I-D.ietf-hip-rfc4843-bis] using a context ID value of 498 0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA (this tag value has been 499 generated randomly by the editor of this specification), and an input 500 that encodes the Host Identity field (see Section 5.2.9) present in a 501 HIP payload packet. The set of hash function, signature algorithm, 502 and the algorithm used for generating the HIT from the HI depends on 503 the HIT Suite (see Appendix E) and is indicated by the four bits of 504 the ORCHID Generation Algorithm (OGA) field in the ORCHID. 505 Currently, truncated SHA-1, truncated SHA-384, and truncated SHA-256 506 [FIPS.180-2.2002] are defined as hashes for generating a HIT. 508 For identities that are either RSA, Digital Signature Algorithm 509 (DSA), or Elliptic Curve DSA (ECDSA) public keys, the ORCHID input 510 consists of the public key encoding as specified for the Host 511 Identity field of the HOST_ID parameter (see Section 5.2.9). This 512 document defines four algorithm profiles: RSA, DSA, ECDSA, and 513 ECDSA_LOW. The ECDSA_LOW profile is meant for devices with low 514 computational capabilities. Hence, one of the following applies: 516 The RSA public key is encoded as defined in [RFC3110] Section 2, 517 taking the exponent length (e_len), exponent (e), and modulus (n) 518 fields concatenated. The length (n_len) of the modulus (n) can be 519 determined from the total HI Length and the preceding HI fields 520 including the exponent (e). Thus, the data that serves as input 521 for the HIT generation has the same length as the HI. The fields 522 MUST be encoded in network byte order, as defined in [RFC3110]. 524 The DSA public key is encoded as defined in [RFC2536] Section 2, 525 taking the fields T, Q, P, G, and Y, concatenated as input. Thus, 526 the data to be hashed is 1 + 20 + 3 * 64 + 3 * 8 * T octets long, 527 where T is the size parameter as defined in [RFC2536]. The size 528 parameter T, affecting the field lengths, MUST be selected as the 529 minimum value that is long enough to accommodate P, G, and Y. The 530 fields MUST be encoded in network byte order, as defined in 531 [RFC2536]. 533 The ECDSA public keys are encoded as defined in [RFC6090] Section 534 4.2 and 6. 536 In Appendix B, the public key encoding process is illustrated using 537 pseudo-code. 539 4. Protocol Overview 541 This section is a simplified overview of the HIP protocol operation, 542 and does not contain all the details of the packet formats or the 543 packet processing steps. Sections 5 and 6 describe in more detail 544 the packet formats and packet processing steps, respectively, and are 545 normative in case of any conflicts with this section. 547 The protocol number 139 has been assigned by IANA to the Host 548 Identity Protocol. 550 The HIP payload (Section 5.1) header could be carried in every IP 551 datagram. However, since HIP headers are relatively large (40 552 bytes), it is desirable to 'compress' the HIP header so that the HIP 553 header only occurs in control packets used to establish or change HIP 554 association state. The actual method for header 'compression' and 555 for matching data packets with existing HIP associations (if any) is 556 defined in separate documents, describing transport formats and 557 methods. All HIP implementations MUST implement, at minimum, the ESP 558 transport format for HIP [I-D.ietf-hip-rfc5202-bis]. 560 4.1. Creating a HIP Association 562 By definition, the system initiating a HIP base exchange is the 563 Initiator, and the peer is the Responder. This distinction is 564 typically forgotten once the base exchange completes, and either 565 party can become the Initiator in future communications. 567 The HIP base exchange serves to manage the establishment of state 568 between an Initiator and a Responder. The first packet, I1, 569 initiates the exchange, and the last three packets, R1, I2, and R2, 570 constitute an authenticated Diffie-Hellman [DIF76] key exchange for 571 session-key generation. In the first two packets, the hosts agree on 572 a set of cryptographic identifiers and algorithms that are then used 573 in and after the exchange. During the Diffie-Hellman key exchange, a 574 piece of keying material is generated. The HIP association keys are 575 drawn from this keying material by using a Key Derivation Function 576 (KDF). If other cryptographic keys are needed, e.g., to be used with 577 ESP, they are expected to be drawn from the same keying material by 578 using the KDF. 580 The Initiator first sends a trigger packet, I1, to the Responder. 581 The packet contains the HIT of the Initiator and possibly the HIT of 582 the Responder, if it is known. Moreover, the I1 packet initializes 583 the negotiation of the Diffie-Hellman group that is used for 584 generating the keying material. Therefore, the I1 packet contains a 585 list of Diffie Hellman Group IDs supported by the Initiator. Note 586 that in some cases it may be possible to replace this trigger packet 587 by some other form of a trigger, in which case the protocol starts 588 with the Responder sending the R1 packet. In such cases, another 589 mechanism to convey the Initiator's supported DH Groups (e.g., by 590 using a default group) must be specified. 592 The second packet, R1, starts the actual authenticated Diffie-Hellman 593 exchange. It contains a puzzle -- a cryptographic challenge that the 594 Initiator must solve before continuing the exchange. The level of 595 difficulty of the puzzle can be adjusted based on level of trust with 596 the Initiator, current load, or other factors. In addition, the R1 597 contains the Responder's Diffie-Hellman parameter and lists of 598 cryptographic algorithms supported by the Responder. Based on these 599 lists, the Initiator can continue, abort, or restart the base 600 exchange with a different selection of cryptographic algorithms. 601 Also, the R1 packet contains a signature that covers selected parts 602 of the message. Some fields are left outside the signature to 603 support pre-created R1s. 605 In the I2 packet, the Initiator MUST display the solution to the 606 received puzzle. Without a correct solution, the I2 message is 607 discarded. The I2 packet also contains a Diffie-Hellman parameter 608 that carries needed information for the Responder. The I2 packet is 609 signed by the Initiator. 611 The R2 packet acknowledges the receipt of the I2 packet and completes 612 the base exchange. The packet is signed by the Responder. 614 The base exchange is illustrated below in Figure 1. The term "key" 615 refers to the Host Identity public key, and "sig" represents a 616 signature using such a key. The packets contain other parameters not 617 shown in this figure. 619 Initiator Responder 621 I1: DH list 622 --------------------------> 623 select precomputed R1 624 R1: puzzle, DH, key, sig 625 <------------------------- 626 check sig remain stateless 627 solve puzzle 628 I2: solution, DH, {key}, sig 629 --------------------------> 630 compute DH check puzzle 631 check sig 632 R2: sig 633 <-------------------------- 634 check sig compute DH 636 Figure 1 638 4.1.1. HIP Puzzle Mechanism 640 The purpose of the HIP puzzle mechanism is to protect the Responder 641 from a number of denial-of-service threats. It allows the Responder 642 to delay state creation until receiving the I2 packet. Furthermore, 643 the puzzle allows the Responder to use a fairly cheap calculation to 644 check that the Initiator is "sincere" in the sense that it has 645 churned enough CPU cycles in solving the puzzle. 647 The puzzle allows a Responder implementation to completely delay 648 session-specific state creation until a valid I2 packet is received. 649 An I2 packet without valid puzzle solution can be rejected 650 immediately once the Responder has checked the solution by computing 651 only one hash function before state is created and CPU-intensive 652 public-key signature verification and Diffie-Hellman key generation 653 are performed. By varying the difficulty of the puzzle, the 654 Responder can frustrate CPU or memory targeted DoS attacks. 656 The Responder can remain stateless and drop most spoofed I2 packets 657 because puzzle calculation is based on the Initiator's Host Identity 658 Tag. The idea is that the Responder has a (perhaps varying) number of 659 pre-calculated R1 packets, and it selects one of these based on the 660 information carried in the I1 packet. When the Responder then later 661 receives the I2 packet, it can verify that the puzzle has been solved 662 using the Initiator's HIT. This makes it impractical for the 663 attacker to first exchange one I1/R1 packet, and then generate a 664 large number of spoofed I2 packets that seemingly come from different 665 HITs. This method does not protect the Responder from an attacker 666 that uses fixed HITs, though. Against such an attacker, a viable 667 approach may be to create a piece of local state, and remember that 668 the puzzle check has previously failed. See Appendix A for one 669 possible implementation. Responder implementations SHOULD include 670 sufficient randomness in the puzzle values so that algorithmic 671 complexity attacks become impossible [CRO03]. 673 The Responder can set the puzzle difficulty for the Initiator, based 674 on its level of trust of the Initiator. Because the puzzle is not 675 included in the signature calculation, the Responder can use pre- 676 calculated R1 packets and include the puzzle just before sending the 677 R1 to the Initiator. The Responder SHOULD use heuristics to 678 determine when it is under a denial-of-service attack, and set the 679 puzzle difficulty value #K appropriately as explained later. 681 4.1.2. Puzzle Exchange 683 The Responder starts the puzzle exchange when it receives an I1 684 packet. The Responder supplies a random number #I, and requires the 685 Initiator to find a number J. To select a proper #J, the Initiator 686 must create the concatenation of #I, the HITs of the parties, and #J, 687 and calculate a hash over this concatenation using the RHASH 688 algorithm. The lowest order #K bits of the result MUST be zeros. 689 The value #K sets the difficulty of the puzzle. 691 To generate a proper number #J, the Initiator will have to generate a 692 number of Js until one produces the hash target of zeros. The 693 Initiator SHOULD give up after exceeding the puzzle Lifetime in the 694 PUZZLE parameter (as described in Section 5.2.4). The Responder 695 needs to re-create the concatenation of #I, the HITs, and the 696 provided #J, and compute the hash once to prove that the Initiator 697 completed its assigned task. 699 To prevent precomputation attacks, the Responder MUST select the 700 number #I in such a way that the Initiator cannot guess it. 701 Furthermore, the construction MUST allow the Responder to verify that 702 the value #I was indeed selected by it and not by the Initiator. See 703 Appendix A for an example on how to implement this. 705 Using the Opaque data field in the PUZZLE (see Section 5.2.4), in an 706 ECHO_REQUEST_SIGNED (see Section 5.2.20) or in an 707 ECHO_REQUEST_UNSIGNED parameter (see Section 5.2.21), the Responder 708 can include some data in R1 that the Initiator MUST copy unmodified 709 in the corresponding I2 packet. The Responder can use the opaque 710 data to transfer a piece of local state information to the Initiator 711 and back, for example to recognize that the I2 is a response to a 712 previously sent R1. The Responder can generate the Opaque data in 713 various ways; e.g., using encryption or hashing with some secret, the 714 sent #I, and possibly using other related data. With the same 715 secret, the received #I (from the I2 packet), and the other related 716 data (if any), the Responder can verify that it has itself sent the 717 #I to the Initiator. The Responder MUST periodically change such a 718 secret. 720 It is RECOMMENDED that the Responder generates new secrets for the 721 puzzle and new R1s once every few minutes. Furthermore, it is 722 RECOMMENDED that the Responder is able to verify valid puzzle 723 solution at least Lifetime seconds after the puzzle secret has been 724 deprecated. This time value guarantees that the puzzle is valid for 725 at least Lifetime and at most 2 * Lifetime seconds. This limits the 726 usability that an old, solved puzzle has to an attacker. Moreover, 727 it avoids problems with the validity of puzzles if the lifetime is 728 relatively short compared to the network delay and the time for 729 solving the puzzle. 731 The puzzle value #I and the solution #J are inputs for deriving the 732 keying material from the Diffie-Hellman key exchange (see 733 Section 6.5). Therefore, a Responder SHOULD NOT use the same puzzle 734 #I with the same DH keys for the same Initiator twice to ensure that 735 the derived keying material differs. Such uniqueness can be 736 achieved, for example, by using a counter as an additional input for 737 generating #I. This counter can be increased for each processed I1 738 packet. The state of the counter can be transmitted in the Opaque 739 data field in the PUZZLE (see Section 5.2.4), in an 740 ECHO_REQUEST_SIGNED (see Section 5.2.20) or in an 741 ECHO_REQUEST_UNSIGNED parameter (see Section 5.2.21) without the need 742 to establish state. 744 NOTE: The protocol developers explicitly considered whether R1 should 745 include a timestamp in order to protect the Initiator from replay 746 attacks. The decision was to NOT include a timestamp to avoid 747 problems with global time synchronization. 749 NOTE: The protocol developers explicitly considered whether a memory 750 bound function should be used for the puzzle instead of a CPU-bound 751 function. The decision was not to use memory-bound functions. 753 4.1.3. Authenticated Diffie-Hellman Protocol with DH Group Negotiation 755 The packets R1, I2, and R2 implement a standard authenticated Diffie- 756 Hellman exchange. The Responder sends one of its public Diffie- 757 Hellman keys and its public authentication key, i.e., its Host 758 Identity, in R1. The signature in the R1 packet allows the Initiator 759 to verify that the R1 has been once generated by the Responder. 760 However, since the R1 is precomputed and therefore does not cover 761 association-specific information in the I1 packet, it does not 762 protect from replay attacks. 764 Before the actual authenticated Diffie-Hellman exchange, the 765 Initiator expresses its preference regarding its choice of the DH 766 groups in the I1 packet. The preference is expressed as a sorted 767 list of DH Group IDs. The I1 packet is not protected by a signature. 768 Therefore, this list is sent in an unauthenticated way to avoid 769 costly computations for processing the I1 packet at the Responder 770 side. Based on the preferences of the Initiator, the Responder sends 771 an R1 packet containing its most suitable public DH value. The 772 Responder also attaches a list of its own preferences to the R1 to 773 convey the basis for the DH group selection to the Initiator. This 774 list is carried in the signed part of the R1 packet. If the choice 775 of the DH group value in the R1 does not match the preferences of the 776 Initiator and the Responder, the Initiator can detect that the list 777 of DH Group IDs in the I1 was manipulated (see below for details). 779 If none of the DH Group IDs in the I1 packet is supported by the 780 Responder, the Responder selects the DH Group most suitable for it 781 regardless of the Initiator's preference. It then sends the R1 782 containing this DH Group and its list of supported DH Group IDs to 783 the Initiator. 785 When the Initiator receives an R1, it receives one of the Responder's 786 public Diffie-Hellman values and the list of DH Group IDs supported 787 by the Responder. This list is covered by the signature in the R1 788 packet to avoid forgery. The Initiator compares the Group ID of the 789 public DH value in the R1 packet to the list of supported DH Group 790 IDs in the R1 packets and to its own preferences expressed in the 791 list of supported DH Group IDs. The Initiator continues the BEX only 792 if the Group ID of the public DH value of the Responder is the most 793 preferred of the IDs supported by both the Initiator and Responder. 794 Otherwise, the communication is subject of a downgrade attack and the 795 Initiator MUST either restart the base exchange with a new I1 packet 796 or abort the base exchange. If the Responder's choice of the DH 797 Group is not supported by the Initiator, the Initiator MAY abort the 798 handshake or send a new I1 packet with a different list of supported 799 DH Groups. However, the Initiator MUST verify the signature of the 800 R1 packet before restarting or aborting the handshake. It MUST 801 silently ignore the R1 packet if the signature is not valid. 803 If the preferences regarding the DH Group ID match, the Initiator 804 computes the Diffie-Hellman session key (Kij). The Initiator creates 805 a HIP association using keying material from the session key (see 806 Section 6.5), and may use the HIP association to encrypt its public 807 authentication key, i.e., the Host Identity. The resulting I2 packet 808 contains the Initiator's Diffie-Hellman key and its (optionally 809 encrypted) public authentication key. The signature of the I2 810 message covers all parameters of the signed parameter ranges (see 811 Section 5.2) in the packet without exceptions as in the R1. 813 The Responder extracts the Initiator's Diffie-Hellman public key from 814 the I2 packet, computes the Diffie-Hellman session key, creates a 815 corresponding HIP association, and decrypts the Initiator's public 816 authentication key. It can then verify the signature using the 817 authentication key. 819 The final message, R2, completes the BEX and protects the Initiator 820 against replay attacks because the Responder uses the shared key from 821 the Diffie-Hellman exchange to create an HMAC as well as uses the 822 private key of its Host Identity to sign the packet contents. 824 4.1.4. HIP Replay Protection 826 The HIP protocol includes the following mechanisms to protect against 827 malicious packet replays. Responders are protected against replays 828 of I1 packets by virtue of the stateless response to I1 packets with 829 pre-signed R1 messages. Initiators are protected against R1 replays 830 by a monotonically increasing "R1 generation counter" included in the 831 R1. Responders are protected against replays of forged I2 packets by 832 the puzzle mechanism (see Section 4.1.1 above), and optional use of 833 opaque data. Hosts are protected against replays of R2 packets and 834 UPDATEs by use of a less expensive HMAC verification preceding the 835 HIP signature verification. 837 The R1 generation counter is a monotonically increasing 64-bit 838 counter that may be initialized to any value. The scope of the 839 counter MAY be system-wide but there SHOULD be a separate counter for 840 each Host Identity, if there is more than one local host identity. 841 The value of this counter SHOULD be preserved across system reboots 842 and invocations of the HIP base exchange. This counter indicates the 843 current generation of puzzles. Implementations MUST accept puzzles 844 from the current generation and MAY accept puzzles from earlier 845 generations. A system's local counter MUST be incremented at least 846 as often as every time old R1s cease to be valid. The local counter 847 SHOULD never be decremented, otherwise the host exposes its peers to 848 the replay of previously generated, higher numbered R1s. 850 The R1 generation counter may roll over or may become reset. It is 851 important for an Initiator to be robust to the loss of state about 852 the R1 generation counter of a peer, or to a reset of the peer's 853 counter. It is recommended that, when choosing between multiple R1s, 854 the Initiator prefer to use the R1 that corresponds to the current R1 855 generation counter, but that if it is unable to make progress with 856 that R1, the Initiator may try the other R1s beginning with the R1 857 packet with the highest counter. 859 A host may receive more than one R1, either due to sending multiple 860 I1 packets (see Section 6.6.1) or due to a replay of an old R1. When 861 sending multiple I1 packets to the same host, an Initiator SHOULD 862 wait for a small amount of time (a reasonable time may be 2 * 863 expected RTT) after the first R1 reception to allow possibly multiple 864 R1s to arrive, and it SHOULD respond to an R1 among the set with the 865 largest R1 generation counter. If an Initiator is processing an R1 866 or has already sent an I2 packet (still waiting for the R2 packet) 867 and it receives another R1 with a larger R1 generation counter, it 868 MAY elect to restart R1 processing with the fresher R1, as if it were 869 the first R1 to arrive. 871 4.1.5. Refusing a HIP Base Exchange 873 A HIP-aware host may choose not to accept a HIP base exchange. If 874 the host's policy is to only be an Initiator, it should begin its own 875 HIP base exchange. A host MAY choose to have such a policy since 876 only the privacy of the Initiator's HI is protected in the exchange. 877 It should be noted that such behavior can introduce the risk of a 878 race condition if each host's policy is to only be an Initiator, at 879 which point the HIP base exchange will fail. 881 If the host's policy does not permit it to enter into a HIP exchange 882 with the Initiator, it should send an ICMP 'Destination Unreachable, 883 Administratively Prohibited' message. A more complex HIP packet is 884 not used here as it actually opens up more potential DoS attacks than 885 a simple ICMP message. A HIP NOTIFY message is not used because no 886 HIP session exists between the two hosts at that time. 888 4.1.6. Aborting a HIP Base Exchange 890 Two HIP hosts may encounter situations in which they cannot complete 891 a HIP base exchange because of insufficient support for cryptographic 892 algorithms, in particular the HIT Suites and DH Groups. After 893 receiving the R1 packet, the Initiator can determine whether the 894 Responder supports the required cryptographic operations to 895 successfully establish a HIP association. The Initiator can abort 896 the BEX silently after receiving an R1 packet that indicates an 897 unsupported set of algorithms. The specific conditions are described 898 below. 900 The R1 packet contains a signed list of HIT Suite IDs as supported by 901 the Responder. Therefore, the Initiator can determine whether its 902 source HIT is supported by the Responder. If the HIT Suite ID of the 903 Initiator's HIT is not contained in the list of HIT Suites in the R1, 904 the Initiator MAY abort the handshake silently or MAY restart the 905 handshake with a new I1 packet that contains a source HIT supported 906 by the Responder. 908 During the Handshake, the Initiator and the Responder agree on a 909 single DH Group. The Responder selects the DH Group and its DH 910 public value in the R1 based on the list of DH Suite IDs in the I1 911 packet. If the responder supports none of the DH Groups requested by 912 the Initiator, the Responder selects an arbitrary DH and replies with 913 an R1 containing its list of supported DH Group IDs. In such case, 914 the Initiator receives an R1 packet containing the DH public value 915 for an unrequested DH Group and also the Responder's DH Group list in 916 the signed part of the R1 packet. At this point, the Initiator MAY 917 abort the handshake or MAY restart the handshake by sending a new I1 918 packet containing a selection of DH Group IDs that is supported by 919 the Responder. 921 4.1.7. HIP Downgrade Protection 923 In a downgrade attack, an attacker attempts to unnoticeably 924 manipulate the packets of an Initiator and/or a Responder to 925 influence the result of the cryptographic negotiations in the BEX to 926 its favor. As a result, the victims select weaker cryptographic 927 algorithms than they would otherwise have selected without the 928 attacker's interference. Downgrade attacks can only be successful if 929 they remain un-detected by the victims and the victims falsely assume 930 a secure communication channel. 932 In HIP, almost all packet parameters related to cryptographic 933 negotiations are covered by signatures. These parameters cannot be 934 directly manipulated in a downgrade attack without invalidating the 935 signature. However, signed packets can be subject to replay attacks. 936 In such a replay attack, the attacker could use an old BEX packet 937 with an outdated and weak selection of cryptographic algorithms and 938 replay it instead of a more recent packet with a collection of 939 stronger cryptographic algorithms. Signed packets that could be 940 subject to this replay attack are the R1 and I2 packet. However, 941 replayed R1 and I2 packets cannot be used to successfully establish a 942 HIP BEX because these packets also contain the public DH values of 943 the Initiator and the Responder. Old DH values from replayed packets 944 lead to invalid keying material and mismatching shared secrets 945 because the attacker is unable to derive valid keying material from 946 the DH public keys in the R1 and cannot generate a valid HMAC and 947 signature for a replayed I2. 949 In contrast to the first version of HIP [RFC5201],the version 2 of 950 HIP defined in this document begins the negotiation of the DH Groups 951 already in the first BEX packet, the I1. The I1 packet is, by 952 intention, not protected by a signature to avoid CPU-intensive 953 cryptographic operations for processing floods of I1 packets targeted 954 at the Responder. Hence, the list of DH Group IDs in the I1 packet 955 is vulnerable to forgery and manipulation. To thwart an unnoticed 956 manipulation of the I1 packet, the Responder chooses the DH Group 957 deterministically and includes its own list of DH Group IDs in the 958 signed part of the R1 packet. The Initiator can detect an attempted 959 downgrade attack by comparing the list of DH Group IDs in the R1 960 packet to its own preferences in the I1 packet. If the choice of the 961 DH Group in the R1 packet does not equal to the best match of the two 962 lists (the highest priority DH ID of the Responder that is present in 963 the Initiator's DH list), the Initiator can conclude that its list in 964 the I1 packet was altered by an attacker. In this case, the 965 Initiator can restart or abort the BEX. As mentioned before, the 966 detection of the downgrade attack is sufficient to prevent it. 968 4.1.8. HIP Opportunistic Mode 970 It is possible to initiate a HIP BEX even if the Responder's HI (and 971 HIT) is unknown. In this case, the initial I1 packet contains all 972 zeros as the destination HIT. This kind of connection setup is 973 called opportunistic mode. 975 The Responder may have multiple HITs due to multiple supported HIT 976 Suites. Since the Responder's HIT Suite in the opportunistic mode is 977 not determined by the destination HIT of the I1 packet, the Responder 978 can freely select a HIT of any HIT Suite. The complete set of HIT 979 Suites supported by the Initiator is not known to the Responder. 980 Therefore, the Responder SHOULD should select its HIT from the same 981 HIT Suite as the Initiator's HIT (indicated by the HIT suite 982 information in the OGA field of the Initiator's HIT) because this HIT 983 Suite is obviously supported by the Initiator. If the Responder 984 selects a different HIT that is not supported by the Initiator, the 985 Initiator MAY restart the BEX with an I1 packet with a source HIT 986 that is contained in the list of the Responder's HIT Suites in the R1 987 packet. 989 Note that the Initiator cannot verify the signature of the R1 packet 990 if the Responder's HIT Suite is not supported. Therefore, the 991 Initiator MUST treat R1 packets with unsupported Responder HITs as 992 potentially forged and MUST NOT use any parameters from the 993 unverified R1 besides the HIT Suite List. Moreover, an Initiator 994 that uses an unverified HIT Suite List from an R1 packet to determine 995 a possible source HIT MUST verify that the HIT_SUITE_LIST in the 996 first unverified R1 packet matches the HIT_SUITE_LIST in the second 997 R1 packet for which the Initiator supports the signature algorithm. 998 The Initiator MUST restart the BEX with a new I1 packet for which the 999 algorithm was mentioned in the verifiable R1 if the two lists do not 1000 match. This procedure is necessary to mitigate downgrade attacks. 1002 There are both security and API issues involved with the 1003 opportunistic mode. These issues are described in the reminder of 1004 this section. 1006 Given that the Responder's HI is not known by the Initiator, there 1007 must be suitable API calls that allow the Initiator to request, 1008 directly or indirectly, that the underlying system initiates the HIP 1009 base exchange solely based on locators. The Responder's HI will be 1010 tentatively available in the R1 packet, and in an authenticated form 1011 once the R2 packet has been received and verified. Hence, the 1012 Responder's HIT could be communicated to the application via new API 1013 mechanisms. However, with a backwards-compatible API the application 1014 sees only the locators used for the initial contact. Depending on 1015 the desired semantics of the API, this can raise the following 1016 issues: 1018 o The actual locators may later change if an UPDATE message is used, 1019 even if from the API perspective the session still appears to be 1020 between two specific locators. However, the locator update is 1021 still secure and the session is still between the same nodes. 1023 o Different sessions between the same two locators may result in 1024 connections to different nodes, if the implementation no longer 1025 remembers which identifier the peer had in an earlier session. 1026 This is possible when the peer's locator has changed for 1027 legitimate reasons or when an attacker pretends to be a node that 1028 has the peer's locator. Therefore, when using opportunistic mode, 1029 HIP implementations MUST NOT place any expectation that the peer's 1030 HI returned in the R1 message matches any HI previously seen from 1031 that address. 1033 If the HIP implementation and application do not have the same 1034 understanding of what constitutes a session, this may even happen 1035 within the same session. For instance, an implementation may not 1036 know when HIP state can be purged for UDP-based applications. 1038 o As with all HIP base exchanges, the handling of locator-based or 1039 interface-based policy is unclear for HIP in opportunistic mode. 1040 An application may create a connection to a specific locator 1041 because the application has knowledge of the security properties 1042 along the network to that locator. If one of the nodes moves and 1043 the locators are updated, these security properties may not be 1044 maintained. Depending on the security policy of the application, 1045 this may be a problem. This is an area of ongoing study. As an 1046 example, there is work to create an API that applications can use 1047 to specify their security requirements in a similar context 1048 [I-D.ietf-btns-c-api]. 1050 In addition, the following security considerations apply. The 1051 generation counter mechanism will be less efficient in protecting 1052 against replays of the R1 packet, given that the Responder can choose 1053 a replay that uses an arbitrary HI, not just the one given in the I1 1054 packet. 1056 More importantly, the opportunistic exchange is vulnerable to man-in- 1057 the-middle attacks, because the Initiator does not have any public 1058 key information about the peer. To assess the impacts of this 1059 vulnerability, we compare it to vulnerabilities in current, non-HIP- 1060 capable communications. 1062 An attacker on the path between the two peers can insert itself as a 1063 man-in-the-middle by providing its own identifier to the Initiator 1064 and then initiating another HIP session towards the Responder. For 1065 this to be possible, the Initiator must employ opportunistic mode, 1066 and the Responder must be configured to accept a connection from any 1067 HIP-enabled node. 1069 An attacker outside the path will be unable to do so, given that it 1070 cannot respond to the messages in the base exchange. 1072 These security properties are characteristic also of communications 1073 in the current Internet. A client contacting a server without 1074 employing end-to-end security may find itself talking to the server 1075 via a man-in-the-middle, assuming again that the server is willing to 1076 talk to anyone. 1078 If end-to-end security is in place, then the worst that can happen in 1079 both the opportunistic HIP and non-HIP (normal IP) cases is denial- 1080 of-service; an entity on the path can disrupt communications, but 1081 will be unable to successfully insert itself as a man-in-the-middle. 1083 However, once the opportunistic exchange has successfully completed, 1084 HIP provides confidentiality and integrity protection for the 1085 communications, and can securely change the locators of the 1086 endpoints. 1088 As a result, it is believed that the HIP opportunistic mode is at 1089 least as secure as current IP. 1091 4.2. Updating a HIP Association 1093 A HIP association between two hosts may need to be updated over time. 1094 Examples include the need to rekey expiring security associations, 1095 add new security associations, or change IP addresses associated with 1096 hosts. The UPDATE packet is used for those and other similar 1097 purposes. This document only specifies the UPDATE packet format and 1098 basic processing rules, with mandatory parameters. The actual usage 1099 is defined in separate specifications. 1101 HIP provides a general purpose UPDATE packet, which can carry 1102 multiple HIP parameters, for updating the HIP state between two 1103 peers. The UPDATE mechanism has the following properties: 1105 UPDATE messages carry a monotonically increasing sequence number 1106 and are explicitly acknowledged by the peer. Lost UPDATEs or 1107 acknowledgments may be recovered via retransmission. Multiple 1108 UPDATE messages may be outstanding under certain circumstances. 1110 UPDATE is protected by both HIP_MAC and HIP_SIGNATURE parameters, 1111 since processing UPDATE signatures alone is a potential DoS attack 1112 against intermediate systems. 1114 UPDATE packets are explicitly acknowledged by the use of an 1115 acknowledgment parameter that echoes an individual sequence number 1116 received from the peer. A single UPDATE packet may contain both a 1117 sequence number and one or more acknowledgment numbers (i.e., 1118 piggybacked acknowledgment(s) for the peer's UPDATE). 1120 The UPDATE packet is defined in Section 5.3.5. 1122 4.3. Error Processing 1124 HIP error processing behavior depends on whether or not there exists 1125 an active HIP association. In general, if a HIP association exists 1126 between the sender and receiver of a packet causing an error 1127 condition, the receiver SHOULD respond with a NOTIFY packet. On the 1128 other hand, if there are no existing HIP associations between the 1129 sender and receiver, or the receiver cannot reasonably determine the 1130 identity of the sender, the receiver MAY respond with a suitable ICMP 1131 message; see Section 5.4 for more details. 1133 The HIP protocol and state machine are designed to recover from one 1134 of the parties crashing and losing its state. The following 1135 scenarios describe the main use cases covered by the design. 1137 No prior state between the two systems. 1139 The system with data to send is the Initiator. The process 1140 follows the standard four-packet base exchange, establishing 1141 the HIP association. 1143 The system with data to send has no state with the receiver, but 1144 the receiver has a residual HIP association. 1146 The system with data to send is the Initiator. The Initiator 1147 acts as in no prior state, sending an I1 packet and receiving 1148 an R1 packet. When the Responder receives a valid I2 packet, 1149 the old association is 'discovered' and deleted, and the new 1150 association is established. 1152 The system with data to send has a HIP association, but the 1153 receiver does not. 1155 The system sends data on the outbound user data security 1156 association. The receiver 'detects' the situation when it 1157 receives a user data packet that it cannot match to any HIP 1158 association. The receiving host MUST discard this packet. 1160 Optionally, the receiving host MAY send an ICMP packet, with 1161 the type Parameter Problem, to inform the sender that the HIP 1162 association does not exist (see Section 5.4), and it MAY 1163 initiate a new HIP BEX. However, responding with these 1164 optional mechanisms is implementation or policy dependent. 1166 4.4. HIP State Machine 1168 The HIP protocol itself has little state. In the HIP base exchange, 1169 there is an Initiator and a Responder. Once the security 1170 associations (SAs) are established, this distinction is lost. If the 1171 HIP state needs to be re-established, the controlling parameters are 1172 which peer still has state and which has a datagram to send to its 1173 peer. The following state machine attempts to capture these 1174 processes. 1176 The state machine is symmetric and is presented in a single system 1177 view, representing either an Initiator or a Responder. The state 1178 machine is not a full representation of the processing logic. 1179 Additional processing rules are presented in the packet definitions. 1180 Hence, both are needed to completely implement HIP. 1182 This document extends the state machine as defined in [RFC5201] and 1183 introduces a restart option to allow for the negotiation of 1184 cryptographic algorithms. The extension to the previous state 1185 machine in [RFC5201] is a transition from state I1-SENT to I1-SENT - 1186 the restart option. An Initiator is required to restart the HIP base 1187 exchange if the Responder does not support the HIT Suite of the 1188 Initiator. In this case, the Initiator restarts the HIP base 1189 exchange by sending a new I1 packet with a source HIT supported by 1190 the Responder. 1192 Implementors must understand that the state machine, as described 1193 here, is informational. Specific implementations are free to 1194 implement the actual processing logic differently. Section 6 1195 describes the packet processing rules in more detail. This state 1196 machine focuses on the HIP I1, R1, I2, and R2 packets only. New 1197 states and state transitions may be introduced by mechanisms in other 1198 specifications (such as mobility and multihoming). 1200 4.4.1. State Machine Terminology 1202 Unused Association Lifetime (UAL): Implementation-specific time for 1203 which, if no packet is sent or received for this time interval, a 1204 host MAY begin to tear down an active HIP association. 1206 Maximum Segment Lifetime (MSL): Maximum time that a TCP segment is 1207 expected to spend in the network. 1209 Exchange Complete (EC): Time that the host spends at the R2-SENT 1210 state before it moves to the ESTABLISHED state. The time is n * 1211 I2 retransmission timeout, where n is about I2_RETRIES_MAX. 1213 Receive ANYOTHER: Any received packet for which no state 1214 transitions or processing rules are defined for a given state. 1216 4.4.2. HIP States 1218 +---------------------+---------------------------------------------+ 1219 | State | Explanation | 1220 +---------------------+---------------------------------------------+ 1221 | UNASSOCIATED | State machine start | 1222 | | | 1223 | I1-SENT | Initiating base exchange | 1224 | | | 1225 | I2-SENT | Waiting to complete base exchange | 1226 | | | 1227 | R2-SENT | Waiting to complete base exchange | 1228 | | | 1229 | ESTABLISHED | HIP association established | 1230 | | | 1231 | CLOSING | HIP association closing, no data can be | 1232 | | sent | 1233 | | | 1234 | CLOSED | HIP association closed, no data can be sent | 1235 | | | 1236 | E-FAILED | HIP base exchange failed | 1237 +---------------------+---------------------------------------------+ 1239 Table 1: HIP States 1241 4.4.3. HIP State Processes 1243 System behavior in state UNASSOCIATED, Table 2. 1245 +---------------------+---------------------------------------------+ 1246 | Trigger | Action | 1247 +---------------------+---------------------------------------------+ 1248 | User data to send, | Send I1 and go to I1-SENT | 1249 | requiring a new HIP | | 1250 | association | | 1251 | | | 1252 | Receive I1 | Send R1 and stay at UNASSOCIATED | 1253 | | | 1254 | Receive I2, process | If successful, send R2 and go to R2-SENT | 1255 | | | 1256 | | If fail, stay at UNASSOCIATED | 1257 | | | 1258 | Receive user data | Optionally send ICMP as defined in | 1259 | for an unknown HIP | Section 5.4 and stay at UNASSOCIATED | 1260 | association | | 1261 | | | 1262 | Receive CLOSE | Optionally send ICMP Parameter Problem and | 1263 | | stay at UNASSOCIATED | 1264 | Receive ANYOTHER | Drop and stay at UNASSOCIATED | 1265 +---------------------+---------------------------------------------+ 1267 Table 2: UNASSOCIATED - Start state 1269 System behavior in state I1-SENT, Table 3. 1271 +---------------------+---------------------------------------------+ 1272 | Trigger | Action | 1273 +---------------------+---------------------------------------------+ 1274 | Receive I1 from | If the local HIT is smaller than the peer | 1275 | Responder | HIT, drop I1 and stay at I1-SENT (see | 1276 | | Section 6.5 for HIT comparison) | 1277 | | | 1278 | | If the local HIT is greater than the peer | 1279 | | HIT, send R1 and stay at I1-SENT | 1280 | | | 1281 | Receive I2, process | If successful, send R2 and go to R2-SENT | 1282 | | | 1283 | | If fail, stay at I1-SENT | 1284 | | | 1285 | Receive R1, process | If the HIT Suite of the local HIT is not | 1286 | | supported by the peer, select supported | 1287 | | local HIT, send I1 and stay at I1-SENT | 1288 | | | 1289 | | If successful, send I2 and go to I2-SENT | 1290 | | | 1291 | | If fail, stay at I1-SENT | 1292 | | | 1293 | Receive ANYOTHER | Drop and stay at I1-SENT | 1294 | | | 1295 | Timeout | Increment timeout counter | 1296 | | | 1297 | | If counter is less than I1_RETRIES_MAX, | 1298 | | send I1 and stay at I1-SENT | 1299 | | | 1300 | | If counter is greater than I1_RETRIES_MAX, | 1301 | | go to E-FAILED | 1302 +---------------------+---------------------------------------------+ 1304 Table 3: I1-SENT - Initiating the HIP Base Exchange 1306 System behavior in state I2-SENT, Table 4. 1308 +---------------------+---------------------------------------------+ 1309 | Trigger | Action | 1310 +---------------------+---------------------------------------------+ 1311 | Receive I1 | Send R1 and stay at I2-SENT | 1312 | | | 1313 | Receive R1, process | If successful, send I2 and stay at I2-SENT | 1314 | | | 1315 | | If fail, stay at I2-SENT | 1316 | | | 1317 | Receive I2, process | If successful and local HIT is smaller than | 1318 | | the peer HIT, drop I2 and stay at I2-SENT | 1319 | | | 1320 | | If successful and local HIT is greater than | 1321 | | the peer HIT, send R2 and go to R2-SENT | 1322 | | | 1323 | | If fail, stay at I2-SENT | 1324 | | | 1325 | Receive R2, process | If successful, go to ESTABLISHED | 1326 | | | 1327 | | If fail, stay at I2-SENT | 1328 | | | 1329 | Receive CLOSE, | If successful, send CLOSE_ACK and go to | 1330 | process | CLOSED | 1331 | | | 1332 | | If fail, stay at I2-SENT | 1333 | | | 1334 | Receive ANYOTHER | Drop and stay at I2-SENT | 1335 | | | 1336 | Timeout | Increment timeout counter | 1337 | | | 1338 | | If counter is less than I2_RETRIES_MAX, | 1339 | | send I2 and stay at I2-SENT | 1340 | | | 1341 | | If counter is greater than I2_RETRIES_MAX, | 1342 | | go to E-FAILED | 1343 +---------------------+---------------------------------------------+ 1345 Table 4: I2-SENT - Waiting to finish the HIP Base Exchange 1347 System behavior in state R2-SENT, Table 5. 1349 +---------------------+---------------------------------------------+ 1350 | Trigger | Action | 1351 +---------------------+---------------------------------------------+ 1352 | Receive I1 | Send R1 and stay at R2-SENT | 1353 | | | 1354 | Receive I2, process | If successful, send R2 and stay at R2-SENT | 1355 | | | 1356 | | If fail, stay at R2-SENT | 1357 | | | 1358 | Receive R1 | Drop and stay at R2-SENT | 1359 | | | 1360 | Receive R2 | Drop and stay at R2-SENT | 1361 | | | 1362 | Receive data or | Move to ESTABLISHED | 1363 | UPDATE | | 1364 | | | 1365 | Exchange Complete | Move to ESTABLISHED | 1366 | Timeout | | 1367 | | | 1368 | Receive CLOSE, | If successful, send CLOSE_ACK and go to | 1369 | process | CLOSED | 1370 | | | 1371 | | If fail, stay at ESTABLISHED | 1372 | | | 1373 | Receive CLOSE_ACK | Drop and stay at R2-SENT | 1374 | | | 1375 | Receive NOTIFY | Process and stay at R2-SENT | 1376 +---------------------+---------------------------------------------+ 1378 Table 5: R2-SENT - Waiting to finish HIP 1380 System behavior in state ESTABLISHED, Table 6. 1382 +---------------------+---------------------------------------------+ 1383 | Trigger | Action | 1384 +---------------------+---------------------------------------------+ 1385 | Receive I1 | Send R1 and stay at ESTABLISHED | 1386 | | | 1387 | Receive I2 | Process with puzzle and possible Opaque | 1388 | | data verification | 1389 | | | 1390 | | If successful, send R2, drop old HIP | 1391 | | association, establish a new HIP | 1392 | | association and go to R2-SENT | 1393 | | | 1394 | | If fail, stay at ESTABLISHED | 1395 | | | 1396 | Receive R1 | Drop and stay at ESTABLISHED | 1397 | | | 1398 | Receive R2 | Drop and stay at ESTABLISHED | 1399 | | | 1400 | Receive user data | Process and stay at ESTABLISHED | 1401 | for HIP association | | 1402 | | | 1403 | No packet | Send CLOSE and go to CLOSING | 1404 | sent/received | | 1405 | during UAL minutes | | 1406 | | | 1407 | Receive UPDATE | Process and stay at ESTABLISHED | 1408 | | | 1409 | Receive CLOSE, | If successful, send CLOSE_ACK and go to | 1410 | process | CLOSED | 1411 | | | 1412 | | If fail, stay at ESTABLISHED | 1413 | | | 1414 | Receive CLOSE_ACK | Drop and stay at ESTABLISHED | 1415 | | | 1416 | Receive NOTIFY | Process and stay at ESTABLISHED | 1417 +---------------------+---------------------------------------------+ 1419 Table 6: ESTABLISHED - HIP association established 1421 System behavior in state CLOSING, Table 7. 1423 +---------------------+---------------------------------------------+ 1424 | Trigger | Action | 1425 +---------------------+---------------------------------------------+ 1426 | User data to send, | Send I1 and stay at CLOSING | 1427 | requires the | | 1428 | creation of another | | 1429 | incarnation of the | | 1430 | HIP association | | 1431 | | | 1432 | Receive I1 | Send R1 and stay at CLOSING | 1433 | | | 1434 | Receive I2, process | If successful, send R2 and go to R2-SENT | 1435 | | | 1436 | | If fail, stay at CLOSING | 1437 | | | 1438 | Receive R1, process | If successful, send I2 and go to I2-SENT | 1439 | | | 1440 | | If fail, stay at CLOSING | 1441 | | | 1442 | Receive CLOSE, | If successful, send CLOSE_ACK, discard | 1443 | process | state and go to CLOSED | 1444 | | | 1445 | | If fail, stay at CLOSING | 1446 | | | 1447 | Receive CLOSE_ACK, | If successful, discard state and go to | 1448 | process | UNASSOCIATED | 1449 | | | 1450 | | If fail, stay at CLOSING | 1451 | | | 1452 | Receive ANYOTHER | Drop and stay at CLOSING | 1453 | | | 1454 | Timeout | Increment timeout sum and reset timer. If | 1455 | | timeout sum is less than UAL+MSL minutes, | 1456 | | retransmit CLOSE and stay at CLOSING | 1457 | | | 1458 | | If timeout sum is greater than UAL+MSL | 1459 | | minutes, go to UNASSOCIATED | 1460 +---------------------+---------------------------------------------+ 1462 Table 7: CLOSING - HIP association has not been used for UAL minutes 1463 System behavior in state CLOSED, Table 8. 1465 +---------------------+---------------------------------------------+ 1466 | Trigger | Action | 1467 +---------------------+---------------------------------------------+ 1468 | Datagram to send, | Send I1, and stay at CLOSED | 1469 | requires the | | 1470 | creation of another | | 1471 | incarnation of the | | 1472 | HIP association | | 1473 | | | 1474 | Receive I1 | Send R1 and stay at CLOSED | 1475 | | | 1476 | Receive I2, process | If successful, send R2 and go to R2-SENT | 1477 | | | 1478 | | If fail, stay at CLOSED | 1479 | | | 1480 | Receive R1, process | If successful, send I2 and go to I2-SENT | 1481 | | | 1482 | | If fail, stay at CLOSED | 1483 | | | 1484 | Receive CLOSE, | If successful, send CLOSE_ACK, stay at | 1485 | process | CLOSED | 1486 | | | 1487 | | If fail, stay at CLOSED | 1488 | | | 1489 | Receive CLOSE_ACK, | If successful, discard state and go to | 1490 | process | UNASSOCIATED | 1491 | | | 1492 | | If fail, stay at CLOSED | 1493 | | | 1494 | Receive ANYOTHER | Drop and stay at CLOSED | 1495 | | | 1496 | Timeout (UAL+2MSL) | Discard state, and go to UNASSOCIATED | 1497 +---------------------+---------------------------------------------+ 1499 Table 8: CLOSED - CLOSE_ACK sent, resending CLOSE_ACK if necessary 1501 System behavior in state E-FAILED, Table 9. 1503 +-------------------------+-----------------------------------------+ 1504 | Trigger | Action | 1505 +-------------------------+-----------------------------------------+ 1506 | Wait for | Go to UNASSOCIATED. Re-negotiation is | 1507 | implementation-specific | possible after moving to UNASSOCIATED | 1508 | time | state. | 1509 +-------------------------+-----------------------------------------+ 1510 Table 9: E-FAILED - HIP failed to establish association with peer 1512 4.4.4. Simplified HIP State Diagram 1514 The following diagram (Figure 2) shows the major state transitions. 1515 Transitions based on received packets implicitly assume that the 1516 packets are successfully authenticated or processed. 1518 +--+ +----------------------------+ 1519 recv I1, send R1 | | | | 1520 | v v | 1521 +--------------+ recv I2, send R2 | 1522 +----------------| UNASSOCIATED |----------------+ | 1523 datagram| +--+ +--------------+ | | 1524 to send,| | | Alg. not supported, | | 1525 send I1| | | send I1 | | 1526 v | v | | 1527 +---------+ recv I2, send R2 | | 1528 +---->| I1-SENT |--------------------------------------+ | | 1529 | +---------+ +----------------------+ | | | 1530 | | recv R2, | recv I2, send R2 | | | | 1531 | v send I2 | v v v | 1532 | +---------+ | +---------+ | 1533 | +--->| I2-SENT |----------+ +--------------| R2-SENT |<---+ | 1534 | | +---------+ | +---------+ | | 1535 | | | |recv R2 | data or| | | 1536 | |recv R1, | | | EC timeout| | | 1537 | |send I2 +--|-----------------+ | receive I2,| | 1538 | | | | +-------------+ | send R2| | 1539 | | | +------>| ESTABLISHED |<----------+ | | 1540 | | | +-------------+ | | 1541 | | | | | | receive I2, send R2 | | 1542 | | +------------+ | +-------------------------------+ | 1543 | | | +-----------+ | | 1544 | | | no packet sent/received| +---+ | | 1545 | | | for UAL min, send CLOSE| | |timeout | | 1546 | | | v v |(UAL+MSL) | | 1547 | | | +---------+ |retransmit | | 1548 +--|----------|------------------------| CLOSING |-+CLOSE | | 1549 | | +---------+ | | 1550 | | | | | | | | 1551 +----------|-------------------------+ | | +----------------+ | 1552 | | +-----------+ +------------------|--+ 1553 | | |recv CLOSE, recv CLOSE_ACK | | 1554 | +-------------+ |send CLOSE_ACK or timeout | | 1555 | recv CLOSE, | | (UAL+MSL) | | 1556 | send CLOSE_ACK v v | | 1557 | +--------+ receive I2, send R2 | | 1558 +---------------------| CLOSED |------------------------------+ | 1559 +--------+ | 1560 ^ | | | 1561 recv CLOSE, send CLOSE_ACK| | | timeout (UAL+2MSL) | 1562 +-+ +------------------------------------+ 1564 Figure 2 1566 4.5. User Data Considerations 1568 4.5.1. TCP and UDP Pseudo-Header Computation for User Data 1570 When computing TCP and UDP checksums on user data packets that flow 1571 through sockets bound to HITs, the IPv6 pseudo-header format 1572 [RFC2460] MUST be used, even if the actual addresses in the header of 1573 the packet are IPv4 addresses. Additionally, the HITs MUST be used 1574 in place of the IPv6 addresses in the IPv6 pseudo-header. Note that 1575 the pseudo-header for actual HIP payloads is computed differently; 1576 see Section 5.1.1. 1578 4.5.2. Sending Data on HIP Packets 1580 Other documents may define how to include user data in various HIP 1581 packets. However, currently the HIP header is a terminal header, and 1582 not followed by any other headers. 1584 4.5.3. Transport Formats 1586 The actual data transmission format, used for user data after the HIP 1587 base exchange, is not defined in this document. Such transport 1588 formats and methods are described in separate specifications. All 1589 HIP implementations MUST implement, at minimum, the ESP transport 1590 format for HIP [I-D.ietf-hip-rfc5202-bis]. The transport format to 1591 be chosen is negotiated in the base exchange. The Responder 1592 expresses its preference of the transport format in the 1593 TRANSPORT_FORMAT_LIST in the R1 packet and the Initiator selects one 1594 transform and adds the respective HIP parameter to the I2 packet. 1596 4.5.4. Reboot, Timeout, and Restart of HIP 1598 Simulating a loss of state is a potential DoS attack. The following 1599 process has been crafted to manage state recovery without presenting 1600 a DoS opportunity. 1602 If a host reboots or the HIP association times out, it has lost its 1603 HIP state. If the host that lost state has a datagram to send to the 1604 peer, it simply restarts the HIP base exchange. After the base 1605 exchange has completed, the Initiator can create a new payload 1606 association and start sending data. The peer does not reset its 1607 state until it receives a valid I2 packet. 1609 If a system receives a user data packet that cannot be matched to any 1610 existing HIP association, it is possible that it has lost the state 1611 and its peer has not. It MAY send an ICMP packet with the Parameter 1612 Problem type, and with the pointer pointing to the referred HIP- 1613 related association information. Reacting to such traffic depends on 1614 the implementation and the environment where the implementation is 1615 used. 1617 If the host, that apparently has lost its state, decides to restart 1618 the HIP base exchange, it sends an I1 packet to the peer. After the 1619 base exchange has been completed successfully, the Initiator can 1620 create a new HIP association and the peer drops its old payload 1621 associations and creates a new one. 1623 4.6. Certificate Distribution 1625 This document does not define how to use certificates or how to 1626 transfer them between hosts. These functions are expected to be 1627 defined in a future specification as for HIP Version 1 [RFC6253]. A 1628 parameter type value, meant to be used for carrying certificates, is 1629 reserved, though: CERT, Type 768; see Section 5.2. 1631 5. Packet Formats 1633 5.1. Payload Format 1635 All HIP packets start with a fixed header. 1637 0 1 2 3 1638 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1640 | Next Header | Header Length |0| Packet Type |Version| RES.|1| 1641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1642 | Checksum | Controls | 1643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1644 | Sender's Host Identity Tag (HIT) | 1645 | | 1646 | | 1647 | | 1648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1649 | Receiver's Host Identity Tag (HIT) | 1650 | | 1651 | | 1652 | | 1653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1654 | | 1655 / HIP Parameters / 1656 / / 1657 | | 1658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1659 The HIP header is logically an IPv6 extension header. However, this 1660 document does not describe processing for Next Header values other 1661 than decimal 59, IPPROTO_NONE, the IPv6 'no next header' value. 1662 Future documents MAY define behavior for also other values. However, 1663 current implementations MUST ignore trailing data if an unimplemented 1664 Next Header value is received. 1666 The Header Length field contains the combined length of the HIP 1667 Header and HIP parameters in 8-byte units, excluding the first 8 1668 bytes. Since all HIP headers MUST contain the sender's and 1669 receiver's HIT fields, the minimum value for this field is 4, and 1670 conversely, the maximum length of the HIP Parameters field is 1671 (255*8)-32 = 2008 bytes. Note: this sets an additional limit for 1672 sizes of parameters included in the Parameters field, independent of 1673 the individual parameter maximum lengths. 1675 The Packet Type indicates the HIP packet type. The individual packet 1676 types are defined in the relevant sections. If a HIP host receives a 1677 HIP packet that contains an unrecognized packet type, it MUST drop 1678 the packet. 1680 The HIP Version field is four bits. The version defined in this 1681 document is 2. The version number is expected to be incremented only 1682 if there are incompatible changes to the protocol. Most extensions 1683 can be handled by defining new packet types, new parameter types, or 1684 new Controls (see Section 5.1.2) . 1686 The following three bits are reserved for future use. They MUST be 1687 zero when sent, and they SHOULD be ignored when handling a received 1688 packet. 1690 The two fixed bits in the header are reserved for SHIM6 compatibility 1691 [RFC5533], Section 5.3. For implementations adhering (only) to this 1692 specification, they MUST be set as shown when sending and MUST be 1693 ignored when receiving. This is to ensure optimal forward 1694 compatibility. Note that for implementations that implement other 1695 compatible specifications in addition to this specification, the 1696 corresponding rules may well be different. For example, an 1697 implementation that implements both this specification and the SHIM6 1698 protocol may need to check these bits in order to determine how to 1699 handle the packet. 1701 The HIT fields are always 128 bits (16 bytes) long. 1703 5.1.1. Checksum 1705 Since the checksum covers the source and destination addresses in the 1706 IP header, it MUST be recomputed on HIP-aware NAT devices. 1708 If IPv6 is used to carry the HIP packet, the pseudo-header [RFC2460] 1709 contains the source and destination IPv6 addresses, HIP packet length 1710 in the pseudo-header length field, a zero field, and the HIP protocol 1711 number (see Section 4) in the Next Header field. The length field is 1712 in bytes and can be calculated from the HIP header length field: (HIP 1713 Header Length + 1) * 8. 1715 In case of using IPv4, the IPv4 UDP pseudo-header format [RFC0768] is 1716 used. In the pseudo-header, the source and destination addresses are 1717 those used in the IP header, the zero field is obviously zero, the 1718 protocol is the HIP protocol number (see Section 4), and the length 1719 is calculated as in the IPv6 case. 1721 5.1.2. HIP Controls 1723 The HIP Controls field conveys information about the structure of the 1724 packet and capabilities of the host. 1726 The following fields have been defined: 1728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1729 | | | | | | | | | | | | | | | |A| 1730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1732 A - Anonymous: If this is set, the sender's HI in this packet is 1733 anonymous, i.e., one not listed in a directory. Anonymous HIs 1734 SHOULD NOT be stored. This control is set in packets using 1735 anonymous sender HIs. The peer receiving an anonymous HI in an R1 1736 or I2 may choose to refuse it. 1738 The rest of the fields are reserved for future use and MUST be set to 1739 zero in sent packets and ignored in received packets. 1741 5.1.3. HIP Fragmentation Support 1743 A HIP implementation MUST support IP fragmentation/reassembly. 1744 Fragment reassembly MUST be implemented in both IPv4 and IPv6, but 1745 fragment generation is REQUIRED to be implemented in IPv4 (IPv4 1746 stacks and networks will usually do this by default) and RECOMMENDED 1747 to be implemented in IPv6. In IPv6 networks, the minimum MTU is 1748 larger, 1280 bytes, than in IPv4 networks. The larger MTU size is 1749 usually sufficient for most HIP packets, and therefore fragment 1750 generation may not be needed. If a host expects to send HIP packets 1751 that are larger than the minimum IPv6 MTU, it MUST implement fragment 1752 generation even for IPv6. 1754 In IPv4 networks, HIP packets may encounter low MTUs along their 1755 routed path. Since basic HIP, as defined in this document, does not 1756 provide a mechanism to use multiple IP datagrams for a single HIP 1757 packet, support for path MTU discovery does not bring any value to 1758 HIP in IPv4 networks. HIP-aware NAT devices SHOULD perform IPv4 1759 reassembly/fragmentation for HIP control packets. 1761 All HIP implementations have to be careful while employing a 1762 reassembly algorithm so that the algorithm is sufficiently resistant 1763 to DoS attacks. 1765 Certificate chains can cause the packet to be fragmented and 1766 fragmentation can open implementations to denial-of-service attacks 1767 [KAU03]. "Hash and URL" schemes as defined in [RFC6253] for HIP 1768 version 1 may be used to avoid fragmentation and mitigate resulting 1769 DoS attacks. 1771 5.2. HIP Parameters 1773 The HIP parameters carry information that is necessary for 1774 establishing and maintaining a HIP association. For example, the 1775 peer's public keys as well as the signaling for negotiating ciphers 1776 and payload handling are encapsulated in HIP parameters. Additional 1777 information, meaningful for end-hosts or middleboxes, may also be 1778 included in HIP parameters. The specification of the HIP parameters 1779 and their mapping to HIP packets and packet types is flexible to 1780 allow HIP extensions to define new parameters and new protocol 1781 behavior. 1783 In HIP packets, HIP parameters are ordered according to their numeric 1784 type number and encoded in TLV format. 1786 The following parameter types are currently defined. 1788 +------------------------+-------+-----------+----------------------+ 1789 | TLV | Type | Length | Data | 1790 +------------------------+-------+-----------+----------------------+ 1791 | R1_COUNTER | 129 | 12 | Puzzle generation | 1792 | | | | counter | 1793 | | | | | 1794 | PUZZLE | 257 | 12 | K and Random #I | 1795 | | | | | 1796 | SOLUTION | 321 | 20 | K, Random #I and | 1797 | | | | puzzle solution J | 1798 | | | | | 1799 | SEQ | 385 | 4 | UPDATE packet ID | 1800 | | | | number | 1801 | | | | | 1802 | ACK | 449 | variable | UPDATE packet ID | 1803 | | | | number | 1804 | | | | | 1805 | DH_GROUP_LIST | 511 | variable | Ordered list of DH | 1806 | | | | Group IDs supported | 1807 | | | | by a host | 1808 | | | | | 1809 | DIFFIE_HELLMAN | 513 | variable | public key | 1810 | | | | | 1811 | HIP_CIPHER | 579 | variable | List of HIP | 1812 | | | | encryption | 1813 | | | | algorithms | 1814 | | | | | 1815 | ENCRYPTED | 641 | variable | Encrypted part of a | 1816 | | | | HIP packet | 1817 | | | | | 1818 | HOST_ID | 705 | variable | Host Identity with | 1819 | | | | Fully-Qualified | 1820 | | | | Domain FQDN (Name) | 1821 | | | | or Network Access | 1822 | | | | Identifier (NAI) | 1823 | | | | | 1824 | HIT_SUITE_LIST | 715 | variable | Ordered list of the | 1825 | | | | HIT suites supported | 1826 | | | | by the Responder | 1827 | | | | | 1828 | CERT | 768 | variable | HI Certificate; used | 1829 | | | | to transfer | 1830 | | | | certificates. | 1831 | | | | Specified in a | 1832 | | | | separate docment. | 1833 | | | | | 1834 | NOTIFICATION | 832 | variable | Informational data | 1835 | | | | | 1836 | ECHO_REQUEST_SIGNED | 897 | variable | Opaque data to be | 1837 | | | | echoed back; signed | 1838 | | | | | 1839 | ECHO_RESPONSE_SIGNED | 961 | variable | Opaque data echoed | 1840 | | | | back by request; | 1841 | | | | signed | 1842 | | | | | 1843 | TRANSPORT_FORMAT_LIST | 2049 | Ordered | variable | 1844 | | | list of | | 1845 | | | preferred | | 1846 | | | HIP | | 1847 | | | transport | | 1848 | | | type | | 1849 | | | numbers | | 1850 | | | | | 1851 | HIP_MAC | 61505 | variable | HMAC-based message | 1852 | | | | authentication code, | 1853 | | | | with key material | 1854 | | | | from KEYMAT | 1855 | | | | | 1856 | HIP_MAC_2 | 61569 | variable | HMAC based message | 1857 | | | | authentication code, | 1858 | | | | with key material | 1859 | | | | from KEYMAT. Unlike | 1860 | | | | HIP_MAC, the HOST_ID | 1861 | | | | parameter is | 1862 | | | | included in | 1863 | | | | HIP_MAC_2 | 1864 | | | | calculation. | 1865 | | | | | 1866 | HIP_SIGNATURE_2 | 61633 | variable | Signature used in R1 | 1867 | | | | packet | 1868 | | | | | 1869 | HIP_SIGNATURE | 61697 | variable | Signature of the | 1870 | | | | packet | 1871 | | | | | 1872 | ECHO_REQUEST_UNSIGNED | 63661 | variable | Opaque data to be | 1873 | | | | echoed back; after | 1874 | | | | signature | 1875 | | | | | 1876 | ECHO_RESPONSE_UNSIGNED | 63425 | variable | Opaque data echoed | 1877 | | | | back by request; | 1878 | | | | after signature | 1879 +------------------------+-------+-----------+----------------------+ 1881 As the ordering (from lowest to highest) of HIP parameters is 1882 strictly enforced (see Section 5.2.1), the parameter type values for 1883 existing parameters have been spaced to allow for future protocol 1884 extensions. 1886 The following parameter type number ranges are defined. 1888 +---------------+---------------------------------------------------+ 1889 | Type Range | Purpose | 1890 +---------------+---------------------------------------------------+ 1891 | 0 - 1023 | Handshake | 1892 | | | 1893 | 1024 - 2047 | Reserved | 1894 | | | 1895 | 2048 - 4095 | Parameters related to HIP transport formats | 1896 | | | 1897 | 4096 - 8191 | Signed parameters allocated through specification | 1898 | | documents | 1899 | | | 1900 | 8192 - 32767 | Reserved | 1901 | | | 1902 | 32768 - 49151 | Free for experimentation. Signed parameters. | 1903 | | | 1904 | 41952 - 61439 | Reserved | 1905 | | | 1906 | 61440 - 64443 | Signatures and (signed) MACs | 1907 | | | 1908 | 62464 - 63487 | Parameters that are neither signed nor MACed | 1909 | | | 1910 | 63488 - 64511 | Rendezvous and relaying | 1911 | | | 1912 | 64512 - 65023 | Parameters that are neither signed nor MACed | 1913 | | | 1914 | 65024 - 65535 | Reserved | 1915 +---------------+---------------------------------------------------+ 1917 The process for defining new parameters is described in Section 5.2.2 1918 of this document. 1920 The range between 32768 (2^15) and 49151 (2^15 + 2^14) are free for 1921 experimentation. Types from this range SHOULD be selected in a 1922 random fashion to reduce the probability of collisions. 1924 5.2.1. TLV Format 1926 The TLV-encoded parameters are described in the following 1927 subsections. The type-field value also describes the order of these 1928 fields in the packet. The parameters MUST be included in the packet 1929 so that their types form an increasing order. If multiple parameters 1930 with the same type number are in one packet, the parameters with the 1931 same type MUST be consecutive in the packet. If the order does not 1932 follow this rule, the packet is considered to be malformed and it 1933 MUST be discarded. 1935 Parameters using type values from 2048 up to 4095 are related to 1936 transport formats. Currently, one transport format is defined: the 1937 ESP transport format [I-D.ietf-hip-rfc5202-bis]. 1939 All of the encoded TLV parameters have a length (that includes the 1940 Type and Length fields), which is a multiple of 8 bytes. When 1941 needed, padding MUST be added to the end of the parameter so that the 1942 total length is a multiple of 8 bytes. This rule ensures proper 1943 alignment of data. Any added padding bytes MUST be zeroed by the 1944 sender, and their values SHOULD NOT be checked by the receiver. 1946 The Length field indicates the length of the Contents field (in 1947 bytes). Consequently, the total length of the TLV parameter 1948 (including Type, Length, Contents, and Padding) is related to the 1949 Length field according to the following formula: 1951 Total Length = 11 + Length - (Length + 3) % 8; 1953 where % is the modulo operator 1955 0 1 2 3 1956 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1958 | Type |C| Length | 1959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1960 | | 1961 / Contents / 1962 / +-+-+-+-+-+-+-+-+ 1963 | | Padding | 1964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1966 Type Type code for the parameter. 16 bits long, C-bit 1967 being part of the Type code. 1968 C Critical. One if this parameter is critical, and 1969 MUST be recognized by the recipient, zero otherwise. 1970 The C bit is considered to be a part of the Type 1971 field. Consequently, critical parameters are always 1972 odd and non-critical ones have an even value. 1973 Length Length of the Contents, in bytes excluding Type, 1974 Length, and Padding. 1975 Contents Parameter specific, defined by Type 1976 Padding Padding, 0-7 bytes, added if needed 1978 Critical parameters (indicated by the odd type number) MUST be 1979 recognized by the recipient. If a recipient encounters a critical 1980 parameter that it does not recognize, it MUST NOT process the packet 1981 any further. It MAY send an ICMP or NOTIFY, as defined in 1982 Section 4.3. 1984 Non-critical parameters MAY be safely ignored. If a recipient 1985 encounters a non-critical parameter that it does not recognize, it 1986 SHOULD proceed as if the parameter was not present in the received 1987 packet. 1989 5.2.2. Defining New Parameters 1991 Future specifications may define new parameters as needed. When 1992 defining new parameters, care must be taken to ensure that the 1993 parameter type values are appropriate and leave suitable space for 1994 other future extensions. One must remember that the parameters MUST 1995 always be arranged in numerically increasing order by Type code, 1996 thereby limiting the order of parameters (see Section 5.2.1). 1998 The following rules MUST be followed when defining new parameters. 2000 1. The low-order bit C of the Type code is used to distinguish 2001 between critical and non-critical parameters. Hence, even 2002 parameter type numbers indicate non-critical parameters while odd 2003 parameter type numbers indicate critical parameters. 2005 2. A new parameter MAY be critical only if an old implementation 2006 that ignored it would cause security problems. In general, new 2007 parameters SHOULD be defined as non-critical, and expect a reply 2008 from the recipient. 2010 3. If a system implements a new critical parameter, it MUST provide 2011 the ability to set the associated feature off, such that the 2012 critical parameter is not sent at all. The configuration option 2013 MUST be well documented. Implementations operating in a mode 2014 adhering to this specification MUST disable the sending of new 2015 critical parameters by default. In other words, the management 2016 interface MUST allow vanilla standards-only mode as a default 2017 configuration setting, and MAY allow new critical payloads to be 2018 configured on (and off). 2020 4. See Section 9 for allocation rules regarding Type codes. 2022 5.2.3. R1_COUNTER 2024 0 1 2 3 2025 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2027 | Type | Length | 2028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2029 | Reserved, 4 bytes | 2030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2031 | R1 generation counter, 8 bytes | 2032 | | 2033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2035 Type 129 2036 Length 12 2037 R1 generation 2038 counter The current generation of valid puzzles 2040 The R1_COUNTER parameter contains a 64-bit unsigned integer in 2041 network-byte order, indicating the current generation of valid 2042 puzzles. The sender SHOULD increment this counter periodically. It 2043 is RECOMMENDED that the counter value is incremented at least as 2044 often as old PUZZLE values are deprecated so that SOLUTIONs to them 2045 are no longer accepted. 2047 Support for the R1_COUNTER parameter is mandatory. It SHOULD be 2048 included in the R1 (in which case, it is covered by the signature), 2049 and if present in the R1, it MUST be echoed (including the Reserved 2050 field verbatim) by the Initiator in the I2 packet. 2052 5.2.4. PUZZLE 2054 0 1 2 3 2055 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2057 | Type | Length | 2058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2059 | #K, 1 byte | Lifetime | Opaque, 2 bytes | 2060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2061 | Random #I, RHASH_len/8 bytes | 2062 / / 2063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2065 Type 257 2066 Length 4 + RHASH_len / 8 2067 #K #K is the number of verified bits 2068 Lifetime puzzle lifetime 2^(value-32) seconds 2069 Opaque data set by the Responder, indexing the puzzle 2070 Random #I random number of size RHASH_len bits 2072 Random #I is represented as a n-bit integer (where n is RHASH_len), 2073 #K and Lifetime as 8-bit integers, all in network byte order. 2075 The PUZZLE parameter contains the puzzle difficulty #K and a n-bit 2076 random integer #I. The Puzzle Lifetime indicates the time during 2077 which the puzzle solution is valid, and sets a time limit that should 2078 not be exceeded by the Initiator while it attempts to solve the 2079 puzzle. The lifetime is indicated as a power of 2 using the formula 2080 2^(Lifetime-32) seconds. A puzzle MAY be augmented with an 2081 ECHO_REQUEST_SIGNED or an ECHO_REQUEST_UNSIGNED parameter included in 2082 the R1; the contents of the echo request are then echoed back in the 2083 ECHO_RESPONSE_SIGNED or in the ECHO_RESPONSE_UNSIGNED parameter, 2084 allowing the Responder to use the included information as a part of 2085 its puzzle processing. 2087 The Opaque and Random #I field are not covered by the HIP_SIGNATURE_2 2088 parameter. 2090 5.2.5. SOLUTION 2092 0 1 2 3 2093 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2095 | Type | Length | 2096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2097 | #K, 1 byte | Reserved | Opaque, 2 bytes | 2098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2099 | Random #I, n bytes | 2100 / / 2101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2102 | Puzzle solution #J, RHASH_len/8 bytes | 2103 / / 2104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2106 Type 321 2107 Length 4 + RHASH_len /4 2108 #K #K is the number of verified bits 2109 Reserved zero when sent, ignored when received 2110 Opaque copied unmodified from the received PUZZLE 2111 parameter 2112 Random #I random number of size RHASH_len bits 2113 Puzzle solution #J random number of size RHASH_len bits 2115 Random #I and Random #J are represented as n-bit unsigned integers 2116 (where n is RHASH_len), #K as an 8-bit unsigned integer, all in 2117 network byte order. 2119 The SOLUTION parameter contains a solution to a puzzle. It also 2120 echoes back the random difficulty #K, the Opaque field, and the 2121 puzzle integer #I. 2123 5.2.6. DH_GROUP_LIST 2125 0 1 2 3 2126 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2128 | Type | Length | 2129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2130 | DH GROUP ID #1| DH GROUP ID #2| DH GROUP ID #3| DH GROUP ID #4| 2131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2132 | DH GROUP ID #n| Padding | 2133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2135 Type 511 2136 Length number of DH Group IDs 2137 DH GROUP ID defines a DH GROUP ID supported by the host. 2138 The list of IDs is ordered by preference of the 2139 host. The list of define DH Group IDs in the 2140 DIFFIE_HELLMAN parameter. Each DH Group ID is one 2141 octet long. 2143 The DH_GROUP_LIST parameter contains the list of supported DH Group 2144 IDs of a host. The Initiator sends the DH_GROUP_LIST in the I1 2145 packet, the Responder sends its own list in the signed part of the R1 2146 packet. The DH Group IDs in the DH_GROUP_LIST are listed in the 2147 order of their preference of the host sending the list. DH Group IDs 2148 that are listed first are preferred over the DH Group IDs listed 2149 later. The information in the DH_GROUP_LIST allows the Responder to 2150 select the DH group preferred by itself and supported by the 2151 Initiator. Based on the DH_GROUP_LIST in the R1 packet, the 2152 Initiator can determine if the Responder has selected the best 2153 possible choice based on the Initiator's and Responder's preferences. 2154 If the Responder's choice differs from the best choice, the Initiator 2155 can conclude that there was an attempted downgrade attack (see 2156 Section 4.1.7). 2158 When selecting the DH group for the DIFFIE_HELLMAN parameter in the 2159 R1 packet, the Responder MUST select the first DH Group ID in its 2160 DH_GROUP_LIST in the R1 packet that is compatible with one of the 2161 Suite IDs in the Initiator's DH_GROUP_LIST in the I1 packet. The 2162 Responder MUST NOT select any other DH Group ID that is contained in 2163 both lists because a downgrade attack cannot be detected then. 2165 In general, hosts SHOULD prefer stronger groups over weaker ones if 2166 the computation overhead is not prohibitively high for the intended 2167 application. 2169 5.2.7. DIFFIE_HELLMAN 2171 0 1 2 3 2172 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2174 | Type | Length | 2175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2176 | Group ID | Public Value Length | Public Value / 2177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2178 / | 2179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2180 / | Padding | 2181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2183 Type 513 2184 Length length in octets, excluding Type, Length, and 2185 Padding 2186 Group ID defines values for p and g as well as the KDF 2187 Public Value length of the following Public Value in octets 2188 Length 2189 Public Value the sender's public Diffie-Hellman key 2191 The following Group IDs have been defined: 2193 Group KDF Value 2194 Reserved 0 2195 DEPRECATED 1 2196 DEPRECATED 2 2197 1536-bit MODP group [RFC3526] HKDF [RFC5869] 3 2198 3072-bit MODP group [RFC3526] HKDF [RFC5869] 4 2199 DEPRECATED 5 2200 DEPRECATED 6 2201 NIST P-256 [RFC5903] HKDF [RFC5869] 7 2202 NIST P-384 [RFC5903] HKDF [RFC5869] 8 2203 NIST P-521 [RFC5903] HKDF [RFC5869] 9 2204 SECP160R1 [SECG] HKDF [RFC5869] 10 2206 The MODP Diffie-Hellman groups are defined in [RFC3526]. The ECDH 2207 groups 7 - 9 are defined in [RFC5903] and [RFC6090]. ECDH group 10 2208 is covered in Appendix D. Any ECDH used with HIP MUST have a co- 2209 factor of 1. 2211 The Group ID also defines the key derivation function that is to be 2212 used for deriving the symmstric keys for the HMAC and symmetric 2213 encryption from the keying material from the Diffie Hellman key 2214 exchange (see Section 6.5). 2216 A HIP implementation MUST implement Group ID 3. The 160-bit 2217 SECP160R1 group can be used when lower security is enough (e.g., web 2218 surfing) and when the equipment is not powerful enough (e.g., some 2219 PDAs). Implementations SHOULD implement Group IDs 4 and 8. 2221 To avoid unnecessary failures during the base exchange, the rest of 2222 the groups SHOULD be implemented in hosts where resources are 2223 adequate. 2225 5.2.8. HIP_CIPHER 2227 0 1 2 3 2228 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 2229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2230 | Type | Length | 2231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2232 | Cipher ID #1 | Cipher ID #2 | 2233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2234 | Cipher ID #n | Padding | 2235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2237 Type 579 2238 Length length in octets, excluding Type, Length, and 2239 Padding 2240 Cipher ID defines the cipher algorithm to be used for 2241 encrypting the contents of the ENCRYPTED parameter 2243 The following Cipher IDs are defined: 2245 Suite ID Value 2247 RESERVED 0 2248 NULL-ENCRYPT 1 ([RFC2410]) 2249 AES-128-CBC 2 ([RFC3602]) 2250 DEPRECATED 3 2251 AES-256-CBC 4 ([RFC3602]) 2253 The sender of a HIP_CIPHER parameter MUST make sure that there are no 2254 more than six (6) Cipher IDs in one HIP_CIPHER parameter. 2255 Conversely, a recipient MUST be prepared to handle received transport 2256 parameters that contain more than six Cipher IDs by accepting the 2257 first six Cipher IDs and dropping the rest. The limited number of 2258 transforms sets the maximum size of the HIP_CIPHER parameter. As the 2259 default configuration, the HIP_CIPHER parameter MUST contain at least 2260 one of the mandatory Cipher IDs. There MAY be a configuration option 2261 that allows the administrator to override this default. 2263 The Responder lists supported and desired Cipher IDs in order of 2264 preference in the R1, up to the maximum of six Cipher IDs. The 2265 Initiator MUST choose only one of the corresponding Cipher IDs. This 2266 Cipher ID will be used for generating the ENCRYPTED parameter. 2268 Mandatory implementation: AES-128-CBC. NULL-ENCRYPTION is included 2269 for testing purposes. 2271 5.2.9. HOST_ID 2273 0 1 2 3 2274 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 2275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2276 | Type | Length | 2277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2278 | HI Length |DI-type| DI Length | 2279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2280 | Algorithm | Host Identity / 2281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2282 / | Domain Identifier / 2283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2284 / | Padding | 2285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2287 Type 705 2288 Length length in octets, excluding Type, Length, and 2289 Padding 2290 HI Length length of the Host Identity in octets 2291 DI-type type of the following Domain Identifier field 2292 DI Length length of the Domain Identifier field in octets 2293 Algorithm index to the employed algorithm 2294 Host Identity actual Host Identity 2295 Domain Identifier the identifier of the sender 2297 The following DI-types have been defined: 2299 Type Value 2300 none included 0 2301 FQDN 1 2302 NAI 2 2304 FQDN Fully Qualified Domain Name, in binary format. 2305 NAI Network Access Identifier 2307 The format for the FQDN is defined in RFC 1035 [RFC1035] Section 3.1. 2308 The format for the NAI is defined in [RFC4282] 2310 A host MAY optionally associate the Host Identity with a single 2311 Domain Identifier in the HOST_ID parameter. If there is no Domain 2312 Identifier, i.e., the DI-type field is zero, the DI Length field is 2313 set to zero as well. 2315 The following HI Algorithms have been defined: 2317 Algorithm 2318 profiles Values 2320 RESERVED 0 2321 DSA 3 [FIPS 186-3] (RECOMMENDED) 2322 RSA 5 [RFC3447] (REQUIRED) 2323 ECDSA 7 [RFC4754] (REQUIRED) 2324 ECDSA_LOW 9 [SECG] (RECOMMENDED) 2326 For DSA, RSA, and ECDSA key types, profiles containing at least 112 2327 bits of security strength (as defined by [NIST.800-131A.2011]) should 2328 be used. For RSA signature padding, the PSS method of padding 2329 [RFC3447] MUST be used. 2331 The Host Identity is derived from the DNSKEY format for RSA and DSA. 2332 For these, the Public Key field of the RDATA part from RFC 4034 2333 [RFC4034] is used. For ECC we distinguish two different profiles: 2334 ECDSA and ECDSA_LOW. ECC contains curves approved by NIST and 2335 defined in RFC 4754 [RFC4754]. ECDSA_LOW is defined for devices with 2336 low computational capabilities and uses shorter curves from SECG 2337 [SECG]. Any ECDSA used with HIP MUST have a co-factor of 1. 2339 For ECDSA and ECDSA_LOW Host Identities are represented by the 2340 following fields: 2342 0 1 2 3 2343 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 2344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2345 | ECC Curve | / 2346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2347 / Public Key | 2348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2350 ECC Curve Curve label 2351 Public Key Represented in Octet-string format 2352 [RFC6090] 2354 For hosts that implement ECDSA as algorithm the following ECC curves 2355 are required: 2357 Algorithm Curve Values 2359 ECDSA RESERVED 0 2360 ECDSA NIST P-256 1 [RFC4754] 2361 ECDSA NIST P-384 2 [RFC4754] 2363 For hosts that implement the EDSA_LOW algorithm profile, the 2364 following curve is required: 2366 Algorithm Curve Values 2368 ECDSA_LOW RESERVED 0 2369 ECDSA_LOW SECP160R1 1 [SECG] 2371 5.2.10. HIT_SUITE_LIST 2373 The HIT_SUITE_LIST parameter contains a list of the supported HIT 2374 suite IDs of the Responder. The Responder sends the HIT_SUITE_LIST 2375 in the signed part of the R1 packet. Based on the HIT_SUITE_LIST, 2376 the Initiator can determine which source HITs are supported by the 2377 Responder. 2379 0 1 2 3 2380 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 2381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2382 | Type | Length | 2383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2384 | ID #1 | ID #2 | ID #3 | ID #4 | 2385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2386 | ID #n | Padding | 2387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2389 Type 715 2390 Length number of HIT Suite IDs 2391 ID defines a HIT Suite ID supported by the host. 2392 The list of IDs is ordered by preference of the 2393 host. Each HIT Suite ID is one octet long. The four 2394 higher-order bits of the ID field correspond to the 2395 HIT Suite ID in the ORCHID OGA field. The four 2396 lower-order bits are reserved and set to 0 and 2397 ignored by the receiver. 2399 The HIT Suite ID indexes a HIT Suite. HIT Suites are composed of 2400 signature algorithms as defined in Section 5.2.9 and hash functions. 2402 The ID field in the HIT_SUITE_LIST is defined as eight-bit field as 2403 opposed to the four-bit HIT Suite ID and OGA field in the ORCHID. 2404 This difference is a measure to accommodate larger HIT Suite IDs if 2405 the 16 available values prove insufficient. In that case, one of the 2406 16 values, zero, will be used to indicate that four additional bits 2407 of the ORCHID will be used to encode the HIT Suite ID. Hence, the 2408 current four-bit HIT Suite-IDs only use the four higher order bits in 2409 the ID field. Future documents may define the use of the four lower- 2410 order bits in the ID field. 2412 The following HIT Suites ID are defined: 2414 HIT Suite ID 2415 RESERVED 0 2416 RSA,DSA/SHA-256 1 (REQUIRED) 2417 ECDSA/SHA-384 2 (RECOMMENDED) 2418 ECDSA_LOW/SHA-1 3 (RECOMMENDED) 2420 5.2.11. TRANSPORT_FORMAT_LIST 2422 The TRANSPORT_FORMAT_LIST parameter contains a list of the supported 2423 HIP transport formats (TFs) of the Responder. The Responder sends 2424 the TRANSPORT_FORMAT_LIST in the signed part of the R1 packet. Based 2425 on the TRANSPORT_FORMAT_LIST, the Initiator chooses one suitable 2426 transport format and includes the respective HIP transport format 2427 parameter in its response packet. 2429 0 1 2 3 2430 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 2431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2432 | Type | Length | 2433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2434 | TF type #1 | TF type #2 / 2435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2436 / TF type #n | Padding | 2437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2439 Type 2049 2440 Length 2x number of TF types 2441 TF Type defines a transport format (TF) type supported by the 2442 host. The TF type numbers correspond to the HIP 2443 parameter type numbers of the respective transform 2444 parameters. The list of TF types is ordered by preference 2445 of the sender 2447 The TF type numbers index the respective HIP parameters for the 2448 transport formats in the type number range between 2050 to 4095. The 2449 parameters and their use is defined in separate documents. 2450 Currently, the only transport format defined is IPsec ESP 2451 [I-D.ietf-hip-rfc5202-bis]. 2453 For each listed TF type, the sender of the parameter MUST include the 2454 repective transport form parameter in the HIP packet. The TF type in 2455 the TRANSPORT_FORM_LIST MUST be ignored if no matching transport form 2456 parameter is present in the packet. 2458 5.2.12. HIP_MAC 2460 0 1 2 3 2461 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 2462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2463 | Type | Length | 2464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2465 | | 2466 | HMAC | 2467 / / 2468 / +-------------------------------+ 2469 | | Padding | 2470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2472 Type 61505 2473 Length length in octets, excluding Type, Length, and 2474 Padding 2475 HMAC HMAC computed over the HIP packet, excluding the 2476 HIP_MAC parameter and any following parameters, such 2477 as HIP_SIGNATURE, HIP_SIGNATURE_2, 2478 ECHO_REQUEST_UNSIGNED, or ECHO_RESPONSE_UNSIGNED. 2479 The checksum field MUST be set to zero and the HIP 2480 header length in the HIP common header MUST be 2481 calculated not to cover any excluded parameters 2482 when the HMAC is calculated. The size of the 2483 HMAC is the natural size of the hash computation 2484 output depending on the used hash function. 2486 The HMAC uses RHASH as hash algorithm. The calculation and 2487 verification process is presented in Section 6.4.1. 2489 5.2.13. HIP_MAC_2 2491 The HIP_MAC_2 is a MAC of the packet and the HOST_ID parameter of the 2492 sender while only the packet without HOST_ID of the sender is sent. 2493 The parameter structure is the same as in Section 5.2.12. The fields 2494 are: 2496 Type 61569 2497 Length length in octets, excluding Type, Length, and 2498 Padding 2499 HMAC HMAC computed over the HIP packet, excluding the 2500 HIP_MAC_2 parameter and any following parameters 2501 such as HIP_SIGNATURE, HIP_SIGNATURE_2, 2502 ECHO_REQUEST_UNSIGNED, or ECHO_RESPONSE_UNSIGNED, 2503 and including an additional sender's HOST_ID 2504 parameter during the HMAC calculation. The checksum 2505 field MUST be set to zero and the HIP header length 2506 in the HIP common header MUST be calculated not to 2507 cover any excluded parameters when the HMAC is 2508 calculated. The size of the HMAC is the natural 2509 size of the hash computation output depending on the 2510 used hash function. 2512 The HMAC uses RHASH as hash algorithm. The calculation and 2513 verification process is presented in Section 6.4.1. 2515 5.2.14. HIP_SIGNATURE 2517 0 1 2 3 2518 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 2519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2520 | Type | Length | 2521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2522 | SIG alg | Signature / 2523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2524 / | Padding | 2525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2527 Type 61697 2528 Length length in octets, excluding Type, Length, and 2529 Padding 2530 SIG alg signature algorithm 2531 Signature the signature is calculated over the HIP packet, 2532 excluding the HIP_SIGNATURE parameter and any 2533 parameters that follow the HIP_SIGNATURE parameter. 2534 When the signature is calculated the checksum field 2535 MUST be set to zero, and the HIP header length in 2536 the HIP common header MUST be calculated only up to 2537 the beginning of the HIP_SIGNATURE parameter. 2539 The signature algorithms are defined in Section 5.2.9. The signature 2540 in the Signature field is encoded using the method depending on the 2541 signature algorithm (e.g., according to [RFC3110] in case of RSA/ 2542 SHA-1, according to [RFC5702] in case of RSA/SHA-256, according to 2543 [RFC2536] in case of DSA, or according to [RFC6090] in case of 2544 ECDSA). 2546 The HIP_SIGNATURE calculation and verification process are presented 2547 in Section 6.4.2. 2549 5.2.15. HIP_SIGNATURE_2 2551 The HIP_SIGNATURE_2 excludes the variable parameters in the R1 packet 2552 to allow R1 pre-creation. The parameter structure is the same as in 2553 Section 5.2.14. The fields are: 2555 Type 61633 2556 Length length in octets, excluding Type, Length, and 2557 Padding 2558 SIG alg signature algorithm 2559 Signature Within the R1 packet that contains the 2560 HIP_SIGNATURE_2 parameter, the Initiator's HIT, the 2561 checksum field, and the Opaque and Random #I fields 2562 in the PUZZLE parameter MUST be set to zero while 2563 computing the HIP_SIGNATURE_2 signature. Further, 2564 the HIP packet length in the HIP header MUST be 2565 adjusted as if the HIP_SIGNATURE_2 was not in the 2566 packet during the signature calculation, i.e., the 2567 HIP packet length points to the beginning of 2568 the HIP_SIGNATURE_2 parameter during signing and 2569 verification. 2571 Zeroing the Initiator's HIT makes it possible to create R1 packets 2572 beforehand, to minimize the effects of possible DoS attacks. Zeroing 2573 the Random #I and Opaque fields within the PUZZLE parameter allows 2574 these fields to be populated dynamically on precomputed R1s. 2576 Signature calculation and verification follows the process defined in 2577 Section 6.4.2. 2579 5.2.16. SEQ 2581 0 1 2 3 2582 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 2583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2584 | Type | Length | 2585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2586 | Update ID | 2587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2588 Type 385 2589 Length 8 2590 Update ID 32-bit sequence number 2592 The Update ID is an unsigned number in network byte order, 2593 initialized by a host to zero upon moving to ESTABLISHED state. The 2594 Update ID has scope within a single HIP association, and not across 2595 multiple associations or multiple hosts. The Update ID is 2596 incremented by one before each new UPDATE that is sent by the host; 2597 the first UPDATE packet originated by a host has an Update ID of 0. 2599 5.2.17. ACK 2601 0 1 2 3 2602 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 2603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2604 | Type | Length | 2605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2606 | peer Update ID 1 | 2607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2608 / peer Update ID n | 2609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2611 Type 449 2612 Length length in octets, excluding Type and Length 2613 peer Update ID 32-bit sequence number corresponding to the 2614 Update ID being ACKed. 2616 The ACK parameter includes one or more Update IDs that have been 2617 received from the peer. The number of peer Update IDs can be 2618 inferred from the length by dividing it by 4. 2620 5.2.18. ENCRYPTED 2622 0 1 2 3 2623 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 2624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2625 | Type | Length | 2626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2627 | Reserved | 2628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2629 | IV / 2630 / / 2631 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 2633 / Encrypted data / 2634 / / 2635 / +-------------------------------+ 2636 / | Padding | 2637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2639 Type 641 2640 Length length in octets, excluding Type, Length, and 2641 Padding 2642 Reserved zero when sent, ignored when received 2643 IV Initialization vector, if needed, otherwise 2644 nonexistent. The length of the IV is inferred from 2645 the HIP_CIPHER. 2646 Encrypted The data is encrypted using the encryption algorithm 2647 data defined in the HIP_CIPHER parameter. 2649 The ENCRYPTED parameter encapsulates other parameters, the encrypted 2650 data, which holds one or more HIP parameters in block encrypted form. 2652 Consequently, the first fields in the encapsulated parameter(s) are 2653 Type and Length of the first such parameter, allowing the contents to 2654 be easily parsed after decryption. 2656 The field labeled "Encrypted data" consists of the output of one or 2657 more HIP parameters concatenated together that have been passed 2658 through an encryption algorithm. Each of these inner parameters is 2659 padded according to the rules of Section 5.2.1 for padding individual 2660 parameters. As a result, the concatenated parameters will be a block 2661 of data that is 8-byte aligned. 2663 Some encryption algorithms require that the data to be encrypted must 2664 be a multiple of the cipher algorithm block size. In this case, the 2665 above block of data MUST include additional padding, as specified by 2666 the encryption algorithm. The size of the extra padding is selected 2667 so that the length of the unencrypted data block is a multiple of the 2668 cipher block size. The encryption algorithm may specify padding 2669 bytes other than zero; for example, AES [FIPS.197.2001] uses the 2670 PKCS5 padding scheme (see section 6.1.1 of [RFC2898]) where the 2671 remaining n bytes to fill the block each have the value of n. This 2672 yields an "unencrypted data" block that is transformed to an 2673 "encrypted data" block by the cipher suite. This extra padding added 2674 to the set of parameters to satisfy the cipher block alignment rules 2675 is not counted in HIP TLV length fields, and this extra padding 2676 should be removed by the cipher suite upon decryption. 2678 Note that the length of the cipher suite output may be smaller or 2679 larger than the length of the set of parameters to be encrypted, 2680 since the encryption process may compress the data or add additional 2681 padding to the data. 2683 Once this encryption process is completed, the Encrypted data field 2684 is ready for inclusion in the parameter. If necessary, additional 2685 Padding for 8-byte alignment is then added according to the rules of 2686 Section 5.2.1. 2688 5.2.19. NOTIFICATION 2690 The NOTIFICATION parameter is used to transmit informational data, 2691 such as error conditions and state transitions, to a HIP peer. A 2692 NOTIFICATION parameter may appear in NOTIFY packets. The use of the 2693 NOTIFICATION parameter in other packet types is for further study. 2695 0 1 2 3 2696 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 2697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2698 | Type | Length | 2699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2700 | Reserved | Notify Message Type | 2701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2702 | / 2703 / Notification Data / 2704 / +---------------+ 2705 / | Padding | 2706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2708 Type 832 2709 Length length in octets, excluding Type, Length, and 2710 Padding 2711 Reserved zero when sent, ignored when received 2712 Notify Message specifies the type of notification 2713 Type 2714 Notification informational or error data transmitted in addition 2715 Data to the Notify Message Type. Values for this field 2716 are type specific (see below). 2717 multiple of 8 bytes. 2719 Notification information can be error messages specifying why an HIP 2720 Security Association could not be established. It can also be status 2721 data that a HIP implementation wishes to communicate with a peer 2722 process. The table below lists the notification messages and their 2723 Notification Message Types. HIP packets MAY contain multiple 2724 NOTIFICATION parameters if several problems exist or several 2725 independent pieces of information must be transmitted. 2727 To avoid certain types of attacks, a Responder SHOULD avoid sending a 2728 NOTIFICATION to any host with which it has not successfully verified 2729 a puzzle solution. 2731 Notify Message Types in the range 0-16383 are intended for reporting 2732 errors and in the range 16384-65535 for other status information. An 2733 implementation that receives a NOTIFY packet with a Notify Message 2734 Type that indicates an error in response to a request packet (e.g., 2735 I1, I2, UPDATE) SHOULD assume that the corresponding request has 2736 failed entirely. Unrecognized error types MUST be ignored except 2737 that they SHOULD be logged. 2739 As currently defined, Notify Message Type values 1-10 are used for 2740 informing about errors in packet structures, values 11-20 for 2741 informing about problems in parameters. 2743 Notification Data in NOTIFICATION parameters with status Notify 2744 Message Types MUST be ignored if not recognized. 2746 Notify Message Types - Errors Value 2747 ----------------------------- ----- 2749 UNSUPPORTED_CRITICAL_PARAMETER_TYPE 1 2751 Sent if the parameter type has the "critical" bit set and the 2752 parameter type is not recognized. Notification Data contains the 2753 two-octet parameter type. 2755 INVALID_SYNTAX 7 2757 Indicates that the HIP message received was invalid because some 2758 type, length, or value was out of range or because the request 2759 was otherwise malformed. To avoid a denial- of-service 2760 attack using forged messages, this status may only be returned 2761 for packets whose HIP_MAC (if present) and SIGNATURE have been 2762 verified. This status MUST be sent in response to any error not 2763 covered by one of the other status types, and SHOULD NOT contain 2764 details to avoid leaking information to someone probing a node. 2765 To aid debugging, more detailed error information SHOULD be 2766 written to a console or log. 2768 NO_DH_PROPOSAL_CHOSEN 14 2770 None of the proposed group IDs was acceptable. 2772 INVALID_DH_CHOSEN 15 2774 The DH Group ID field does not correspond to one offered 2775 by the Responder. 2777 NO_HIP_PROPOSAL_CHOSEN 16 2779 None of the proposed HIT Suites or HIP Encryption Algorithms was 2780 acceptable. 2782 INVALID_HIP_CIPHER_CHOSEN 17 2784 The HIP_CIPHER Crypto ID does not correspond to one offered by 2785 the Responder. 2787 UNSUPPORTED_HIT_SUITE 20 2789 Sent in response to an I1 or R1 packet for which the HIT suite 2790 is not supported. 2792 AUTHENTICATION_FAILED 24 2794 Sent in response to a HIP signature failure, except when 2795 the signature verification fails in a NOTIFY message. 2797 CHECKSUM_FAILED 26 2799 Sent in response to a HIP checksum failure. 2801 HIP_MAC_FAILED 28 2803 Sent in response to a HIP HMAC failure. 2805 ENCRYPTION_FAILED 32 2807 The Responder could not successfully decrypt the 2808 ENCRYPTED parameter. 2810 INVALID_HIT 40 2812 Sent in response to a failure to validate the peer's 2813 HIT from the corresponding HI. 2815 BLOCKED_BY_POLICY 42 2817 The Responder is unwilling to set up an association 2818 for some policy reason (e.g., received HIT is NULL 2819 and policy does not allow opportunistic mode). 2821 RESPONDER_BUSY_PLEASE_RETRY 44 2823 The Responder is unwilling to set up an association as it is 2824 suffering under some kind of overload and has chosen to shed load 2825 by rejecting the Initiator's request. The Initiator may retry; 2826 however, the Initiator MUST find another (different) puzzle 2827 solution for any such retries. Note that the Initiator may need 2828 to obtain a new puzzle with a new I1/R1 exchange. 2830 Notify Message Types - Status Value 2831 ----------------------------- ----- 2833 I2_ACKNOWLEDGEMENT 16384 2835 The Responder has an I2 packet from the Initiator but had to 2836 queue the I2 packet for processing. The puzzle was correctly 2837 solved and the Responder is willing to set up an association but 2838 currently has a number of I2 packets in the processing queue. 2839 The R2 packet is sent after the I2 packet was processed. 2841 5.2.20. ECHO_REQUEST_SIGNED 2843 0 1 2 3 2844 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 2845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2846 | Type | Length | 2847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2848 | Opaque data (variable length) | 2849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2851 Type 897 2852 Length length of the opaque data in octets 2853 Opaque data opaque data, supposed to be meaningful only to the 2854 node that sends ECHO_REQUEST_SIGNED and receives a 2855 corresponding ECHO_RESPONSE_SIGNED or 2856 ECHO_RESPONSE_UNSIGNED. 2858 The ECHO_REQUEST_SIGNED parameter contains an opaque blob of data 2859 that the sender wants to get echoed back in the corresponding reply 2860 packet. 2862 The ECHO_REQUEST_SIGNED and corresponding echo response parameters 2863 MAY be used for any purpose where a node wants to carry some state in 2864 a request packet and get it back in a response packet. The 2865 ECHO_REQUEST_SIGNED is covered by the HIP_MAC and SIGNATURE. A HIP 2866 packet can contain only one ECHO_REQUEST_SIGNED parameter and MAY 2867 contain multiple ECHO_REQUEST_UNSIGNED parameter. The 2868 ECHO_REQUEST_SIGNED parameter MUST be responded to with an 2869 ECHO_RESPONSE_SIGNED. 2871 5.2.21. ECHO_REQUEST_UNSIGNED 2873 0 1 2 3 2874 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 2875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2876 | Type | Length | 2877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2878 | Opaque data (variable length) | 2879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2881 Type 63661 2882 Length length of the opaque data in octets 2883 Opaque data opaque data, supposed to be meaningful only to the 2884 node that sends ECHO_REQUEST_UNSIGNED and receives a 2885 corresponding ECHO_RESPONSE_UNSIGNED. 2887 The ECHO_REQUEST_UNSIGNED parameter contains an opaque blob of data 2888 that the sender wants to get echoed back in the corresponding reply 2889 packet. 2891 The ECHO_REQUEST_UNSIGNED and corresponding echo response parameters 2892 MAY be used for any purpose where a node wants to carry some state in 2893 a request packet and get it back in a response packet. The 2894 ECHO_REQUEST_UNSIGNED is not covered by the HIP_MAC and SIGNATURE. A 2895 HIP packet can contain one or more ECHO_REQUEST_UNSIGNED parameters. 2896 It is possible that middleboxes add ECHO_REQUEST_UNSIGNED parameters 2897 in HIP packets passing by. The creator of the ECHO_REQUEST_UNSIGNED 2898 (end-host or middlebox) has to create the Opaque field so that it can 2899 later identify and remove the corresponding ECHO_RESPONSE_UNSIGNED 2900 parameter. 2902 The ECHO_REQUEST_UNSIGNED parameter MUST be responded to with an 2903 ECHO_RESPONSE_UNSIGNED parameter. 2905 5.2.22. ECHO_RESPONSE_SIGNED 2907 0 1 2 3 2908 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 2909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2910 | Type | Length | 2911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2912 | Opaque data (variable length) | 2913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2915 Type 961 2916 Length length of the opaque data in octets 2917 Opaque data opaque data, copied unmodified from the 2918 ECHO_REQUEST_SIGNED or ECHO_REQUEST_UNSIGNED 2919 parameter that triggered this response. 2921 The ECHO_RESPONSE_SIGNED parameter contains an opaque blob of data 2922 that the sender of the ECHO_REQUEST_SIGNED wants to get echoed back. 2923 The opaque data is copied unmodified from the ECHO_REQUEST_SIGNED 2924 parameter. 2926 The ECHO_REQUEST_SIGNED and ECHO_RESPONSE_SIGNED parameters MAY be 2927 used for any purpose where a node wants to carry some state in a 2928 request packet and get it back in a response packet. The 2929 ECHO_RESPONSE_SIGNED is covered by the HIP_MAC and SIGNATURE. 2931 5.2.23. ECHO_RESPONSE_UNSIGNED 2933 0 1 2 3 2934 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 2935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2936 | Type | Length | 2937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2938 | Opaque data (variable length) | 2939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2941 Type 63425 2942 Length length of the opaque data in octets 2943 Opaque data opaque data, copied unmodified from the 2944 ECHO_REQUEST_SIGNED or ECHO_REQUEST_UNSIGNED 2945 parameter that triggered this response. 2947 The ECHO_RESPONSE_UNSIGNED parameter contains an opaque blob of data 2948 that the sender of the ECHO_REQUEST_SIGNED or ECHO_REQUEST_UNSIGNED 2949 wants to get echoed back. The opaque data is copied unmodified from 2950 the corresponding echo request parameter. 2952 The echo request and ECHO_RESPONSE_UNSIGNED parameters MAY be used 2953 for any purpose where a node wants to carry some state in a request 2954 packet and get it back in a response packet. The 2955 ECHO_RESPONSE_UNSIGNED is not covered by the HIP_MAC and SIGNATURE. 2957 5.3. HIP Packets 2959 There are eight basic HIP packets (see Table 10). Four are for the 2960 HIP base exchange, one is for updating, one is for sending 2961 notifications, and two are for closing a HIP association. 2963 +------------------+------------------------------------------------+ 2964 | Packet type | Packet name | 2965 +------------------+------------------------------------------------+ 2966 | 1 | I1 - the HIP Initiator Packet | 2967 | | | 2968 | 2 | R1 - the HIP Responder Packet | 2969 | | | 2970 | 3 | I2 - the Second HIP Initiator Packet | 2971 | | | 2972 | 4 | R2 - the Second HIP Responder Packet | 2973 | | | 2974 | 16 | UPDATE - the HIP Update Packet | 2975 | | | 2976 | 17 | NOTIFY - the HIP Notify Packet | 2977 | | | 2978 | 18 | CLOSE - the HIP Association Closing Packet | 2979 | | | 2980 | 19 | CLOSE_ACK - the HIP Closing Acknowledgment | 2981 | | Packet | 2982 +------------------+------------------------------------------------+ 2984 Table 10: HIP packets and packet type values 2986 Packets consist of the fixed header as described in Section 5.1, 2987 followed by the parameters. The parameter part, in turn, consists of 2988 zero or more TLV-coded parameters. 2990 In addition to the base packets, other packet types may be defined 2991 later in separate specifications. For example, support for mobility 2992 and multi-homing is not included in this specification. 2994 See Notation (Section 2.2) for the notation used in the operations. 2996 In the future, an optional upper-layer payload MAY follow the HIP 2997 header. The Next Header field in the header indicates if there is 2998 additional data following the HIP header. The HIP packet, however, 2999 MUST NOT be fragmented. This limits the size of the possible 3000 additional data in the packet. 3002 5.3.1. I1 - the HIP Initiator Packet 3004 The HIP header values for the I1 packet: 3006 Header: 3007 Packet Type = 1 3008 SRC HIT = Initiator's HIT 3009 DST HIT = Responder's HIT, or NULL 3011 IP ( HIP ( DH_GROUP_LIST ) ) 3013 The I1 packet contains the fixed HIP header and the Initiator's 3014 DH_GROUP_LIST. 3016 Valid control bits: none 3018 The Initiator receives the Responder's HIT either from a DNS lookup 3019 of the Responder's FQDN (see 5205-bis), from some other repository, 3020 or from a local table. If the Initiator does not know the 3021 Responder's HIT, it may attempt to use opportunistic mode by using 3022 NULL (all zeros) as the Responder's HIT. See also "HIP Opportunistic 3023 Mode" (Section 4.1.8). 3025 Since the I1 packet is so easy to spoof even if it were signed, no 3026 attempt is made to add to its generation or processing cost. 3028 The Initiator includes a DH_GROUP_LIST parameter in the I1 packet to 3029 inform the Responder of its preferred DH Group IDs. Note that the 3030 DH_GROUP_LIST in the I1 packet is not protected by a signature. 3032 Implementations MUST be able to handle a storm of received I1 3033 packets, discarding those with common content that arrive within a 3034 small time delta. 3036 5.3.2. R1 - the HIP Responder Packet 3038 The HIP header values for the R1 packet: 3040 Header: 3041 Packet Type = 2 3042 SRC HIT = Responder's HIT 3043 DST HIT = Initiator's HIT 3045 IP ( HIP ( [ R1_COUNTER, ] 3046 PUZZLE, 3047 DIFFIE_HELLMAN, 3048 HIP_CIPHER, 3049 HOST_ID, 3050 HIT_SUITE_LIST, 3051 DH_GROUP_LIST, 3052 [ ECHO_REQUEST_SIGNED, ] 3053 TRANSPORT_FORMAT_LIST, 3054 HIP_SIGNATURE_2 ) 3055 <, ECHO_REQUEST_UNSIGNED >i) 3057 Valid control bits: A 3058 If the Responder's HI is an anonymous one, the A control MUST be set. 3060 The Initiator's HIT MUST match the one received in the I1 packet if 3061 the R1 is a response to an I1. If the Responder has multiple HIs, 3062 the Responder's HIT used MUST match Initiator's request. If the 3063 Initiator used opportunistic mode, the Responder may select freely 3064 among its HIs. See also "HIP Opportunistic Mode" (Section 4.1.8). 3066 The R1 packet generation counter is used to determine the currently 3067 valid generation of puzzles. The value is increased periodically, 3068 and it is RECOMMENDED that it is increased at least as often as 3069 solutions to old puzzles are no longer accepted. 3071 The Puzzle contains a Random #I and the difficulty #K. The 3072 difficulty #K indicates the number of lower-order bits, in the puzzle 3073 hash result, that must be zeros; see Section 4.1.2. The Random #I is 3074 not covered by the signature and must be zeroed during the signature 3075 calculation, allowing the sender to select and set the #I into a 3076 precomputed R1 packet just prior sending it to the peer. 3078 The Responder selects the Diffie-Hellman public value based on the 3079 Initiator's preference expressed in the DH_GROUP_LIST parameter in 3080 the I1 packet. The Responder sends back its own preference based on 3081 which it chose the DH public value as DH_GROUP_LIST. This allows the 3082 Initiator to determine whether its own DH_GROUP_LIST in the sent I1 3083 packet was manipulated by an attacker. 3085 The Diffie-Hellman public value is ephemeral, and values SHOULD NOT 3086 be reused across different HIP sessions. Once the Responder has 3087 received a valid response to an R1 packet, that Diffie-Hellman value 3088 SHOULD be deprecated. It it is possible that the Responder has sent 3089 the same Diffie-Hellman value to different hosts simultaneously in 3090 corresponding R1 packets and those responses should also be accepted. 3091 However, as a defense against I1 packet storms, an implementation MAY 3092 propose, and re-use unless avoidable, the same Diffie-Hellman value 3093 for a period of time, for example, 15 minutes. By using a small 3094 number of different puzzles for a given Diffie-Hellman value, the R1 3095 packets can be precomputed and delivered as quickly as I1 packets 3096 arrive. A scavenger process should clean up unused Diffie-Hellman 3097 values and puzzles. 3099 Re-using Diffie-Hellman public values opens up the potential security 3100 risk of more than one Initiator ending up with the same keying 3101 material (due to faulty random number generators). Also, more than 3102 one Initiator using the same Responder public key half may lead to 3103 potentially easier cryptographic attacks and to imperfect forward 3104 security. 3106 However, these risks involved in re-using the same public value are 3107 statistical; that is, the authors are not aware of any mechanism that 3108 would allow manipulation of the protocol so that the risk of the re- 3109 use of any given Responder Diffie-Hellman public key would differ 3110 from the base probability. Consequently, it is RECOMMENDED that 3111 Responders avoid re-using the same DH key with multiple Initiators, 3112 but because the risk is considered statistical and not known to be 3113 manipulable, the implementations MAY re-use a key in order to ease 3114 resource-constrained implementations and to increase the probability 3115 of successful communication with legitimate clients even under an I1 3116 packet storm. In particular, when it is too expensive to generate 3117 enough precomputed R1 packets to supply each potential Initiator with 3118 a different DH key, the Responder MAY send the same DH key to several 3119 Initiators, thereby creating the possibility of multiple legitimate 3120 Initiators ending up using the same Responder-side public key. 3121 However, as soon as the Responder knows that it will use a particular 3122 DH key, it SHOULD stop offering it. This design is aimed to allow 3123 resource-constrained Responders to offer services under I1 packet 3124 storms and to simultaneously make the probability of DH key re-use 3125 both statistical and as low as possible. 3127 If the Responder uses the same DH keypair for multiple handshakes. 3128 It must take care to avoid small subgroup attacks [RFC2785]. To 3129 avoid these attacks, when receiving the I2 message, the Responder 3130 SHOULD validate the Initiators DH public key as described in 3131 [RFC2785] Section 3.1. In case the validation fails, the Responder 3132 MUST NOT generate a DH shared key and MUST silently abort the HIP 3133 BEX. 3135 The HIP_CIPHER contains the encryption algorithms supported by the 3136 Responder to encrypt the contents of the ENCRYPTED parameter, in the 3137 order of preference. All implementations MUST support AES [RFC3602]. 3139 The HIT_SUITE_LIST parameter is an ordered list of the Responder's 3140 preferred and supported HIT Suites. The list allows the Initiator to 3141 determine whether its own source HIT matches any suite supported by 3142 the Responder. 3144 The ECHO_REQUEST_SIGNED and ECHO_REQUEST_UNSIGNED parameters contain 3145 data that the sender wants to receive unmodified in the corresponding 3146 response packet in the ECHO_RESPONSE_SIGNED or ECHO_RESPONSE_UNSIGNED 3147 parameter. The R1 packet may contain zero or more 3148 ECHO_REQUEST_UNSIGNED parameters as described in Section 3149 Section 5.2.21. 3151 The TRANSPORT_FORMAT_LIST parameter is an ordered list of the 3152 Responder's preferred and supported transport format types. The list 3153 allows the Initiator and the Responder to agree on a common type for 3154 payload protection. This parameter is described in Section 5.2.11. 3156 The signature is calculated over the whole HIP packet as described in 3157 Section 5.2.15. This allows the Responder to use precomputed R1s. 3158 The Initiator SHOULD validate this signature. It MUST check that the 3159 Responder's HI matches with the one expected, if any. 3161 5.3.3. I2 - the Second HIP Initiator Packet 3163 The HIP header values for the I2 packet: 3165 Header: 3166 Type = 3 3167 SRC HIT = Initiator's HIT 3168 DST HIT = Responder's HIT 3170 IP ( HIP ( [R1_COUNTER,] 3171 SOLUTION, 3172 DIFFIE_HELLMAN, 3173 HIP_CIPHER, 3174 ENCRYPTED { HOST_ID } or HOST_ID, 3175 [ ECHO_RESPONSE_SIGNED ,] 3176 TRANSPORT_FORMAT_LIST, 3177 HIP_MAC, 3178 HIP_SIGNATURE 3179 <, ECHO_RESPONSE_UNSIGNED>i ) ) 3181 Valid control bits: A 3183 The HITs used MUST match the ones used in the R1. 3185 If the Initiator's HI is an anonymous one, the A control MUST be set. 3187 If present in the I1 packet, the Initiator MUST include an unmodified 3188 copy of the R1_COUNTER parameter received in the corresponding R1 3189 packet into the I2 packet. 3191 The Solution contains the Random #I from R1 and the computed #J. The 3192 low-order #K bits of the RHASH(I | ... | J) MUST be zero. 3194 The Diffie-Hellman value is ephemeral. If precomputed, a scavenger 3195 process should clean up unused Diffie-Hellman values. The Responder 3196 MAY re-use Diffie-Hellman values under some conditions as specified 3197 in Section 5.3.2. 3199 The HIP_CIPHER contains the single encryption transform selected by 3200 the Initiator, that it uses to encrypt the ENCRYPTED parameters. The 3201 chosen cipher MUST correspond to one of the ciphers offered by the 3202 Responder in the R1. All implementations MUST support AES [RFC3602]. 3204 The Initiator's HI MAY be encrypted using the HIP_CIPHER encryption 3205 algorithm. The keying material is derived from the Diffie-Hellman 3206 exchanged as defined in Section 6.5. 3208 The ECHO_RESPONSE_SIGNED and ECHO_RESPONSE_UNSIGNED contain the 3209 unmodified Opaque data copied from the corresponding echo request 3210 parameter(s). 3212 The TRANSPORT_FORMAT_LIST contains the single transport format type 3213 selected by the Initiator. The chosen type MUST correspond to one of 3214 the types offered by the Responder in the R1. Currently, the only 3215 transport format defined is the ESP transport format 3216 ([I-D.ietf-hip-rfc5202-bis]). 3218 The HMAC value in the HIP_MAC parameter is calculated over the whole 3219 HIP packet, excluding any parameters after the HIP_MAC, as described 3220 in Section 6.4.1. The Responder MUST validate the HIP_MAC. 3222 The signature is calculated over the whole HIP packet, excluding any 3223 parameters after the HIP_SIGNATURE, as described in Section 5.2.14. 3224 The Responder MUST validate this signature. The Responder uses the 3225 HI in the packet or a HI acquired by some other means for verifying 3226 the signature. 3228 5.3.4. R2 - the Second HIP Responder Packet 3230 The HIP header values for the R2 packet: 3232 Header: 3233 Packet Type = 4 3234 SRC HIT = Responder's HIT 3235 DST HIT = Initiator's HIT 3237 IP ( HIP ( HIP_MAC_2, HIP_SIGNATURE ) ) 3239 Valid control bits: none 3241 The HIP_MAC_2 is calculated over the whole HIP packet, with 3242 Responder's HOST_ID parameter concatenated with the HIP packet. The 3243 HOST_ID parameter is removed after the HMAC calculation. The 3244 procedure is described in Section 6.4.1. 3246 The signature is calculated over the whole HIP packet. 3248 The Initiator MUST validate both the HIP_MAC and the signature. 3250 5.3.5. UPDATE - the HIP Update Packet 3252 Support for the UPDATE packet is MANDATORY. 3254 The HIP header values for the UPDATE packet: 3256 Header: 3257 Packet Type = 16 3258 SRC HIT = Sender's HIT 3259 DST HIT = Recipient's HIT 3261 IP ( HIP ( [SEQ, ACK, ] HIP_MAC, HIP_SIGNATURE ) ) 3263 Valid control bits: None 3265 The UPDATE packet contains mandatory HIP_MAC and HIP_SIGNATURE 3266 parameters, and other optional parameters. 3268 The UPDATE packet contains zero or one SEQ parameter. The presence 3269 of a SEQ parameter indicates that the receiver MUST acknowledge the 3270 the UPDATE. An UPDATE that does not contain a SEQ but only an ACK 3271 parameter is simply an acknowledgment of a previous UPDATE and itself 3272 MUST NOT be acknowledged by a separate ACK. Such UPDATE packets 3273 containing only an ACK parameter do not require processing in 3274 relative order to other UPDATE packets. An UPDATE packet without 3275 either a SEQ or an ACK parameter is invalid; such unacknowledged 3276 updates MUST instead use a NOTIFY packet. 3278 An UPDATE packet contains zero or one ACK parameters. The ACK 3279 parameter echoes the SEQ sequence number of the UPDATE packet being 3280 ACKed. A host MAY choose to acknowledge more than one UPDATE packet 3281 at a time; e.g., the ACK may contain the last two SEQ values 3282 received, for resilience against ACK loss. ACK values are not 3283 cumulative; each received unique SEQ value requires at least one 3284 corresponding ACK value in reply. Received ACKs that are redundant 3285 are ignored. Hosts MUST implement the processing of ACKs with 3286 multiple SEQ numbers even if they do not implement sending ACKs with 3287 multiple SEQ numbers. 3289 The UPDATE packet may contain both a SEQ and an ACK parameter. In 3290 this case, the ACK is being piggybacked on an outgoing UPDATE. In 3291 general, UPDATEs carrying SEQ SHOULD be ACKed upon completion of the 3292 processing of the UPDATE. A host MAY choose to hold the UPDATE 3293 carrying ACK for a short period of time to allow for the possibility 3294 of piggybacking the ACK parameter, in a manner similar to TCP delayed 3295 acknowledgments. 3297 A sender MAY choose to forgo reliable transmission of a particular 3298 UPDATE (e.g., it becomes overcome by events). The semantics are such 3299 that the receiver MUST acknowledge the UPDATE, but the sender MAY 3300 choose to not care about receiving the ACK. 3302 UPDATEs MAY be retransmitted without incrementing SEQ. If the same 3303 subset of parameters is included in multiple UPDATEs with different 3304 SEQs, the host MUST ensure that the receiver's processing of the 3305 parameters multiple times will not result in a protocol error. 3307 5.3.6. NOTIFY - the HIP Notify Packet 3309 Implementing the NOTIFY packet is optional. The NOTIFY packet MAY be 3310 used to provide information to a peer. Typically, NOTIFY is used to 3311 indicate some type of protocol error or negotiation failure. NOTIFY 3312 packets are unacknowledged. The receiver can handle the packet only 3313 as informational, and SHOULD NOT change its HIP state (see 3314 Section 4.4.2) based purely on a received NOTIFY packet. 3316 The HIP header values for the NOTIFY packet: 3318 Header: 3319 Packet Type = 17 3320 SRC HIT = Sender's HIT 3321 DST HIT = Recipient's HIT, or zero if unknown 3323 IP ( HIP (i, [HOST_ID, ] HIP_SIGNATURE) ) 3325 Valid control bits: None 3327 The NOTIFY packet is used to carry one or more NOTIFICATION 3328 parameters. 3330 5.3.7. CLOSE - the HIP Association Closing Packet 3332 The HIP header values for the CLOSE packet: 3334 Header: 3335 Packet Type = 18 3336 SRC HIT = Sender's HIT 3337 DST HIT = Recipient's HIT 3339 IP ( HIP ( ECHO_REQUEST_SIGNED, HIP_MAC, HIP_SIGNATURE ) ) 3341 Valid control bits: none 3343 The sender MUST include an ECHO_REQUEST_SIGNED used to validate 3344 CLOSE_ACK received in response, and both a HIP_MAC and a signature 3345 (calculated over the whole HIP packet). 3347 The receiver peer MUST reply with a CLOSE_ACK containing an 3348 ECHO_RESPONSE_SIGNED corresponding to the received 3349 ECHO_REQUEST_SIGNED. 3351 5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet 3353 The HIP header values for the CLOSE_ACK packet: 3355 Header: 3356 Packet Type = 19 3357 SRC HIT = Sender's HIT 3358 DST HIT = Recipient's HIT 3360 IP ( HIP ( ECHO_RESPONSE_SIGNED, HIP_MAC, HIP_SIGNATURE ) ) 3362 Valid control bits: none 3364 The sender MUST include both an HMAC and signature (calculated over 3365 the whole HIP packet). 3367 The receiver peer MUST validate the ECHO_RESPONSE_SIGNED and validate 3368 both the HIP_MAC and the signature if the receiver has state for a 3369 HIP association. 3371 5.4. ICMP Messages 3373 When a HIP implementation detects a problem with an incoming packet, 3374 and it either cannot determine the identity of the sender of the 3375 packet or does not have any existing HIP association with the sender 3376 of the packet, it MAY respond with an ICMP packet. Any such replies 3377 MUST be rate-limited as described in [RFC4443]. In most cases, the 3378 ICMP packet has the Parameter Problem type (12 for ICMPv4, 4 for 3379 ICMPv6), with the Pointer field pointing to the field that caused the 3380 ICMP message to be generated. 3382 5.4.1. Invalid Version 3384 If a HIP implementation receives a HIP packet that has an 3385 unrecognized HIP version number, it SHOULD respond, rate-limited, 3386 with an ICMP packet with type Parameter Problem, with the Pointer 3387 pointing to the Version/RES. byte in the HIP header. 3389 5.4.2. Other Problems with the HIP Header and Packet Structure 3391 If a HIP implementation receives a HIP packet that has other 3392 unrecoverable problems in the header or packet format, it MAY 3393 respond, rate-limited, with an ICMP packet with type Parameter 3394 Problem, the Pointer pointing to the field that failed to pass the 3395 format checks. However, an implementation MUST NOT send an ICMP 3396 message if the checksum fails; instead, it MUST silently drop the 3397 packet. 3399 5.4.3. Invalid Puzzle Solution 3401 If a HIP implementation receives an I2 packet that has an invalid 3402 puzzle solution, the behavior depends on the underlying version of 3403 IP. If IPv6 is used, the implementation SHOULD respond with an ICMP 3404 packet with type Parameter Problem, the Pointer pointing to the 3405 beginning of the Puzzle solution #J field in the SOLUTION payload in 3406 the HIP message. 3408 If IPv4 is used, the implementation MAY respond with an ICMP packet 3409 with the type Parameter Problem, copying enough of bytes from the I2 3410 message so that the SOLUTION parameter fits into the ICMP message, 3411 the Pointer pointing to the beginning of the Puzzle solution #J 3412 field, as in the IPv6 case. Note, however, that the resulting ICMPv4 3413 message exceeds the typical ICMPv4 message size as defined in 3414 [RFC0792]. 3416 5.4.4. Non-Existing HIP Association 3418 If a HIP implementation receives a CLOSE or UPDATE packet, or any 3419 other packet whose handling requires an existing association, that 3420 has either a Receiver or Sender HIT that does not match with any 3421 existing HIP association, the implementation MAY respond, rate- 3422 limited, with an ICMP packet with the type Parameter Problem. The 3423 Pointer of the ICMP Parameter Problem packet is set pointing to the 3424 beginning of the first HIT that does not match. 3426 A host MUST NOT reply with such an ICMP if it receives any of the 3427 following messages: I1, R2, I2, R2, and NOTIFY packet. When 3428 introducing new packet types, a specification SHOULD define the 3429 appropriate rules for sending or not sending this kind of ICMP reply. 3431 6. Packet Processing 3433 Each host is assumed to have a single HIP protocol implementation 3434 that manages the host's HIP associations and handles requests for new 3435 ones. Each HIP association is governed by a conceptual state 3436 machine, with states defined above in Section 4.4. The HIP 3437 implementation can simultaneously maintain HIP associations with more 3438 than one host. Furthermore, the HIP implementation may have more 3439 than one active HIP association with another host; in this case, HIP 3440 associations are distinguished by their respective HITs. It is not 3441 possible to have more than one HIP association between any given pair 3442 of HITs. Consequently, the only way for two hosts to have more than 3443 one parallel association is to use different HITs, at least at one 3444 end. 3446 The processing of packets depends on the state of the HIP 3447 association(s) with respect to the authenticated or apparent 3448 originator of the packet. A HIP implementation determines whether it 3449 has an active association with the originator of the packet based on 3450 the HITs. In the case of user data carried in a specific transport 3451 format, the transport format document specifies how the incoming 3452 packets are matched with the active associations. 3454 6.1. Processing Outgoing Application Data 3456 In a HIP host, an application can send application-level data using 3457 an identifier specified via the underlying API. The API can be a 3458 backwards-compatible API (see [RFC5338]), using identifiers that look 3459 similar to IP addresses, or a completely new API, providing enhanced 3460 services related to Host Identities. Depending on the HIP 3461 implementation, the identifier provided to the application may be 3462 different; for example, it can be a HIT or an IP address. 3464 The exact format and method for transferring the user data from the 3465 source HIP host to the destination HIP host is defined in the 3466 corresponding transport format document. The actual data is 3467 transferred in the network using the appropriate source and 3468 destination IP addresses. 3470 In this document, conceptual processing rules are defined only for 3471 the base case where both hosts have only single usable IP addresses; 3472 the multi-address multi-homing case is specified separately. 3474 The following conceptual algorithm describes the steps that are 3475 required for handling outgoing datagrams destined to a HIT. 3477 1. If the datagram has a specified source address, it MUST be a HIT. 3478 If it is not, the implementation MAY replace the source address 3479 with a HIT. Otherwise, it MUST drop the packet. 3481 2. If the datagram has an unspecified source address, the 3482 implementation MUST choose a suitable source HIT for the 3483 datagram. Selecting the source HIT is subject to local policy. 3485 3. If there is no active HIP association with the given HIT pair, one MUST be created by running the base 3487 exchange. While waiting for the base exchange to complete, the 3488 implementation SHOULD queue at least one packet per HIP 3489 association to be formed, and it MAY queue more than one. 3491 4. Once there is an active HIP association for the given HIT pair, the outgoing datagram is passed to 3493 transport handling. The possible transport formats are defined 3494 in separate documents, of which the ESP transport format for HIP 3495 is mandatory for all HIP implementations. 3497 5. Before sending the packet, the HITs in the datagram are replaced 3498 with suitable IP addresses. For IPv6, the rules defined in 3499 [RFC3484] SHOULD be followed. Note that this HIT-to-IP-address 3500 conversion step MAY also be performed at some other point in the 3501 stack, e.g., before wrapping the packet into the output format. 3503 6.2. Processing Incoming Application Data 3505 The following conceptual algorithm describes the incoming datagram 3506 handling when HITs are used at the receiving host as application- 3507 level identifiers. More detailed steps for processing packets are 3508 defined in corresponding transport format documents. 3510 1. The incoming datagram is mapped to an existing HIP association, 3511 typically using some information from the packet. For example, 3512 such mapping may be based on the ESP Security Parameter Index 3513 (SPI). 3515 2. The specific transport format is unwrapped, in a way depending on 3516 the transport format, yielding a packet that looks like a 3517 standard (unencrypted) IP packet. If possible, this step SHOULD 3518 also verify that the packet was indeed (once) sent by the remote 3519 HIP host, as identified by the HIP association. 3521 Depending on the used transport mode, the verification method can 3522 vary. While the HI (as well as HIT) is used as the higher-layer 3523 identifier, the verification method has to verify that the data 3524 packet was sent by the correct node identity and that the actual 3525 identity maps to this particular HIT. When using ESP transport 3526 format [I-D.ietf-hip-rfc5202-bis], the verification is done using 3527 the SPI value in the data packet to find the corresponding SA 3528 with associated HIT and key, and decrypting the packet with that 3529 associated key. 3531 3. The IP addresses in the datagram are replaced with the HITs 3532 associated with the HIP association. Note that this IP-address- 3533 to-HIT conversion step MAY also be performed at some other point 3534 in the stack. 3536 4. The datagram is delivered to the upper layer (e.g., UDP or TCP). 3537 When demultiplexing the datagram, the right upper-layer socket is 3538 selected based on the HITs. 3540 6.3. Solving the Puzzle 3542 This subsection describes the details for solving the puzzle. 3544 In the R1 packet, the values #I and #K are sent in network byte 3545 order. Similarly, in the I2 packet, the values #I and #J are sent in 3546 network byte order. The hash is created by concatenating, in network 3547 byte order, the following data, in the following order and using the 3548 RHASH algorithm: 3550 n-bit random value #I (where n is RHASH_len), in network byte 3551 order, as appearing in the R1 and I2 packets. 3553 128-bit Initiator's HIT, in network byte order, as appearing in 3554 the HIP Payload in the R1 and I2 packets. 3556 128-bit Responder's HIT, in network byte order, as appearing in 3557 the HIP Payload in the R1 and I2 packets. 3559 n-bit random value #J (where n is RHASH_len), in network byte 3560 order, as appearing in the I2 packet. 3562 In a valid response puzzle, the #K low-order bits of the resulting 3563 RHASH digest MUST be zero. 3565 Notes: 3567 i) The length of the data to be hashed is variable depending on 3568 the output length of the Responder's hash function RHASH. 3570 ii) All the data in the hash input MUST be in network byte order. 3572 iii) The order of the Initiator's and Responder's HITs are 3573 different in the R1 and I2 packets; see Section 5.1. Care must be 3574 taken to copy the values in the right order to the hash input. 3576 iv) For a puzzle #I, there may exist multiple valid puzzle 3577 solutions #J. 3579 The following procedure describes the processing steps involved, 3580 assuming that the Responder chooses to precompute the R1 packets: 3582 Precomputation by the Responder: 3583 Sets up the puzzle difficulty #K. 3584 Creates a signed R1 and caches it. 3586 Responder: 3587 Selects a suitable cached R1. 3588 Generates a random number #I. 3589 Sends #I and #K in an R1. 3590 Saves #I and #K for a Delta time. 3592 Initiator: 3593 Generates repeated attempts to solve the puzzle until a matching 3594 #J is found: 3595 Ltrunc( RHASH( #I | HIT-I | HIT-R | #J ), #K ) == 0 3596 Sends #I and #J in an I2. 3598 Responder: 3599 Verifies that the received #I is a saved one. 3600 Finds the right #K based on #I. 3601 Computes V := Ltrunc( RHASH( #I | HIT-I | HIT-R | #J ), #K ) 3602 Rejects if V != 0 3603 Accept if V == 0 3605 6.4. HIP_MAC and SIGNATURE Calculation and Verification 3607 The following subsections define the actions for processing HIP_MAC, 3608 HIP_MAC_2, HIP_SIGNATURE and HIP_SIGNATURE_2 parameters. The 3609 HIP_MAC_2 parameter is contained in the R2 packet. The 3610 HIP_SIGNATURE_2 parameter is contained in the R1 packet. The 3611 HIP_SIGNATURE and HIP_MAC parameter are contained in other HIP 3612 control packets. 3614 6.4.1. HMAC Calculation 3616 The HMAC uses RHASH as underlying hash function. The type of RHASH 3617 depends on the HIT Suite of the Responder. Hence, HMAC-SHA-256 3618 [RFC4868] is used for HIT Suite RSA/DSA/SHA-256, HMAC-SHA-1 [RFC2404] 3619 is used for HIT Suite ECDSA_LOW/SHA-1, and HMAC-SHA-384 [RFC4868] for 3620 HIT Suite ECDSA/SHA-384. 3622 The following process applies both to the HIP_MAC and HIP_MAC_2 3623 parameters. When processing HIP_MAC_2, the difference is that the 3624 HIP_MAC calculation includes a pseudo HOST_ID field containing the 3625 Responder's information as sent in the R1 packet earlier. 3627 Both the Initiator and the Responder should take some care when 3628 verifying or calculating the HIP_MAC_2. Specifically, the Initiator 3629 has to preserve the HOST_ID exactly as it was received in the R1 3630 packet until it receives the HIP_MAC_2 in the R2 packet. 3632 The scope of the calculation for HIP_MAC is: 3634 HMAC: { HIP header | [ Parameters ] } 3636 where Parameters include all HIP parameters of the packet that is 3637 being calculated with Type values ranging from 1 to (HIP_MAC's Type 3638 value - 1) and exclude parameters with Type values greater or equal 3639 to HIP_MAC's Type value. 3641 During HIP_MAC calculation, the following applies: 3643 o In the HIP header, the Checksum field is set to zero. 3645 o In the HIP header, the Header Length field value is calculated to 3646 the beginning of the HIP_MAC parameter. 3648 Parameter order is described in Section 5.2.1. 3650 The scope of the calculation for HIP_MAC_2 is: 3652 HIP_MAC_2: { HIP header | [ Parameters ] | HOST_ID } 3654 where Parameters include all HIP parameters for the packet that is 3655 being calculated with Type values from 1 to (HIP_MAC_2's Type value - 3656 1) and exclude parameters with Type values greater or equal to 3657 HIP_MAC_2's Type value. 3659 During HIP_MAC_2 calculation, the following applies: 3661 o In the HIP header, the Checksum field is set to zero. 3663 o In the HIP header, the Header Length field value is calculated to 3664 the beginning of the HIP_MAC_2 parameter and increased by the 3665 length of the concatenated HOST_ID parameter length (including 3666 type and length fields). 3668 o HOST_ID parameter is exactly in the form it was received in the R1 3669 packet from the Responder. 3671 Parameter order is described in Section 5.2.1, except that the 3672 HOST_ID parameter in this calculation is added to the end. 3674 The HIP_MAC parameter is defined in Section 5.2.12 and the HIP_MAC_2 3675 parameter in Section 5.2.13. The HMAC calculation and verification 3676 process (the process applies both to HIP_MAC and HIP_MAC_2 except 3677 where HIP_MAC_2 is mentioned separately) is as follows: 3679 Packet sender: 3681 1. Create the HIP packet, without the HIP_MAC, HIP_SIGNATURE, 3682 HIP_SIGNATURE_2, or any other parameter with greater Type value 3683 than the HIP_MAC parameter has. 3685 2. In case of HIP_MAC_2 calculation, add a HOST_ID (Responder) 3686 parameter to the end of the packet. 3688 3. Calculate the Header Length field in the HIP header including the 3689 added HOST_ID parameter in case of HIP_MAC_2. 3691 4. Compute the HMAC using either HIP-gl or HIP-lg integrity key 3692 retrieved from KEYMAT as defined in Section 6.5. 3694 5. In case of HIP_MAC_2, remove the HOST_ID parameter from the 3695 packet. 3697 6. Add the HIP_MAC parameter to the packet and any parameter with 3698 greater Type value than the HIP_MAC's (HIP_MAC_2's) that may 3699 follow, including possible HIP_SIGNATURE or HIP_SIGNATURE_2 3700 parameters 3702 7. Recalculate the Length field in the HIP header. 3704 Packet receiver: 3706 1. Verify the HIP header Length field. 3708 2. Remove the HIP_MAC or HIP_MAC_2 parameter, as well as all other 3709 parameters that follow it with greater Type value including 3710 possible HIP_SIGNATURE or HIP_SIGNATURE_2 fields, saving the 3711 contents if they are needed later. 3713 3. In case of HIP_MAC_2, build and add a HOST_ID parameter (with 3714 Responder information) to the packet. The HOST_ID parameter 3715 should be identical to the one previously received from the 3716 Responder. 3718 4. Recalculate the HIP packet length in the HIP header and clear the 3719 Checksum field (set it to all zeros). In case of HIP_MAC_2, the 3720 length is calculated with the added HOST_ID parameter. 3722 5. Compute the HMAC using either HIP-gl or HIP-lg integrity key as 3723 defined in Section 6.5 and verify it against the received HMAC. 3725 6. Set Checksum and Header Length field in the HIP header to 3726 original values. Note that the checksum and length fields 3727 contain incorrect values after this step. 3729 7. In case of HIP_MAC_2, remove the HOST_ID parameter from the 3730 packet before further processing. 3732 6.4.2. Signature Calculation 3734 The following process applies both to the HIP_SIGNATURE and 3735 HIP_SIGNATURE_2 parameters. When processing the HIP_SIGNATURE_2, the 3736 only difference is that instead of the HIP_SIGNATURE parameter, the 3737 HIP_SIGNATURE_2 parameter is used, and the Initiator's HIT and PUZZLE 3738 Opaque and Random #I fields are cleared (set to all zeros) before 3739 computing the signature. The HIP_SIGNATURE parameter is defined in 3740 Section 5.2.14 and the HIP_SIGNATURE_2 parameter in Section 5.2.15. 3742 The scope of the calculation for HIP_SIGNATURE and HIP_SIGNATURE_2 3743 is: 3745 HIP_SIGNATURE: { HIP header | [ Parameters ] } 3747 where Parameters include all HIP parameters for the packet that is 3748 being calculated with Type values from 1 to (HIP_SIGNATURE's Type 3749 value - 1). 3751 During signature calculation, the following applies: 3753 o In the HIP header, the Checksum field is set to zero. 3755 o In the HIP header, the Header Length field value is calculated to 3756 the beginning of the HIP_SIGNATURE parameter. 3758 The parameter order is described in Section 5.2.1. 3760 HIP_SIGNATURE_2: { HIP header | [ Parameters ] } 3762 where Parameters include all HIP parameters for the packet that is 3763 being calculated with Type values ranging from 1 to 3764 (HIP_SIGNATURE_2's Type value - 1). 3766 During signature calculation, the following apply: 3768 o In the HIP header, the Initiator's HIT field and Checksum fields 3769 are set to zero. 3771 o In the HIP header, the Header Length field value is calculated to 3772 the beginning of the HIP_SIGNATURE_2 parameter. 3774 o PUZZLE parameter's Opaque and Random #I fields are set to zero. 3776 Parameter order is described in Section 5.2.1. 3778 The signature calculation and verification process (the process 3779 applies both to HIP_SIGNATURE and HIP_SIGNATURE_2 except in the case 3780 where HIP_SIGNATURE_2 is separately mentioned) is as follows: 3782 Packet sender: 3784 1. Create the HIP packet without the HIP_SIGNATURE parameter or any 3785 other parameters that follow the HIP_SIGNATURE parameter. 3787 2. Calculate the Length field and zero the Checksum field in the HIP 3788 header. In case of HIP_SIGNATURE_2, set Initiator's HIT field in 3789 the HIP header as well as PUZZLE parameter's Opaque and Random #I 3790 fields to zero. 3792 3. Compute the signature using the private key corresponding to the 3793 Host Identifier (public key). 3795 4. Add the HIP_SIGNATURE parameter to the packet. 3797 5. Add any parameters that follow the HIP_SIGNATURE parameter. 3799 6. Recalculate the Length field in the HIP header, and calculate the 3800 Checksum field. 3802 Packet receiver: 3804 1. Verify the HIP header Length field and checksum. 3806 2. Save the contents of the HIP_SIGNATURE parameter and any other 3807 parameters following the HIP_SIGNATURE parameter and remove them 3808 from the packet. 3810 3. Recalculate the HIP packet Length in the HIP header and clear the 3811 Checksum field (set it to all zeros). In case of 3812 HIP_SIGNATURE_2, set Initiator's HIT field in the HIP header as 3813 well as PUZZLE parameter's Opaque and Random #I fields to zero. 3815 4. Compute the signature and verify it against the received 3816 signature using the packet sender's Host Identity (public key). 3818 5. Restore the original packet by adding removed parameters (in step 3819 2) and resetting the values that were set to zero (in step 3). 3821 The verification can use either the HI received from a HIP packet, 3822 the HI from a DNS query, if the FQDN has been received in the HOST_ID 3823 packet or one received by some other means. 3825 6.5. HIP KEYMAT Generation 3827 HIP keying material is derived from the Diffie-Hellman session key, 3828 Kij, produced during the HIP base exchange (see Section 4.1.3). The 3829 Initiator has Kij during the creation of the I2 packet, and the 3830 Responder has Kij once it receives the I2 packet. This is why I2 can 3831 already contain encrypted information. 3833 The KEYMAT is derived by feeding Kij into the key derivation function 3834 defined by the DH Group ID. Currently the only key derivation 3835 function defied in this document is the Hash-based Key Derivation 3836 Function (HKDF) [RFC5869] using the RHASH hash function. Other 3837 documents may define new DH Group IDs and corresponding key 3838 distribution functions. 3840 In the following we provide the details for deriving the keying 3841 material using HKDF. 3843 where 3845 info = sort(HIT-I | HIT-R) 3846 salt = #I | #J 3848 Sort(HIT-I | HIT-R) is defined as the network byte order 3849 concatenation of the two HITs, with the smaller HIT preceding the 3850 larger HIT, resulting from the numeric comparison of the two HITs 3851 interpreted as positive (unsigned) 128-bit integers in network byte 3852 order. The #I and #J values are from the puzzle and its solution 3853 that were exchanged in R1 and I2 messages when this HIP association 3854 was set up. Both hosts have to store #I and #J values for the HIP 3855 association for future use. 3857 The initial keys are drawn sequentially in the order that is 3858 determined by the numeric comparison of the two HITs, with comparison 3859 method described in the previous paragraph. HOST_g denotes the host 3860 with the greater HIT value, and HOST_l the host with the lower HIT 3861 value. 3863 The drawing order for the four initial keys is as follows: 3865 HIP-gl encryption key for HOST_g's ENCRYPTED parameter 3867 HIP-gl integrity (HMAC) key for HOST_g's outgoing HIP packets 3868 HIP-lg encryption key for HOST_l's ENCRYPTED parameter 3870 HIP-lg integrity (HMAC) key for HOST_l's outgoing HIP packets 3872 The number of bits drawn for a given algorithm is the "natural" size 3873 of the keys. For the mandatory algorithms, the following sizes 3874 apply: 3876 AES 128 or 256 bits 3878 SHA-1 160 bits 3880 SHA-256 256 bits 3882 SHA-384 384 bits 3884 NULL 0 bits 3886 If other key sizes are used, they MUST be treated as different 3887 encryption algorithms and defined separately. 3889 6.6. Initiation of a HIP Base Exchange 3891 An implementation may originate a HIP base exchange to another host 3892 based on a local policy decision, usually triggered by an application 3893 datagram, in much the same way that an IPsec IKE key exchange can 3894 dynamically create a Security Association. Alternatively, a system 3895 may initiate a HIP exchange if it has rebooted or timed out, or 3896 otherwise lost its HIP state, as described in Section 4.5.4. 3898 The implementation prepares an I1 packet and sends it to the IP 3899 address that corresponds to the peer host. The IP address of the 3900 peer host may be obtained via conventional mechanisms, such as DNS 3901 lookup. The I1 packet contents are specified in Section 5.3.1. The 3902 selection of which source or destination Host Identity to use, if a 3903 Initiator or Responder has more than one to choose from, is typically 3904 a policy decision. 3906 The following steps define the conceptual processing rules for 3907 initiating a HIP base exchange: 3909 1. The Initiator receives one or more of the Responder's HITs and 3910 one or more addresses either from a DNS lookup of the Responder's 3911 FQDN, from some other repository, or from a local database. If 3912 the Initiator does not know the Responder's HIT, it may attempt 3913 opportunistic mode by using NULL (all zeros) as the Responder's 3914 HIT (see also "HIP Opportunistic Mode" (Section 4.1.8)). If the 3915 Initiator can choose from multiple Responder HITs, it selects a 3916 HIT for which the Initiator supports the HIT Suite. 3918 2. The Initiator sends an I1 packet to one of the Responder's 3919 addresses. The selection of which address to use is a local 3920 policy decision. 3922 3. The Initiator includes the DH_GROUP_LIST in the I1 packet. The 3923 selection and order of DH Group IDs in the DH_GROUP_LIST MUST be 3924 stored by the Initiator because this list is needed for later R1 3925 processing. In most cases, the preferences regarding the DH 3926 Groups will be static, so no per-association storage is 3927 necessary. 3929 4. Upon sending an I1 packet, the sender transitions to state I1- 3930 SENT, starts a timer for which the timeout value SHOULD be larger 3931 than the worst-case anticipated RTT. The sender SHOULD also 3932 increment the timeout counter associated with the I1. 3934 5. Upon timeout, the sender SHOULD retransmit the I1 packet and 3935 restart the timer, up to a maximum of I1_RETRIES_MAX tries. 3937 6.6.1. Sending Multiple I1 Packets in Parallel 3939 For the sake of minimizing the session establishment latency, an 3940 implementation MAY send the same I1 packet to more than one of the 3941 Responder's addresses. However, it MUST NOT send to more than three 3942 (3) Responder addresses in parallel. Furthermore, upon timeout, the 3943 implementation MUST refrain from sending the same I1 packet to 3944 multiple addresses. That is, if it retries to initialize the 3945 connection after a timeout, it MUST NOT send the I1 packet to more 3946 than one destination address. These limitations are placed in order 3947 to avoid congestion of the network, and potential DoS attacks that 3948 might occur, e.g., because someone's claim to have hundreds or 3949 thousands of addresses could generate a huge number of I1 packets 3950 from the Initiator. 3952 As the Responder is not guaranteed to distinguish the duplicate I1 3953 packets it receives at several of its addresses (because it avoids 3954 storing states when it answers back an R1 packet), the Initiator may 3955 receive several duplicate R1 packets. 3957 The Initiator SHOULD then select the initial preferred destination 3958 address using the source address of the selected received R1, and use 3959 the preferred address as a source address for the I2 packet. 3960 Processing rules for received R1s are discussed in Section 6.8. 3962 6.6.2. Processing Incoming ICMP Protocol Unreachable Messages 3964 A host may receive an ICMP 'Destination Protocol Unreachable' message 3965 as a response to sending a HIP I1 packet. Such a packet may be an 3966 indication that the peer does not support HIP, or it may be an 3967 attempt to launch an attack by making the Initiator believe that the 3968 Responder does not support HIP. 3970 When a system receives an ICMP 'Destination Protocol Unreachable' 3971 message while it is waiting for an R1 packet, it MUST NOT terminate 3972 waiting. It MAY continue as if it had not received the ICMP message, 3973 and send a few more I1 packets. Alternatively, it MAY take the ICMP 3974 message as a hint that the peer most probably does not support HIP, 3975 and return to state UNASSOCIATED earlier than otherwise. However, at 3976 minimum, it MUST continue waiting for an R1 packet for a reasonable 3977 time before returning to UNASSOCIATED. 3979 6.7. Processing Incoming I1 Packets 3981 An implementation SHOULD reply to an I1 with an R1 packet, unless the 3982 implementation is unable or unwilling to set up a HIP association. 3983 If the implementation is unable to set up a HIP association, the host 3984 SHOULD send an ICMP Destination Protocol Unreachable, 3985 Administratively Prohibited, message to the I1 packet source IP 3986 address. If the implementation is unwilling to set up a HIP 3987 association, the host MAY ignore the I1 packet. This latter case may 3988 occur during a DoS attack such as an I1 packet flood. 3990 The implementation SHOULD be able to handle a storm of received I1 3991 packets, discarding those with common content that arrive within a 3992 small time delta. 3994 A spoofed I1 packet can result in an R1 attack on a system. An R1 3995 packet sender MUST have a mechanism to rate-limit R1 packets sent to 3996 an address. 3998 It is RECOMMENDED that the HIP state machine does not transition upon 3999 sending an R1 packet. 4001 The following steps define the conceptual processing rules for 4002 responding to an I1 packet: 4004 1. The Responder MUST check that the Responder's HIT in the received 4005 I1 packet is either one of its own HITs or NULL. Otherwise it 4006 must drop the packet. 4008 2. If the Responder is in ESTABLISHED state, the Responder MAY 4009 respond to this with an R1 packet, prepare to drop an existing 4010 HIP security association with the peer, and stay at ESTABLISHED 4011 state. 4013 3. If the Responder is in I1-SENT state, it MUST make a comparison 4014 between the sender's HIT and its own (i.e., the receiver's) HIT. 4015 If the sender's HIT is greater than its own HIT, it should drop 4016 the I1 packet and stay at I1-SENT. If the sender's HIT is 4017 smaller than its own HIT, it SHOULD send the R1 packet and stay 4018 at I1-SENT. The HIT comparison is performed as defined in 4019 Section 6.5. 4021 4. If the implementation chooses to respond to the I1 packet with an 4022 R1 packet, it creates a new R1 or selects a precomputed R1 4023 according to the format described in Section 5.3.2. It creates 4024 or chooses an R1 that contains its most preferred DH public value 4025 that is also contained in the DH_GROUP_LIST in the I1 packet. If 4026 no suitable DH Group ID was contained in the DH_GROUP_LIST in the 4027 I1 packet, it sends an R1 with any suitable DH public key. 4029 5. If the received Responder's HIT in the I1 is NULL, the Responder 4030 selects a HIT with a the same HIT Suite as the Initiator's HIT. 4031 If this HIT Suite is not supported by the Responder, it SHOULD 4032 select a REQUIRED HIT Suite from Section 5.2.10, which is 4033 currently RSA/DSA/SHA-256. Other than that, selecting the HIT is 4034 a local policy matter. 4036 6. The responder expresses its supported HIP transport formats in 4037 the TRANSPORT_FORMAT_LIST as described in Section 5.2.11. The 4038 Responder MUST at least provide one payload transport format 4039 type. 4041 7. The Responder sends the R1 packet to the source IP address of the 4042 I1 packet. 4044 6.7.1. R1 Management 4046 All compliant implementations MUST be able to produce R1 packets. An 4047 R1 packet MAY be precomputed. An R1 packet MAY be reused for time 4048 Delta T, which is implementation dependent, and SHOULD be deprecated 4049 and not used once a valid response I2 packet has been received from 4050 an Initiator. During an I1 message storm, an R1 packet MAY be re- 4051 used beyond this limit. R1 information MUST NOT be discarded until 4052 Delta S after T. Time S is the delay needed for the last I2 packet 4053 to arrive back to the Responder. 4055 Implementations that support multiple DH groups MAY pre-compute R1 4056 packets for each supported group so that incoming I1 packets with 4057 different DH Group IDs in the DH_GROUP_LIST can be served quickly. 4059 An implementation MAY keep state about received I1 packets and match 4060 the received I2 packets against the state, as discussed in 4061 Section 4.1.1. 4063 6.7.2. Handling Malformed Messages 4065 If an implementation receives a malformed I1 packet, it SHOULD NOT 4066 respond with a NOTIFY message, as such practice could open up a 4067 potential denial-of-service threat. Instead, it MAY respond with an 4068 ICMP packet, as defined in Section 5.4. 4070 6.8. Processing Incoming R1 Packets 4072 A system receiving an R1 packet MUST first check to see if it has 4073 sent an I1 packet to the originator of the R1 packet (i.e., it is in 4074 state I1-SENT). If so, it SHOULD process the R1 as described below, 4075 send an I2 packet, and transition to state I2-SENT, setting a timer 4076 to protect the I2 packet. If the system is in state I2-SENT, it MAY 4077 respond to the R1 packet if the R1 packet has a larger R1 generation 4078 counter; if so, it should drop its state due to processing the 4079 previous R1 packet and start over from state I1-SENT. If the system 4080 is in any other state with respect to that host, the system SHOULD 4081 silently drop the R1 packet. 4083 When sending multiple I1 packets, an Initiator SHOULD wait for a 4084 small amount of time after the first R1 reception to allow possibly 4085 multiple R1 packets to arrive, and it SHOULD respond to an R1 packet 4086 among the set with the largest R1 generation counter. 4088 The following steps define the conceptual processing rules for 4089 responding to an R1 packet: 4091 1. A system receiving an R1 MUST first check to see if it has sent 4092 an I1 packet to the originator of the R1 packet (i.e., it has a 4093 HIP association that is in state I1-SENT and that is associated 4094 with the HITs in the R1). Unless the I1 packet was sent in 4095 opportunistic mode (see Section 4.1.8), the IP addresses in the 4096 received R1 packet SHOULD be ignored by the R1 processing and, 4097 when looking up the right HIP association, the received R1 4098 packet SHOULD be matched against the associations using only the 4099 HITs. If a match exists, the system should process the R1 4100 packet as described below. 4102 2. Otherwise, if the system is in any other state than I1-SENT or 4103 I2-SENT with respect to the HITs included in the R1 packet, it 4104 SHOULD silently drop the R1 packet and remain in the current 4105 state. 4107 3. If the HIP association state is I1-SENT or I2-SENT, the received 4108 Initiator's HIT MUST correspond to the HIT used in the original 4109 I1. Also, the Responder's HIT MUST correspond to the one used 4110 in the I1, unless the I1 packet contained a NULL HIT. 4112 4. The system SHOULD validate the R1 signature before applying 4113 further packet processing, according to Section 5.2.15. 4115 5. If the HIP association state is I1-SENT, and multiple valid R1 4116 packets are present, the system MUST select from among the R1 4117 packets with the largest R1 generation counter. 4119 6. The system MUST check that the Initiator HIT Suite is contained 4120 in the HIT_SUITE_LIST parameter in the R1 packet (i.e., the 4121 Initiator's HIT Suite is supported by the Responder). If the 4122 HIT Suite is supported by the Responder, the system proceeds 4123 normally. Otherwise, the system MAY stay in state I1-sent and 4124 restart the BEX by sending a new I1 packet with an Initiator HIT 4125 that is supported by the Responder and hence is contained in the 4126 HIT_SUITE_LIST in the R1 packet. The system MAY abort the BEX 4127 if no suitable source HIT is available. The system SHOULD wait 4128 for an acceptable time span to allow further R1 packets with 4129 higher R1 generation counters or different HIT and HIT Suites to 4130 arrive before restarting or aborting the BEX. 4132 7. The system MUST check that the DH Group ID in the DIFFIE_HELLMAN 4133 parameter in the R1 matches the first DH Suite ID in the 4134 Responder's DH_GROUP_LIST in the R1 packet that was also 4135 contained in the Initiator's DH_GROUP_LIST in the I1 packet. If 4136 the DH Group ID of the DIFFIE_HELLMAN parameter does not express 4137 the Responder's best choice, the Initiator can conclude that the 4138 DH_GROUP_LIST in the I1 packet was adversely modified. In such 4139 case, the Initiator MAY send a new I1 packet, however, it SHOULD 4140 NOT change its preference in the DH_GROUP_LIST in the new I1 4141 packet. Alternatively, the Initiator MAY abort the HIP base 4142 exchange. 4144 8. If the HIP association state is I2-SENT, the system MAY re-enter 4145 state I1-SENT and process the received R1 packet if it has a 4146 larger R1 generation counter than the R1 packet responded to 4147 previously. 4149 9. The R1 packet may have the A bit set -- in this case, the system 4150 MAY choose to refuse it by dropping the R1 packet and returning 4151 to state UNASSOCIATED. The system SHOULD consider dropping the 4152 R1 packet only if it used a NULL HIT in I1 packet. If the A bit 4153 is set, the Responder's HIT is anonymous and SHOULD NOT be 4154 stored permanently. 4156 10. The system SHOULD attempt to validate the HIT against the 4157 received Host Identity by using the received Host Identity to 4158 construct a HIT and verify that it matches the Sender's HIT. 4160 11. The system MUST store the received R1 generation counter for 4161 future reference. 4163 12. The system attempts to solve the puzzle in the R1 packet. The 4164 system MUST terminate the search after exceeding the remaining 4165 lifetime of the puzzle. If the puzzle is not successfully 4166 solved, the implementation MAY either resend the I1 packet 4167 within the retry bounds or abandon the HIP base exchange. 4169 13. The system computes standard Diffie-Hellman keying material 4170 according to the public value and Group ID provided in the 4171 DIFFIE_HELLMAN parameter. The Diffie-Hellman keying material 4172 Kij is used for key extraction as specified in Section 6.5. 4174 14. The system selects the HIP_CIPHER ID from the choices presented 4175 in the R1 packet and uses the selected values subsequently when 4176 generating and using encryption keys, and when sending the I2 4177 packet. If the proposed alternatives are not acceptable to the 4178 system, it may either resend an I1 within the retry bounds or 4179 abandon the HIP base exchange. 4181 15. The system chooses one suitable transport format from the 4182 TRANSPORT_FORMAT_LIST and includes the respective transport 4183 format parameter in the subsequent I2 packet. 4185 16. The system initializes the remaining variables in the associated 4186 state, including Update ID counters. 4188 17. The system prepares and sends an I2 packet, as described in 4189 Section 5.3.3. 4191 18. The system SHOULD start a timer whose timeout value SHOULD be 4192 larger than the worst-case anticipated RTT, and MUST increment a 4193 timeout counter associated with the I2 packet. The sender 4194 SHOULD retransmit the I2 packet upon a timeout and restart the 4195 timer, up to a maximum of I2_RETRIES_MAX tries. 4197 19. If the system is in state I1-SENT, it SHALL transition to state 4198 I2-SENT. If the system is in any other state, it remains in the 4199 current state. 4201 6.8.1. Handling of Malformed Messages 4203 If an implementation receives a malformed R1 message, it MUST 4204 silently drop the packet. Sending a NOTIFY or ICMP would not help, 4205 as the sender of the R1 packet typically doesn't have any state. An 4206 implementation SHOULD wait for some more time for a possibly well- 4207 formed R1, after which it MAY try again by sending a new I1 packet. 4209 6.9. Processing Incoming I2 Packets 4211 Upon receipt of an I2 packet, the system MAY perform initial checks 4212 to determine whether the I2 packet corresponds to a recent R1 packet 4213 that has been sent out, if the Responder keeps such state. For 4214 example, the sender could check whether the I2 packet is from an 4215 address or HIT for which the Responder has recently received an I1. 4216 The R1 packet may have had Opaque data included that was echoed back 4217 in the I2 packet. If the I2 packet is considered to be suspect, it 4218 MAY be silently discarded by the system. 4220 Otherwise, the HIP implementation SHOULD process the I2 packet. This 4221 includes validation of the puzzle solution, generating the Diffie- 4222 Hellman key, possibly decrypting the Initiator's Host Identity, 4223 verifying the signature, creating state, and finally sending an R2 4224 packet. 4226 The following steps define the conceptual processing rules for 4227 responding to an I2 packet: 4229 1. The system MAY perform checks to verify that the I2 packet 4230 corresponds to a recently sent R1 packet. Such checks are 4231 implementation dependent. See Appendix A for a description of 4232 an example implementation. 4234 2. The system MUST check that the Responder's HIT corresponds to 4235 one of its own HITs and MUST drop the packet otherwise. 4237 3. The system MUST further check that the Initiator's HIT Suite is 4238 supported. The Responder SHOULD silently drop I2 packets with 4239 unsupported Initiator HITs. 4241 4. If the system's state machine is in the R2-SENT state, the 4242 system MAY check if the newly received I2 packet is similar to 4243 the one that triggered moving to R2-SENT. If so, it MAY 4244 retransmit a previously sent R2 packet, reset the R2-SENT timer, 4245 and the state machine stays in R2-SENT. 4247 5. If the system's state machine is in the I2-SENT state, the 4248 system makes a comparison between its local and sender's HITs 4249 (similarly as in Section 6.5). If the local HIT is smaller than 4250 the sender's HIT, it should drop the I2 packet, use the peer 4251 Diffie-Hellman key and nonce #I from the R1 packet received 4252 earlier, and get the local Diffie-Hellman key and nonce #J from 4253 the I2 packet sent to the peer earlier. Otherwise, the system 4254 should process the received I2 packet and drop any previously 4255 derived Diffie-Hellman keying material Kij it might have formed 4256 upon sending the I2 packet previously. The peer Diffie-Hellman 4257 key and the nonce #J are taken from the just arrived I2 packet. 4258 The local Diffie-Hellman key and the nonce I are the ones that 4259 were sent earlier in the R1 packet. 4261 6. If the system's state machine is in the I1-SENT state, and the 4262 HITs in the I2 packet match those used in the previously sent I1 4263 packet, the system uses this received I2 packet as the basis for 4264 the HIP association it was trying to form, and stops 4265 retransmitting I1 packets (provided that the I2 packet passes 4266 the additional checks below). 4268 7. If the system's state machine is in any other state than R2- 4269 SENT, the system SHOULD check that the echoed R1 generation 4270 counter in the I2 packet is within the acceptable range if the 4271 counter is included. Implementations MUST accept puzzles from 4272 the current generation and MAY accept puzzles from earlier 4273 generations. If the generation counter in the newly received I2 4274 packet is outside the accepted range, the I2 packet is stale 4275 (and perhaps replayed) and SHOULD be dropped. 4277 8. The system MUST validate the solution to the puzzle by computing 4278 the hash described in Section 5.3.3 using the same RHASH 4279 algorithm. 4281 9. The I2 packet MUST have a single value in the HIP_CIPHER 4282 parameter, which MUST match one of the values offered to the 4283 Initiator in the R1 packet. 4285 10. The system must derive Diffie-Hellman keying material Kij based 4286 on the public value and Group ID in the DIFFIE_HELLMAN 4287 parameter. This key is used to derive the HIP association keys, 4288 as described in Section 6.5. If the Diffie-Hellman Group ID is 4289 unsupported, the I2 packet is silently dropped. 4291 11. The encrypted HOST_ID is decrypted by the Initiator's encryption 4292 key defined in Section 6.5. If the decrypted data is not a 4293 HOST_ID parameter, the I2 packet is silently dropped. 4295 12. The implementation SHOULD also verify that the Initiator's HIT 4296 in the I2 packet corresponds to the Host Identity sent in the I2 4297 packet. (Note: some middleboxes may not able to make this 4298 verification.) 4300 13. The system MUST process the TRANSPORT_FORMAT_LIST parameter. 4301 Other documents specifying transport formats (e.g. 4302 [I-D.ietf-hip-rfc5202-bis]) contain specifications for handling 4303 any specific transport selected. 4305 14. The system MUST verify the HIP_MAC according to the procedures 4306 in Section 5.2.12. 4308 15. The system MUST verify the HIP_SIGNATURE according to 4309 Section 5.2.14 and Section 5.3.3. 4311 16. If the checks above are valid, then the system proceeds with 4312 further I2 processing; otherwise, it discards the I2 and its 4313 state machine remains in the same state. 4315 17. The I2 packet may have the A bit set -- in this case, the system 4316 MAY choose to refuse it by dropping the I2 and the state machine 4317 returns to state UNASSOCIATED. If the A bit is set, the 4318 Initiator's HIT is anonymous and should not be stored 4319 permanently. 4321 18. The system initializes the remaining variables in the associated 4322 state, including Update ID counters. 4324 19. Upon successful processing of an I2 message when the system's 4325 state machine is in state UNASSOCIATED, I1-SENT, I2-SENT, or R2- 4326 SENT, an R2 packet is sent and the system's state machine 4327 transitions to state R2-SENT. 4329 20. Upon successful processing of an I2 packet when the system's 4330 state machine is in state ESTABLISHED, the old HIP association 4331 is dropped and a new one is installed, an R2 packet is sent, and 4332 the system's state machine transitions to R2-SENT. 4334 21. Upon the system's state machine transitioning to R2-SENT, the 4335 system starts a timer. The state machine transitions to 4336 ESTABLISHED if some data has been received on the incoming HIP 4337 association, or an UPDATE packet has been received (or some 4338 other packet that indicates that the peer system's state machine 4339 has moved to ESTABLISHED). If the timer expires (allowing for 4340 maximal amount of retransmissions of I2 packets), the state 4341 machine transitions to ESTABLISHED. 4343 6.9.1. Handling of Malformed Messages 4345 If an implementation receives a malformed I2 message, the behavior 4346 SHOULD depend on how many checks the message has already passed. If 4347 the puzzle solution in the message has already been checked, the 4348 implementation SHOULD report the error by responding with a NOTIFY 4349 packet. Otherwise, the implementation MAY respond with an ICMP 4350 message as defined in Section 5.4. 4352 6.10. Processing of Incoming R2 Packets 4354 An R2 packet received in states UNASSOCIATED, I1-SENT, or ESTABLISHED 4355 results in the R2 packet being dropped and the state machine staying 4356 in the same state. If an R2 packet is received in state I2-SENT, it 4357 MUST be processed. 4359 The following steps define the conceptual processing rules for an 4360 incoming R2 packet: 4362 1. If the system is in any other state than I2-SENT, the R2 packet 4363 is silently dropped. 4365 2. The system MUST verify that the HITs in use correspond to the 4366 HITs that were received in the R1 packet that caused the 4367 transition to the I1-SENT state. 4369 3. The system MUST verify the HIP_MAC_2 according to the procedures 4370 in Section 5.2.13. 4372 4. The system MUST verify the HIP signature according to the 4373 procedures in Section 5.2.14. 4375 5. If any of the checks above fail, there is a high probability of 4376 an ongoing man-in-the-middle or other security attack. The 4377 system SHOULD act accordingly, based on its local policy. 4379 6. Upon successful processing of the R2 packet, the state machine 4380 transitions to state ESTABLISHED. 4382 6.11. Sending UPDATE Packets 4384 A host sends an UPDATE packet when it intends to update some 4385 information related to a HIP association. There are a number of 4386 possible scenarios when this can occur, e.g., mobility management and 4387 rekeying of an existing ESP Security Association. The following 4388 paragraphs define the conceptual rules for sending an UPDATE packet 4389 to the peer. Additional steps can be defined in other documents 4390 where the UPDATE packet is used. 4392 The sequence of UPDATE messages is indicated by their SEQ parameter. 4393 Before sending an UPDATE message, the system first determines whether 4394 there are any outstanding UPDATE messages that may conflict with the 4395 new UPDATE message under consideration. When multiple UPDATEs are 4396 outstanding (not yet acknowledged), the sender must assume that such 4397 UPDATEs may be processed in an arbitrary order by the receiver. 4398 Therefore, any new UPDATEs that depend on a previous outstanding 4399 UPDATE being successfully received and acknowledged MUST be postponed 4400 until reception of the necessary ACK(s) occurs. One way to prevent 4401 any conflicts is to only allow one outstanding UPDATE at a time. 4402 However, allowing multiple UPDATEs may improve the performance of 4403 mobility and multihoming protocols. 4405 The following steps define the conceptual processing rules for 4406 sending UPDATE packets. 4408 1. The first UPDATE packet is sent with Update ID of zero. 4409 Otherwise, the system increments its own Update ID value by one 4410 before continuing the steps below. 4412 2. The system creates an UPDATE packet that contains a SEQ parameter 4413 with the current value of Update ID. The UPDATE packet MAY also 4414 include zero or more ACKs of the peer's Update ID(s) from 4415 previously received UPDATE SEQ parameter(s) 4417 3. The system sends the created UPDATE packet and starts an UPDATE 4418 timer. The default value for the timer is 2 * RTT estimate. If 4419 multiple UPDATEs are outstanding, multiple timers are in effect. 4421 4. If the UPDATE timer expires, the UPDATE is resent. The UPDATE 4422 can be resent UPDATE_RETRY_MAX times. The UPDATE timer SHOULD be 4423 exponentially backed off for subsequent retransmissions. If no 4424 acknowledgment is received from the peer after UPDATE_RETRY_MAX 4425 times, the HIP association is considered to be broken and the 4426 state machine SHOULD move from state ESTABLISHED to state CLOSING 4427 as depicted in Section 4.4.4. The UPDATE timer is cancelled upon 4428 receiving an ACK from the peer that acknowledges receipt of the 4429 UPDATE. 4431 6.12. Receiving UPDATE Packets 4433 When a system receives an UPDATE packet, its processing depends on 4434 the state of the HIP association and the presence and values of the 4435 SEQ and ACK parameters. Typically, an UPDATE message also carries 4436 optional parameters whose handling is defined in separate documents. 4438 For each association, a host stores the peer's next expected in- 4439 sequence Update ID ("peer Update ID"). Initially, this value is 4440 zero. Update ID comparisons of "less than" and "greater than" are 4441 performed with respect to a circular sequence number space. Hence, a 4442 wrap around after 2^32 updates has to be expected and MUST be handled 4443 accordingly. 4445 The sender MAY send multiple outstanding UPDATE messages. These 4446 messages are processed in the order in which they are received at the 4447 receiver (i.e., no re-sequencing is performed). When processing 4448 UPDATEs out-of-order, the receiver MUST keep track of which UPDATEs 4449 were previously processed, so that duplicates or retransmissions are 4450 ACKed and not reprocessed. A receiver MAY choose to define a receive 4451 window of Update IDs that it is willing to process at any given time, 4452 and discard received UPDATEs falling outside of that window. 4454 The following steps define the conceptual processing rules for 4455 receiving UPDATE packets. 4457 1. If there is no corresponding HIP association, the implementation 4458 MAY reply with an ICMP Parameter Problem, as specified in 4459 Section 5.4.4. 4461 2. If the association is in the ESTABLISHED state and the SEQ (but 4462 not ACK) parameter is present, the UPDATE is processed and 4463 replied to as described in Section 6.12.1. 4465 3. If the association is in the ESTABLISHED state and the ACK (but 4466 not SEQ) parameter is present, the UPDATE is processed as 4467 described in Section 6.12.2. 4469 4. If the association is in the ESTABLISHED state and there is both 4470 an ACK and SEQ in the UPDATE, the ACK is first processed as 4471 described in Section 6.12.2, and then the rest of the UPDATE is 4472 processed as described in Section 6.12.1. 4474 6.12.1. Handling a SEQ Parameter in a Received UPDATE Message 4476 The following steps define the conceptual processing rules for 4477 handling a SEQ parameter in a received UPDATE packet. 4479 1. If the Update ID in the received SEQ is not the next in the 4480 sequence of Update IDs and is greater than the receiver's window 4481 for new UPDATEs, the packet MUST be dropped. 4483 2. If the Update ID in the received SEQ corresponds to an UPDATE 4484 that has recently been processed, the packet is treated as a 4485 retransmission. The HIP_MAC verification (next step) MUST NOT be 4486 skipped. (A byte-by-byte comparison of the received and a stored 4487 packet would be acceptable, though.) It is recommended that a 4488 host caches UPDATE packets sent with ACKs to avoid the cost of 4489 generating a new ACK packet to respond to a replayed UPDATE. The 4490 system MUST acknowledge, again, such (apparent) UPDATE message 4491 retransmissions but SHOULD also consider rate-limiting such 4492 retransmission responses to guard against replay attacks. 4494 3. The system MUST verify the HIP_MAC in the UPDATE packet. If the 4495 verification fails, the packet MUST be dropped. 4497 4. The system MAY verify the SIGNATURE in the UPDATE packet. If the 4498 verification fails, the packet SHOULD be dropped and an error 4499 message logged. 4501 5. If a new SEQ parameter is being processed, the parameters in the 4502 UPDATE are then processed. The system MUST record the Update ID 4503 in the received SEQ parameter, for replay protection. 4505 6. An UPDATE acknowledgment packet with ACK parameter is prepared 4506 and sent to the peer. This ACK parameter MAY be included in a 4507 separate UPDATE or piggybacked in an UPDATE with SEQ parameter, 4508 as described in Section 5.3.5. The ACK parameter MAY acknowledge 4509 more than one of the peer's Update IDs. 4511 6.12.2. Handling an ACK Parameter in a Received UPDATE Packet 4513 The following steps define the conceptual processing rules for 4514 handling an ACK parameter in a received UPDATE packet. 4516 1. The sequence number reported in the ACK must match with an UPDATE 4517 packet sent earlier that has not already been acknowledged. If 4518 no match is found or if the ACK does not acknowledge a new 4519 UPDATE, the packet MUST either be dropped if no SEQ parameter is 4520 present, or the processing steps in Section 6.12.1 are followed. 4522 2. The system MUST verify the HIP_MAC in the UPDATE packet. If the 4523 verification fails, the packet MUST be dropped. 4525 3. The system MAY verify the SIGNATURE in the UPDATE packet. If the 4526 verification fails, the packet SHOULD be dropped and an error 4527 message logged. 4529 4. The corresponding UPDATE timer is stopped (see Section 6.11) so 4530 that the now acknowledged UPDATE is no longer retransmitted. If 4531 multiple UPDATEs are acknowledged, multiple timers are stopped. 4533 6.13. Processing of NOTIFY Packets 4535 Processing of NOTIFY packets is OPTIONAL. If processed, any errors 4536 in a received NOTIFICATION parameter SHOULD be logged. Received 4537 errors MUST be considered only as informational, and the receiver 4538 SHOULD NOT change its HIP state (see Section 4.4.2) purely based on 4539 the received NOTIFY message. 4541 6.14. Processing CLOSE Packets 4543 When the host receives a CLOSE message, it responds with a CLOSE_ACK 4544 message and moves to CLOSED state. (The authenticity of the CLOSE 4545 message is verified using both HIP_MAC and SIGNATURE). This 4546 processing applies whether or not the HIP association state is 4547 CLOSING in order to handle simultaneous CLOSE messages from both ends 4548 that cross in flight. 4550 The HIP association is not discarded before the host moves to the 4551 UNASSOCIATED state. 4553 Once the closing process has started, any new need to send data 4554 packets triggers creating and establishing of a new HIP association, 4555 starting with sending of an I1 packet. 4557 If there is no corresponding HIP association, the CLOSE packet is 4558 dropped. 4560 6.15. Processing CLOSE_ACK Packets 4562 When a host receives a CLOSE_ACK message, it verifies that it is in 4563 CLOSING or CLOSED state and that the CLOSE_ACK was in response to the 4564 CLOSE. A host can map CLOSE_ACK messages to CLOSE messages by 4565 comparing the value of ECHO_REQUEST_SIGNED (in the CLOSE packet) to 4566 the value of ECHO_RESPONSE_SIGNED (in the CLOSE_ACK packet). 4568 The CLOSE_ACK contains the HIP_MAC and the SIGNATURE parameters for 4569 verification. The state is discarded when the state changes to 4570 UNASSOCIATED and, after that, the host MAY respond with an ICMP 4571 Parameter Problem to an incoming CLOSE message (see Section 5.4.4). 4573 6.16. Handling State Loss 4575 In the case of a system crash and unanticipated state loss, the 4576 system SHOULD delete the corresponding HIP state, including the 4577 keying material. That is, the state SHOULD NOT be stored in long- 4578 term storage. If the implementation does drop the state (as 4579 RECOMMENDED), it MUST also drop the peer's R1 generation counter 4580 value, unless a local policy explicitly defines that the value of 4581 that particular host is stored. An implementation MUST NOT store a 4582 peer's R1 generation counters by default, but storing R1 generation 4583 counter values, if done, MUST be configured by explicit HITs. 4585 7. HIP Policies 4587 There are a number of variables that will influence the HIP base 4588 exchanges that each host must support. All HIP implementations MUST 4589 support more than one simultaneous HI, at least one of which SHOULD 4590 be reserved for anonymous usage. Although anonymous HIs will be 4591 rarely used as Responders' HIs, they will be common for Initiators. 4592 Support for more than two HIs is RECOMMENDED. 4594 Initiators MAY use a different HI for different Responders to provide 4595 basic privacy. Whether such private HIs are used repeatedly with the 4596 same Responder and how long these HIs are used is decided by local 4597 policy and depends on the privacy requirements of the Initiator. 4599 The value of #K used in the HIP R1 must be chosen with care. Too 4600 high numbers of #K will exclude clients with weak CPUs because these 4601 devices cannot solve the puzzle within reasonable time. #K should 4602 only be raised if a Responder is under high load, i.e., it cannot 4603 process all incoming HIP handshakes any more. If a responder is not 4604 under high load, K SHOULD be 0. 4606 Responders that only respond to selected Initiators require an ACL, 4607 representing for which hosts they accept HIP base exchanges, and the 4608 preferred transform and local lifetimes. Wildcarding SHOULD be 4609 supported for such ACLs, and also for Responders that offer public or 4610 anonymous services. 4612 8. Security Considerations 4614 HIP is designed to provide secure authentication of hosts. HIP also 4615 attempts to limit the exposure of the host to various denial-of- 4616 service and man-in-the-middle (MitM) attacks. In doing so, HIP 4617 itself is subject to its own DoS and MitM attacks that potentially 4618 could be more damaging to a host's ability to conduct business as 4619 usual. 4621 Denial-of-service attacks often take advantage of asymmetries in the 4622 cost of an starting an association. One example of such asymmetry is 4623 the need of a Responder to store local state while a malicious 4624 Initiator can stay stateless. HIP makes no attempt to increase the 4625 cost of the start of state at the Initiator, but makes an effort to 4626 reduce the cost for the Responder. This is accomplished by having 4627 the Responder start the 3-way exchange instead of the Initiator, 4628 making the HIP protocol 4 packets long. In doing this, the first 4629 packet from the Responder, R1, becomes a 'stock' packet that the 4630 Responder MAY use many times, until some Initiator has provided a 4631 valid response to such an R1 packet. During an I1 packet storm, the 4632 host may reuse the same DH value also even if some Initiator has 4633 provided a valid response using that particular DH value. However, 4634 such behavior is discouraged and should be avoided. Using the same 4635 Diffie-Hellman values and random puzzle #I value has some risks. 4636 This risk needs to be balanced against a potential storm of HIP I1 4637 packets. 4639 This shifting of the start of state cost to the Initiator in creating 4640 the I2 HIP packet presents another DoS attack. The attacker can 4641 spoof the I1 packet and the Responder sends out the R1 HIP packet. 4642 This could conceivably tie up the 'Initiator' with evaluating the R1 4643 HIP packet, and creating the I2 packet. The defense against this 4644 attack is to simply ignore any R1 packet where a corresponding I1 4645 packet was not sent (as defined in Section 6.8 step 1). 4647 The R1 packet is considerably larger than the I1 packet. This 4648 asymmetry can be exploited in an reflection attack. A malicious 4649 attacker could spoof the IP address of a victim and send a flood of 4650 I1 messages to a powerful Responder. For each small I1 packet, the 4651 Responder would send a larger R1 packet to the victim. The 4652 difference in packet sizes can further amplify a flooding attack 4653 against the victim. To avoid such reflection attacks, the Responder 4654 SHOULD rate limit the sending of R1 packets in general or SHOULD rate 4655 limit the sending of R1 packets to a specific IP address. 4657 Floods of forged I2 packets form a second kind of DoS attack. Once 4658 the attacking Initiator has solved the puzzle, it can send packets 4659 with spoofed IP source addresses with either an invalid HIP signature 4660 or invalid encrypted HIP payload (in the ENCRYPTED parameter). This 4661 would take resources in the Responder's part to reach the point to 4662 discover that the I2 packet cannot be completely processed. The 4663 defense against this attack is after N bad I2 packets with the same 4664 puzzle solution, the Responder would discard any I2 packets that 4665 contain the given solution. This will shut down the attack. The 4666 attacker would have to request another R1 packet and use that to 4667 launch a new attack. The Responder could increase the value of #K 4668 while under attack. Keeping a list of solutions from malformed 4669 packets requires that the Responder keeps state for these malformed 4670 I2 packets. This state has to be kept until the R1 counter is 4671 increased. As malformed packets are generally filtered by their 4672 checksum before signature verification, only solutions in packets 4673 that are forged to pass the checksum and puzzle are put to the 4674 blacklist. In addition, a valid puzzle is required before a new list 4675 entry is created. Hence, attackers that intend to flood the 4676 blacklist must solve puzzles first. 4678 A third form of DoS attack is emulating the restart of state after a 4679 reboot of one of the peers. A restarting host would send an I1 4680 packet to the peers, which would respond with an R1 packet even if it 4681 were in the ESTABLISHED state. If the I1 packet were spoofed, the 4682 resulting R1 packet would be received unexpectedly by the spoofed 4683 host and would be dropped, as in the first case above. 4685 A fourth form of DoS attack is emulating closing of the HIP 4686 association. HIP relies on timers and a CLOSE/CLOSE_ACK handshake to 4687 explicitly signal the end of a HIP association. Because both CLOSE 4688 and CLOSE_ACK messages contain a HIP_MAC, an outsider cannot close a 4689 connection. The presence of an additional SIGNATURE allows 4690 middleboxes to inspect these messages and discard the associated 4691 state (for e.g., firewalling, SPI-based NATing, etc.). However, the 4692 optional behavior of replying to CLOSE with an ICMP Parameter Problem 4693 packet (as described in Section 5.4.4) might allow an attacker 4694 spoofing the source IP address to send CLOSE messages to launch 4695 reflection attacks. 4697 A fifth form of DoS attack is replaying R1s to cause the Initiator to 4698 solve stale puzzles and become out of synchronization with the 4699 Responder. The R1 generation counter is a monotonically increasing 4700 counter designed to protect against this attack, as described in 4701 Section 4.1.4. 4703 Man-in-the-middle attacks are difficult to defend against, without 4704 third-party authentication. A skillful MitM could easily handle all 4705 parts of HIP, but HIP indirectly provides the following protection 4706 from a MitM attack. If the Responder's HI is retrieved from a signed 4707 DNS zone, a certificate, or through some other secure means, the 4708 Initiator can use this to validate the R1 HIP packet. 4710 Likewise, if the Initiator's HI is in a secure DNS zone, a trusted 4711 certificate, or otherwise securely available, the Responder can 4712 retrieve the HI (after having got the I2 HIP packet) and verify that 4713 the HI indeed can be trusted. 4715 The HIP Opportunistic Mode concept has been introduced in this 4716 document, but this document does not specify what the semantics of 4717 such a connection setup are for applications. There are certain 4718 concerns with opportunistic mode, as discussed in Section 4.1.8. 4720 NOTIFY messages are used only for informational purposes and they are 4721 unacknowledged. A HIP implementation cannot rely solely on the 4722 information received in a NOTIFY message because the packet may have 4723 been replayed. An implementation SHOULD NOT change any state 4724 information purely based on a received NOTIFY message. 4726 Since not all hosts will ever support HIP, ICMP 'Destination Protocol 4727 Unreachable' messages are to be expected and may be used for a DoS 4728 attack. Against an Initiator, the attack would look like the 4729 Responder does not support HIP, but shortly after receiving the ICMP 4730 message, the Initiator would receive a valid R1 HIP packet. Thus, to 4731 protect from this attack, an Initiator SHOULD NOT react to an ICMP 4732 message until a reasonable delta time to get the real Responder's R1 4733 HIP packet. A similar attack against the Responder is more involved. 4734 Normally, if an I1 message received by a Responder was a bogus one 4735 sent by an attacker, the Responder may receive an ICMP message from 4736 the IP address the R1 message was sent to. However, a sophisticated 4737 attacker can try to take advantage of such a behavior and try to 4738 break up the HIP base exchange by sending such an ICMP message to the 4739 Responder before the Initiator has a chance to send a valid I2 4740 message. Hence, the Responder SHOULD NOT act on such an ICMP 4741 message. Especially, it SHOULD NOT remove any minimal state created 4742 when it sent the R1 HIP packet (if it did create one), but wait for 4743 either a valid I2 HIP packet or the natural timeout (that is, if R1 4744 packets are tracked at all). Likewise, the Initiator SHOULD ignore 4745 any ICMP message while waiting for an R2 HIP packet, and SHOULD 4746 delete any pending state only after a natural timeout. 4748 9. IANA Considerations 4750 IANA has reserved protocol number 139 for the Host Identity Protocol. 4752 This document defines a new 128-bit value under the CGA Message Type 4753 namespace [RFC3972], 0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA, to be 4754 used for HIT generation as specified in ORCHID 4755 [I-D.ietf-hip-rfc4843-bis]. 4757 This document uses HIP version number 2 for the four-bit Version 4758 field in a HIP protocol packet defined in [RFC5201]. 4760 This document also creates a set of new namespaces. These are 4761 described below. 4763 Packet Type 4765 The 7-bit Packet Type field in a HIP protocol packet describes the 4766 type of a HIP protocol message. It is defined in Section 5.1. 4767 The current values are defined in Sections 5.3.1 through 5.3.8. 4769 New values are assigned through IETF Review or IESG Approval 4770 [RFC5226]. 4772 HIT Suite 4774 The four-bit HIT Suite ID uses the OGA field in the ORCHID to 4775 express the type of the HIT. This document defines two HIT Suites 4776 (see Appendix E). 4778 The HIT Suite ID is also carried in the four higher-order bits of 4779 the ID field in the HIT_SUITE_LIST parameter. The four lower- 4780 order bits are reserved for future extensions of the HIT Suite ID 4781 space beyond 16 values. 4783 At the time being, the HIT Suite uses only four bits because these 4784 bits have to be carried in the HIT. Using more bits for the HIT 4785 Suite ID reduces the cryptographic strength of the HIT. HIT Suite 4786 IDs must be allocated carefully to avoid namespace exhaustion. 4787 Moreover, deprecated IDs should be reused after an appropriate 4788 time span. If 16 Suite IDs prove insufficient and more HIT Suite 4789 IDs are needed concurrently, more bits can be used for the HIT 4790 Suite ID by using one HIT Suite ID (0) to indicate that more bits 4791 should be used. The HIT_SUITE_LIST parameter already supports 4792 8-bit HIT Suite IDs, should longer IDs be needed. Possible 4793 extensions of the HIT Suite ID space to accommodate eight bits and 4794 new HIT Suite IDs are defined through IETF Review or IESG 4795 Approval. 4797 Parameter Type 4799 The 16-bit Type field in a HIP parameter describes the type of the 4800 parameter. It is defined in Section 5.2.1. The current values 4801 are defined in Sections 5.2.3 through 5.2.23. 4803 With the exception of the assigned Type codes, the Type codes 0 4804 through 1023 and 61440 through 65535 are reserved for future base 4805 protocol extensions, and are assigned through IETF Review or IESG 4806 Approval. 4808 The Type codes 32768 through 49151 are reserved for 4809 experimentation. Types SHOULD be selected in a random fashion 4810 from this range, thereby reducing the probability of collisions. 4811 A method employing genuine randomness (such as flipping a coin) 4812 SHOULD be used. 4814 All other Type codes are assigned through First Come First Served, 4815 with Specification Required [RFC5226]. 4817 Group ID 4819 The eight-bit Group ID values appear in the DIFFIE_HELLMAN 4820 parameter and the DH_GROUP_LIST parameter and are defined in 4821 Section 5.2.7. New values are assigned through IETF Review or 4822 IESG Approval. 4824 HIP Cipher ID 4826 The 16-bit Cipher ID values in a HIP_CIPHER parameter are defined 4827 in Section 5.2.8. New values either from the reserved or 4828 unassigned space are assigned through IETF Review or IESG 4829 Approval. 4831 DI-Type 4833 The four-bit DI-Type values in a HOST_ID parameter are defined in 4834 Section 5.2.9. New values are assigned through IETF Review or 4835 IESG Approval. 4837 Notify Message Type 4839 The 16-bit Notify Message Type values in a NOTIFICATION parameter 4840 are defined in Section 5.2.19. 4842 Notify Message Type values 1-10 are used for informing about 4843 errors in packet structures, values 11-20 for informing about 4844 problems in parameters containing cryptographic related material, 4845 values 21-30 for informing about problems in authentication or 4846 packet integrity verification. Parameter numbers above 30 can be 4847 used for informing about other types of errors or events. Values 4848 51-8191 are error types reserved to be allocated by IANA. Values 4849 8192-16383 are error types for experimentation. Values 16385- 4850 40959 are status types to be allocated by IANA, and values 40960- 4851 65535 are status types for experimentation. New values in ranges 4852 51-8191 and 16385-40959 are assigned through First Come First 4853 Served, with Specification Required. 4855 10. Acknowledgments 4857 The drive to create HIP came to being after attending the MALLOC 4858 meeting at the 43rd IETF meeting. Baiju Patel and Hilarie Orman 4859 really gave the original author, Bob Moskowitz, the assist to get HIP 4860 beyond 5 paragraphs of ideas. It has matured considerably since the 4861 early versions thanks to extensive input from IETFers. Most 4862 importantly, its design goals are articulated and are different from 4863 other efforts in this direction. Particular mention goes to the 4864 members of the NameSpace Research Group of the IRTF. Noel Chiappa 4865 provided valuable input at early stages of discussions about 4866 identifier handling and Keith Moore the impetus to provide 4867 resolvability. Steve Deering provided encouragement to keep working, 4868 as a solid proposal can act as a proof of ideas for a research group. 4870 Many others contributed; extensive security tips were provided by 4871 Steve Bellovin. Rob Austein kept the DNS parts on track. Paul 4872 Kocher taught Bob Moskowitz how to make the puzzle exchange expensive 4873 for the Initiator to respond, but easy for the Responder to validate. 4874 Bill Sommerfeld supplied the Birthday concept, which later evolved 4875 into the R1 generation counter, to simplify reboot management. Erik 4876 Nordmark supplied the CLOSE-mechanism for closing connections. 4877 Rodney Thayer and Hugh Daniels provided extensive feedback. In the 4878 early times of this document, John Gilmore kept Bob Moskowitz 4879 challenged to provide something of value. 4881 During the later stages of this document, when the editing baton was 4882 transferred to Pekka Nikander, the input from the early implementors 4883 was invaluable. Without having actual implementations, this document 4884 would not be on the level it is now. 4886 In the usual IETF fashion, a large number of people have contributed 4887 to the actual text or ideas. The list of these people include Jeff 4888 Ahrenholz, Francis Dupont, Derek Fawcus, George Gross, Andrew 4889 McGregor, Julien Laganier, Miika Komu, Mika Kousa, Jan Melen, Henrik 4890 Petander, Michael Richardson, Rene Hummen, Tim Shepard, Jorma Wall, 4891 Xin Gu, and Jukka Ylitalo. Our apologies to anyone whose name is 4892 missing. 4894 Once the HIP Working Group was founded in early 2004, a number of 4895 changes were introduced through the working group process. Most 4896 notably, the original document was split in two, one containing the 4897 base exchange and the other one defining how to use ESP. Some 4898 modifications to the protocol proposed by Aura, et al., [AUR03] were 4899 added at a later stage. 4901 11. Changes from RFC 5201 4903 This section summarizes the changes made from [RFC5201]. 4905 11.1. Changes from draft-ietf-hip-rfc5201-bis-11 4907 o Specify that TRANSFORM_FORMAT_LIST is mandatory in R1 and I2; fix 4908 incorrect section reference. 4910 11.2. Changes from draft-ietf-hip-rfc5201-bis-10 4912 o Issue 39: Text clarifying R1 counter rollover and Initiator 4913 response to unexpected reset of the counter. 4915 11.3. Changes from draft-ietf-hip-rfc5201-bis-09 4917 o Editorial changes based on working group last call. 4919 11.4. Changes from draft-ietf-hip-rfc5201-bis-08 4921 o Issue 29: Use different RSA mode OEAP/PSS, elevate ECDSA to 4922 REQUIRED status 4924 o Issue 35: limiting ECC cofactor to 1 4926 o Changed text regarding issue 33 reusing DH values 4928 o Fix tracker issue 32 on Domain Identifier normative text 4930 11.5. Changes from draft-ietf-hip-rfc5201-bis-07 4932 o Removed lingering references to SHA-1 as the mandatory hash 4933 algorithm (which was changed to SHA-256 in the -02 draft version). 4935 o For parameter type number changes, changed "IETF Review" to "IETF 4936 Review or IESG Approval". 4938 o Updated Appendix C checksum examples to conform to HIPv2 packets. 4940 11.6. Changes from draft-ietf-hip-rfc5201-bis-06 4942 o Made echoing the R1_COUNTER in the I2 mandatory if the R1 contains 4943 an R1_COUNTER. This required to make the R1 counter a critical 4944 parameter. Hence, the parameter type number of the R1_COUNTER 4945 changed from 128 to 129. 4947 o Made KDF dependent on DH Group to enable negotiation of the KDF. 4949 11.7. Changes from draft-ietf-hip-rfc5201-bis-05 4951 o Changed type number of DH_GROUP_LIST from 2151 to 511 because it 4952 was in the number space that is reserved for the HIP transport 4953 mode negotiations. 4955 o Added transport form type list parameter. Transport forms are now 4956 negotiated with this list instead of by their order in the HIP 4957 packet. This allows to remove the exception of the transport 4958 format parameters that were ordered by their preference instead of 4959 by their type number. This should remove complexity from 4960 implementations. 4962 o Clarify that in HIP signature processing, the restored checksum 4963 and length fields have been rendered invalid by the previous 4964 steps. 4966 o Clarify behavior for when UPDATE does not contain SEQ or ACQ 4967 (disallow this). 4969 o For namespace changes, changed "IETF Review" to "IETF Review or 4970 IESG Approval". 4972 o Addressed IESG comment about ignoring packet IP addresses. 4974 o Permit using Anonymous HI control in packets other than R1/I2. 4976 o Fixed minor reference error (RFC2418, RFC2410). 4978 o Deleted comment that NULL-ENCRYPTION SHOULD NOT be configurable 4979 via the UI. 4981 o Editorial changes. 4983 11.8. Changes from draft-ietf-hip-rfc5201-bis-04 4985 o Clarifications of the Security Considerations section. One DoS 4986 defense mechanism was changed to be more effective and less prone 4987 to misuse. 4989 o Minor clarifications of the state machine. 4991 o Clarified text on HIP puzzle. 4993 o Added names and references for figures. 4995 o Extended the definitions section. 4997 o Added a reference to the HIP Version 1 certificate document. 4999 o Added Initiator, Responder, HIP association, and signed data to 5000 the definitions section. 5002 o Changed parameter figure for PUZZLE and SOLUTION to use 5003 RHASH_len/8 instead of n-byte. 5005 o Replaced occurrences of SHOULD not with SHOULD NOT. 5007 o Changed text to reflect the fact that several 5008 ECHO_REQUEST_UNSIGNED parameters may be present in an R1 and 5009 several ECHO_RESPONSE parameters may be present in an I2. 5011 o Added text on verifying the ECHO_RESPONSE_SIGNED parameter in 5012 CLOSE_ACK. 5014 o Changed wording from HMAC to HIP_MAC in Section 5.3.8. 5016 o Reflected fact that the UPDATE packet MAY include zero or more 5017 ACKs. 5019 o Added BEX to Definitions section. 5021 o Changed HIP_SIGNATURE algorithm field from 8 bit to 16 bit to 5022 achieve alignment with the HOST_ID parameters. 5024 o Fixed the wrong figures of the SEQ and ACK parameters. SEQ always 5025 contains ONE update ID. ACK may acknowledge SEVERAL update IDs. 5027 o Added wording that several NOTIFY parameters may be present in a 5028 HIP packet. 5030 o Changed wording for the ECHO_RESPONSE_SIGNED parameter. Also 5031 lifted the restriction that only one ECHO_RESPONSE_UNSIGNED 5032 parameter MUST be present in each HIP control packet. This did 5033 contradict the definition of the ECHO_RESPONSE_UNSIGNED parameter. 5035 o Changed IETF Consensus to IETF Review or IESG Approval in IANA 5036 section. 5038 o Aligned use of I, J, and K. Now I is #I, J is #J and K is #K 5039 throughout the document. 5041 o Updated references. 5043 o Editorial changes. 5045 11.9. Changes from draft-ietf-hip-rfc5201-bis-03 5047 o Editorial changes to improve clarity and readability. 5049 o Removed obsoleted (not applicable) attack from security 5050 consideration section. 5052 o Added a requirement that hosts MUST support processing of ACK 5053 parameters with several SEQ numbers even when they do not support 5054 sending such parameters. 5056 o Removed note on memory bound puzzles. The use of memory bound 5057 puzzles was reconsidered but no convincing arguments for inclusion 5058 in this document have been made on the list. 5060 o Changed references to reference the new bis documents. 5062 o Specified the ECC curves and the hashes used for these. 5064 o Specified representation of ECC curves in the HI. 5066 o Added text on the dependency between RHASH and HMAC. 5068 o Rephrased part of the security considerations to make them 5069 clearer. 5071 o Clarified the use of HITs in opportunistic mode. 5073 o Clarified the difference between HIP_MAC and HIP_MAC_2 as well as 5074 between SIGNATURE and SIGNATURE_2. 5076 o Changed NOTIFY name for value 44 from SERVER_BUSY_PLEASE_RETRY to 5077 RESPONDER_BUSY_PLEASE_RETRY. 5079 o Mentioned that there are multiple valid puzzle solutions. 5081 11.10. Changes from draft-ietf-hip-rfc5201-bis-02 5083 o Added recommendation to not use puzzle #I twice for the same host 5084 to avoid identical key material. 5086 o Revised state machine and added missing event handling. 5088 o Added UNSUPPORTED_HIT_SUITE to NOTIFY to indicate unsupported HIT 5089 suites. 5091 o Revised parameter type numbers (corresponding to IANA allocations) 5092 and added missing "free for experimentation" range to the 5093 description. 5095 o Clarifying note on the use of the C bit in the parameter type 5096 numbers. 5098 11.11. Changes from draft-ietf-hip-rfc5201-bis-01 5100 o Changed RHASH-len to RHASH_len to avoid confusion in calculations 5101 (- could be minus) 5103 o Added RHASH_len to list of abbreviations 5105 o Fixed length of puzzle #I and #J to be 1*RHASH_len 5107 o Changed RHASH-len to RHASH_len to avoid confusion in calculations 5108 (- could be minus) 5110 o Added RHASH_len to list of abbreviations 5112 o Fixed length of puzzle #I and #J to be 1*RHASH_len 5114 o Included HIT_SUITEs. 5116 o Added DH negotiation to I1 and R1. 5118 o Added DH_LIST parameter. 5120 o Added text for DH Group negotiation. 5122 o Removed second DH public value from DH parameter. 5124 o Added ECC to HI generation. 5126 o Added Responder HIT selection to opportunistic mode. 5128 o Added ECDSA HI text and references (not complete yet). 5130 o Added separate section on aborting BEX. 5132 o Added separate section on downgrade attack prevention. 5134 o Added text about DH Group selection for use cases without I1. 5136 o Removed type range allocation for parameters related to HIP 5137 transform types. 5139 o New type range allocation for parameters that are only covered by 5140 a signature if a signature is present (Applies to DH_GROUP_LIST). 5142 o Renamed HIP_TRANSFORM to HIP_CIPHER and removed hashes from it - 5143 hashes are determined by RHASH. 5145 o The length of #I and #J for the puzzle now depends on RHASH. 5147 o New keymat generation. 5149 o Puzzle seed and solution now use RHASH and have variable length. 5151 o Moved timing definitions closer to state machine. 5153 o Simplified text regarding puzzle lifetime. 5155 o Clarified the description of the use of #I in the puzzle 5157 o Removed "Opportunistic mode" description from general definitions. 5159 o More consistency across the old RFC5201 text. Aligned 5160 capitalization and abbreviations. 5162 o Extended protocol overview to include restart option. 5164 o Extended state machine to include restart option because of 5165 unsupported Algorithms. 5167 o Replaced SHA-1 with SHA-256 for required implementation. 5169 o Added OGA list parameter (715) for detecting the Responder's set 5170 of OGAs. 5172 o Added Appendix on ORCHID use in HITs. 5174 o Added truncated SHA-256 option for HITs. 5176 o Added truncated SHA-1 option for HITs. 5178 o Added text about new ORCHID structure to HIT overview. 5180 o Moved Editor role to Robert Moskowitz. 5182 o Added SHA-256 to puzzle parameter. 5184 o Generalized LTRUNC to be hash-function agnostic. 5186 o Added text about RHASH depending on OGA. 5188 11.12. Changes from draft-ietf-hip-rfc5201-bis-00 5190 o Added reasoning why BIS document is needed. 5192 11.13. Contents of draft-ietf-hip-rfc5201-bis-00 5194 o RFC5201 was submitted as draft-RFC. 5196 12. References 5198 12.1. Normative References 5200 [FIPS.180-2.2002] National Institute of Standards and 5201 Technology, "Secure Hash Standard", 5202 FIPS PUB 180-2, August 2002, . 5206 [I-D.ietf-hip-rfc4843-bis] Laganier, J. and F. Dupont, "An IPv6 5207 Prefix for Overlay Routable Cryptographic 5208 Hash Identifiers Version 2 (ORCHIDv2)", 5209 draft-ietf-hip-rfc4843-bis-02 (work in 5210 progress), September 2012. 5212 [I-D.ietf-hip-rfc5202-bis] Jokela, P., Moskowitz, R., and J. Melen, 5213 "Using the Encapsulating Security Payload 5214 (ESP) Transport Format with the Host 5215 Identity Protocol (HIP)", 5216 draft-ietf-hip-rfc5202-bis-02 (work in 5217 progress), June 2013. 5219 [NIST.800-131A.2011] National Institute of Standards and 5220 Technology, "Transitions: Recommendation 5221 for Transitioning the Use of 5222 Cryptographic Algorithms and Key 5223 Lengths", NIST 800-131A, January 2011. 5225 [RFC0768] Postel, J., "User Datagram Protocol", 5226 STD 6, RFC 768, August 1980. 5228 [RFC1035] Mockapetris, P., "Domain names - 5229 implementation and specification", 5230 STD 13, RFC 1035, November 1987. 5232 [RFC2119] Bradner, S., "Key words for use in RFCs 5233 to Indicate Requirement Levels", BCP 14, 5234 RFC 2119, March 1997. 5236 [RFC2404] Madson, C. and R. Glenn, "The Use of 5237 HMAC-SHA-1-96 within ESP and AH", 5238 RFC 2404, November 1998. 5240 [RFC2410] Glenn, R. and S. Kent, "The NULL 5241 Encryption Algorithm and Its Use With 5242 IPsec", RFC 2410, November 1998. 5244 [RFC2460] Deering, S. and R. Hinden, "Internet 5245 Protocol, Version 6 (IPv6) 5246 Specification", RFC 2460, December 1998. 5248 [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the 5249 Domain Name System (DNS)", RFC 2536, 5250 March 1999. 5252 [RFC2785] Zuccherato, R., "Methods for Avoiding the 5253 "Small-Subgroup" Attacks on the Diffie- 5254 Hellman Key Agreement Method for S/MIME", 5255 RFC 2785, March 2000. 5257 [RFC2898] Kaliski, B., "PKCS #5: Password-Based 5258 Cryptography Specification Version 2.0", 5259 RFC 2898, September 2000. 5261 [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA 5262 KEYs in the Domain Name System (DNS)", 5263 RFC 3110, May 2001. 5265 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key 5266 Cryptography Standards (PKCS) #1: RSA 5267 Cryptography Specifications Version 2.1", 5268 RFC 3447, February 2003. 5270 [RFC3484] Draves, R., "Default Address Selection 5271 for Internet Protocol version 6 (IPv6)", 5272 RFC 3484, February 2003. 5274 [RFC3526] Kivinen, T. and M. Kojo, "More Modular 5275 Exponential (MODP) Diffie-Hellman groups 5276 for Internet Key Exchange (IKE)", 5277 RFC 3526, May 2003. 5279 [RFC3602] Frankel, S., Glenn, R., and S. Kelly, 5280 "The AES-CBC Cipher Algorithm and Its Use 5281 with IPsec", RFC 3602, September 2003. 5283 [RFC3972] Aura, T., "Cryptographically Generated 5284 Addresses (CGA)", RFC 3972, March 2005. 5286 [RFC4034] Arends, R., Austein, R., Larson, M., 5287 Massey, D., and S. Rose, "Resource 5288 Records for the DNS Security Extensions", 5289 RFC 4034, March 2005. 5291 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. 5292 Eronen, "The Network Access Identifier", 5293 RFC 4282, December 2005. 5295 [RFC4443] Conta, A., Deering, S., and M. Gupta, 5296 "Internet Control Message Protocol 5297 (ICMPv6) for the Internet Protocol 5298 Version 6 (IPv6) Specification", 5299 RFC 4443, March 2006. 5301 [RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 5302 Authentication Using the Elliptic Curve 5303 Digital Signature Algorithm (ECDSA)", 5304 RFC 4754, January 2007. 5306 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC- 5307 SHA-256, HMAC-SHA-384, and HMAC-SHA-512 5308 with IPsec", RFC 4868, May 2007. 5310 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., 5311 and T. Henderson, "Host Identity 5312 Protocol", RFC 5201, April 2008. 5314 [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with 5315 RSA in DNSKEY and RRSIG Resource Records 5316 for DNSSEC", RFC 5702, October 2009. 5318 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based 5319 Extract-and-Expand Key Derivation 5320 Function (HKDF)", RFC 5869, May 2010. 5322 [RFC5903] Fu, D. and J. Solinas, "Elliptic Curve 5323 Groups modulo a Prime (ECP Groups) for 5324 IKE and IKEv2", RFC 5903, June 2010. 5326 [RFC6090] McGrew, D., Igoe, K., and M. Salter, 5327 "Fundamental Elliptic Curve Cryptography 5328 Algorithms", RFC 6090, February 2011. 5330 12.2. Informative References 5332 [AUR03] Aura, T., Nagarajan, A., and A. Gurtov, 5333 "Analysis of the HIP Base Exchange 5334 Protocol", in Proceedings of 10th 5335 Australasian Conference on Information 5336 Security and Privacy, July 2003. 5338 [CRO03] Crosby, SA. and DS. Wallach, "Denial of 5339 Service via Algorithmic Complexity 5340 Attacks", in Proceedings of Usenix 5341 Security Symposium 2003, Washington, 5342 DC., August 2003. 5344 [DIF76] Diffie, W. and M. Hellman, "New 5345 Directions in Cryptography", IEEE 5346 Transactions on Information Theory vol. 5347 IT-22, number 6, pages 644-654, Nov 1976. 5349 [FIPS.197.2001] National Institute of Standards and 5350 Technology, "Advanced Encryption Standard 5351 (AES)", FIPS PUB 197, November 2001, . 5355 [I-D.ietf-btns-c-api] Richardson, M., Williams, N., Komu, M., 5356 and S. Tarkoma, "C-Bindings for IPsec 5357 Application Programming Interfaces", 5358 draft-ietf-btns-c-api-04 (work in 5359 progress), March 2009. 5361 [I-D.ietf-hip-rfc4423-bis] Moskowitz, R., "Host Identity Protocol 5362 Architecture", 5363 draft-ietf-hip-rfc4423-bis-05 (work in 5364 progress), September 2012. 5366 [I-D.ietf-hip-rfc5204-bis] Laganier, J. and L. Eggert, "Host 5367 Identity Protocol (HIP) Rendezvous 5368 Extension", draft-ietf-hip-rfc5204-bis-02 5369 (work in progress), September 2012. 5371 [I-D.ietf-hip-rfc5205-bis] Laganier, J., "Host Identity Protocol 5372 (HIP) Domain Name System (DNS) 5373 Extension", draft-ietf-hip-rfc5205-bis-02 5374 (work in progress), September 2012. 5376 [I-D.ietf-hip-rfc5206-bis] Henderson, T., Vogt, C., and J. Arkko, 5377 "Host Mobility with the Host Identity 5378 Protocol", draft-ietf-hip-rfc5206-bis-04 5379 (work in progress), July 2012. 5381 [KAU03] Kaufman, C., Perlman, R., and B. 5382 Sommerfeld, "DoS protection for UDP-based 5383 protocols", ACM Conference on Computer 5384 and Communications Security , Oct 2003. 5386 [KRA03] Krawczyk, H., "SIGMA: The 'SIGn-and-MAc' 5387 Approach to Authenticated Diffie-Hellman 5388 and Its Use in the IKE-Protocols", in 5389 Proceedings of CRYPTO 2003, pages 400- 5390 425, August 2003. 5392 [RFC0792] Postel, J., "Internet Control Message 5393 Protocol", STD 5, RFC 792, 5394 September 1981. 5396 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 5397 Address Prefix Reserved for 5398 Documentation", RFC 3849, July 2004. 5400 [RFC4306] Kaufman, C., "Internet Key Exchange 5401 (IKEv2) Protocol", RFC 4306, 5402 December 2005. 5404 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines 5405 for Writing an IANA Considerations 5406 Section in RFCs", BCP 26, RFC 5226, 5407 May 2008. 5409 [RFC5338] Henderson, T., Nikander, P., and M. Komu, 5410 "Using the Host Identity Protocol with 5411 Legacy Applications", RFC 5338, 5412 September 2008. 5414 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: 5415 Level 3 Multihoming Shim Protocol for 5416 IPv6", RFC 5533, June 2009. 5418 [RFC5747] Wu, J., Cui, Y., Li, X., Xu, M., and C. 5419 Metz, "4over6 Transit Solution Using IP 5420 Encapsulation and MP-BGP Extensions", 5421 RFC 5747, March 2010. 5423 [RFC6253] Heer, T. and S. Varjonen, "Host Identity 5424 Protocol Certificates", RFC 6253, 5425 May 2011. 5427 [SECG] SECG, "Recommended Elliptic Curve Domain 5428 Parameters", SEC 2 , 2000, 5429 . 5431 Appendix A. Using Responder Puzzles 5433 As mentioned in Section 4.1.1, the Responder may delay state creation 5434 and still reject most spoofed I2 packets by using a number of pre- 5435 calculated R1 packets and a local selection function. This appendix 5436 defines one possible implementation in detail. The purpose of this 5437 appendix is to give the implementors an idea on how to implement the 5438 mechanism. If the implementation is based on this appendix, it MAY 5439 contain some local modification that makes an attacker's task harder. 5441 The Responder creates a secret value S, that it regenerates 5442 periodically. The Responder needs to remember the two latest values 5443 of S. Each time the S is regenerated, the R1 generation counter 5444 value is incremented by one. 5446 The Responder generates a pre-signed R1 packet. The signature for 5447 pre-generated R1s must be recalculated when the Diffie-Hellman key is 5448 recomputed or when the R1_COUNTER value changes due to S value 5449 regeneration. 5451 When the Initiator sends the I1 packet for initializing a connection, 5452 the Responder receives the HIT and IP address from the packet, and 5453 generates an #I value for the puzzle. The #I value is set to the 5454 pre-signed R1 packet. 5456 #I value calculation: 5457 #I = Ltrunc( RHASH ( S | HIT-I | HIT-R | IP-I | IP-R ), n) 5458 where n = RHASH_len 5460 The RHASH algorithm is the same that is used to generate the 5461 Responder's HIT value. 5463 From an incoming I2 packet, the Responder receives the required 5464 information to validate the puzzle: HITs, IP addresses, and the 5465 information of the used S value from the R1_COUNTER. Using these 5466 values, the Responder can regenerate the #I, and verify it against 5467 the #I received in the I2 packet. If the #I values match, it can 5468 verify the solution using #I, #J, and difficulty #K. If the #I values 5469 do not match, the I2 is dropped. 5471 puzzle_check: 5472 V := Ltrunc( RHASH( I2.I | I2.hit_i | I2.hit_r | I2.J ), #K ) 5473 if V != 0, drop the packet 5475 If the puzzle solution is correct, the #I and #J values are stored 5476 for later use. They are used as input material when keying material 5477 is generated. 5479 Keeping state about failed puzzle solutions depends on the 5480 implementation. Although it is possible for the Responder not to 5481 keep any state information, it still may do so to protect itself 5482 against certain attacks (see Section 4.1.1). 5484 Appendix B. Generating a Public Key Encoding from an HI 5486 The following pseudo-code illustrates the process to generate a 5487 public key encoding from an HI for both RSA and DSA. 5489 The symbol := denotes assignment; the symbol += denotes appending. 5490 The pseudo-function encode_in_network_byte_order takes two 5491 parameters, an integer (bignum) and a length in bytes, and returns 5492 the integer encoded into a byte string of the given length. 5494 switch ( HI.algorithm ) 5495 { 5497 case RSA: 5498 buffer := encode_in_network_byte_order ( HI.RSA.e_len, 5499 ( HI.RSA.e_len > 255 ) ? 3 : 1 ) 5500 buffer += encode_in_network_byte_order ( HI.RSA.e, HI.RSA.e_len ) 5501 buffer += encode_in_network_byte_order ( HI.RSA.n, HI.RSA.n_len ) 5502 break; 5504 case DSA: 5505 buffer := encode_in_network_byte_order ( HI.DSA.T , 1 ) 5506 buffer += encode_in_network_byte_order ( HI.DSA.Q , 20 ) 5507 buffer += encode_in_network_byte_order ( HI.DSA.P , 64 + 5508 8 * HI.DSA.T ) 5509 buffer += encode_in_network_byte_order ( HI.DSA.G , 64 + 5510 8 * HI.DSA.T ) 5511 buffer += encode_in_network_byte_order ( HI.DSA.Y , 64 + 5512 8 * HI.DSA.T ) 5513 break; 5515 } 5517 Appendix C. Example Checksums for HIP Packets 5519 The HIP checksum for HIP packets is specified in Section 5.1.1. 5520 Checksums for TCP and UDP packets running over HIP-enabled security 5521 associations are specified in Section 3.5. The examples below use 5522 [RFC3849] and [RFC5747] addresses, and HITs with the prefix of 5523 2001:10 followed by zeros, followed by a decimal 1 or 2, 5524 respectively. 5526 The following example is defined only for testing the checksum 5527 calculation. 5529 C.1. IPv6 HIP Example (I1 packet) 5531 Source Address: 2001:d88::1 5532 Destination Address: 2001:d88::2 5533 Upper-Layer Packet Length: 48 0x30 5534 Next Header: 139 0x8b 5535 Payload Protocol: 59 0x3b 5536 Header Length: 4 0x4 5537 Packet Type: 1 0x1 5538 Version: 2 0x2 5539 Reserved: 1 0x1 5540 Control: 0 0x0 5541 Checksum: 6878 0x1ade 5542 Sender's HIT : 2001:10::1 5543 Receiver's HIT: 2001:10::2 5544 DH_GROUP_LIST type: 511 0x1ff 5545 DH_GROUP_LIST length: 3 0x3 5546 DH_GROUP_LIST group IDs: 3,4,8 5548 C.2. IPv4 HIP Packet (I1 packet) 5550 The IPv4 checksum value for the example I1 packet is shown below. 5552 Source Address: 192.0.2.1 5553 Destination Address: 192.0.2.2 5554 Upper-Layer Packet Length: 48 0x30 5555 Next Header: 139 0x8b 5556 Payload Protocol: 59 0x3b 5557 Header Length: 4 0x4 5558 Packet Type: 1 0x1 5559 Version: 2 0x2 5560 Reserved: 1 0x1 5561 Control: 0 0x0 5562 Checksum: 61934 0xf1ee 5563 Sender's HIT : 2001:10::1 5564 Receiver's HIT: 2001:10::2 5565 DH_GROUP_LIST type: 511 0x1ff 5566 DH_GROUP_LIST length: 3 0x3 5567 DH_GROUP_LIST group IDs: 3,4,8 5569 C.3. TCP Segment 5571 Regardless of whether IPv6 or IPv4 is used, the TCP and UDP sockets 5572 use the IPv6 pseudo-header format [RFC2460], with the HITs used in 5573 place of the IPv6 addresses. 5575 Sender's HIT: 2001:10::1 5576 Receiver's HIT: 2001:10::2 5577 Upper-Layer Packet Length: 20 0x14 5578 Next Header: 6 0x06 5579 Source port: 65500 0xffdc 5580 Destination port: 22 0x0016 5581 Sequence number: 1 0x00000001 5582 Acknowledgment number: 0 0x00000000 5583 Header length: 20 0x14 5584 Flags: SYN 0x02 5585 Window size: 65535 0xffff 5586 Checksum: 28618 0x6fca 5587 Urgent pointer: 0 0x0000 5589 0x0000: 6000 0000 0014 0640 2001 0010 0000 0000 5590 0x0010: 0000 0000 0000 0001 2001 0010 0000 0000 5591 0x0020: 0000 0000 0000 0002 ffdc 0016 0000 0001 5592 0x0030: 0000 0000 5002 ffff 6fca 0000 5594 Appendix D. ECDH and ECDSA 160 Bit Groups 5596 The ECDH and ECDSA 160-bit group SECP160R1 is rated at 80 bits 5597 symmetric strength. Once this was considered appropriate for one 5598 year of security. Today these groups should be used only when the 5599 host is not powerful enough (e.g., some embedded devices) and when 5600 security requirements are low (e.g., long-term confidentiality is not 5601 required). 5603 Appendix E. HIT Suites and HIT Generation 5605 The HIT as an ORCHID [I-D.ietf-hip-rfc4843-bis] consists of three 5606 parts: A 28-bit prefix, a 4-bit encoding of the ORCHID generation 5607 algorithm (OGA) and the representation of the public key. The OGA is 5608 an index pointing to the specific algorithm by which the public key 5609 and the 96-bit hashed encoding is generated. The OGA is protocol 5610 specific and is to be interpreted as defined below for all protocols 5611 that use the same context ID as HIP. HIP groups sets of valid 5612 combinations of signature and hash algorithms into HIT Suites. These 5613 HIT suites are addressed by an index, which is transmitted in the OGA 5614 field of the ORCHID. 5616 The set of used HIT Suites will be extended to counter the progress 5617 in computation capabilities and vulnerabilities in the employed 5618 algorithms. The intended use of the HIT Suites is to introduce a new 5619 HIT Suite and phase out an old one before it becomes insecure. Since 5620 the 4-bit OGA field only permits 15 HIT Suites (the HIT Suite with ID 5621 0 is reserved) to be used in parallel, phased-out HIT Suites must be 5622 reused at some point. In such a case, there will be a rollover of 5623 the HIT Suite ID and the next newly introduced HIT Suite will start 5624 with a lower HIT Suite index than the previously introduced one. The 5625 rollover effectively deprecates the reused HIT Suite. For a smooth 5626 transition, the HIT Suite should be deprecated a considerable time 5627 before the HIT Suite index is reused. 5629 Since the number of HIT Suites is tightly limited to 16, the HIT 5630 Suites must be assigned carefully. Hence, sets of suitable 5631 algorithms are grouped in a HIT Suite. 5633 The HIT Suite of the Responder's HIT determines the RHASH and the 5634 hash function to be used for the HMAC in HIP control packets as well 5635 as the signature algorithm family used for generating the HI. The 5636 list of HIT Suites is defined in Table 11. 5638 The following HIT Suites are defined for HIT generation. The input 5639 for each generation algorithm is the encoding of the HI as defined in 5640 Section 3.2. The output is 96 bits long and is directly used in the 5641 ORCHID. 5643 +-------+----------+--------------+------------+--------------------+ 5644 | Index | Hash | HMAC | Signature | Description | 5645 | | function | | algorithm | | 5646 | | | | family | | 5647 +-------+----------+--------------+------------+--------------------+ 5648 | 0 | | | | Reserved | 5649 | 1 | SHA-256 | HMAC-SHA-256 | RSA, DSA | RSA or DSA HI | 5650 | | | | | hashed with | 5651 | | | | | SHA-256, truncated | 5652 | | | | | to 96 bits | 5653 | 2 | SHA-384 | HMAC-SHA-384 | ECDSA | ECDSA HI hashed | 5654 | | | | | with SHA-384, | 5655 | | | | | truncated to 96 | 5656 | | | | | bits | 5657 | 3 | SHA-1 | HMAC-SHA-1 | ECDSA_LOW | ECDSA_LOW HI | 5658 | | | | | hashed with SHA-1, | 5659 | | | | | truncated to 96 | 5660 | | | | | bits | 5661 +-------+----------+--------------+------------+--------------------+ 5663 Table 11: HIT Suites 5665 The hash of the responder as defined in the HIT Suite determines the 5666 HMAC to be used for the HMAC parameter. The HMACs currently defined 5667 here are HMAC-SHA-256 [RFC4868], HMAC-SHA-384 [RFC4868], and HMAC- 5668 SHA-1 [RFC2404]. 5670 Authors' Addresses 5672 Robert Moskowitz (editor) 5673 Verizon Telcom and Business 5674 1000 Bent Creek Blvd, Suite 200 5675 Mechanicsburg, PA 5676 USA 5678 EMail: robert.moskowitz@verizonbusiness.com 5680 Tobias Heer 5681 Hirschmann Automation and Control 5682 Stuttgarter Strasse 45-51 5683 Neckartenzlingen 72654 5684 Germany 5686 EMail: tobias.heer@belden.com 5688 Petri Jokela 5689 Ericsson Research NomadicLab 5690 JORVAS FIN-02420 5691 FINLAND 5693 Phone: +358 9 299 1 5694 EMail: petri.jokela@nomadiclab.com 5696 Thomas R. Henderson 5697 The Boeing Company 5698 P.O. Box 3707 5699 Seattle, WA 5700 USA 5702 EMail: thomas.r.henderson@boeing.com