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