idnits 2.17.1 draft-ietf-hip-rfc5201-bis-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. == There are 2 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 2086 has weird spacing: '...c Value leng...' == Line 2088 has weird spacing: '...c Value the ...' == Line 2606 has weird spacing: '...ication info...' == Line 2738 has weird spacing: '...ue data opaqu...' == Line 2770 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 'MUST not' in this paragraph: When selecting the DH group for the DIFFIE_HELLMAN parameter in the R1 packet, the Responder MUST select the first DH Group ID in its DH_GROUP_LIST in the R1 packet that is contained in the Initiator's DH_GROUP_LIST in the I1 packet. The Responder MUST not select any other DH Group ID that is contained in both lists because a downgrade attack cannot be detected then. == 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: The Diffie-Hellman public value is ephemeral, and values SHOULD not be reused across different HIP sessions. Once the Responder has received a valid response to an R1 packet, that Diffie-Hellman value SHOULD be deprecated. It it is possible that the Responder has sent the same Diffie-Hellman value to different hosts simultaneously in corresponding R1 packets and those responses should also be accepted. However, as a defense against I1 packet storms, an implementation MAY propose, and re-use unless avoidable, the same Diffie-Hellman value for a period of time, for example, 15 minutes. By using a small number of different puzzles for a given Diffie-Hellman value, the R1 packets can be precomputed and delivered as quickly as I1 packets arrive. A scavenger process should clean up unused Diffie-Hellman values and puzzles. == 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: 7. The system MUST check that the DH Group ID in the DH parameter in the R1 matches the first DH Suite ID in the Responder's DH_GROUP_LIST in the R1 packet that was also contained in the Initiator's DH_GROUP_LIST in the I1 packet. If the DH Group ID of the DH parameter does not express the Responder's best choice, the Initiator can conclude that the DH_GROUP_LIST in the I1 packet was adversely modified. In such case, the Initiator MAY send a new I1 packet, however, it SHOULD not change its preference in the DH_GROUP_LIST in the new I1 packet. Alternatively, the Initiator MAY abort the HIP exchange. == 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 (January 20, 2011) is 4838 days in the past. Is this intentional? 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: 'RFC2410' is mentioned on line 2141, 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 == Outdated reference: A later version (-04) exists of draft-mcgrew-fundamental-ecc-03 ** Downref: Normative reference to an Informational draft: draft-mcgrew-fundamental-ecc (ref. 'I-D.mcgrew-fundamental-ecc') ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2463 (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 2898 (Obsoleted by RFC 8018) ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) ** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542) ** Obsolete normative reference: RFC 4753 (Obsoleted by RFC 5903) ** Obsolete normative reference: RFC 5201 (Obsoleted by RFC 7401) ** Downref: Normative reference to an Informational RFC: RFC 5869 == Outdated reference: A later version (-20) exists of draft-ietf-hip-rfc4423-bis-01 == 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 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) Summary: 9 errors (**), 0 flaws (~~), 21 warnings (==), 3 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 ICSA labs 4 Obsoletes: 5201 (if approved) P. Jokela 5 Intended status: Standards Track Ericsson Research NomadicLab 6 Expires: July 24, 2011 T. Henderson 7 The Boeing Company 8 T. Heer 9 RWTH Aachen University, 10 Communication and Distributed 11 Systems Group 12 January 20, 2011 14 Host Identity Protocol 15 draft-ietf-hip-rfc5201-bis-04 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 July 24, 2011. 53 Copyright Notice 55 Copyright (c) 2011 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 This document may contain material from IETF Documents or IETF 69 Contributions published or made publicly available before November 70 10, 2008. The person(s) controlling the copyright in some of this 71 material may not have granted the IETF Trust the right to allow 72 modifications of such material outside the IETF Standards Process. 73 Without obtaining an adequate license from the person(s) controlling 74 the copyright in such materials, this document may not be modified 75 outside the IETF Standards Process, and derivative works of it may 76 not be created outside the IETF Standards Process, except to format 77 it for publication as an RFC or to translate it into languages other 78 than English. 80 Table of Contents 82 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 83 1.1. A New Namespace and Identifiers . . . . . . . . . . . . . 7 84 1.2. The HIP Base Exchange (BEX) . . . . . . . . . . . . . . . 7 85 1.3. Memo Structure . . . . . . . . . . . . . . . . . . . . . 8 86 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 8 87 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 8 88 2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 8 89 2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 9 90 3. Host Identifier (HI) and its Structure . . . . . . . . . . . 9 91 3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 10 92 3.2. Generating a HIT from an HI . . . . . . . . . . . . . . . 11 93 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 12 94 4.1. Creating a HIP Association . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . 16 99 4.1.4. HIP Replay Protection . . . . . . . . . . . . . . . . 18 100 4.1.5. Refusing a HIP Exchange . . . . . . . . . . . . . . . 19 101 4.1.6. Aborting a HIP Exchange . . . . . . . . . . . . . . . 19 102 4.1.7. HIP Downgrade Protection . . . . . . . . . . . . . . 20 103 4.1.8. HIP Opportunistic Mode . . . . . . . . . . . . . . . 21 104 4.2. Updating a HIP Association . . . . . . . . . . . . . . . 23 105 4.3. Error Processing . . . . . . . . . . . . . . . . . . . . 24 106 4.4. HIP State Machine . . . . . . . . . . . . . . . . . . . . 25 107 4.4.1. Timespan Definitions . . . . . . . . . . . . . . . . 26 108 4.4.2. HIP States . . . . . . . . . . . . . . . . . . . . . 26 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. DIFFIE_HELLMAN . . . . . . . . . . . . . . . . . . . 49 129 5.2.7. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . 50 130 5.2.8. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 51 131 5.2.9. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 53 132 5.2.10. DH_GROUP_LIST . . . . . . . . . . . . . . . . . . . . 54 133 5.2.11. HIP_MAC . . . . . . . . . . . . . . . . . . . . . . . 55 134 5.2.12. HIP_MAC_2 . . . . . . . . . . . . . . . . . . . . . . 55 135 5.2.13. HIP_SIGNATURE . . . . . . . . . . . . . . . . . . . . 56 136 5.2.14. HIP_SIGNATURE_2 . . . . . . . . . . . . . . . . . . . 57 137 5.2.15. SEQ . . . . . . . . . . . . . . . . . . . . . . . . . 58 138 5.2.16. ACK . . . . . . . . . . . . . . . . . . . . . . . . . 58 139 5.2.17. ENCRYPTED . . . . . . . . . . . . . . . . . . . . . . 59 140 5.2.18. NOTIFICATION . . . . . . . . . . . . . . . . . . . . 60 141 5.2.19. ECHO_REQUEST_SIGNED . . . . . . . . . . . . . . . . . 64 142 5.2.20. ECHO_REQUEST_UNSIGNED . . . . . . . . . . . . . . . . 64 143 5.2.21. ECHO_RESPONSE_SIGNED . . . . . . . . . . . . . . . . 65 144 5.2.22. ECHO_RESPONSE_UNSIGNED . . . . . . . . . . . . . . . 66 146 5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 66 147 5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 67 148 5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 68 149 5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 71 150 5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 72 151 5.3.5. UPDATE - the HIP Update Packet . . . . . . . . . . . 72 152 5.3.6. NOTIFY - the HIP Notify Packet . . . . . . . . . . . 73 153 5.3.7. CLOSE - the HIP Association Closing Packet . . . . . 74 154 5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet . . 74 155 5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 75 156 5.4.1. Invalid Version . . . . . . . . . . . . . . . . . . . 75 157 5.4.2. Other Problems with the HIP Header and Packet 158 Structure . . . . . . . . . . . . . . . . . . . . . . 75 159 5.4.3. Invalid Puzzle Solution . . . . . . . . . . . . . . . 75 160 5.4.4. Non-Existing HIP Association . . . . . . . . . . . . 76 161 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 76 162 6.1. Processing Outgoing Application Data . . . . . . . . . . 76 163 6.2. Processing Incoming Application Data . . . . . . . . . . 77 164 6.3. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 78 165 6.4. HIP_MAC and SIGNATURE Calculation and Verification . . . 80 166 6.4.1. HMAC Calculation . . . . . . . . . . . . . . . . . . 80 167 6.4.2. Signature Calculation . . . . . . . . . . . . . . . . 82 168 6.5. HIP KEYMAT Generation . . . . . . . . . . . . . . . . . . 84 169 6.6. Initiation of a HIP Exchange . . . . . . . . . . . . . . 85 170 6.6.1. Sending Multiple I1 Packets in Parallel . . . . . . . 86 171 6.6.2. Processing Incoming ICMP Protocol Unreachable 172 Messages . . . . . . . . . . . . . . . . . . . . . . 87 173 6.7. Processing Incoming I1 Packets . . . . . . . . . . . . . 87 174 6.7.1. R1 Management . . . . . . . . . . . . . . . . . . . . 88 175 6.7.2. Handling Malformed Messages . . . . . . . . . . . . . 89 176 6.8. Processing Incoming R1 Packets . . . . . . . . . . . . . 89 177 6.8.1. Handling of Malformed Messages . . . . . . . . . . . 92 178 6.9. Processing Incoming I2 Packets . . . . . . . . . . . . . 92 179 6.9.1. Handling of Malformed Messages . . . . . . . . . . . 94 180 6.10. Processing of Incoming R2 Packets . . . . . . . . . . . . 95 181 6.11. Sending UPDATE Packets . . . . . . . . . . . . . . . . . 95 182 6.12. Receiving UPDATE Packets . . . . . . . . . . . . . . . . 96 183 6.12.1. Handling a SEQ Parameter in a Received UPDATE 184 Message . . . . . . . . . . . . . . . . . . . . . . . 97 185 6.12.2. Handling an ACK Parameter in a Received UPDATE 186 Packet . . . . . . . . . . . . . . . . . . . . . . . 98 187 6.13. Processing of NOTIFY Packets . . . . . . . . . . . . . . 98 188 6.14. Processing CLOSE Packets . . . . . . . . . . . . . . . . 99 189 6.15. Processing CLOSE_ACK Packets . . . . . . . . . . . . . . 99 190 6.16. Handling State Loss . . . . . . . . . . . . . . . . . . . 99 191 7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 99 192 8. Changes from RFC 5201 . . . . . . . . . . . . . . . . . . . . 100 193 8.1. Changes from draft-ietf-hip-rfc5201-bis-03 . . . . . . . 100 194 8.2. Changes from draft-ietf-hip-rfc5201-bis-02 . . . . . . . 101 195 8.3. Changes from draft-ietf-hip-rfc5201-bis-01 . . . . . . . 101 196 8.4. Changes from draft-ietf-hip-rfc5201-bis-00 . . . . . . . 103 197 8.5. Contents of draft-ietf-hip-rfc5201-bis-00 . . . . . . . . 103 198 9. Security Considerations . . . . . . . . . . . . . . . . . . . 103 199 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 106 200 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 108 201 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 109 202 12.1. Normative References . . . . . . . . . . . . . . . . . . 109 203 12.2. Informative References . . . . . . . . . . . . . . . . . 111 204 Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 113 205 Appendix B. Generating a Public Key Encoding from an HI . . . . 115 206 Appendix C. Example Checksums for HIP Packets . . . . . . . . . 115 207 C.1. IPv6 HIP Example (I1 packet) . . . . . . . . . . . . . . 116 208 C.2. IPv4 HIP Packet (I1 packet) . . . . . . . . . . . . . . . 116 209 C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . . 116 210 Appendix D. ECDH and ECDSA 160 Bit Groups . . . . . . . . . . . 117 211 Appendix E. HIT Suites and HIT Generation . . . . . . . . . . . 117 213 1. Introduction 215 This document specifies the details of the Host Identity Protocol 216 (HIP). A high-level description of the protocol and the underlying 217 architectural thinking is available in the separate HIP architecture 218 description [I-D.ietf-hip-rfc4423-bis]. Briefly, the HIP 219 architecture proposes an alternative to the dual use of IP addresses 220 as "locators" (routing labels) and "identifiers" (endpoint, or host, 221 identifiers). In HIP, public cryptographic keys, of a public/private 222 key pair, are used as Host Identifiers, to which higher layer 223 protocols are bound instead of an IP address. By using public keys 224 (and their representations) as host identifiers, dynamic changes to 225 IP address sets can be directly authenticated between hosts, and if 226 desired, strong authentication between hosts at the TCP/IP stack 227 level can be obtained. 229 This memo specifies the base HIP protocol ("base exchange") used 230 between hosts to establish an IP-layer communications context, called 231 HIP association, prior to communications. It also defines a packet 232 format and procedures for updating an active HIP association. Other 233 elements of the HIP architecture are specified in other documents, 234 such as. 236 o "Using the Encapsulating Security Payload (ESP) Transport Format 237 with the Host Identity Protocol (HIP)" [I-D.ietf-hip-rfc5202-bis]: 238 how to use the Encapsulating Security Payload (ESP) for integrity 239 protection and optional encryption 241 o "End-Host Mobility and Multihoming with the Host Identity 242 Protocol" [I-D.ietf-hip-rfc5206-bis]: how to support mobility and 243 multihoming in HIP 245 o "Host Identity Protocol (HIP) Domain Name System (DNS) Extensions" 246 [I-D.ietf-hip-rfc5205-bis]: how to extend DNS to contain Host 247 Identity information 249 o "Host Identity Protocol (HIP) Rendezvous Extension" 250 [I-D.ietf-hip-rfc5204-bis]: using a rendezvous mechanism to 251 contact mobile HIP hosts 253 Since the HIP Base Exchange was first developed, there have been a 254 few advances in cryptography and attacks against cryptographic 255 systems. As a result, all cryptographic protocols need to be agile. 256 That is it should be a part of the protocol to switch from one 257 cryptographic primitive to another, and reasonable effort should be 258 done to support a reasonable set of mainstream algorithms. This 259 update to the Base Exchange includes this needed cryptographic 260 agility while addressing the downgrade attacks that such flexibility 261 introduces. In particular, Elliptic Curve support (ECDSA and ECDH) 262 and alternative hash functions have been added. 264 1.1. A New Namespace and Identifiers 266 The Host Identity Protocol introduces a new namespace, the Host 267 Identity namespace. Some ramifications of this new namespace are 268 explained in the HIP architecture description 269 [I-D.ietf-hip-rfc4423-bis]. 271 There are two main representations of the Host Identity, the full 272 Host Identifier (HI) and the Host Identity Tag (HIT). The HI is a 273 public key and directly represents the Identity. Since there are 274 different public key algorithms that can be used with different key 275 lengths, the HI is unsuitable for use as a packet identifier, or as 276 an index into the various state-related implementation structures 277 needed to support HIP. Consequently, a hash of the HI, the Host 278 Identity Tag (HIT), is the operational representation. It is 128 279 bits long and is used in the HIP headers and to index the 280 corresponding state in the end hosts. The HIT has an important 281 security property in that it is self-certifying (see Section 3). 283 1.2. The HIP Base Exchange (BEX) 285 The HIP base exchange is a two-party cryptographic protocol used to 286 establish communications context between hosts. The base exchange is 287 a SIGMA-compliant [KRA03] four-packet exchange. The first party is 288 called the Initiator and the second party the Responder. The 289 protocol exchanges Diffie-Hellman keys in the 2nd and 3rd packets, 290 and authenticates the parties in the 3rd and 4th packets. The four- 291 packet design helps to make HIP DoS resilient. It allows the 292 Responder to stay stateless until the IP address and the a 293 cryptographic puzzle is verified. The Responder starts the puzzle 294 exchange in the 2nd packet, with the Initiator completing it in the 295 3rd packet before the Responder stores any state from the exchange. 297 The exchange can use the Diffie-Hellman output to encrypt the Host 298 Identity of the Initiator in the 3rd packet (although Aura, et al., 299 [AUR03] notes that such operation may interfere with packet- 300 inspecting middleboxes), or the Host Identity may instead be sent 301 unencrypted. The Responder's Host Identity is not protected. It 302 should be noted, however, that both the Initiator's and the 303 Responder's HITs are transported as such (in cleartext) in the 304 packets, allowing an eavesdropper with a priori knowledge about the 305 parties to identify them by their HITs. Hence, encrypting the HI of 306 any party does not provide privacy against such attacker. 308 Data packets start to flow after the 4th packet. The 3rd and 4th HIP 309 packets may carry a data payload in the future. However, the details 310 of this may be defined later. 312 An existing HIP association can be updated using the update mechanism 313 defined in this document, and when the association is no longer 314 needed, it can be closed using the defined closing mechanism. 316 Finally, HIP is designed as an end-to-end authentication and key 317 establishment protocol, to be used with Encapsulated Security Payload 318 (ESP) [I-D.ietf-hip-rfc5202-bis] and other end-to-end security 319 protocols. The base protocol does not cover all the fine-grained 320 policy control found in Internet Key Exchange (IKE) [RFC4306] that 321 allows IKE to support complex gateway policies. Thus, HIP is not a 322 complete replacement for IKE. 324 1.3. Memo Structure 326 The rest of this memo is structured as follows. Section 2 defines 327 the central keywords, notation, and terms used throughout the rest of 328 the document. Section 3 defines the structure of the Host Identity 329 and its various representations. Section 4 gives an overview of the 330 HIP base exchange protocol. Sections 5 and 6 define the detail 331 packet formats and rules for packet processing. Finally, Sections 7, 332 9, and 10 discuss policy, security, and IANA considerations, 333 respectively. 335 2. Terms and Definitions 337 2.1. Requirements Terminology 339 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 340 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 341 document are to be interpreted as described in RFC 2119 [RFC2119]. 343 2.2. Notation 345 [x] indicates that x is optional. 347 {x} indicates that x is encrypted. 349 X(y) indicates that y is a parameter of X. ` 351 i indicates that x exists i times. 353 --> signifies "Initiator to Responder" communication (requests). 355 <-- signifies "Responder to Initiator" communication (replies). 357 | signifies concatenation of information-- e.g., X | Y is the 358 concatenation of X with Y. 360 Ltrunc (H(x), K) denotes the lowest order K bits of the result of 361 the hash function H on the input x. 363 2.3. Definitions 365 Host Identity (HI) The Host Identity is the public key of a 366 signature algorithm and represents the identity of the host. In 367 HIP, a host proves its identity by creating a signature with the 368 private key belonging to its HI (c.f. Section 3). 370 Host Identity Tag (HIT) The Host Identity Tag is a shorthand for the 371 HI in IPv6 format. It is generated by hashing the HI (c.f. 372 Section 3.1). 374 HIT Suite: A HIT Suite groups all cryptographic algorithms that are 375 required to generate and use an HI and its HIT. In particular, 376 these algorithms are: 1) the public key signature algorithm and 2) 377 the hash function, 3) the truncation (c.f. Appendix E). 379 Responder's HIT Hash Algorithm (RHASH): The Hash algorithm used for 380 various hash calculations in this document. The algorithm is the 381 same as is used to generate the Responder's HIT. The RHASH is the 382 hash function defined by the HIT Suite of the Responder's HIT 383 (c.f. Appendix E). 385 Length of the Responder's HIT Hash Algorithm (RHASH_len): RHASH_len 386 is the natural output length of RHASH in bits. 388 3. Host Identifier (HI) and its Structure 390 In this section, the properties of the Host Identifier and Host 391 Identifier Tag are discussed, and the exact format for them is 392 defined. In HIP, the public key of an asymmetric key pair is used as 393 the Host Identifier (HI). Correspondingly, the host itself is 394 defined as the entity that holds the private key of the key pair. 395 See the HIP architecture specification [I-D.ietf-hip-rfc4423-bis] for 396 more details on the difference between an identity and the 397 corresponding identifier. 399 HIP implementations MUST support the Rivest Shamir Adelman (RSA) 400 [RFC3110] public key algorithm, and SHOULD support the Digital 401 Signature Algorithm (DSA) [RFC2536] algorithms, and Elliptic Curve 402 Digital Signature Algorithm (ECDSA) defined in Section 5.2.8. Other 403 algorithms MAY be supported. 405 A hashed encoding of the HI, the Host Identity Tag (HIT), is used in 406 protocols to represent the Host Identity. The HIT is 128 bits long 407 and has the following three key properties: i) it is the same length 408 as an IPv6 address and can be used in fixed address-sized fields in 409 APIs and protocols, ii) it is self-certifying (i.e., given a HIT, it 410 is computationally hard to find a Host Identity key that matches the 411 HIT), and iii) the probability of a HIT collision between two hosts 412 is very low, hence, it is infeasible for an attacker to find a 413 collision with a HIT that is in use. For details on the security 414 properties of the HIT see [I-D.ietf-hip-rfc4423-bis]. 416 The structure of the HIT is defined in [I-D.ietf-hip-rfc4843-bis]. 417 The HIT consists of three parts: first, an IANA assigned prefix to 418 distinguish it from other IPv6 addresses. Second, a four-bit 419 encoding of the algorithms that were used for generating the HI and 420 the hashed representation of HI. Third, a 96-bit hashed 421 representation of the Host Identity. The encoding of the ORCHID 422 generation algorithm and the exact algorithm for generating the 423 hashed representation is specified in Appendix E. 425 Carrying HIs and HITs in the header of user data packets would 426 increase the overhead of packets. Thus, it is not expected that they 427 are carried in every packet, but other methods are used to map the 428 data packets to the corresponding HIs. In some cases, this makes it 429 possible to use HIP without any additional headers in the user data 430 packets. For example, if ESP is used to protect data traffic, the 431 Security Parameter Index (SPI) carried in the ESP header can be used 432 to map the encrypted data packet to the correct HIP association. 434 3.1. Host Identity Tag (HIT) 436 The Host Identity Tag is a 128-bit value -- a hashed encoding of the 437 Host Identifier. There are two advantages of using a hashed encoding 438 over the actual variable-sized Host Identity public key in protocols. 439 Firstly, the fixed length of the HIT eases protocol coding and also 440 manages better the packet size cost of this technology. Secondly, it 441 presents a consistent format to the protocol, independently of the 442 underlying identity technology used. 444 RFC 4843-bis [I-D.ietf-hip-rfc4843-bis] specifies 128-bit hash-based 445 identifiers, called Overlay Routable Cryptographic Hash Identifiers 446 (ORCHIDs). Their prefix, allocated from the IPv6 address block, is 447 defined in [I-D.ietf-hip-rfc4843-bis]. The Host Identity Tag is one 448 type of an ORCHID. 450 This document extends [RFC5201] with measures to support crypto 451 agility. One of these measures is to allow different hash functions 452 for creating a HIT. HIT Suites group the sets of algorithms that are 453 required to generate and use a particular HIT. The Suites are 454 encoded in HIT Suite IDs. These HIT Suite IDs are transmitted in the 455 ORCHID Generation Algorithm (OGA) field in the ORCHID. With the HIT 456 Suite ID in the OGA field, a hosts can tell from another host's HIT, 457 whether it supports the necessary hash and signature algorithms to 458 establish a HIP association with that host. 460 3.2. Generating a HIT from an HI 462 The HIT MUST be generated according to the ORCHID generation method 463 described in [I-D.ietf-hip-rfc4843-bis] using a context ID value of 464 0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA (this tag value has been 465 generated randomly by the editor of this specification), and an input 466 that encodes the Host Identity field (see Section 5.2.8) present in a 467 HIP payload packet. The set of hash function, signature algorithm, 468 and the algorithm used for generating the HIT from the HI depends on 469 the HIT Suite (see Appendix E) and is indicated by the four bits of 470 the Orchid Generation Algorithm (OGA) field in the ORCHID. 471 Currently, truncated SHA-1 [FIPS.95-1.1993] and truncated SHA-256 472 [FIPS.180-2.2002] are defined as hashes for generating a HIT. 474 For Identities that are either RSA, Digital Signature Algorithm 475 (DSA), or Elliptic Curve DSA (ECDSA) public keys, the ORCHID input 476 consists of the public key encoding as specified in the Section 477 Section 5.2.8. This document defines four Algorithm profiles: RSA, 478 DSA, ECDSA, and ECDSA_LOW. The ECDSA_LOW profile is meant for 479 devices with low computational capabilities. There are currently 480 only three defined public key algorithm classes: RSA/SHA-1, DSA, and 481 ECDSA. Hence, either of the following applies: 483 The RSA public key is encoded as defined in [RFC3110] Section 2, 484 taking the exponent length (e_len), exponent (e), and modulus (n) 485 fields concatenated. The length (n_len) of the modulus (n) can be 486 determined from the total HI Length and the preceding HI fields 487 including the exponent (e). Thus, the data that serves as input 488 for the HIT generation has the same length as the HI. The fields 489 MUST be encoded in network byte order, as defined in [RFC3110]. 491 The DSA public key is encoded as defined in [RFC2536] Section 2, 492 taking the fields T, Q, P, G, and Y, concatenated as input. Thus, 493 the data to be hashed is 1 + 20 + 3 * 64 + 3 * 8 * T octets long, 494 where T is the size parameter as defined in [RFC2536]. The size 495 parameter T, affecting the field lengths, MUST be selected as the 496 minimum value that is long enough to accommodate P, G, and Y. The 497 fields MUST be encoded in network byte order, as defined in 498 [RFC2536]. 500 The ECDSA public keys are encoded as defined in 501 [I-D.mcgrew-fundamental-ecc] Section 4.2 and 6. 503 In Appendix B, the public key encoding process is illustrated using 504 pseudo-code. 506 4. Protocol Overview 508 This section is a simplified overview of the HIP protocol operation, 509 and does not contain all the details of the packet formats or the 510 packet processing steps. Sections 5 and 6 describe in more detail 511 the packet formats and packet processing steps, respectively, and are 512 normative in case of any conflicts with this section. 514 The protocol number 139 has been assigned by IANA to the Host 515 Identity Protocol. 517 The HIP payload (Section 5.1) header could be carried in every IP 518 datagram. However, since HIP headers are relatively large (40 519 bytes), it is desirable to 'compress' the HIP header so that the HIP 520 header only occurs in control packets used to establish or change HIP 521 association state. The actual method for header 'compression' and 522 for matching data packets with existing HIP associations (if any) is 523 defined in separate documents, describing transport formats and 524 methods. All HIP implementations MUST implement, at minimum, the ESP 525 transport format for HIP [I-D.ietf-hip-rfc5202-bis]. 527 4.1. Creating a HIP Association 529 By definition, the system initiating a HIP exchange is the Initiator, 530 and the peer is the Responder. This distinction is forgotten once 531 the base exchange completes, and either party can become the 532 Initiator in future communications. 534 The HIP base exchange serves to manage the establishment of state 535 between an Initiator and a Responder. The first packet, I1, 536 initiates the exchange, and the last three packets, R1, I2, and R2, 537 constitute an authenticated Diffie-Hellman [DIF76] key exchange for 538 session-key generation. In the first two packets, the hosts agree on 539 a set of cryptographic identifiers and algorithms that are then used 540 in and after the exchange. During the Diffie-Hellman key exchange, a 541 piece of keying material is generated. The HIP association keys are 542 drawn from this keying material. If other cryptographic keys are 543 needed, e.g., to be used with ESP, they are expected to be drawn from 544 the same keying material. 546 The Initiator first sends a trigger packet, I1, to the Responder. 547 The packet contains the HIT of the Initiator and possibly the HIT of 548 the Responder, if it is known. Moreover, the I1 packet initializes 549 the negotiation of the Diffie-Hellman group that is used for 550 generating the keying material. Therefore, the I1 packet contains a 551 list of Diffie Hellman Group IDs supported by the Initiator. Note 552 that in some cases it may be possible to replace this trigger packet 553 by some other form of a trigger, in which case the protocol starts 554 with the Responder sending the R1 packet. In such cases, another 555 mechanism to convey the Initiator's supported DH Groups (e.g., by 556 using a default group) must be specified. 558 The second packet, R1, starts the actual authenticated Diffie-Hellman 559 exchange. It contains a puzzle -- a cryptographic challenge that the 560 Initiator must solve before continuing the exchange. The level of 561 difficulty of the puzzle can be adjusted based on level of trust with 562 the Initiator, current load, or other factors. In addition, the R1 563 contains the Responder's Diffie-Hellman parameter and lists of 564 cryptographic algorithms supported by the Responder. Based on these 565 lists, the Initiator can continue, abort, or restart the base 566 exchange with a different selection of cryptographic algorithms. 567 Also, the R1 packet contains a signature that covers selected parts 568 of the message. Some fields are left outside the signature to 569 support pre-created R1s. 571 In the I2 packet, the Initiator must display the solution to the 572 received puzzle. Without a correct solution, the I2 message is 573 discarded. The I2 packet also contains a Diffie-Hellman parameter 574 that carries needed information for the Responder. The packet is 575 signed by the Initiator. 577 The R2 packet acknowledges the receipt of the I2 packet and completes 578 the base exchange. The packet is signed by the Responder. 580 The base exchange is illustrated below. The term "key" refers to the 581 Host Identity public key, and "sig" represents a signature using such 582 a key. The packets contain other parameters not shown in this 583 figure. 585 Initiator Responder 587 I1: DH list 588 --------------------------> 589 select precomputed R1 590 R1: puzzle, DH, key, sig 591 <------------------------- 592 check sig remain stateless 593 solve puzzle 594 I2: solution, DH, {key}, sig 595 --------------------------> 596 compute DH check puzzle 597 check sig 598 R2: sig 599 <-------------------------- 600 check sig compute DH 602 4.1.1. HIP Puzzle Mechanism 604 The purpose of the HIP puzzle mechanism is to protect the Responder 605 from a number of denial-of-service threats. It allows the Responder 606 to delay state creation until receiving the I2 packet. Furthermore, 607 the puzzle allows the Responder to use a fairly cheap calculation to 608 check that the Initiator is "sincere" in the sense that it has 609 churned enough CPU cycles in solving the puzzle. 611 The puzzle mechanism has been explicitly designed to give space for 612 various implementation options. First, it allows a Responder 613 implementation to completely delay session-specific state creation 614 until a valid I2 packet is received. In such a case, a correctly 615 formatted I2 packet can be rejected immediately once the Responder 616 has checked its validity by computing only one hash function. 617 Second, hand, the design also allows a Responder implementation to 618 keep state about received I1 packets, and match the received I2 619 packets against the state, thereby allowing the implementation to 620 avoid the computational cost of the hash function. The drawback of 621 this second approach is the requirement of creating state. Finally, 622 it also allows an implementation to use other combinations of the 623 space-saving and computation-saving mechanisms. 625 The Responder can remain stateless and drop most spoofed I2 packets 626 because puzzle calculation is based on the Initiator's Host Identity 627 Tag. The idea is that the Responder has a (perhaps varying) number of 628 pre-calculated R1 packets, and it selects one of these based on the 629 information carried in the I1 packet. When the Responder then later 630 receives the I2 packet, it can verify that the puzzle has been solved 631 using the Initiator's HIT. This makes it impractical for the 632 attacker to first exchange one I1/R1 packet, and then generate a 633 large number of spoofed I2 packets that seemingly come from different 634 HITs. This method does not protect the Responder from an attacker 635 that uses fixed HITs, though. Against such an attacker, a viable 636 approach may be to create a piece of local state, and remember that 637 the puzzle check has previously failed. See Appendix A for one 638 possible implementation. Responder implementations SHOULD include 639 sufficient randomness in the puzzle values so that algorithmic 640 complexity attacks become impossible [CRO03]. 642 The Responder can set the puzzle difficulty for the Initiator, based 643 on its level of trust of the Initiator. Because the puzzle is not 644 included in the signature calculation, the Responder can use pre- 645 calculated R1 packets and include the puzzle just before sending the 646 R1 to the Initiator. The Responder SHOULD use heuristics to 647 determine when it is under a denial-of-service attack, and set the 648 puzzle difficulty value K appropriately as explained later. 650 4.1.2. Puzzle Exchange 652 The Responder starts the puzzle exchange when it receives an I1 653 packet. The Responder supplies a random number I, and requires the 654 Initiator to find a number J. To select a proper J, the Initiator 655 must create the concatenation of I, the HITs of the parties, and J, 656 and calculate a hash over this concatenation using the RHASH 657 algorithm. The lowest order K bits of the result MUST be zeros. The 658 value K sets the difficulty of the puzzle. 660 To generate a proper number J, the Initiator will have to generate a 661 number of Js until one produces the hash target of zeros. The 662 Initiator SHOULD give up after exceeding the puzzle lifetime in the 663 PUZZLE parameter (as described in Section 5.2.4). The Responder 664 needs to re-create the concatenation of I, the HITs, and the provided 665 J, and compute the hash once to prove that the Initiator completed 666 its assigned task. 668 To prevent precomputation attacks, the Responder MUST select the 669 number I in such a way that the Initiator cannot guess it. 670 Furthermore, the construction MUST allow the Responder to verify that 671 the value I was indeed selected by it and not by the Initiator. See 672 Appendix A for an example on how to implement this. 674 Using the Opaque data field in the PUZZLE (see Section 5.2.4), in an 675 ECHO_REQUEST_SIGNED (see Section 5.2.19) or in an 676 ECHO_REQUEST_UNSIGNED parameter (see Section 5.2.20), the Responder 677 can include some data in R1 that the Initiator MUST copy unmodified 678 in the corresponding I2 packet. The Responder can use the opaque 679 data to transfer a piece of local state information to the Initiator 680 and back, for example to recognize that the I2 is a response to a 681 previously sent R1. The Responder can generate the Opaque data in 682 various ways; e.g., using encryption or hashing with some secret, the 683 sent I, and possibly using other related data. With the same secret, 684 the received I (from the I2 packet), and the other related data (if 685 any), the Receiver can verify that it has itself sent the I to the 686 Initiator. The Responder MUST periodically change such a secret. 688 It is RECOMMENDED that the Responder generates new secrets for the 689 puzzle and new R1s once every few minutes. Furthermore, it is 690 RECOMMENDED that the Responder is able to verify valid puzzle 691 solution at least Lifetime seconds after the puzzle secret has been 692 deprecated. This time value guarantees that the puzzle is valid for 693 at least Lifetime and at most 2*Lifetime seconds. This limits the 694 usability of an old, solved puzzle has to an attacker. Moreover, it 695 avoids problems with the validity of puzzles if the lifetime is 696 relatively short compared to the network delay and the time for 697 solving the puzzle. 699 The puzzle value I and the solution J are inputs for deriving the 700 keying material from the Diffie Hellman key exchange (see 701 Section 6.5). Therefore, a Responder SHOULD NOT use the same puzzle 702 I with the same DH keys for the same Initiator twice to ensure that 703 the derived keying material differs. Such uniqueness can be 704 achieved, for example, by using a counter as an additional input for 705 generating I. This counter can be increased for each processed I1 706 packet. The state of the counter can be transmitted in the Opaque 707 data field in the PUZZLE (see Section 5.2.4), in an 708 ECHO_REQUEST_SIGNED (see Section 5.2.19) or in an 709 ECHO_REQUEST_UNSIGNED parameter (see Section 5.2.20) without the need 710 to establish state. 712 NOTE: The protocol developers explicitly considered whether R1 should 713 include a timestamp in order to protect the Initiator from replay 714 attacks. The decision was to NOT include a timestamp to avoid 715 problems with global time synchronization. 717 NOTE: The protocol developers explicitly considered whether a memory 718 bound function should be used for the puzzle instead of a CPU-bound 719 function. The decision was not to use memory-bound functions. 721 4.1.3. Authenticated Diffie-Hellman Protocol with DH Group Negotiation 723 The packets R1, I2, and R2 implement a standard authenticated Diffie- 724 Hellman exchange. The Responder sends one of its public Diffie- 725 Hellman keys and its public authentication key, i.e., its Host 726 Identity, in R1. The signature in the R1 packet allows the Initiator 727 to verify that the R1 has been once generated by the Responder. 729 However, since it is precomputed and therefore does not cover 730 association-specific information in the I1 packet, it does not 731 protect from replay attacks. 733 Before the actual authenticated Diffie-Hellman exchange, the 734 Initiator expresses its preference regarding its choice of the DH 735 groups in the I1 packet. The preference is expressed as a sorted 736 list of DH Group IDs. The I1 packet is not protected by a signature. 737 Therefore, this list is sent in an unauthenticated way to avoid 738 costly computations for processing the I1 packet at the Responder 739 side. Based on the preferences of the Initiator, the Responder sends 740 an R1 packet containing its most suitable public DH value. The 741 Responder also attaches a list of its own preferences to the R1 to 742 convey the basis for the DH group selection to the Initiator. This 743 list is carried in the signed part of the R1 packet. If the choice 744 of the DH group value in the R1 does not match the preferences of the 745 Initiator and the Responder, the Initiator can detect that the list 746 of DH Group IDs in the I1 was manipulated (see below for details). 748 If none of the DH Group IDs in the I1 packet is supported by the 749 Responder, the Responder selects the DH Group most suitable for it 750 regardless of the Initiator's preference. It then sends the R1 751 containing this DH Group and its list of supported DH Group IDs to 752 the Initiator. 754 When the Initiator receives an R1, it receives one of the Responder's 755 public Diffie-Hellman values and the list of DH Group IDs supported 756 by the Responder. This list is covered by the signature in the R1 757 packet to avoid forgery. The Initiator compares the Group ID of the 758 public DH value in the R1 packet to the list of supported DH Group 759 IDs in the R1 packets and to its own preferences expressed in the 760 list of supported DH Group IDs. The Initiator continues the BEX only 761 if the Group ID of the public DH value of the Responder intersects 762 the preferences of both Initiator and Responder. Otherwise, the 763 communication is subject of a downgrade attack and the Initiator MUST 764 either restart the key exchange with a new I1 packet or abort the key 765 exchange. If the Responder's choice of the DH Group is not supported 766 by the Initiator, the Initiator MAY abort the handshake or send a new 767 I1 packet with a different list of supported DH Groups. However, the 768 Initiator MUST verify the signature of the R1 packet before 769 restarting or aborting the handshake. It MUST silently ignore the R1 770 packet if the signature is not valid. 772 If the preferences regarding the DH Group ID match, the Initiator 773 computes the Diffie-Hellman session key (Kij). The Initiator creates 774 a HIP association using keying material from the session key (see 775 Section 6.5), and may use the HIP association to encrypt its public 776 authentication key, i.e., Host Identity. The resulting I2 packet 777 contains the Initiator's Diffie-Hellman key and its (optionally 778 encrypted) public authentication key. The signature of the I2 779 message covers all signed parameters of the packet without exceptions 780 as in the R1. 782 The Responder extracts the Initiator's Diffie-Hellman public key from 783 the I2 packet, computes the Diffie-Hellman session key, creates a 784 corresponding HIP association, and decrypts the Initiator's public 785 authentication key. It can then verify the signature using the 786 authentication key. 788 The final message, R2, completes the BEX and protects the Initiator 789 against replay attacks because the Responder uses the shared key from 790 the Diffie-Hellman exchange to create a HMAC as well as it uses the 791 private key of its Host Identity to sign the packet contents. 793 4.1.4. HIP Replay Protection 795 The HIP protocol includes the following mechanisms to protect against 796 malicious packet replays. Responders are protected against replays 797 of I1 packets by virtue of the stateless response to I1 packets with 798 presigned R1 messages. Initiators are protected against R1 replays 799 by a monotonically increasing "R1 generation counter" included in the 800 R1. Responders are protected against replays of forged I2 packets by 801 the puzzle mechanism (see Section 4.1.1 above), and optional use of 802 opaque data. Hosts are protected against replays of R2 packets and 803 UPDATEs by use of a less expensive HMAC verification preceding the 804 HIP signature verification. 806 The R1 generation counter is a monotonically increasing 64-bit 807 counter that may be initialized to any value. The scope of the 808 counter MAY be system-wide but SHOULD be applied per Host Identity, 809 if there is more than one local host identity. The value of this 810 counter SHOULD be preserved across system reboots and invocations of 811 the HIP base exchange. This counter indicates the current generation 812 of puzzles. Implementations MUST accept puzzles from the current 813 generation and MAY accept puzzles from earlier generations. A 814 system's local counter MUST be incremented at least as often as every 815 time old R1s cease to be valid. The local counter SHOULD never be 816 decremented, lest the host exposes its peers to the replay of 817 previously generated, higher numbered R1s. The R1 counter SHOULD NOT 818 roll over. 820 A host may receive more than one R1, either due to sending multiple 821 I1 packets (see Section 6.6.1) or due to a replay of an old R1. When 822 sending multiple I1 packets, an Initiator SHOULD wait for a small 823 amount of time (a reasonable time may be 2 * expected RTT) after the 824 first R1 reception to allow possibly multiple R1s to arrive, and it 825 SHOULD respond to an R1 among the set with the largest R1 generation 826 counter. If an Initiator is processing an R1 or has already sent an 827 I2 packet (still waiting for the R2 packet) and it receives another 828 R1 with a larger R1 generation counter, it MAY elect to restart R1 829 processing with the fresher R1, as if it were the first R1 to arrive. 831 Upon conclusion of an active HIP association with another host, the 832 R1 generation counter associated with the peer host SHOULD be 833 flushed. A local policy MAY override the default flushing of R1 834 counters on a per-HIT basis. The reason for recommending the 835 flushing of this counter is that there may be hosts where the R1 836 generation counter (occasionally) decreases; e.g., due to hardware 837 failure. 839 4.1.5. Refusing a HIP Exchange 841 A HIP-aware host may choose not to accept a HIP exchange. If the 842 host's policy is to only be an Initiator, it should begin its own HIP 843 exchange. A host MAY choose to have such a policy since only the 844 privacy of the Initiator's HI is protected in the exchange. It 845 should be noted that such behavior can introduce the risk of a race 846 condition if each host's policy is to only be an Initiator, at which 847 point the HIP exchange will fail. 849 If the host's policy does not permit it to enter into a HIP exchange 850 with the Initiator, it should send an ICMP 'Destination Unreachable, 851 Administratively Prohibited' message. A more complex HIP packet is 852 not used here as it actually opens up more potential DoS attacks than 853 a simple ICMP message. A HIP NOTIFY message is not used because no 854 HIP session exists between the two hosts at that time. 856 4.1.6. Aborting a HIP Exchange 858 Two HIP hosts may encounter situations in which they cannot complete 859 a HIP exchange because of insufficient support for cryptographic 860 algorithms, in particular the HIT Suites and DH Groups. After 861 receiving the R1 packet, the Initiator can determine whether the 862 Responder supports the required cryptographic operations to 863 successfully establish a HIP association. The Initiator can abort 864 the BEX silently after receiving an R1 packet that indicates an 865 unsupported set of algorithms. The specific conditions are described 866 below. 868 The R1 packet contains a signed list of HIT Suite IDs as supported by 869 the Responder. Therefore, the Initiator can determine whether its 870 source HIT is supported by the Responder. If the HIT Suite ID of the 871 Initiator's HIT is not contained in the list of HIT Suites in the R1, 872 the Initiator MAY abort the handshake silently or MAY restart the 873 handshake with a new I1 packet that contains a source HIT supported 874 by the Responder. 876 During the Handshake, the Initiator and the Responder agree on a 877 single DH Group. The Responder selects the DH Group and its DH 878 public value in the R1 based on the list of DH Suite IDs in the I1 879 packet. If the responder supports none of the DH Groups requested by 880 the Initiator, the Responder selects an arbitrary DH and replies with 881 an R1 containing its list of supported DH Group IDs. In such case, 882 the Initiator receives an R1 packet containing the DH public value 883 for an unrequested DH Group and also the Responder's DH Group list in 884 the signed part of the R1 packet. At this point, the Initiator MAY 885 abort the handshake or MAY restart the handshake by sending a new I1 886 packet containing a selection of DH Group IDs that is supported by 887 the Responder. 889 4.1.7. HIP Downgrade Protection 891 In a downgrade attack, an attacker manipulates the packets of an 892 Initiator and/or a Responder to unnoticeably influence the result of 893 the cryptographic negotiations in the BEX to its favor. As a result, 894 the victims select weaker cryptographic algorithms than they would 895 otherwise have without the attacker's interference. Downgrade 896 attacks can only be successful if they are remain un-detected by the 897 victims and the victims falsely assume a secure communication 898 channel. 900 In HIP, almost all packet parameters related to cryptographic 901 negotiations are covered by signatures. These parameters cannot be 902 directly manipulated in a downgrade attack without invalidating the 903 signature. However, signed packets can be subject to replay attacks. 904 In such a replay attack, the attacker could use an old BEX packet 905 with an outdated and weak selection of cryptographic algorithms and 906 replay it instead of a more recent packet with a collection of 907 stronger cryptographic algorithms. Signed packets that could be 908 subject to this replay attack are the R1 and I2 packet. However, 909 replayed R1 and I2 packets cannot be used to successfully establish a 910 HIP BEX because these packets also contain the public DH values of 911 the Initiator and the Responder. Old DH values from replayed packets 912 lead to invalid keying material and mismatching shared secrets. 913 Because the attacker is unable to derive valid keying material from 914 the DH public keys in the R1 and cannot generate a valid HMAC and 915 signature for a replayed I2. 917 In contrast to the first version of HIP [RFC5201], this version 918 begins the negotiation of the DH Groups already in the first BEX 919 packet, the I1. The I1 packet is, by intention, not protected by a 920 signature to avoid CPU-intensive cryptographic operations for 921 processing floods of I1 packets targeted at the Responder. Hence, 922 the list of DH Group IDs in the I1 packet is vulnerable to forgery 923 and manipulation. To thwart an unnoticed manipulation of the I1 924 packet, the Responder chooses the DH Group deterministically and 925 includes its own list of DH Group IDs in the signed part of the R1 926 packet. The Initiator can detect an attempted downgrade attack by 927 comparing the list of DH Group IDs in the R1 packet to its own 928 preferences in the I1 packet. If the choice of the DH Group in the 929 R1 packet does not equal to the best match of the two lists (the 930 highest priority of the Responder that is present in the Initiator's 931 DH list), the Initiator can conclude that its list in the I1 packet 932 was altered by an attacker. In this case, the Initiator can restart 933 or abort the BEX. As mentioned before, the detection of the 934 downgrade attack is sufficient to prevent it. 936 4.1.8. HIP Opportunistic Mode 938 It is possible to initiate a HIP BEX even if the Responder's HI (and 939 HIT) is unknown. In this case, the initial I1 packet contains all 940 zeros as the destination HIT. This kind of connection setup is 941 called opportunistic mode. 943 The Responder may have multiple HITs due to multiple supported HIT 944 Suites. Since the Responder's HIT Suite is not determined by the 945 destination HIT of the I1 packet, the Responder can freely select a 946 HIT of any HIT Suite. The complete set of HIT Suites supported by 947 the Initiator is not known to the Responder. Therefore, the 948 Responder SHOULD should select its HIT from the same HIT Suite as the 949 Initiator's HIT (indicated by the HIT suite information in the OGA 950 field of the Initiator's HIT) because this HIT Suite is obviously 951 supported by the Initiator. If the Responder selects a different HIT 952 that is not supported by the Initiator, the Initiator MAY restart the 953 BEX with an I1 packet with a source HIT that is contained in the list 954 of the Responder's HIT Suites in the R1 packet. 956 Note that the Initiator cannot verify the signature of the R1 packet 957 if the Responder's HIT Suite is not supported. Therefore, the 958 Initiator MUST treat R1 packets with unsupported Responder HITs as 959 potentially forged and MUST NOT use any parameters from the 960 unverified R1 besides the HIT Suite List. Moreover, an Initiator 961 that uses an unverified HIT Suite List from an R1 packet to determine 962 a possible source HIT MUST verify that the HIT_SUITE_LIST in the 963 first unverified R1 packet matches the HIT_SUITE_LIST in the second 964 R1 packet for which the Initiator supports the signature algorithm. 965 The Initiator MUST restart the BEX with a new I1 packet for which the 966 algorithm was mentioned in the verifiable R1 if the two lists do not 967 match. This procedure is necessary to mitigate downgrade attacks. 969 There are both security and API issues involved with the 970 opportunistic mode. These issues are described in the reminder of 971 this section. 973 Given that the Responder's HI is not known by the Initiator, there 974 must be suitable API calls that allow the Initiator to request, 975 directly or indirectly, that the underlying system initiates the HIP 976 base exchange solely based on locators. The Responder's HI will be 977 tentatively available in the R1 packet, and in an authenticated form 978 once the R2 packet has been received and verified. Hence, the 979 Responder's HIT could be communicated to the application via new API 980 mechanisms. However, with a backwards-compatible API the application 981 sees only the locators used for the initial contact. Depending on 982 the desired semantics of the API, this can raise the following 983 issues: 985 o The actual locators may later change if an UPDATE message is used, 986 even if from the API perspective the session still appears to be 987 between two specific locators. However, the locator update is 988 still secure and the session is still between the same nodes. 990 o Different sessions between the same two locators may result in 991 connections to different nodes, if the implementation no longer 992 remembers which identifier the peer had in an earlier session. 993 This is possible when the peer's locator has changed for 994 legitimate reasons or when an attacker pretends to be a node that 995 has the peer's locator. Therefore, when using opportunistic mode, 996 HIP implementations MUST NOT place any expectation that the peer's 997 HI returned in the R1 message matches any HI previously seen from 998 that address. 1000 If the HIP implementation and application do not have the same 1001 understanding of what constitutes a session, this may even happen 1002 within the same session. For instance, an implementation may not 1003 know when HIP state can be purged for UDP-based applications. 1005 o As with all HIP exchanges, the handling of locator-based or 1006 interface-based policy is unclear for HIP in opportunistic mode. 1007 An application may create a connection to a specific locator 1008 because the application has knowledge of the security properties 1009 along the network to that locator. If one of the nodes moves and 1010 the locators are updated, these security properties may not be 1011 maintained. Depending on the security policy of the application, 1012 this may be a problem. This is an area of ongoing study. As an 1013 example, there is work to create an API that applications can use 1014 to specify their security requirements in a similar context 1015 [I-D.ietf-btns-c-api]. 1017 In addition, the following security considerations apply. The 1018 generation counter mechanism will be less efficient in protecting 1019 against replays of the R1 packet, given that the Responder can choose 1020 a replay that uses an arbitrary HI, not just the one given in the I1 1021 packet. 1023 More importantly, the opportunistic exchange is vulnerable to man-in- 1024 the-middle attacks, because the Initiator does not have any public 1025 key information about the peer. To assess the impacts of this 1026 vulnerability, we compare it to vulnerabilities in current, non-HIP- 1027 capable communications. 1029 An attacker on the path between the two peers can insert itself as a 1030 man-in-the-middle by providing its own identifier to the Initiator 1031 and then initiating another HIP session towards the Responder. For 1032 this to be possible, the Initiator must employ opportunistic mode, 1033 and the Responder must be configured to accept a connection from any 1034 HIP-enabled node. 1036 An attacker outside the path will be unable to do so, given that it 1037 cannot respond to the messages in the base exchange. 1039 These security properties are characteristic also of communications 1040 in the current Internet. A client contacting a server without 1041 employing end-to-end security may find itself talking to the server 1042 via a man-in-the-middle, assuming again that the server is willing to 1043 talk to anyone. 1045 If end-to-end security is in place, then the worst that can happen in 1046 both the opportunistic HIP and non-HIP (normal IP) cases is denial- 1047 of-service; an entity on the path can disrupt communications, but 1048 will be unable to successfully insert itself as a man-in-the-middle. 1050 However, once the opportunistic exchange has successfully completed, 1051 HIP provides confidentiality and integrity protection for the 1052 communications, and can securely change the locators of the 1053 endpoints. 1055 As a result, it is believed that the HIP opportunistic mode is at 1056 least as secure as current IP. 1058 4.2. Updating a HIP Association 1060 A HIP association between two hosts may need to be updated over time. 1061 Examples include the need to rekey expiring user data security 1062 associations, add new security associations, or change IP addresses 1063 associated with hosts. The UPDATE packet is used for those and other 1064 similar purposes. This document only specifies the UPDATE packet 1065 format and basic processing rules, with mandatory parameters. The 1066 actual usage is defined in separate specifications. 1068 HIP provides a general purpose UPDATE packet, which can carry 1069 multiple HIP parameters, for updating the HIP state between two 1070 peers. The UPDATE mechanism has the following properties: 1072 UPDATE messages carry a monotonically increasing sequence number 1073 and are explicitly acknowledged by the peer. Lost UPDATEs or 1074 acknowledgments may be recovered via retransmission. Multiple 1075 UPDATE messages may be outstanding under certain circumstances. 1077 UPDATE is protected by both HIP_MAC and HIP_SIGNATURE parameters, 1078 since processing UPDATE signatures alone is a potential DoS attack 1079 against intermediate systems. 1081 UPDATE packets are explicitly acknowledged by the use of an 1082 acknowledgment parameter that echoes an individual sequence number 1083 received from the peer. A single UPDATE packet may contain both a 1084 sequence number and one or more acknowledgment numbers (i.e., 1085 piggybacked acknowledgment(s) for the peer's UPDATE). 1087 The UPDATE packet is defined in Section 5.3.5. 1089 4.3. Error Processing 1091 HIP error processing behavior depends on whether or not there exists 1092 an active HIP association. In general, if a HIP association exists 1093 between the sender and receiver of a packet causing an error 1094 condition, the receiver SHOULD respond with a NOTIFY packet. On the 1095 other hand, if there are no existing HIP associations between the 1096 sender and receiver, or the receiver cannot reasonably determine the 1097 identity of the sender, the receiver MAY respond with a suitable ICMP 1098 message; see Section 5.4 for more details. 1100 The HIP protocol and state machine are designed to recover from one 1101 of the parties crashing and losing its state. The following 1102 scenarios describe the main use cases covered by the design. 1104 No prior state between the two systems. 1106 The system with data to send is the Initiator. The process 1107 follows the standard four-packet base exchange, establishing 1108 the HIP association. 1110 The system with data to send has no state with the receiver, but 1111 the receiver has a residual HIP association. 1113 The system with data to send is the Initiator. The Initiator 1114 acts as in no prior state, sendin an I1 packet and receiving an 1115 R1 packet. When the Responder receives a valid I2 packet, the 1116 old association is 'discovered' and deleted, and the new 1117 association is established. 1119 The system with data to send has a HIP association, but the 1120 receiver does not. 1122 The system sends data on the outbound user data security 1123 association. The receiver 'detects' the situation when it 1124 receives a user data packet that it cannot match to any HIP 1125 association. The receiving host MUST discard this packet. 1127 Optionally, the receiving host MAY send an ICMP packet, with 1128 the type Parameter Problem, to inform the sender that the HIP 1129 association does not exist (see Section 5.4), and it MAY 1130 initiate a new HIP BEX. However, responding with these 1131 optional mechanisms is implementation or policy dependent. 1133 4.4. HIP State Machine 1135 The HIP protocol itself has little state. In the HIP base exchange, 1136 there is an Initiator and a Responder. Once the security 1137 associations (SAs) are established, this distinction is lost. If the 1138 HIP state needs to be re-established, the controlling parameters are 1139 which peer still has state and which has a datagram to send to its 1140 peer. The following state machine attempts to capture these 1141 processes. 1143 The state machine is symmetric and is presented in a single system 1144 view, representing either an Initiator or a Responder. The state 1145 machine is not a full representation of the processing logic. 1146 Additional processing rules are presented in the packet definitions. 1147 Hence, both are needed to completely implement HIP. 1149 This document extends the state machine as defined in [RFC5201] and 1150 introduces a restart option to allow for the negotiation of 1151 cryptographic algorithms. The extension to the previous state 1152 machine in [RFC5201] is a transition from state I1-SENT to I1-SENT - 1153 the restart option. An Initiator is required to restart the HIP 1154 exchange if the Responder does not support the HIT Suite of the 1155 Initiator. In this case, the Initiator restarts the HIP exchange by 1156 sending a new I1 packet with a source HIT supported by the Responder. 1158 Implementors must understand that the state machine, as described 1159 here, is informational. Specific implementations are free to 1160 implement the actual processing logic differently. Section 6 1161 describes the packet processing rules in more detail. This state 1162 machine focuses on the HIP I1, R1, I2, and R2 packets only. New 1163 states may be introduced by mechanisms in other specifications (such 1164 as mobility and multihoming). 1166 4.4.1. Timespan Definitions 1168 Unused Association Lifetime (UAL): Implementation-specific time for 1169 which, if no packet is sent or received for this time interval, a 1170 host MAY begin to tear down an active HIP association. 1172 Maximum Segment Lifetime (MSL): Maximum time that a TCP segment is 1173 expected to spend in the network. 1175 Exchange Complete (EC): Time that the host spends at the R2-SENT 1176 before it moves to ESTABLISHED state. The time is n * I2 1177 retransmission timeout, where n is about I2_RETRIES_MAX. 1179 4.4.2. HIP States 1181 +---------------------+---------------------------------------------+ 1182 | State | Explanation | 1183 +---------------------+---------------------------------------------+ 1184 | UNASSOCIATED | State machine start | 1185 | | | 1186 | I1-SENT | Initiating base exchange | 1187 | | | 1188 | I2-SENT | Waiting to complete base exchange | 1189 | | | 1190 | R2-SENT | Waiting to complete base exchange | 1191 | | | 1192 | ESTABLISHED | HIP association established | 1193 | | | 1194 | CLOSING | HIP association closing, no data can be | 1195 | | sent | 1196 | | | 1197 | CLOSED | HIP association closed, no data can be sent | 1198 | | | 1199 | E-FAILED | HIP exchange failed | 1200 +---------------------+---------------------------------------------+ 1202 Table 1: HIP States 1204 4.4.3. HIP State Processes 1206 System behavior in state UNASSOCIATED, Table 2. 1208 +---------------------+---------------------------------------------+ 1209 | Trigger | Action | 1210 +---------------------+---------------------------------------------+ 1211 | User data to send, | Send I1 and go to I1-SENT | 1212 | requiring a new HIP | | 1213 | association | | 1214 | | | 1215 | Receive I1 | Send R1 and stay at UNASSOCIATED | 1216 | | | 1217 | Receive I2, process | If successful, send R2 and go to R2-SENT | 1218 | | | 1219 | | If fail, stay at UNASSOCIATED | 1220 | | | 1221 | Receive user data | Optionally send ICMP as defined in | 1222 | for an unknown HIP | Section 5.4 and stay at UNASSOCIATED | 1223 | association | | 1224 | | | 1225 | Receive CLOSE | Optionally send ICMP Parameter Problem and | 1226 | | stay at UNASSOCIATED | 1227 | | | 1228 | Receive ANYOTHER | Drop and stay at UNASSOCIATED | 1229 +---------------------+---------------------------------------------+ 1231 Table 2: UNASSOCIATED - Start state 1233 System behavior in state I1-SENT, Table 3. 1235 +---------------------+---------------------------------------------+ 1236 | Trigger | Action | 1237 +---------------------+---------------------------------------------+ 1238 | Receive I1 | If the local HIT is smaller than the peer | 1239 | | HIT, drop I1 and stay at I1-SENT | 1240 | | | 1241 | | If the local HIT is greater than the peer | 1242 | | HIT, send R1 and stay at I1_SENT | 1243 | | | 1244 | Receive I2, process | If successful, send R2 and go to R2-SENT | 1245 | | | 1246 | | If fail, stay at I1-SENT | 1247 | | | 1248 | Receive R1, process | If the HIT Suite of the local HIT is not | 1249 | | supported by the peer, select supported | 1250 | | local HIT, send I1 and stay at I1-SENT | 1251 | | | 1252 | | If successful, send I2 and go to I2-SENT | 1253 | | | 1254 | | If fail, stay at I1-SENT | 1255 | | | 1256 | Receive ANYOTHER | Drop and stay at I1-SENT | 1257 | | | 1258 | Timeout | Increment timeout counter | 1259 | | | 1260 | | If counter is less than I1_RETRIES_MAX, | 1261 | | send I1 and stay at I1-SENT | 1262 | | | 1263 | | If counter is greater than I1_RETRIES_MAX, | 1264 | | go to E-FAILED | 1265 +---------------------+---------------------------------------------+ 1267 Table 3: I1-SENT - Initiating HIP 1269 System behavior in state I2-SENT, Table 4. 1271 +---------------------+---------------------------------------------+ 1272 | Trigger | Action | 1273 +---------------------+---------------------------------------------+ 1274 | Receive I1 | Send R1 and stay at I2-SENT | 1275 | | | 1276 | Receive R1, process | If successful, send I2 and stay at I2-SENT | 1277 | | | 1278 | | If fail, stay at I2-SENT | 1279 | | | 1280 | Receive I2, process | If successful and local HIT is smaller than | 1281 | | the peer HIT, drop I2 and stay at I2-SENT | 1282 | | | 1283 | | If successful and local HIT is greater than | 1284 | | the peer HIT, send R2 and go to R2-SENT | 1285 | | | 1286 | | If fail, stay at I2-SENT | 1287 | | | 1288 | Receive R2, process | If successful, go to ESTABLISHED | 1289 | | | 1290 | | If fail, stay at I2-SENT | 1291 | | | 1292 | Receive CLOSE, | If successful, send CLOSE_ACK and go to | 1293 | process | CLOSED | 1294 | | | 1295 | | If fail, stay at I2-SENT | 1296 | | | 1297 | Receive ANYOTHER | Drop and stay at I2-SENT | 1298 | | | 1299 | Timeout | Increment timeout counter | 1300 | | | 1301 | | If counter is less than I2_RETRIES_MAX, | 1302 | | send I2 and stay at I2-SENT | 1303 | | | 1304 | | If counter is greater than I2_RETRIES_MAX, | 1305 | | go to E-FAILED | 1306 +---------------------+---------------------------------------------+ 1308 Table 4: I2-SENT - Waiting to finish HIP 1310 System behavior in state R2-SENT, Table 5. 1312 +---------------------+---------------------------------------------+ 1313 | Trigger | Action | 1314 +---------------------+---------------------------------------------+ 1315 | Receive I1 | Send R1 and stay at R2-SENT | 1316 | | | 1317 | Receive I2, process | If successful, send R2 and stay at R2-SENT | 1318 | | | 1319 | | If fail, stay at R2-SENT | 1320 | | | 1321 | Receive R1 | Drop and stay at R2-SENT | 1322 | | | 1323 | Receive R2 | Drop and stay at R2-SENT | 1324 | | | 1325 | Receive data or | Move to ESTABLISHED | 1326 | UPDATE | | 1327 | | | 1328 | Exchange Complete | Move to ESTABLISHED | 1329 | Timeout | | 1330 | | | 1331 | Receive CLOSE, | If successful, send CLOSE_ACK and go to | 1332 | process | CLOSED | 1333 | | | 1334 | | If fail, stay at ESTABLISHED | 1335 | | | 1336 | Receive NOTIFY | Process and stay at R2-SENT | 1337 +---------------------+---------------------------------------------+ 1339 Table 5: R2-SENT - Waiting to finish HIP 1341 System behavior in state ESTABLISHED, Table 6. 1343 +---------------------+---------------------------------------------+ 1344 | Trigger | Action | 1345 +---------------------+---------------------------------------------+ 1346 | Receive I1 | Send R1 and stay at ESTABLISHED | 1347 | | | 1348 | Receive I2 | Process with puzzle and possible Opaque | 1349 | | data verification | 1350 | | | 1351 | | If successful, send R2, drop old HIP | 1352 | | association, establish a new HIP | 1353 | | association and go to R2-SENT | 1354 | | | 1355 | | If fail, stay at ESTABLISHED | 1356 | | | 1357 | Receive R1 | Drop and stay at ESTABLISHED | 1358 | | | 1359 | Receive R2 | Drop and stay at ESTABLISHED | 1360 | | | 1361 | Receive user data | Process and stay at ESTABLISHED | 1362 | for HIP association | | 1363 | | | 1364 | No packet | Send CLOSE and go to CLOSING | 1365 | sent/received | | 1366 | during UAL minutes | | 1367 | | | 1368 | Receive UPDATE | Process and stay at ESTABLISHED | 1369 | | | 1370 | Receive CLOSE, | If successful, send CLOSE_ACK and go to | 1371 | process | CLOSED | 1372 | | | 1373 | | If fail, stay at ESTABLISHED | 1374 | | | 1375 | Receive CLOSE_ACK | Drop and stay at ESTABLISHED | 1376 | | | 1377 | Receive NOTIFY | Process and stay at ESTABLISHED | 1378 +---------------------+---------------------------------------------+ 1380 Table 6: ESTABLISHED - HIP association established 1382 System behavior in state CLOSING, Table 7. 1384 +---------------------+---------------------------------------------+ 1385 | Trigger | Action | 1386 +---------------------+---------------------------------------------+ 1387 | User data to send, | Send I1 and stay at CLOSING | 1388 | requires the | | 1389 | creation of another | | 1390 | incarnation of the | | 1391 | HIP association | | 1392 | | | 1393 | Receive I1 | Send R1 and stay at CLOSING | 1394 | | | 1395 | Receive I2, process | If successful, send R2 and go to R2-SENT | 1396 | | | 1397 | | If fail, stay at CLOSING | 1398 | | | 1399 | Receive R1, process | If successful, send I2 and go to I2-SENT | 1400 | | | 1401 | | If fail, stay at CLOSING | 1402 | | | 1403 | Receive CLOSE, | If successful, send CLOSE_ACK, discard | 1404 | process | state and go to CLOSED | 1405 | | | 1406 | | If fail, stay at CLOSING | 1407 | | | 1408 | Receive CLOSE_ACK, | If successful, discard state and go to | 1409 | process | UNASSOCIATED | 1410 | | | 1411 | | If fail, stay at CLOSING | 1412 | | | 1413 | Receive ANYOTHER | Drop and stay at CLOSING | 1414 | | | 1415 | Timeout, increment | If timeout sum is less than UAL+MSL | 1416 | timeout sum, reset | minutes, retransmit CLOSE and stay at | 1417 | timer | CLOSING | 1418 | | | 1419 | | If timeout sum is greater than UAL+MSL | 1420 | | minutes, go to UNASSOCIATED | 1421 +---------------------+---------------------------------------------+ 1423 Table 7: CLOSING - HIP association has not been used for UAL minutes 1424 System behavior in state CLOSED, Table 8. 1426 +---------------------+---------------------------------------------+ 1427 | Trigger | Action | 1428 +---------------------+---------------------------------------------+ 1429 | Datagram to send, | Send I1, and stay at CLOSED | 1430 | requires the | | 1431 | creation of another | | 1432 | incarnation of the | | 1433 | HIP association | | 1434 | | | 1435 | Receive I1 | Send R1 and stay at CLOSED | 1436 | | | 1437 | Receive I2, process | If successful, send R2 and go to R2-SENT | 1438 | | | 1439 | | If fail, stay at CLOSED | 1440 | | | 1441 | Receive R1, process | If successful, send I2 and go to I2-SENT | 1442 | | | 1443 | | If fail, stay at CLOSED | 1444 | | | 1445 | Receive CLOSE, | If successful, send CLOSE_ACK, stay at | 1446 | process | CLOSED | 1447 | | | 1448 | | If fail, stay at CLOSED | 1449 | | | 1450 | Receive CLOSE_ACK, | If successful, discard state and go to | 1451 | process | UNASSOCIATED | 1452 | | | 1453 | | If fail, stay at CLOSED | 1454 | | | 1455 | Receive ANYOTHER | Drop and stay at CLOSED | 1456 | | | 1457 | Timeout (UAL+2MSL) | Discard state, and go to UNASSOCIATED | 1458 +---------------------+---------------------------------------------+ 1460 Table 8: CLOSED - CLOSE_ACK sent, resending CLOSE_ACK if necessary 1462 System behavior in state E-FAILED, Table 9. 1464 +-------------------------+-----------------------------------------+ 1465 | Trigger | Action | 1466 +-------------------------+-----------------------------------------+ 1467 | Wait for | Go to UNASSOCIATED. Re-negotiation is | 1468 | implementation-specific | possible after moving to UNASSOCIATED | 1469 | time | state. | 1470 +-------------------------+-----------------------------------------+ 1471 Table 9: E-FAILED - HIP failed to establish association with peer 1473 4.4.4. Simplified HIP State Diagram 1475 The following diagram shows the major state transitions. Transitions 1476 based on received packets implicitly assume that the packets are 1477 successfully authenticated or processed. 1479 +--+ +----------------------------+ 1480 recv I1, send R1 | | | | 1481 | v v | 1482 +--------------+ recv I2, send R2 | 1483 +----------------| UNASSOCIATED |----------------+ | 1484 datagram| +--+ +--------------+ | | 1485 to send,| | | Alg. not supported, | | 1486 send I1| | | send I1 | | 1487 v | v | | 1488 +---------+ recv I2, send R2 | | 1489 +---->| I1-SENT |--------------------------------------+ | | 1490 | +---------+ | | | 1491 | | +----------------------+ | | | 1492 | | recv R2, | recv I2, send R2 | | | | 1493 | v send I2 | v v v | 1494 | +---------+ | +---------+ | 1495 | +--->| I2-SENT |----------+ +--------------| R2-SENT |<---+ | 1496 | | +---------+ | +---------+ | | 1497 | | | | | | | | 1498 | | | |recv R2 | data or| | | 1499 | |recv R1, | | | EC timeout| | | 1500 | |send I2 +--|-----------------+ | receive I2,| | 1501 | | | | +-------------+ | send R2| | 1502 | | | +------>| ESTABLISHED |<----------+ | | 1503 | | | +-------------+ | | 1504 | | | | | | receive I2, send R2 | | 1505 | | +------------+ | +-------------------------------+ | 1506 | | | +-----------+ | | 1507 | | | no packet sent/received| +---+ | | 1508 | | | for UAL min, send CLOSE| | |timeout | | 1509 | | | v v |(UAL+MSL) | | 1510 | | | +---------+ |retransmit | | 1511 +--|----------|------------------------| CLOSING |-+CLOSE | | 1512 | | +---------+ | | 1513 | | | | | | | | 1514 +----------|-------------------------+ | | +----------------+ | 1515 | | +-----------+ +------------------|--+ 1516 | | |recv CLOSE, recv CLOSE_ACK | | 1517 | | |send CLOSE_ACK or timeout | | 1518 | +-------------+ | (UAL+MSL) | | 1519 | recv CLOSE, | | | | 1520 | send CLOSE_ACK v v | | 1521 | +--------+ receive I2, send R2 | | 1522 +---------------------| CLOSED |------------------------------+ | 1523 +--------+ | 1524 ^ | | | 1525 recv CLOSE, send CLOSE_ACK| | | timeout (UAL+2MSL) | 1526 +-+ +------------------------------------+ 1528 4.5. User Data Considerations 1530 4.5.1. TCP and UDP Pseudo-Header Computation for User Data 1532 When computing TCP and UDP checksums on user data packets that flow 1533 through sockets bound to HITs, the IPv6 pseudo-header format 1534 [RFC2460] MUST be used, even if the actual addresses on the packet 1535 are IPv4 addresses. Additionally, the HITs MUST be used in the place 1536 of the IPv6 addresses in the IPv6 pseudo-header. Note that the 1537 pseudo-header for actual HIP payloads is computed differently; see 1538 Section 5.1.1. 1540 4.5.2. Sending Data on HIP Packets 1542 A future version of this document may define how to include user data 1543 in various HIP packets. However, currently the HIP header is a 1544 terminal header, and not followed by any other headers. 1546 4.5.3. Transport Formats 1548 The actual data transmission format, used for user data after the HIP 1549 base exchange, is not defined in this document. Such transport 1550 formats and methods are described in separate specifications. All 1551 HIP implementations MUST implement, at minimum, the ESP transport 1552 format for HIP [I-D.ietf-hip-rfc5202-bis]. 1554 4.5.4. Reboot, Timeout, and Restart of HIP 1556 Simulating a loss of state is a potential DoS attack. The following 1557 process has been crafted to manage state recovery without presenting 1558 a DoS opportunity. 1560 If a host reboots or the HIP association times out, it has lost its 1561 HIP state. If the host that lost state has a datagram to send to the 1562 peer, it simply restarts the HIP base exchange. After the base 1563 exchange has completed, the Initiator can create a new payload 1564 association and start sending data. The peer does not reset its 1565 state until it receives a valid I2 packet. 1567 If a system receives a user data packet that cannot be matched to any 1568 existing HIP association, it is possible that it has lost the state 1569 and its peer has not. It MAY send an ICMP packet with the Parameter 1570 Problem type, and with the pointer pointing to the referred HIP- 1571 related association information. Reacting to such traffic depends on 1572 the implementation and the environment where the implementation is 1573 used. 1575 If the host, that apparently has lost its state, decides to restart 1576 the HIP base exchange, it sends an I1 packet to the peer. After the 1577 base exchange has been completed successfully, the Initiator can 1578 create a new HIP association and the peer drops its old payload 1579 associations and creates a new one. 1581 4.6. Certificate Distribution 1583 This document does not define how to use certificates or how to 1584 transfer them between hosts. These functions are expected to be 1585 defined in a future specification. A parameter type value, meant to 1586 be used for carrying certificates, is reserved, though: CERT, Type 1587 768; see Section 5.2. 1589 5. Packet Formats 1591 5.1. Payload Format 1593 All HIP packets start with a fixed header. 1595 0 1 2 3 1596 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 1597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1598 | Next Header | Header Length |0| Packet Type | VER. | RES.|1| 1599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1600 | Checksum | Controls | 1601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1602 | Sender's Host Identity Tag (HIT) | 1603 | | 1604 | | 1605 | | 1606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1607 | Receiver's Host Identity Tag (HIT) | 1608 | | 1609 | | 1610 | | 1611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1612 | | 1613 / HIP Parameters / 1614 / / 1615 | | 1616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1618 The HIP header is logically an IPv6 extension header. However, this 1619 document does not describe processing for Next Header values other 1620 than decimal 59, IPPROTO_NONE, the IPv6 'no next header' value. 1621 Future documents MAY do so. However, current implementations MUST 1622 ignore trailing data if an unimplemented Next Header value is 1623 received. 1625 The Header Length field contains the length of the HIP Header and HIP 1626 parameters in 8-byte units, excluding the first 8 bytes. Since all 1627 HIP headers MUST contain the sender's and receiver's HIT fields, the 1628 minimum value for this field is 4, and conversely, the maximum length 1629 of the HIP Parameters field is (255*8)-32 = 2008 bytes. Note: this 1630 sets an additional limit for sizes of parameters included in the 1631 Parameters field, independent of the individual parameter maximum 1632 lengths. 1634 The Packet Type indicates the HIP packet type. The individual packet 1635 types are defined in the relevant sections. If a HIP host receives a 1636 HIP packet that contains an unrecognized packet type, it MUST drop 1637 the packet. 1639 The HIP Version is four bits. The current version is 2. The version 1640 number is expected to be incremented only if there are incompatible 1641 changes to the protocol. Most extensions can be handled by defining 1642 new packet types, new parameter types, or new controls. 1644 The following three bits are reserved for future use. They MUST be 1645 zero when sent, and they SHOULD be ignored when handling a received 1646 packet. 1648 The two fixed bits in the header are reserved for potential SHIM6 1649 compatibility [RFC5533]. For implementations adhering (only) to this 1650 specification, they MUST be set as shown when sending and MUST be 1651 ignored when receiving. This is to ensure optimal forward 1652 compatibility. Note that for implementations that implement other 1653 compatible specifications in addition to this specification, the 1654 corresponding rules may well be different. For example, in the case 1655 that the forthcoming SHIM6 protocol happens to be compatible with 1656 this specification, an implementation that implements both this 1657 specification and the SHIM6 protocol may need to check these bits in 1658 order to determine how to handle the packet. 1660 The HIT fields are always 128 bits (16 bytes) long. 1662 5.1.1. Checksum 1664 Since the checksum covers the source and destination addresses in the 1665 IP header, it MUST be recomputed on HIP-aware NAT devices. 1667 If IPv6 is used to carry the HIP packet, the pseudo-header [RFC2460] 1668 contains the source and destination IPv6 addresses, HIP packet length 1669 in the pseudo-header length field, a zero field, and the HIP protocol 1670 number (see Section 4) in the Next Header field. The length field is 1671 in bytes and can be calculated from the HIP header length field: (HIP 1672 Header Length + 1) * 8. 1674 In case of using IPv4, the IPv4 UDP pseudo-header format [RFC0768] is 1675 used. In the pseudo-header, the source and destination addresses are 1676 those used in the IP header, the zero field is obviously zero, the 1677 protocol is the HIP protocol number (see Section 4), and the length 1678 is calculated as in the IPv6 case. 1680 5.1.2. HIP Controls 1682 The HIP Controls section conveys information about the structure of 1683 the packet and capabilities of the host. 1685 The following fields have been defined: 1687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1688 | | | | | | | | | | | | | | | |A| 1689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1691 A - Anonymous: If this is set, the sender's HI in this packet is 1692 anonymous, i.e., one not listed in a directory. Anonymous HIs 1693 SHOULD NOT be stored. This control is set in packets R1 and/or 1694 I2. The peer receiving an anonymous HI may choose to refuse it. 1696 The rest of the fields are reserved for future use and MUST be set to 1697 zero in sent packets and ignored in received packets. 1699 5.1.3. HIP Fragmentation Support 1701 A HIP implementation must support IP fragmentation/reassembly. 1702 Fragment reassembly MUST be implemented in both IPv4 and IPv6, but 1703 fragment generation is REQUIRED to be implemented in IPv4 (IPv4 1704 stacks and networks will usually do this by default) and RECOMMENDED 1705 to be implemented in IPv6. In IPv6 networks, the minimum MTU is 1706 larger, 1280 bytes, than in IPv4 networks. The larger MTU size is 1707 usually sufficient for most HIP packets, and therefore fragment 1708 generation may not be needed. If a host expects to send HIP packets 1709 that are larger than the minimum IPv6 MTU, it MUST implement fragment 1710 generation even for IPv6. 1712 In IPv4 networks, HIP packets may encounter low MTUs along their 1713 routed path. Since HIP does not provide a mechanism to use multiple 1714 IP datagrams for a single HIP packet, support for path MTU discovery 1715 does not bring any value to HIP in IPv4 networks. HIP-aware NAT 1716 devices MUST perform any IPv4 reassembly/fragmentation. 1718 All HIP implementations have to be careful while employing a 1719 reassembly algorithm so that the algorithm is sufficiently resistant 1720 to DoS attacks. 1722 Because certificate chains can cause the packet to be fragmented and 1723 fragmentation can open implementation to denial-of-service attacks 1724 [KAU03], it is strongly recommended that the separate document 1725 specifying the certificate usage in the HIP Base Exchange defines the 1726 usage of "Hash and URL" formats rather than including certificates in 1727 exchanges. With this, most problems related to DoS attacks with 1728 fragmentation can be avoided. 1730 5.2. HIP Parameters 1732 The HIP Parameters are used to carry the public key associated with 1733 the sender's HIT, together with related security and other 1734 information. They consist of parameters, ordered according to their 1735 numeric type number and encoded in TLV format. 1737 The following parameter types are currently defined. 1739 +------------------------+-------+----------+-----------------------+ 1740 | TLV | Type | Length | Data | 1741 +------------------------+-------+----------+-----------------------+ 1742 | R1_COUNTER | 128 | 12 | System Boot Counter | 1743 | | | | | 1744 | PUZZLE | 257 | 12 | K and Random #I | 1745 | | | | | 1746 | SOLUTION | 321 | 20 | K, Random #I and | 1747 | | | | puzzle solution J | 1748 | | | | | 1749 | SEQ | 385 | 4 | Update packet ID | 1750 | | | | number | 1751 | | | | | 1752 | ACK | 449 | variable | Update packet ID | 1753 | | | | number | 1754 | | | | | 1755 | DIFFIE_HELLMAN | 513 | variable | public key | 1756 | | | | | 1757 | HIP_CIPHER | 579 | variable | HIP encryption | 1758 | | | | algorithm | 1759 | | | | | 1760 | ENCRYPTED | 641 | variable | Encrypted part of I2 | 1761 | | | | packet | 1762 | | | | | 1763 | HOST_ID | 705 | variable | Host Identity with | 1764 | | | | Fully-Qualified | 1765 | | | | Domain FQDN (Name) or | 1766 | | | | Network Access | 1767 | | | | Identifier (NAI) | 1768 | | | | | 1769 | HIT_SUITE_LIST | 715 | variable | Ordered list of the | 1770 | | | | HIT suites supported | 1771 | | | | by the Responder | 1772 | | | | | 1773 | CERT | 768 | variable | HI Certificate; used | 1774 | | | | to transfer | 1775 | | | | certificates. Usage | 1776 | | | | is currently not | 1777 | | | | defined, but it will | 1778 | | | | be specified in a | 1779 | | | | separate document | 1780 | | | | once needed. | 1781 | | | | | 1782 | NOTIFICATION | 832 | variable | Informational data | 1783 | | | | | 1784 | ECHO_REQUEST_SIGNED | 897 | variable | Opaque data to be | 1785 | | | | echoed back; under | 1786 | | | | signature | 1787 | ECHO_RESPONSE_SIGNED | 961 | variable | Opaque data echoed | 1788 | | | | back; under signature | 1789 | | | | | 1790 | DH_GROUP_LIST | 2151 | variable | Ordered list of DH | 1791 | | | | Group IDs supported | 1792 | | | | by a host | 1793 | | | | | 1794 | HIP_MAC | 61505 | variable | HMAC-based message | 1795 | | | | authentication code, | 1796 | | | | with key material | 1797 | | | | from KEYMAT | 1798 | | | | | 1799 | HIP_MAC_2 | 61569 | variable | HMAC based message | 1800 | | | | authentication code, | 1801 | | | | with key material | 1802 | | | | from KEYMAT. | 1803 | | | | Compared to HIP_MAC, | 1804 | | | | the HOST_ID parameter | 1805 | | | | is included in | 1806 | | | | HIP_MAC_2 | 1807 | | | | calculation. | 1808 | | | | | 1809 | HIP_SIGNATURE_2 | 61633 | variable | Signature of the R1 | 1810 | | | | packet | 1811 | | | | | 1812 | HIP_SIGNATURE | 61697 | variable | Signature of the | 1813 | | | | packet | 1814 | | | | | 1815 | ECHO_REQUEST_UNSIGNED | 63661 | variable | Opaque data to be | 1816 | | | | echoed back; after | 1817 | | | | signature | 1818 | | | | | 1819 | ECHO_RESPONSE_UNSIGNED | 63425 | variable | Opaque data echoed | 1820 | | | | back; after signature | 1821 +------------------------+-------+----------+-----------------------+ 1823 As the ordering (from lowest to highest) of HIP parameters is 1824 strictly enforced (see Section 5.2.1), the parameter type values for 1825 existing parameters have been spaced to allow for future protocol 1826 extensions. 1828 The following parameter type number ranges are defined. 1830 +---------------+---------------------------------------------------+ 1831 | Type Range | Purpose | 1832 +---------------+---------------------------------------------------+ 1833 | 0 - 1023 | Handshake | 1834 | | | 1835 | 1024 - 2047 | Reserved | 1836 | | | 1837 | 2048 - 4095 | Parameters related to HIP transport types | 1838 | | | 1839 | 4096 - 8191 | Signed parameters allocated through specification | 1840 | | documents | 1841 | | | 1842 | 8192 - 32767 | Reserved | 1843 | | | 1844 | 32768 - 49151 | Free for experimentation. Signed parameters. | 1845 | | | 1846 | 41952 - 61439 | Reserved | 1847 | | | 1848 | 61440 - 62463 | Signatures and (signed) MACs | 1849 | | | 1850 | 62464 - 63487 | Parameters that are neither signed nor MACed | 1851 | | | 1852 | 63488 - 64511 | Rendezvous and relaying | 1853 | | | 1854 | 64512 - 65023 | Parameters that are neither signed nor MACed | 1855 | | | 1856 | 65024 - 65535 | Reserved | 1857 +---------------+---------------------------------------------------+ 1859 The process for defining new parameters is described in Section 5.2.2 1860 of this document. 1862 The range between 32768 (2^15) and 49151 (2^15 + 2^14) are free for 1863 experimentation. Types from this range SHOULD be selected in a 1864 random fashion to reduce the probability of collisions. 1866 5.2.1. TLV Format 1868 The TLV-encoded parameters are described in the following 1869 subsections. The type-field value also describes the order of these 1870 fields in the packet, except for type values from 2048 to 4095 which 1871 are reserved for new transport forms. The parameters MUST be 1872 included in the packet such that their types form an increasing 1873 order. If the parameter can exist multiple times in the packet, the 1874 type value may be the same in consecutive parameters. If the order 1875 does not follow this rule, the packet is considered to be malformed 1876 and it MUST be discarded. 1878 Parameters using type values from 2048 up to 4095 are transport 1879 formats. Currently, one transport format is defined: the ESP 1880 transport format [I-D.ietf-hip-rfc5202-bis]. The order of these 1881 parameters does not follow the order of their type value, but they 1882 are put in the packet in order of preference. The first of the 1883 transport formats it the most preferred, and so on. 1885 All of the TLV parameters have a length (including Type and Length 1886 fields), which is a multiple of 8 bytes. When needed, padding MUST 1887 be added to the end of the parameter so that the total length is a 1888 multiple of 8 bytes. This rule ensures proper alignment of data. 1889 Any added padding bytes MUST be zeroed by the sender, and their 1890 values SHOULD NOT be checked by the receiver. 1892 Consequently, the Length field indicates the length of the Contents 1893 field (in bytes). The total length of the TLV parameter (including 1894 Type, Length, Contents, and Padding) is related to the Length field 1895 according to the following formula: 1897 Total Length = 11 + Length - (Length + 3) % 8; 1899 where % is the modulo operator 1901 0 1 2 3 1902 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 1903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1904 | Type |C| Length | 1905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1906 | | 1907 / Contents / 1908 / +-+-+-+-+-+-+-+-+ 1909 | | Padding | 1910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1912 Type Type code for the parameter. 16 bits long, C-bit 1913 being part of the Type code. 1914 C Critical. One if this parameter is critical, and 1915 MUST be recognized by the recipient, zero otherwise. 1916 The C bit is considered to be a part of the Type 1917 field. Consequently, critical parameters are always 1918 odd and non-critical ones have an even value. 1919 Length Length of the Contents, in bytes excluding Type, 1920 Length, and Padding. 1921 Contents Parameter specific, defined by Type 1922 Padding Padding, 0-7 bytes, added if needed 1924 Critical parameters (indicated by the odd type number) MUST be 1925 recognized by the recipient. If a recipient encounters a critical 1926 parameter that it does not recognize, it MUST NOT process the packet 1927 any further. It MAY send an ICMP or NOTIFY, as defined in 1928 Section 4.3. 1930 Non-critical parameters MAY be safely ignored. If a recipient 1931 encounters a non-critical parameter that it does not recognize, it 1932 SHOULD proceed as if the parameter was not present in the received 1933 packet. 1935 5.2.2. Defining New Parameters 1937 Future specifications may define new parameters as needed. When 1938 defining new parameters, care must be taken to ensure that the 1939 parameter type values are appropriate and leave suitable space for 1940 other future extensions. One must remember that the parameters MUST 1941 always be arranged in numerically increasing order by Type code, 1942 thereby limiting the order of parameters (see Section 5.2.1). 1944 The following rules must be followed when defining new parameters. 1946 1. The low-order bit C of the Type code is used to distinguish 1947 between critical and non-critical parameters. Hence, even 1948 parameter type numbers indicate non-critical parameters while odd 1949 parameter type numbers indicate critical parameters. 1951 2. A new parameter may be critical only if an old implementation 1952 that ignored it would cause security problems. In general, new 1953 parameters SHOULD be defined as non-critical, and expect a reply 1954 from the recipient. 1956 3. If a system implements a new critical parameter, it MUST provide 1957 the ability to set the associated feature off, such that the 1958 critical parameter is not sent at all. The configuration option 1959 MUST be well documented. Implementations operating in a mode 1960 adhering to this specification MUST disable the sending of new 1961 critical parameters. In other words, the management interface 1962 MUST allow vanilla standards-only mode as a default configuration 1963 setting, and MAY allow new critical payloads to be configured on 1964 (and off). 1966 4. See Section 10 for allocation rules regarding Type codes. 1968 5.2.3. R1_COUNTER 1970 0 1 2 3 1971 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 1972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1973 | Type | Length | 1974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1975 | Reserved, 4 bytes | 1976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1977 | R1 generation counter, 8 bytes | 1978 | | 1979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1981 Type 128 1982 Length 12 1983 R1 generation 1984 counter The current generation of valid puzzles 1986 The R1_COUNTER parameter contains a 64-bit unsigned integer in 1987 network-byte order, indicating the current generation of valid 1988 puzzles. The sender is supposed to increment this counter 1989 periodically. It is RECOMMENDED that the counter value is 1990 incremented at least as often as old PUZZLE values are deprecated so 1991 that SOLUTIONs to them are no longer accepted. 1993 The R1_COUNTER parameter is optional. It SHOULD be included in the 1994 R1 (in which case, it is covered by the signature), and if present in 1995 the R1, it MAY be echoed (including the Reserved field verbatim) by 1996 the Initiator in the I2 packet. 1998 5.2.4. PUZZLE 2000 0 1 2 3 2001 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 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2003 | Type | Length | 2004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2005 | K, 1 byte | Lifetime | Opaque, 2 bytes | 2006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2007 | Random #I, n bytes | 2008 / / 2009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2011 Type 257 2012 Length 4+RHASH_len/8 2013 K K is the number of verified bits 2014 Lifetime puzzle lifetime 2^(value-32) seconds 2015 Opaque data set by the Responder, indexing the puzzle 2016 Random #I random number of size RHASH_len bits 2018 Random #I is represented as a n-bit integer (where n is RHASH_len), K 2019 and Lifetime as 8-bit integers, all in network byte order. 2021 The PUZZLE parameter contains the puzzle difficulty K and a n-bit 2022 random integer #I. The Puzzle Lifetime indicates the time during 2023 which the puzzle solution is valid, and sets a time limit that should 2024 not be exceeded by the Initiator while it attempts to solve the 2025 puzzle. The lifetime is indicated as a power of 2 using the formula 2026 2^(Lifetime-32) seconds. A puzzle MAY be augmented with an 2027 ECHO_REQUEST_SIGNED or an ECHO_REQUEST_UNSIGNED parameter included in 2028 the R1; the contents of the echo request are then echoed back in the 2029 ECHO_RESPONSE_SIGNED or in the ECHO_RESPONSE_UNSIGNED, allowing the 2030 Responder to use the included information as a part of its puzzle 2031 processing. 2033 The Opaque and Random #I field are not covered by the HIP_SIGNATURE_2 2034 parameter. 2036 5.2.5. SOLUTION 2038 0 1 2 3 2039 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 2040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2041 | Type | Length | 2042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2043 | K, 1 byte | Reserved | Opaque, 2 bytes | 2044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2045 | Random #I, n bytes | 2046 / / 2047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2048 | Puzzle solution #J, n bytes | 2049 / / 2050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2052 Type 321 2053 Length 4 + RHASH_len/4 2054 K K is the number of verified bits 2055 Reserved zero when sent, ignored when received 2056 Opaque copied unmodified from the received PUZZLE 2057 parameter 2058 Random #I random number of size RHASH_len bits 2059 Puzzle solution #J random number of size RHASH_len bits 2061 Random #I and Random #J are represented as n-bit integers (where n is 2062 RHASH_len), K as an 8-bit integer, all in network byte order. 2064 The SOLUTION parameter contains a solution to a puzzle. It also 2065 echoes back the random difficulty K, the Opaque field, and the puzzle 2066 integer #I. 2068 5.2.6. DIFFIE_HELLMAN 2070 0 1 2 3 2071 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 2072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2073 | Type | Length | 2074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2075 | Group ID | Public Value Length | Public Value / 2076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2077 / | 2078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2079 / | Padding | 2080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2082 Type 513 2083 Length length in octets, excluding Type, Length, and 2084 Padding 2085 Group ID defines values for p and g 2086 Public Value length of the following Public Value in octets 2087 Length 2088 Public Value the sender's public Diffie-Hellman key 2090 The following Group IDs have been defined: 2092 Group Value 2093 Reserved 0 2094 DEPRECATED 1 2095 DEPRECATED 2 2096 1536-bit MODP group 3 [RFC3526] 2097 3072-bit MODP group 4 [RFC3526] 2098 DEPRECATED 5 2099 DEPRECATED 6 2100 NIST P-256 7 [RFC4753] 2101 NIST P-384 8 [RFC4753] 2102 NIST P-521 9 [RFC4753] 2103 SECP160R1 10 [SECG] 2105 The MODP Diffie-Hellman groups are defined in [RFC3526]. The ECDH 2106 groups 8 - 10 are defined in [RFC4753] and 2107 [I-D.mcgrew-fundamental-ecc]. ECDH group 7 is covered in Appendix D. 2109 A HIP implementation MUST implement Group ID 3. The 160-bit ECP 2110 group can be used when lower security is enough (e.g., web surfing) 2111 and when the equipment is not powerful enough (e.g., some PDAs). 2112 Implementations SHOULD implement Group IDs 4 and 8. 2114 To avoid unnecessary failures during the base exchange, the rest of 2115 the groups SHOULD be implemented in hosts where resources are 2116 adequate. 2118 5.2.7. HIP_CIPHER 2120 0 1 2 3 2121 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 2122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2123 | Type | Length | 2124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2125 | Cipher ID #1 | Cipher ID #2 | 2126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2127 | Cipher ID #n | Padding | 2128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2130 Type 579 2131 Length length in octets, excluding Type, Length, and 2132 Padding 2133 Cipher ID defines the cipher algorithm to be used for 2134 encrypting parts of the HIP packet 2136 The following Cipher IDs are defined: 2138 Suite ID Value 2140 RESERVED 0 2141 NULL-ENCRYPT 1 ([RFC2410]) 2142 AES-128-CBC 2 ([RFC3602]) 2143 3DES-CBC 3 ([RFC2451]) 2144 AES-256-CBC 4 ([RFC3602]) 2146 The sender of a HIP_CIPHER parameter MUST make sure that there are no 2147 more than six (6) Cipher IDs in one HIP_CIPHER parameter. 2148 Conversely, a recipient MUST be prepared to handle received transport 2149 parameters that contain more than six Cipher IDs by accepting the 2150 first six Cipher IDs and dropping the rest. The limited number of 2151 transforms sets the maximum size of the HIP_CIPHER parameter. As the 2152 default configuration, the HIP_CIPHER parameter MUST contain at least 2153 one of the mandatory Cipher IDs. There MAY be a configuration option 2154 that allows the administrator to override this default. 2156 The Responder lists supported and desired Cipher IDs in order of 2157 preference in the R1, up to the maximum of six Cipher IDs. The 2158 Initiator MUST choose only one of the corresponding Cipher IDs. This 2159 Cipher ID will be used for generating the ENCRYPTED parameter. 2161 Mandatory implementation: AES-128-CBC. NULL-ENCRYPTION is included 2162 for testing purposes. NULL-ENCRYPTION SHOULD NOT be configurable via 2163 the UI. 2165 5.2.8. HOST_ID 2167 0 1 2 3 2168 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 2169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2170 | Type | Length | 2171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2172 | HI Length |DI-type| DI Length | 2173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2174 | Algorithm | Host Identity / 2175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2176 / | Domain Identifier / 2177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2178 / | Padding | 2179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2181 Type 705 2182 Length length in octets, excluding Type, Length, and 2183 Padding 2184 HI Length length of the Host Identity in octets 2185 DI-type type of the following Domain Identifier field 2186 Algorithm index to the employed algorithm 2187 DI Length length of the FQDN or NAI in octets 2188 Host Identity actual Host Identity 2189 Domain Identifier the identifier of the sender 2191 The Host Identity is derived from the DNSKEY format for RSA and DSA. 2192 For these, the Public Key field of the RDATA part from RFC 4034 2193 [RFC4034] is used. For ECC we distinguish two different profiles: 2194 ECDSA and ECDSA_LOW. ECC contains curves approved by NIST and 2195 defined in RFC 4754 [RFC4754]. ECDSA_LOW is defined for devices with 2196 low computational capabilities and uses shorter curves from SECG 2197 [SECG]. 2199 Algorithm 2200 profiles Values 2202 RESERVED 0 2203 DSA 3 [RFC2536] (RECOMMENDED) 2204 RSA 5 [RFC3110] (REQUIRED) 2205 ECDSA 7 [RFC4754] (RECOMMENDED) 2206 ECDSA_LOW 9 [SECG] (RECOMMENDED) 2208 For ECDSA and ECDSA_LOW Host Identities is represented by the 2209 following fields: 2211 0 1 2 3 2212 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 2213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2214 | ECC Curve | / 2215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2216 / Public Key | 2217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2219 ECC Curve Curve label 2220 Public Key Represented in Octet-string format 2221 [I-D.mcgrew-fundamental-ecc] 2223 For hosts that implement ECDSA as algorithm the following ECC curves 2224 are required: 2226 Algorithm Curve Values 2228 ECDSA RESERVED 0 2230 ECDSA NIST P-256 1 [RFC4754] 2231 ECDSA NIST P-384 2 [RFC4754] 2233 For hosts that implement the EDSA_LOW algorithm profile, the 2234 following curve is required: 2236 Algorithm Curve Values 2238 ECDSA_LOW RESERVED 0 2240 ECDSA_LOW SECP160R1 1 [SECG] 2242 The following DI-types have been defined: 2244 Type Value 2245 none included 0 2246 FQDN 1 2247 NAI 2 2249 FQDN Fully Qualified Domain Name, in binary format. 2250 NAI Network Access Identifier 2252 The format for the FQDN is defined in RFC 1035 [RFC1035] Section 3.1. 2253 The format for the NAI is defined in [RFC4282] 2255 If there is no Domain Identifier, i.e., the DI-type field is zero, 2256 the DI Length field is set to zero as well. 2258 5.2.9. HIT_SUITE_LIST 2260 0 1 2 3 2261 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 2262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2263 | Type | Length | 2264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2265 | ID #1 | ID #2 | ID #3 | ID #4 | 2266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2267 | ID #n | Padding | 2268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2270 Type 715 2271 Length number of HIT Suite IDs 2272 ID defines a HIT Suite ID supported by the host. 2273 The list of IDs is ordered by preference of the 2274 host. Each HIT Suite ID is one octet long. The four 2275 higher-order bits of the ID field correspond to the 2276 HIT Suite ID in the ORCHID OGA field. The four 2277 lower-order bits are reserved and set to 0. The four 2278 lower-order bits are ignored. 2280 The HIT Suite ID indexes a HIT Suite. HIT Suites are composed of 2281 signature algorithms as defined in Section Section 5.2.8 and hash 2282 functions. 2284 The ID field in the HIT_SUITE_LIST is defined as eight-bit field as 2285 opposed to the four-bit HIT Suite ID and OGA field in the ORCHID. 2286 This difference is a measure to accommodate larger HIT Suite IDs if 2287 the 16 available values prove insufficient. In that case, one of the 2288 16 values, zero, will be used to indicate that four additional bits 2289 of the ORCHID will be used to encode the HIT Suite ID. Hence, the 2290 current four-bit HIT Suite-IDs only use the four higher order bits in 2291 the ID field. Future documents may define the use of the four lower- 2292 order bits in the ID field. 2294 The following HIT Suites ID are defined: 2296 HIT Suite ID 2297 RESERVED 0 2298 RSA,DSA/SHA-1 1 (REQUIRED) 2299 ECDSA/SHA-384 2 (RECOMMENDED) 2300 ECDSA_LOW/SHA-1 3 (RECOMMENDED) 2302 The HIT_SUITE_LIST parameter contains a list of the supported HIT 2303 suite IDs of the Responder. The Responder sends the HIT_SUITE_LIST 2304 in the signed part of the R1 packet. Based on the HIT_SUITE_LIST, 2305 the Initiator can determine which source HITs are supported by the 2306 Responder. 2308 5.2.10. DH_GROUP_LIST 2310 0 1 2 3 2311 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 2312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2313 | Type | Length | 2314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2315 | DH GROUP ID #1| DH GROUP ID #2| DH GROUP ID #3| DH GROUP ID #4| 2316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2317 | DH GROUP ID #n| Padding | 2318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2320 Type 2151 2321 Length number of DH Group IDs 2322 DH GROUP ID defines a DH GROUP ID supported by the host. 2323 The list of IDs is ordered by preference of the 2324 host. The list of define DH Group IDs in the 2325 DIFFIE_HELLMAN parameter. Each DH Group ID is one 2326 octet long. 2328 The DH_GROUP_LIST parameter contains the list of supported DH Group 2329 IDs of a host. The Initiator sends the DH_GROUP_LIST in the I1 2330 packet, the Responder sends it in the signed part of the R1 packet. 2331 The DH Group IDs in the DH_GROUP_LIST are listed in the order of 2332 their preference of the host. DH Group IDs that are listed first are 2333 preferred over the DH Group IDs listed later. The information in the 2334 DH_GROUP_LIST allows the Responder to select the DH group preferred 2335 by itself and the Initiator. Based on the DH_GROUP_LIST in the R1 2336 packet, the Initiator can determine if the Responder has selected the 2337 best possible choice based on the Initiator's and Responder's 2338 preferences. If the Responder's choice differs from the best choice, 2339 the Initiator can conclude that there was an attempted downgrade 2340 attack (see Section 4.1.7). 2342 When selecting the DH group for the DIFFIE_HELLMAN parameter in the 2343 R1 packet, the Responder MUST select the first DH Group ID in its 2344 DH_GROUP_LIST in the R1 packet that is contained in the Initiator's 2345 DH_GROUP_LIST in the I1 packet. The Responder MUST not select any 2346 other DH Group ID that is contained in both lists because a downgrade 2347 attack cannot be detected then. 2349 5.2.11. HIP_MAC 2351 0 1 2 3 2352 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 2353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2354 | Type | Length | 2355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2356 | | 2357 | HMAC | 2358 / / 2359 / +-------------------------------+ 2360 | | Padding | 2361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2363 Type 61505 2364 Length length in octets, excluding Type, Length, and 2365 Padding 2366 HMAC HMAC computed over the HIP packet, excluding the 2367 HIP_MAC parameter and any following parameters, such 2368 as HIP_SIGNATURE, HIP_SIGNATURE_2, 2369 ECHO_REQUEST_UNSIGNED, or ECHO_RESPONSE_UNSIGNED. 2370 The checksum field MUST be set to zero and the HIP 2371 header length in the HIP common header MUST be 2372 calculated not to cover any excluded parameters 2373 when the HMAC is calculated. The size of the 2374 HMAC is the natural size of the hash computation 2375 output depending on the used hash function. 2377 The HMAC uses RHASH as hash algorithm. The calculation and 2378 verification process is presented in Section 6.4.1. 2380 5.2.12. HIP_MAC_2 2382 The HIP_MAC_2 is a MAC of the packet and the HOST_ID parameter of the 2383 sender while only the packet without HOST_ID is sent. The parameter 2384 structure is the same as in Section 5.2.11. The fields are: 2386 Type 61569 2387 Length length in octets, excluding Type, Length, and 2388 Padding 2389 HMAC HMAC computed over the HIP packet, excluding the 2390 HIP_MAC_2 parameter and any following parameters 2391 such as HIP_SIGNATURE, HIP_SIGNATURE_2, 2392 ECHO_REQUEST_UNSIGNED, or ECHO_RESPONSE_UNSIGNED, 2393 and including an additional sender's HOST_ID 2394 parameter during the HMAC calculation. The checksum 2395 field MUST be set to zero and the HIP header length 2396 in the HIP common header MUST be calculated not to 2397 cover any excluded parameters when the HMAC is 2398 calculated. The size of the HMAC is the natural 2399 size of the hash computation output depending on the 2400 used hash function. 2402 The HMAC uses RHASH as hash algorithm. The calculation and 2403 verification process is presented in Section 6.4.1. 2405 5.2.13. HIP_SIGNATURE 2407 0 1 2 3 2408 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 2409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2410 | Type | Length | 2411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2412 | SIG alg | Signature / 2413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2414 / | Padding | 2415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2417 Type 61697 2418 Length length in octets, excluding Type, Length, and 2419 Padding 2420 SIG alg signature algorithm 2421 Signature the signature is calculated over the HIP packet, 2422 excluding the HIP_SIGNATURE parameter and any 2423 parameters that follow the HIP_SIGNATURE parameter. 2424 When the signature is calculated the checksum field 2425 MUST be set to zero, and the HIP header length in 2426 the HIP common header MUST be calculated only up to 2427 the beginning of the HIP_SIGNATURE parameter. 2429 The signature algorithms are defined in Section 5.2.8. The signature 2430 in the Signature field is encoded using the method depending on the 2431 signature algorithm (e.g., according to [RFC3110] in case of RSA/ 2432 SHA-1, according to [RFC5702] in case of RSA/SHA-256, according to 2433 [RFC2536] in case of DSA, or according to 2435 [I-D.mcgrew-fundamental-ecc] in case of ECDSA). 2437 The HIP_SIGNATURE calculation and verification process are presented 2438 in Section 6.4.2. 2440 5.2.14. HIP_SIGNATURE_2 2442 The HIP_SIGNATURE_2 excludes the variable parameters in the R1 packet 2443 to allow R1 pre-creation. The parameter structure is the same as in 2444 Section 5.2.13. The fields are: 2446 Type 61633 2447 Length length in octets, excluding Type, Length, and 2448 Padding 2449 SIG alg signature algorithm 2450 Signature Within the R1 packet that contains the 2451 HIP_SIGNATURE_2 parameter, the Initiator's HIT, the 2452 checksum field, and the Opaque and Random #I fields 2453 in the PUZZLE parameter MUST be set to zero while 2454 computing the HIP_SIGNATURE_2 signature. Further, 2455 the HIP packet length in the HIP header MUST be 2456 adjusted as if the HIP_SIGNATURE_2 was not in the 2457 packet during the signature calculation, i.e., the 2458 HIP packet length points to the beginning of 2459 the HIP_SIGNATURE_2 parameter during signing and 2460 verification. 2462 Zeroing the Initiator's HIT makes it possible to create R1 packets 2463 beforehand, to minimize the effects of possible DoS attacks. Zeroing 2464 the Random #I and Opaque fields within the PUZZLE parameter allows 2465 these fields to be populated dynamically on precomputed R1s. 2467 Signature calculation and verification follows the process defined in 2468 Section 6.4.2. 2470 5.2.15. SEQ 2472 0 1 2 3 2473 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 2474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2475 | Type | Length | 2476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2477 | Update ID 1 | 2478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2479 / Update ID n / 2480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2481 Type 385 2482 Length length in octets, excluding Type, Length, and 2483 Padding 2484 Update ID 32-bit sequence number 2486 The Update ID is an unsigned quantity, initialized by a host to zero 2487 upon moving to ESTABLISHED state. The Update ID has scope within a 2488 single HIP association, and not across multiple associations or 2489 multiple hosts. The Update ID is incremented by one before each new 2490 UPDATE that is sent by the host; the first UPDATE packet originated 2491 by a host has an Update ID of 0. 2493 5.2.16. ACK 2495 0 1 2 3 2496 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 2497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2498 | Type | Length | 2499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2500 | peer Update ID | 2501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2503 Type 449 2504 Length variable (multiple of 4) 2505 peer Update ID 32-bit sequence number corresponding to the 2506 Update ID being ACKed. 2508 The ACK parameter includes one or more Update IDs that have been 2509 received from the peer. The Length field identifies the number of 2510 peer Update IDs that are present in the parameter. 2512 5.2.17. ENCRYPTED 2514 0 1 2 3 2515 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 2516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2517 | Type | Length | 2518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2519 | Reserved | 2520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2521 | IV / 2522 / / 2523 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 2525 / Encrypted data / 2526 / / 2527 / +-------------------------------+ 2528 / | Padding | 2529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2531 Type 641 2532 Length length in octets, excluding Type, Length, and 2533 Padding 2534 Reserved zero when sent, ignored when received 2535 IV Initialization vector, if needed, otherwise 2536 nonexistent. The length of the IV is inferred from 2537 the HIP_CIPHER. 2538 Encrypted The data is encrypted using an encryption algorithm 2539 data as defined in the HIP_CIPHER parameter. 2541 The ENCRYPTED parameter encapsulates another parameter, the encrypted 2542 data, which holds one or more HIP parameters in block encrypted form. 2544 Consequently, the first fields in the encapsulated parameter(s) are 2545 Type and Length of the first such parameter, allowing the contents to 2546 be easily parsed after decryption. 2548 The field labeled "Encrypted data" consists of the output of one or 2549 more HIP parameters concatenated together that have been passed 2550 through an encryption algorithm. Each of these inner parameters is 2551 padded according to the rules of Section 5.2.1 for padding individual 2552 parameters. As a result, the concatenated parameters will be a block 2553 of data that is 8-byte aligned. 2555 Some encryption algorithms require that the data to be encrypted must 2556 be a multiple of the cipher algorithm block size. In this case, the 2557 above block of data MUST include additional padding, as specified by 2558 the encryption algorithm. The size of the extra padding is selected 2559 so that the length of the unencrypted data block is a multiple of the 2560 cipher block size. The encryption algorithm may specify padding 2561 bytes other than zero; for example, AES [FIPS.197.2001] uses the 2562 PKCS5 padding scheme (see section 6.1.1 of [RFC2898]) where the 2563 remaining n bytes to fill the block each have the value of n. This 2564 yields an "unencrypted data" block that is transformed to an 2565 "encrypted data" block by the cipher suite. This extra padding added 2566 to the set of parameters to satisfy the cipher block alignment rules 2567 is not counted in HIP TLV length fields, and this extra padding 2568 should be removed by the cipher suite upon decryption. 2570 Note that the length of the cipher suite output may be smaller or 2571 larger than the length of the set of parameters to be encrypted, 2572 since the encryption process may compress the data or add additional 2573 padding to the data. 2575 Once this encryption process is completed, the Encrypted data field 2576 is ready for inclusion in the Parameter. If necessary, additional 2577 Padding for 8-byte alignment is then added according to the rules of 2578 Section 5.2.1. 2580 5.2.18. NOTIFICATION 2582 The NOTIFICATION parameter is used to transmit informational data, 2583 such as error conditions and state transitions, to a HIP peer. A 2584 NOTIFICATION parameter may appear in NOTIFY packets. The use of the 2585 NOTIFICATION parameter in other packet types is for further study. 2587 0 1 2 3 2588 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 2589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2590 | Type | Length | 2591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2592 | Reserved | Notify Message Type | 2593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2594 | / 2595 / Notification Data / 2596 / +---------------+ 2597 / | Padding | 2598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2600 Type 832 2601 Length length in octets, excluding Type, Length, and 2602 Padding 2603 Reserved zero when sent, ignored when received 2604 Notify Message specifies the type of notification 2605 Type 2606 Notification informational or error data transmitted in addition 2607 Data to the Notify Message Type. Values for this field 2608 are type specific (see below). 2609 Padding any Padding, if necessary, to make the parameter a 2610 multiple of 8 bytes. 2612 Notification information can be error messages specifying why an SA 2613 could not be established. It can also be status data that a process 2614 managing an SA database wishes to communicate with a peer process. 2615 The table below lists the Notification messages and their 2616 corresponding values. 2618 To avoid certain types of attacks, a Responder SHOULD avoid sending a 2619 NOTIFICATION to any host with which it has not successfully verified 2620 a puzzle solution. 2622 Types in the range 0-16383 are intended for reporting errors and in 2623 the range 16384-65535 for other status information. An 2624 implementation that receives a NOTIFY packet with a NOTIFICATION 2625 error parameter in response to a request packet (e.g., I1, I2, 2626 UPDATE) SHOULD assume that the corresponding request has failed 2627 entirely. Unrecognized error types MUST be ignored except that they 2628 SHOULD be logged. 2630 Notify payloads with status types MUST be ignored if not recognized. 2632 NOTIFICATION PARAMETER - ERROR TYPES Value 2633 ------------------------------------ ----- 2634 UNSUPPORTED_CRITICAL_PARAMETER_TYPE 1 2636 Sent if the parameter type has the "critical" bit set and the 2637 parameter type is not recognized. Notification Data contains the 2638 two-octet parameter type. 2640 INVALID_SYNTAX 7 2642 Indicates that the HIP message received was invalid because some 2643 type, length, or value was out of range or because the request 2644 was rejected for policy reasons. To avoid a denial- of-service 2645 attack using forged messages, this status may only be returned 2646 for packets whose HIP_MAC (if present) and SIGNATURE have been 2647 verified. This status MUST be sent in response to any error not 2648 covered by one of the other status types, and should not contain 2649 details to avoid leaking information to someone probing a node. 2650 To aid debugging, more detailed error information SHOULD be 2651 written to a console or log. 2653 NO_DH_PROPOSAL_CHOSEN 14 2655 None of the proposed group IDs was acceptable. 2657 INVALID_DH_CHOSEN 15 2659 The DH Group ID field does not correspond to one offered 2660 by the Responder. 2662 NO_HIP_PROPOSAL_CHOSEN 16 2664 None of the proposed HIT Suites or HIP Encryption Algorithms was 2665 acceptable. 2667 INVALID_HIP_CIPHER_CHOSEN 17 2669 The HIP_CIPHER Crypto ID does not correspond to one offered by 2670 the Responder. 2672 UNSUPPORTED_HIT_SUITE 20 2674 Sent in response to an I1 or R1 packet for which the HIT suite 2675 is not supported. 2677 AUTHENTICATION_FAILED 24 2679 Sent in response to a HIP signature failure, except when 2680 the signature verification fails in a NOTIFY message. 2682 CHECKSUM_FAILED 26 2684 Sent in response to a HIP checksum failure. 2686 HIP_MAC_FAILED 28 2688 Sent in response to a HIP HMAC failure. 2690 ENCRYPTION_FAILED 32 2692 The Responder could not successfully decrypt the 2693 ENCRYPTED parameter. 2695 INVALID_HIT 40 2697 Sent in response to a failure to validate the peer's 2698 HIT from the corresponding HI. 2700 BLOCKED_BY_POLICY 42 2702 The Responder is unwilling to set up an association 2703 for some policy reason (e.g., received HIT is NULL 2704 and policy does not allow opportunistic mode). 2706 RESPONDER_BUSY_PLEASE_RETRY 44 2708 The Responder is unwilling to set up an association as it is 2709 suffering under some kind of overload and has chosen to shed load 2710 by rejecting the Initiator's request. The Initiator may retry; 2711 however, the Initiator MUST find another (different) puzzle 2712 solution for any such retries. Note that the Initiator may need 2713 to obtain a new puzzle with a new I1/R1 exchange. 2715 NOTIFY MESSAGES - STATUS TYPES Value 2716 ------------------------------ ----- 2718 I2_ACKNOWLEDGEMENT 16384 2720 The Responder has an I2 packet from the Initiator but had to 2721 queue the I2 packet or processing. The puzzle was correctly 2722 solved and the Responder is willing to set up an association but 2723 currently has a number of I2 packets in the processing queue. R2 2724 are sent after the I2 packet has been processed. 2726 5.2.19. ECHO_REQUEST_SIGNED 2728 0 1 2 3 2729 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 2730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2731 | Type | Length | 2732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2733 | Opaque data (variable length) | 2734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2736 Type 897 2737 Length variable 2738 Opaque data opaque data, supposed to be meaningful only to the 2739 node that sends ECHO_REQUEST_SIGNED and receives a 2740 corresponding ECHO_RESPONSE_SIGNED or 2741 ECHO_RESPONSE_UNSIGNED. 2743 The ECHO_REQUEST_SIGNED parameter contains an opaque blob of data 2744 that the sender wants to get echoed back in the corresponding reply 2745 packet. 2747 The ECHO_REQUEST_SIGNED and corresponding echo response parameters 2748 MAY be used for any purpose where a node wants to carry some state in 2749 a request packet and get it back in a response packet. The 2750 ECHO_REQUEST_SIGNED is covered by the HIP_MAC and SIGNATURE. A HIP 2751 packet can contain only one ECHO_REQUEST_SIGNED or 2752 ECHO_REQUEST_UNSIGNED parameter. The ECHO_REQUEST_SIGNED parameter 2753 MUST be responded to with a corresponding echo response. 2754 ECHO_RESPONSE_SIGNED SHOULD be used, but if it is not possible, e.g., 2755 due to a middlebox-provided response, it MAY be responded to with an 2756 ECHO_RESPONSE_UNSIGNED. 2758 5.2.20. ECHO_REQUEST_UNSIGNED 2760 0 1 2 3 2761 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 2762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2763 | Type | Length | 2764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2765 | Opaque data (variable length) | 2766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2768 Type 63661 2769 Length variable 2770 Opaque data opaque data, supposed to be meaningful only to the 2771 node that sends ECHO_REQUEST_UNSIGNED and receives a 2772 corresponding ECHO_RESPONSE_UNSIGNED. 2774 The ECHO_REQUEST_UNSIGNED parameter contains an opaque blob of data 2775 that the sender wants to get echoed back in the corresponding reply 2776 packet. 2778 The ECHO_REQUEST_UNSIGNED and corresponding echo response parameters 2779 MAY be used for any purpose where a node wants to carry some state in 2780 a request packet and get it back in a response packet. The 2781 ECHO_REQUEST_UNSIGNED is not covered by the HIP_MAC and SIGNATURE. A 2782 HIP packet can contain one or more ECHO_REQUEST_UNSIGNED parameters. 2783 It is possible that middleboxes add ECHO_REQUEST_UNSIGNED parameters 2784 in HIP packets passing by. The sender has to create the Opaque field 2785 so that it can later identify and remove the corresponding 2786 ECHO_RESPONSE_UNSIGNED parameter. 2788 The ECHO_REQUEST_UNSIGNED parameter MUST be responded to with an 2789 ECHO_RESPONSE_UNSIGNED parameter. 2791 5.2.21. ECHO_RESPONSE_SIGNED 2793 0 1 2 3 2794 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 2795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2796 | Type | Length | 2797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2798 | Opaque data (variable length) | 2799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2801 Type 961 2802 Length variable 2803 Opaque data opaque data, copied unmodified from the 2804 ECHO_REQUEST_SIGNED or ECHO_REQUEST_UNSIGNED 2805 parameter that triggered this response. 2807 The ECHO_RESPONSE_SIGNED parameter contains an opaque blob of data 2808 that the sender of the ECHO_REQUEST_SIGNED wants to get echoed back. 2809 The opaque data is copied unmodified from the ECHO_REQUEST_SIGNED 2810 parameter. 2812 The ECHO_REQUEST_SIGNED and ECHO_RESPONSE_SIGNED parameters MAY be 2813 used for any purpose where a node wants to carry some state in a 2814 request packet and get it back in a response packet. The 2815 ECHO_RESPONSE_SIGNED is covered by the HIP_MAC and SIGNATURE. 2817 5.2.22. ECHO_RESPONSE_UNSIGNED 2819 0 1 2 3 2820 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 2821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2822 | Type | Length | 2823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2824 | Opaque data (variable length) | 2825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2827 Type 63425 2828 Length variable 2829 Opaque data opaque data, copied unmodified from the 2830 ECHO_REQUEST_SIGNED or ECHO_REQUEST_UNSIGNED 2831 parameter that triggered this response. 2833 The ECHO_RESPONSE_UNSIGNED parameter contains an opaque blob of data 2834 that the sender of the ECHO_REQUEST_SIGNED or ECHO_REQUEST_UNSIGNED 2835 wants to get echoed back. The opaque data is copied unmodified from 2836 the corresponding echo request parameter. 2838 The echo request and ECHO_RESPONSE_UNSIGNED parameters MAY be used 2839 for any purpose where a node wants to carry some state in a request 2840 packet and get it back in a response packet. The 2841 ECHO_RESPONSE_UNSIGNED is not covered by the HIP_MAC and SIGNATURE. 2843 5.3. HIP Packets 2845 There are eight basic HIP packets (see Table 10). Four are for the 2846 HIP base exchange, one is for updating, one is for sending 2847 notifications, and two are for closing a HIP association. 2849 +------------------+------------------------------------------------+ 2850 | Packet type | Packet name | 2851 +------------------+------------------------------------------------+ 2852 | 1 | I1 - the HIP Initiator Packet | 2853 | | | 2854 | 2 | R1 - the HIP Responder Packet | 2855 | | | 2856 | 3 | I2 - the Second HIP Initiator Packet | 2857 | | | 2858 | 4 | R2 - the Second HIP Responder Packet | 2859 | | | 2860 | 16 | UPDATE - the HIP Update Packet | 2861 | | | 2862 | 17 | NOTIFY - the HIP Notify Packet | 2863 | | | 2864 | 18 | CLOSE - the HIP Association Closing Packet | 2865 | | | 2866 | 19 | CLOSE_ACK - the HIP Closing Acknowledgment | 2867 | | Packet | 2868 +------------------+------------------------------------------------+ 2870 Table 10: HIP packets and packet type numbers 2872 Packets consist of the fixed header as described in Section 5.1, 2873 followed by the parameters. The parameter part, in turn, consists of 2874 zero or more TLV-coded parameters. 2876 In addition to the base packets, other packet types may be defined 2877 later in separate specifications. For example, support for mobility 2878 and multi-homing is not included in this specification. 2880 See Notation (Section 2.2) for used operations. 2882 In the future, an OPTIONAL upper-layer payload MAY follow the HIP 2883 header. The Next Header field in the header indicates if there is 2884 additional data following the HIP header. The HIP packet, however, 2885 MUST NOT be fragmented. This limits the size of the possible 2886 additional data in the packet. 2888 5.3.1. I1 - the HIP Initiator Packet 2890 The HIP header values for the I1 packet: 2892 Header: 2893 Packet Type = 1 2894 SRC HIT = Initiator's HIT 2895 DST HIT = Responder's HIT, or NULL 2897 IP ( HIP ( DH_GROUP_LIST ) ) 2899 The I1 packet contains the fixed HIP header and the Initiator's 2900 DH_GROUP_LIST. 2902 Valid control bits: none 2904 The Initiator receives the Responder's HIT either from a DNS lookup 2905 of the Responder's FQDN, from some other repository, or from a local 2906 table. If the Initiator does not know the Responder's HIT, it may 2907 attempt to use opportunistic mode by using NULL (all zeros) as the 2908 Responder's HIT. See also "HIP Opportunistic Mode" (Section 4.1.8). 2910 Since this packet is so easy to spoof even if it were signed, no 2911 attempt is made to add to its generation or processing cost. 2913 The Initiator includes a DH_GROUP_LIST parameter in the I1 packet to 2914 inform the Responder of its preferred DH Group IDs. Note that the 2915 DH_GROUP_LIST in the I1 packet is not protected by a signature. 2917 Implementations MUST be able to handle a storm of received I1 2918 packets, discarding those with common content that arrive within a 2919 small time delta. 2921 5.3.2. R1 - the HIP Responder Packet 2923 The HIP header values for the R1 packet: 2925 Header: 2926 Packet Type = 2 2927 SRC HIT = Responder's HIT 2928 DST HIT = Initiator's HIT 2930 IP ( HIP ( [ R1_COUNTER, ] 2931 PUZZLE, 2932 DIFFIE_HELLMAN, 2933 HIP_CIPHER, 2934 HOST_ID, 2935 HIT_SUITE_LIST, 2936 DH_GROUP_LIST, 2937 [ ECHO_REQUEST_SIGNED, ] 2938 HIP_SIGNATURE_2 ) 2939 <, ECHO_REQUEST_UNSIGNED >i) 2941 Valid control bits: A 2943 If the Responder's HI is an anonymous one, the A control MUST be set. 2945 The Initiator's HIT MUST match the one received in the I1 packet. If 2946 the Responder has multiple HIs, the Responder's HIT used MUST match 2947 Initiator's request. If the Initiator used opportunistic mode, the 2948 Responder may select freely among its HIs. See also "HIP 2949 Opportunistic Mode" (Section 4.1.8). 2951 The R1 packet generation counter is used to determine the currently 2952 valid generation of puzzles. The value is increased periodically, 2953 and it is RECOMMENDED that it is increased at least as often as 2954 solutions to old puzzles are no longer accepted. 2956 The Puzzle contains a Random #I and the difficulty K. The difficulty 2957 K indicates the number of lower-order bits, in the puzzle hash 2958 result, that must be zeros; see Section 4.1.2. The Random #I is not 2959 covered by the signature and must be zeroed during the signature 2960 calculation, allowing the sender to select and set the #I into a 2961 precomputed R1 packet just prior sending it to the peer. 2963 The Responder selects the Diffie-Hellman public value based on the 2964 Initiator's preference expressed in the DH_GROUP_LIST parameter in 2965 the I1 packet. The Responder sends back its own preference based on 2966 which it chose the DH public value as DH_GROUP_LIST. This allows the 2967 Initiator to determine whether its own DH_GROUP_LIST in the sent I1 2968 packet was manipulated by an attacker. 2970 The Diffie-Hellman public value is ephemeral, and values SHOULD not 2971 be reused across different HIP sessions. Once the Responder has 2972 received a valid response to an R1 packet, that Diffie-Hellman value 2973 SHOULD be deprecated. It it is possible that the Responder has sent 2974 the same Diffie-Hellman value to different hosts simultaneously in 2975 corresponding R1 packets and those responses should also be accepted. 2976 However, as a defense against I1 packet storms, an implementation MAY 2977 propose, and re-use unless avoidable, the same Diffie-Hellman value 2978 for a period of time, for example, 15 minutes. By using a small 2979 number of different puzzles for a given Diffie-Hellman value, the R1 2980 packets can be precomputed and delivered as quickly as I1 packets 2981 arrive. A scavenger process should clean up unused Diffie-Hellman 2982 values and puzzles. 2984 Re-using Diffie-Hellman public keys opens up the potential security 2985 risk of more than one Initiator ending up with the same keying 2986 material (due to faulty random number generators). Also, more than 2987 one Initiator using the same Responder public key half may lead to 2988 potentially easier cryptographic attacks and to imperfect forward 2989 security. 2991 However, these risks involved in re-using the same key are 2992 statistical; that is, the authors are not aware of any mechanism that 2993 would allow manipulation of the protocol so that the risk of the re- 2994 use of any given Responder Diffie-Hellman public key would differ 2995 from the base probability. Consequently, it is RECOMMENDED that 2996 Responders avoid re-using the same DH key with multiple Initiators, 2997 but because the risk is considered statistical and not known to be 2998 manipulable, the implementations MAY re-use a key in order to ease 2999 resource-constrained implementations and to increase the probability 3000 of successful communication with legitimate clients even under an I1 3001 packet storm. In particular, when it is too expensive to generate 3002 enough precomputed R1 packets to supply each potential Initiator with 3003 a different DH key, the Responder MAY send the same DH key to several 3004 Initiators, thereby creating the possibility of multiple legitimate 3005 Initiators ending up using the same Responder-side public key. 3006 However, as soon as the Responder knows that it will use a particular 3007 DH key, it SHOULD stop offering it. This design is aimed to allow 3008 resource-constrained Responders to offer services under I1 packet 3009 storms and to simultaneously make the probability of DH key re-use 3010 both statistical and as low as possible. 3012 If a future version of this protocol is considered, we strongly 3013 recommend that these issues be studied again. Especially, the 3014 current design allows hosts to become potentially more vulnerable to 3015 a statistical, low-probability problem during I1 packet storm attacks 3016 than what they are if no attack is taking place; whether this is 3017 acceptable or not should be reconsidered in the light of any new 3018 experience gained. 3020 The HIP_CIPHER contains the encryption algorithms supported by the 3021 Responder to encrypt the ENCRYPTED parameter, in the order of 3022 preference. All implementations MUST support AES [RFC3602]. 3024 The HIT_SUITE_LIST parameter is an ordered list of the Responder's 3025 preferred and supported HIT Suites. The list allows the Initiator to 3026 determine whether its own source HIT matches any suite supported by 3027 the Responder. 3029 The ECHO_REQUEST_SIGNED and ECHO_REQUEST_UNSIGNED contains data that 3030 the sender wants to receive unmodified in the corresponding response 3031 packet in the ECHO_RESPONSE_SIGNED or ECHO_RESPONSE_UNSIGNED 3032 parameter. 3034 The signature is calculated over the whole HIP envelope, after 3035 setting the Initiator's HIT, header checksum, as well as the Opaque 3036 field and the Random #I in the PUZZLE parameter temporarily to zero, 3037 and excluding any parameters that follow the signature, as described 3038 in Section 5.2.14. This allows the Responder to use precomputed R1s. 3039 The Initiator SHOULD validate this signature. It MUST check that the 3040 Responder's HI matches with the one expected, if any. 3042 5.3.3. I2 - the Second HIP Initiator Packet 3044 The HIP header values for the I2 packet: 3046 Header: 3047 Type = 3 3048 SRC HIT = Initiator's HIT 3049 DST HIT = Responder's HIT 3051 IP ( HIP ( [R1_COUNTER,] 3052 SOLUTION, 3053 DIFFIE_HELLMAN, 3054 HIP_CIPHER, 3055 ENCRYPTED { HOST_ID } or HOST_ID, 3056 [ ECHO_RESPONSE_SIGNED ,] 3057 HIP_MAC, 3058 HIP_SIGNATURE 3059 <, ECHO_RESPONSE_UNSIGNED>i ) ) 3061 Valid control bits: A 3063 The HITs used MUST match the ones used previously. 3065 If the Initiator's HI is an anonymous one, the A control MUST be set. 3067 The Initiator MAY include an unmodified copy of the R1_COUNTER 3068 parameter received in the corresponding R1 packet into the I2 packet. 3070 The Solution contains the Random #I from R1 and the computed #J. The 3071 low-order K bits of the RHASH(I | ... | J) MUST be zero. 3073 The Diffie-Hellman value is ephemeral. If precomputed, a scavenger 3074 process should clean up unused Diffie-Hellman values. The Responder 3075 may re-use Diffie-Hellman values under some conditions as specified 3076 in Section 5.3.2. 3078 The HIP_CIPHER contains the single encryption transform selected by 3079 the Initiator, that it uses to encrypt the ENCRYPTED parameter. The 3080 chosen cipher MUST correspond to one of the ciphers offered by the 3081 Responder in the R1. All implementations MUST support AES [RFC3602]. 3083 The Initiator's HI MAY be encrypted using the HIP_CIPHER encryption 3084 algorithm. The keying material is derived from the Diffie-Hellman 3085 exchanged as defined in Section 6.5. 3087 The ECHO_RESPONSE_SIGNED and ECHO_RESPONSE_UNSIGNED contain the 3088 unmodified Opaque data copied from the corresponding echo request 3089 parameter. 3091 The HMAC is calculated over the whole HIP envelope, excluding any 3092 parameters after the HIP_MAC, as described in Section 6.4.1. The 3093 Responder MUST validate the HIP_MAC. 3095 The signature is calculated over the whole HIP envelope, excluding 3096 any parameters after the HIP_SIGNATURE, as described in 3097 Section 5.2.13. The Responder MUST validate this signature. The 3098 Responder uses the HI in the packet or a HI acquired by some other 3099 means for verifying the signature. 3101 5.3.4. R2 - the Second HIP Responder Packet 3103 The HIP header values for the R2 packet: 3105 Header: 3106 Packet Type = 4 3107 SRC HIT = Responder's HIT 3108 DST HIT = Initiator's HIT 3110 IP ( HIP ( HIP_MAC_2, HIP_SIGNATURE ) ) 3112 Valid control bits: none 3114 The HIP_MAC_2 is calculated over the whole HIP envelope, with 3115 Responder's HOST_ID parameter concatenated with the HIP envelope. 3116 The HOST_ID parameter is removed after the HMAC calculation. The 3117 procedure is described in Section 6.4.1. 3119 The signature is calculated over the whole HIP envelope. 3121 The Initiator MUST validate both the HIP_MAC and the signature. 3123 5.3.5. UPDATE - the HIP Update Packet 3125 Support for the UPDATE packet is MANDATORY. 3127 The HIP header values for the UPDATE packet: 3129 Header: 3130 Packet Type = 16 3131 SRC HIT = Sender's HIT 3132 DST HIT = Recipient's HIT 3134 IP ( HIP ( [SEQ, ACK, ] HIP_MAC, HIP_SIGNATURE ) ) 3136 Valid control bits: None 3137 The UPDATE packet contains mandatory HIP_MAC and HIP_SIGNATURE 3138 parameters, and other optional parameters. 3140 The UPDATE packet contains zero or one SEQ parameter. The presence 3141 of a SEQ parameter indicates that the receiver MUST acknowledge the 3142 the UPDATE. An UPDATE that does not contain a SEQ parameter is 3143 simply an acknowledgment of a previous UPDATE and itself MUST NOT be 3144 acknowledged by a separate ACK. 3146 An UPDATE packet contains zero or one ACK parameters. The ACK 3147 parameter echoes the SEQ sequence number of the UPDATE packet being 3148 ACKed. A host MAY choose to acknowledge more than one UPDATE packet 3149 at a time; e.g., the ACK may contain the last two SEQ values 3150 received, for resilience against ACK loss. ACK values are not 3151 cumulative; each received unique SEQ value requires at least one 3152 corresponding ACK value in reply. Received ACKs that are redundant 3153 are ignored. Hosts MUST implement the processing of ACKS with 3154 multiple SEQ numbers even if they do not implement sending ACKs with 3155 multiple SEQ numbers. 3157 The UPDATE packet may contain both a SEQ and an ACK parameter. In 3158 this case, the ACK is being piggybacked on an outgoing UPDATE. In 3159 general, UPDATEs carrying SEQ SHOULD be ACKed upon completion of the 3160 processing of the UPDATE. A host MAY choose to hold the UPDATE 3161 carrying ACK for a short period of time to allow for the possibility 3162 of piggybacking the ACK parameter, in a manner similar to TCP delayed 3163 acknowledgments. 3165 A sender MAY choose to forgo reliable transmission of a particular 3166 UPDATE (e.g., it becomes overcome by events). The semantics are such 3167 that the receiver MUST acknowledge the UPDATE, but the sender MAY 3168 choose to not care about receiving the ACK. 3170 UPDATEs MAY be retransmitted without incrementing SEQ. If the same 3171 subset of parameters is included in multiple UPDATEs with different 3172 SEQs, the host MUST ensure that the receiver's processing of the 3173 parameters multiple times will not result in a protocol error. 3175 5.3.6. NOTIFY - the HIP Notify Packet 3177 The NOTIFY packet is OPTIONAL. The NOTIFY packet MAY be used to 3178 provide information to a peer. Typically, NOTIFY is used to indicate 3179 some type of protocol error or negotiation failure. NOTIFY packets 3180 are unacknowledged. The receiver can handle the packet only as 3181 informational, and SHOULD NOT change its HIP state (see 3182 Section 4.4.2) based purely on a received NOTIFY packet. 3184 The HIP header values for the NOTIFY packet: 3186 Header: 3187 Packet Type = 17 3188 SRC HIT = Sender's HIT 3189 DST HIT = Recipient's HIT, or zero if unknown 3191 IP ( HIP (i, [HOST_ID, ] HIP_SIGNATURE) ) 3193 Valid control bits: None 3195 The NOTIFY packet is used to carry one or more NOTIFICATION 3196 parameters. 3198 5.3.7. CLOSE - the HIP Association Closing Packet 3200 The HIP header values for the CLOSE packet: 3202 Header: 3203 Packet Type = 18 3204 SRC HIT = Sender's HIT 3205 DST HIT = Recipient's HIT 3207 IP ( HIP ( ECHO_REQUEST_SIGNED, HIP_MAC, HIP_SIGNATURE ) ) 3209 Valid control bits: none 3211 The sender MUST include an ECHO_REQUEST_SIGNED used to validate 3212 CLOSE_ACK received in response, and both an HIP_MAC and a signature 3213 (calculated over the whole HIP envelope). 3215 The receiver peer MUST validate both the HIP_MAC and the signature if 3216 it has state for a HIP association, and MUST reply with a CLOSE_ACK 3217 containing an ECHO_RESPONSE_SIGNED corresponding to the received 3218 ECHO_REQUEST_SIGNED. 3220 5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet 3222 The HIP header values for the CLOSE_ACK packet: 3224 Header: 3225 Packet Type = 19 3226 SRC HIT = Sender's HIT 3227 DST HIT = Recipient's HIT 3229 IP ( HIP ( ECHO_RESPONSE_SIGNED, HIP_MAC, HIP_SIGNATURE ) ) 3231 Valid control bits: none 3232 The sender MUST include both an HMAC and signature (calculated over 3233 the whole HIP envelope). 3235 The receiver peer MUST validate both the HMAC and the signature. 3237 5.4. ICMP Messages 3239 When a HIP implementation detects a problem with an incoming packet, 3240 and it either cannot determine the identity of the sender of the 3241 packet or does not have any existing HIP association with the sender 3242 of the packet, it MAY respond with an ICMP packet. Any such replies 3243 MUST be rate-limited as described in [RFC2463]. In most cases, the 3244 ICMP packet has the Parameter Problem type (12 for ICMPv4, 4 for 3245 ICMPv6), with the Pointer field pointing to the field that caused the 3246 ICMP message to be generated. 3248 5.4.1. Invalid Version 3250 If a HIP implementation receives a HIP packet that has an 3251 unrecognized HIP version number, it SHOULD respond, rate-limited, 3252 with an ICMP packet with type Parameter Problem, with the Pointer 3253 pointing to the VER./RES. byte in the HIP header. 3255 5.4.2. Other Problems with the HIP Header and Packet Structure 3257 If a HIP implementation receives a HIP packet that has other 3258 unrecoverable problems in the header or packet format, it MAY 3259 respond, rate-limited, with an ICMP packet with type Parameter 3260 Problem, the Pointer pointing to the field that failed to pass the 3261 format checks. However, an implementation MUST NOT send an ICMP 3262 message if the checksum fails; instead, it MUST silently drop the 3263 packet. 3265 5.4.3. Invalid Puzzle Solution 3267 If a HIP implementation receives an I2 packet that has an invalid 3268 puzzle solution, the behavior depends on the underlying version of 3269 IP. If IPv6 is used, the implementation SHOULD respond with an ICMP 3270 packet with type Parameter Problem, the Pointer pointing to the 3271 beginning of the Puzzle solution #J field in the SOLUTION payload in 3272 the HIP message. 3274 If IPv4 is used, the implementation MAY respond with an ICMP packet 3275 with the type Parameter Problem, copying enough of bytes from the I2 3276 message so that the SOLUTION parameter fits into the ICMP message, 3277 the Pointer pointing to the beginning of the Puzzle solution #J 3278 field, as in the IPv6 case. Note, however, that the resulting ICMPv4 3279 message exceeds the typical ICMPv4 message size as defined in 3281 [RFC0792]. 3283 5.4.4. Non-Existing HIP Association 3285 If a HIP implementation receives a CLOSE or UPDATE packet, or any 3286 other packet whose handling requires an existing association, that 3287 has either a Receiver or Sender HIT that does not match with any 3288 existing HIP association, the implementation MAY respond, rate- 3289 limited, with an ICMP packet with the type Parameter Problem. The 3290 Pointer of the ICMP Parameter Problem packet is set pointing to the 3291 beginning of the first HIT that does not match. 3293 A host MUST NOT reply with such an ICMP if it receives any of the 3294 following messages: I1, R2, I2, R2, and NOTIFY packet. When 3295 introducing new packet types, a specification SHOULD define the 3296 appropriate rules for sending or not sending this kind of ICMP reply. 3298 6. Packet Processing 3300 Each host is assumed to have a single HIP protocol implementation 3301 that manages the host's HIP associations and handles requests for new 3302 ones. Each HIP association is governed by a conceptual state 3303 machine, with states defined above in Section 4.4. The HIP 3304 implementation can simultaneously maintain HIP associations with more 3305 than one host. Furthermore, the HIP implementation may have more 3306 than one active HIP association with another host; in this case, HIP 3307 associations are distinguished by their respective HITs. It is not 3308 possible to have more than one HIP association between any given pair 3309 of HITs. Consequently, the only way for two hosts to have more than 3310 one parallel association is to use different HITs, at least at one 3311 end. 3313 The processing of packets depends on the state of the HIP 3314 association(s) with respect to the authenticated or apparent 3315 originator of the packet. A HIP implementation determines whether it 3316 has an active association with the originator of the packet based on 3317 the HITs. In the case of user data carried in a specific transport 3318 format, the transport format document specifies how the incoming 3319 packets are matched with the active associations. 3321 6.1. Processing Outgoing Application Data 3323 In a HIP host, an application can send application-level data using 3324 an identifier specified via the underlying API. The API can be a 3325 backwards-compatible API (see [RFC5338]), using identifiers that look 3326 similar to IP addresses, or a completely new API, providing enhanced 3327 services related to Host Identities. Depending on the HIP 3328 implementation, the identifier provided to the application may be 3329 different; for example, it can be a HIT or an IP address. 3331 The exact format and method for transferring the data from the source 3332 HIP host to the destination HIP host is defined in the corresponding 3333 transport format document. The actual data is transferred in the 3334 network using the appropriate source and destination IP addresses. 3336 In this document, conceptual processing rules are defined only for 3337 the base case where both hosts have only single usable IP addresses; 3338 the multi-address multi-homing case is specified separately. 3340 The following conceptual algorithm describes the steps that are 3341 required for handling outgoing datagrams destined to a HIT. 3343 1. If the datagram has a specified source address, it MUST be a HIT. 3344 If it is not, the implementation MAY replace the source address 3345 with a HIT. Otherwise, it MUST drop the packet. 3347 2. If the datagram has an unspecified source address, the 3348 implementation must choose a suitable source HIT for the 3349 datagram. 3351 3. If there is no active HIP association with the given HIT pair, one must be created by running the base 3353 exchange. While waiting for the base exchange to complete, the 3354 implementation SHOULD queue at least one packet per HIP 3355 association to be formed, and it MAY queue more than one. 3357 4. Once there is an active HIP association for the given HIT pair, the outgoing datagram is passed to 3359 transport handling. The possible transport formats are defined 3360 in separate documents, of which the ESP transport format for HIP 3361 is mandatory for all HIP implementations. 3363 5. Before sending the packet, the HITs in the datagram are replaced 3364 with suitable IP addresses. For IPv6, the rules defined in 3365 [RFC3484] SHOULD be followed. Note that this HIT-to-IP-address 3366 conversion step MAY also be performed at some other point in the 3367 stack, e.g., before wrapping the packet into the output format. 3369 6.2. Processing Incoming Application Data 3371 The following conceptual algorithm describes the incoming datagram 3372 handling when HITs are used at the receiving host as application- 3373 level identifiers. More detailed steps for processing packets are 3374 defined in corresponding transport format documents. 3376 1. The incoming datagram is mapped to an existing HIP association, 3377 typically using some information from the packet. For example, 3378 such mapping may be based on the ESP Security Parameter Index 3379 (SPI). 3381 2. The specific transport format is unwrapped, in a way depending on 3382 the transport format, yielding a packet that looks like a 3383 standard (unencrypted) IP packet. If possible, this step SHOULD 3384 also verify that the packet was indeed (once) sent by the remote 3385 HIP host, as identified by the HIP association. 3387 Depending on the used transport mode, the verification method can 3388 vary. While the HI (as well as HIT) is used as the higher-layer 3389 identifier, the verification method has to verify that the data 3390 packet was sent by a the correct node identity and that the 3391 actual identity maps to this particular HIT. When using ESP 3392 transport format [I-D.ietf-hip-rfc5202-bis], the verification is 3393 done using the SPI value in the data packet to find the 3394 corresponding SA with associated HIT and key, and decrypting the 3395 packet with that associated key. 3397 3. The IP addresses in the datagram are replaced with the HITs 3398 associated with the HIP association. Note that this IP-address- 3399 to-HIT conversion step MAY also be performed at some other point 3400 in the stack. 3402 4. The datagram is delivered to the upper layer (e.g., UDP or TCP). 3403 When demultiplexing the datagram, the right upper-layer socket is 3404 based on the HITs. 3406 6.3. Solving the Puzzle 3408 This subsection describes the details for solving the puzzle. 3410 In the R1 packet, the values I and K are sent in network byte order. 3411 Similarly, in the I2 packet, the values I and J are sent in network 3412 byte order. The hash is created by concatenating, in network byte 3413 order, the following data, in the following order and using the RHASH 3414 algorithm: 3416 n-bit random value I (where n is RHASH_len), in network byte 3417 order, as appearing in the R1 and I2 packets. 3419 128-bit Initiator's HIT, in network byte order, as appearing in 3420 the HIP Payload in the R1 and I2 packets. 3422 128-bit Responder's HIT, in network byte order, as appearing in 3423 the HIP Payload in the R1 and I2 packets. 3425 n-bit random value J (where n is RHASH_len), in network byte 3426 order, as appearing in the I2 packet. 3428 In a valid response puzzle, the K low-order bits of the resulting 3429 RHASH digest MUST be zero. 3431 Notes: 3433 i) The length of the data to be hashed is variable depending on 3434 the output length of the Responder's hash function RHASH. 3436 ii) All the data in the hash input MUST be in network byte order. 3438 iii) The order of the Initiator's and Responder's HITs are 3439 different in the R1 and I2 packets; see Section 5.1. Care must be 3440 taken to copy the values in the right order to the hash input. 3442 iv) For a puzzle I, there may exist multiple valid puzzle 3443 solutions J. 3445 The following procedure describes the processing steps involved, 3446 assuming that the Responder chooses to precompute the R1 packets: 3448 Precomputation by the Responder: 3449 Sets up the puzzle difficulty K. 3450 Creates a signed R1 and caches it. 3452 Responder: 3453 Selects a suitable cached R1. 3454 Generates a random number I. 3455 Sends I and K in an R1. 3456 Saves I and K for a Delta time. 3458 Initiator: 3459 Generates repeated attempts to solve the puzzle until a matching J 3460 is found: 3461 Ltrunc( RHASH( I | HIT-I | HIT-R | J ), K ) == 0 3462 Sends I and J in an I2. 3464 Responder: 3465 Verifies that the received I is a saved one. 3466 Finds the right K based on I. 3467 Computes V := Ltrunc( RHASH( I | HIT-I | HIT-R | J ), K ) 3468 Rejects if V != 0 3469 Accept if V == 0 3471 6.4. HIP_MAC and SIGNATURE Calculation and Verification 3473 The following subsections define the actions for processing HIP_MAC, 3474 HIP_MAC_2, HIP_SIGNATURE and HIP_SIGNATURE_2 parameters. The 3475 HIP_MAC_2 parameter is contained in the R2 packet. The 3476 HIP_SIGNATURE_2 parameter is contained in the R1 packet. The 3477 HIP_SIGNATURE and HIP_MAC parameter are contained in other HIP 3478 control packets. 3480 6.4.1. HMAC Calculation 3482 The HMAC uses RHASH as underlying hash function. The RHASH depends 3483 on the HIT Suite of the Responder. Hence, HMAC-SHA-1 [RFC2404] is 3484 used for HIT Suites RSA/DSA/SAH-1 and ECDSA_LOW/SHA-1 and HMAC-SHA- 3485 256 [RFC4868] for ECDSA/SHA-384. 3487 The following process applies both to the HIP_MAC and HIP_MAC_2 3488 parameters. When processing HIP_MAC_2, the difference is that the 3489 HIP_MAC calculation includes a pseudo HOST_ID field containing the 3490 Responder's information as sent in the R1 packet earlier. 3492 Both the Initiator and the Responder should take some care when 3493 verifying or calculating the HIP_MAC_2. Specifically, the Initiator 3494 has to preserve the HOST_ID exactly as it was received in the R1 3495 packet until it receives the HIP_MAC_2 in the R2 packet. 3497 The scope of the calculation for HIP_MAC and HIP_MAC_2 is: 3499 HMAC: { HIP header | [ Parameters ] } 3501 where Parameters include all HIP parameters of the packet that is 3502 being calculated with Type values ranging from 1 to (HIP_MAC's Type 3503 value - 1) and exclude parameters with Type values greater or equal 3504 to HIP_MAC's Type value. 3506 During HIP_MAC calculation, the following applies: 3508 o In the HIP header, the Checksum field is set to zero. 3510 o In the HIP header, the Header Length field value is calculated to 3511 the beginning of the HIP_MAC parameter. 3513 Parameter order is described in Section 5.2.1. 3515 HIP_MAC_2: { HIP header | [ Parameters ] | HOST_ID } 3517 where Parameters include all HIP parameters for the packet that is 3518 being calculated with Type values from 1 to (HIP_MAC_2's Type value - 3519 1) and exclude parameters with Type values greater or equal to 3520 HIP_MAC_2's Type value. 3522 During HIP_MAC_2 calculation, the following applies: 3524 o In the HIP header, the Checksum field is set to zero. 3526 o In the HIP header, the Header Length field value is calculated to 3527 the beginning of the HIP_MAC_2 parameter and added to the length 3528 of the concatenated HOST_ID parameter length. 3530 o HOST_ID parameter is exactly in the form it was received in the R1 3531 packet from the Responder. 3533 Parameter order is described in Section 5.2.1, except that the 3534 HOST_ID parameter in this calculation is added to the end. 3536 The HIP_MAC parameter is defined in Section 5.2.11 and the HIP_MAC_2 3537 parameter in Section 5.2.12. The HMAC calculation and verification 3538 process (the process applies both to HIP_MAC and HIP_MAC_2 except 3539 where HIP_MAC_2 is mentioned separately) is as follows: 3541 Packet sender: 3543 1. Create the HIP packet, without the HIP_MAC, HIP_SIGNATURE, 3544 HIP_SIGNATURE_2, or any other parameter with greater Type value 3545 than the HIP_MAC parameter has. 3547 2. In case of HIP_MAC_2 calculation, add a HOST_ID (Responder) 3548 parameter to the end of the packet. 3550 3. Calculate the Header Length field in the HIP header including the 3551 added HOST_ID parameter in case of HIP_MAC_2. 3553 4. Compute the HMAC using either HIP-gl or HIP-lg integrity key 3554 retrieved from KEYMAT as defined in Section 6.5. 3556 5. In case of HIP_MAC_2, remove the HOST_ID parameter from the 3557 packet. 3559 6. Add the HIP_MAC parameter to the packet and any parameter with 3560 greater Type value than the HIP_MAC's (HIP_MAC_2's) that may 3561 follow, including possible HIP_SIGNATURE or HIP_SIGNATURE_2 3562 parameters 3564 7. Recalculate the Length field in the HIP header. 3566 Packet receiver: 3568 1. Verify the HIP header Length field. 3570 2. Remove the HIP_MAC or HIP_MAC_2 parameter, as well as all other 3571 parameters that follow it with greater Type value including 3572 possible HIP_SIGNATURE or HIP_SIGNATURE_2 fields, saving the 3573 contents if they are needed later. 3575 3. In case of HIP_MAC_2, build and add a HOST_ID parameter (with 3576 Responder information) to the packet. The HOST_ID parameter 3577 should be identical to the one previously received from the 3578 Responder. 3580 4. Recalculate the HIP packet length in the HIP header and clear the 3581 Checksum field (set it to all zeros). In case of HIP_MAC_2, the 3582 length is calculated with the added HOST_ID parameter. 3584 5. Compute the HMAC using either HIP-gl or HIP-lg integrity key as 3585 defined in Section 6.5 and verify it against the received HMAC. 3587 6. Set Checksum and Header Length field in the HIP header to 3588 original values. 3590 7. In case of HIP_MAC_2, remove the HOST_ID parameter from the 3591 packet before further processing. 3593 6.4.2. Signature Calculation 3595 The following process applies both to the HIP_SIGNATURE and 3596 HIP_SIGNATURE_2 parameters. When processing the HIP_SIGNATURE_2, the 3597 only difference is that instead of the HIP_SIGNATURE parameter, the 3598 HIP_SIGNATURE_2 parameter is used, and the Initiator's HIT and PUZZLE 3599 Opaque and Random #I fields are cleared (set to all zeros) before 3600 computing the signature. The HIP_SIGNATURE parameter is defined in 3601 Section 5.2.13 and the HIP_SIGNATURE_2 parameter in Section 5.2.14. 3603 The scope of the calculation for HIP_SIGNATURE and HIP_SIGNATURE_2 3604 is: 3606 HIP_SIGNATURE: { HIP header | [ Parameters ] } 3608 where Parameters include all HIP parameters for the packet that is 3609 being calculated with Type values from 1 to (HIP_SIGNATURE's Type 3610 value - 1). 3612 During signature calculation, the following applies: 3614 o In the HIP header, the Checksum field is set to zero. 3616 o In the HIP header, the Header Length field value is calculated to 3617 the beginning of the HIP_SIGNATURE parameter. 3619 The parameter order is described in Section 5.2.1. 3621 HIP_SIGNATURE_2: { HIP header | [ Parameters ] } 3623 where Parameters include all HIP parameters for the packet that is 3624 being calculated with Type values ranging from 1 to 3625 (HIP_SIGNATURE_2's Type value - 1). 3627 During signature calculation, the following apply: 3629 o In the HIP header, the Initiator's HIT field and Checksum fields 3630 are set to zero. 3632 o In the HIP header, the Header Length field value is calculated to 3633 the beginning of the HIP_SIGNATURE_2 parameter. 3635 o PUZZLE parameter's Opaque and Random #I fields are set to zero. 3637 Parameter order is described in Section 5.2.1. 3639 The signature calculation and verification process (the process 3640 applies both to HIP_SIGNATURE and HIP_SIGNATURE_2 except in the case 3641 where HIP_SIGNATURE_2 is separately mentioned) is as follows: 3643 Packet sender: 3645 1. Create the HIP packet without the HIP_SIGNATURE parameter or any 3646 other parameters that follow the HIP_SIGNATURE parameter. 3648 2. Calculate the Length field and zero the Checksum field in the HIP 3649 header. In case of HIP_SIGNATURE_2, set Initiator's HIT field in 3650 the HIP header as well as PUZZLE parameter's Opaque and Random #I 3651 fields to zero. 3653 3. Compute the signature using the private key corresponding to the 3654 Host Identifier (public key). 3656 4. Add the HIP_SIGNATURE parameter to the packet. 3658 5. Add any parameters that follow the HIP_SIGNATURE parameter. 3660 6. Recalculate the Length field in the HIP header, and calculate the 3661 Checksum field. 3663 Packet receiver: 3665 1. Verify the HIP header Length field and checksum. 3667 2. Save the contents of the HIP_SIGNATURE parameter and any other 3668 parameters following the HIP_SIGNATURE parameter and remove them 3669 from the packet. 3671 3. Recalculate the HIP packet Length in the HIP header and clear the 3672 Checksum field (set it to all zeros). In case of 3673 HIP_SIGNATURE_2, set Initiator's HIT field in the HIP header as 3674 well as PUZZLE parameter's Opaque and Random #I fields to zero. 3676 4. Compute the signature and verify it against the received 3677 signature using the packet sender's Host Identifier (public key). 3679 5. Restore the original packet by adding removed parameters (in step 3680 2) and resetting the values that were set to zero (in step 3). 3682 The verification can use either the HI received from a HIP packet, 3683 the HI from a DNS query, if the FQDN has been received in the HOST_ID 3684 packet, or one received by some other means. 3686 6.5. HIP KEYMAT Generation 3688 HIP keying material is derived from the Diffie-Hellman session key, 3689 Kij, produced during the HIP base exchange (see Section 4.1.3). The 3690 Initiator has Kij during the creation of the I2 packet, and the 3691 Responder has Kij once it receives the I2 packet. This is why I2 can 3692 already contain encrypted information. 3694 The KEYMAT is derived by feeding Kij into HKDF [RFC5869] using the 3695 RHASH hash function. 3697 where 3699 info = sort(HIT-I | HIT-R) 3700 salt = I | J 3702 Sort(HIT-I | HIT-R) is defined as the network byte order 3703 concatenation of the two HITs, with the smaller HIT preceding the 3704 larger HIT, resulting from the numeric comparison of the two HITs 3705 interpreted as positive (unsigned) 128-bit integers in network byte 3706 order. 3708 The I and J values are from the puzzle and its solution that were 3709 exchanged in R1 and I2 messages when this HIP association was set up. 3710 Both hosts have to store I and J values for the HIP association for 3711 future use. 3713 The initial keys are drawn sequentially in the order that is 3714 determined by the numeric comparison of the two HITs, with comparison 3715 method described in the previous paragraph. HOST_g denotes the host 3716 with the greater HIT value, and HOST_l the host with the lower HIT 3717 value. 3719 The drawing order for the initial keys is as follows: 3721 HIP-gl encryption key for HOST_g's outgoing HIP packets 3723 HIP-gl integrity (HMAC) key for HOST_g's outgoing HIP packets 3725 HIP-lg encryption key (currently unused) for HOST_l's outgoing HIP 3726 packets 3728 HIP-lg integrity (HMAC) key for HOST_l's outgoing HIP packets 3730 The number of bits drawn for a given algorithm is the "natural" size 3731 of the keys. For the mandatory algorithms, the following sizes 3732 apply: 3734 AES 128 or 256 bits 3736 SHA-1 160 bits 3738 SHA-256 256 bits 3740 SHA-384 384 bits 3742 NULL 0 bits 3744 If other key sizes are used, they must be treated as different 3745 encryption algorithms and defined separately. 3747 6.6. Initiation of a HIP Exchange 3749 An implementation may originate a HIP exchange to another host based 3750 on a local policy decision, usually triggered by an application 3751 datagram, in much the same way that an IPsec IKE key exchange can 3752 dynamically create a Security Association. Alternatively, a system 3753 may initiate a HIP exchange if it has rebooted or timed out, or 3754 otherwise lost its HIP state, as described in Section 4.5.4. 3756 The implementation prepares an I1 packet and sends it to the IP 3757 address that corresponds to the peer host. The IP address of the 3758 peer host may be obtained via conventional mechanisms, such as DNS 3759 lookup. The I1 packet contents are specified in Section 5.3.1. The 3760 selection of which source or destination Host Identity to use, if a 3761 Initiator or Responder has more than one to choose from, is typically 3762 a policy decision. 3764 The following steps define the conceptual processing rules for 3765 initiating a HIP exchange: 3767 1. The Initiator receives one or more of the Responder's HITs and 3768 one or more addresses either from a DNS lookup of the Responder's 3769 FQDN, from some other repository, or from a local database. If 3770 the Initiator does not know the Responder's HIT, it may attempt 3771 opportunistic mode by using NULL (all zeros) as the Responder's 3772 HIT (see also "HIP Opportunistic Mode" (Section 4.1.8)). If the 3773 Initiator can choose from multiple Responder HITs, it selects a 3774 HIT for which the Initiator supports the HIT Suite. 3776 2. The Initiator sends an I1 packet to one of the Responder's 3777 addresses. The selection of which address to use is a local 3778 policy decision. 3780 3. The Initiator includes the DH_GROUP_LIST in the I1 packet. The 3781 selection and order of DH Group IDs in the DH_GROUP_LIST MUST be 3782 stored by the Initiator because this list is needed for later R1 3783 processing. In most cases, the preferences regarding the DH 3784 Groups will be static, so no per-association storage is 3785 necessary. 3787 4. Upon sending an I1 packet, the sender transitions to state I1- 3788 SENT, starts a timer for which the timeout value SHOULD be larger 3789 than the worst-case anticipated RTT. The sender SHOULD also 3790 increment the timeout counter associated with the I1. 3792 5. Upon timeout, the sender SHOULD retransmit the I1 packet and 3793 restart the timer, up to a maximum of I1_RETRIES_MAX tries. 3795 6.6.1. Sending Multiple I1 Packets in Parallel 3797 For the sake of minimizing the session establishment latency, an 3798 implementation MAY send the same I1 packet to more than one of the 3799 Responder's addresses. However, it MUST NOT send to more than three 3800 (3) Responder addresses in parallel. Furthermore, upon timeout, the 3801 implementation MUST refrain from sending the same I1 packet to 3802 multiple addresses. That is, if it retries to initialize the 3803 connection after a timeout, it MUST NOT send the I1 packet to more 3804 than one destination address. These limitations are placed in order 3805 to avoid congestion of the network, and potential DoS attacks that 3806 might occur, e.g., because someone's claim to have hundreds or 3807 thousands of addresses could generate a huge number of I1 packets 3808 from the Initiator. 3810 As the Responder is not guaranteed to distinguish the duplicate I1 3811 packets it receives at several of its addresses (because it avoids 3812 storing states when it answers back an R1 packet), the Initiator may 3813 receive several duplicate R1 packets. 3815 The Initiator SHOULD then select the initial preferred destination 3816 address using the source address of the selected received R1, and use 3817 the preferred address as a source address for the I2 packet. 3818 Processing rules for received R1s are discussed in Section 6.8. 3820 6.6.2. Processing Incoming ICMP Protocol Unreachable Messages 3822 A host may receive an ICMP 'Destination Protocol Unreachable' message 3823 as a response to sending a HIP I1 packet. Such a packet may be an 3824 indication that the peer does not support HIP, or it may be an 3825 attempt to launch an attack by making the Initiator believe that the 3826 Responder does not support HIP. 3828 When a system receives an ICMP 'Destination Protocol Unreachable' 3829 message while it is waiting for an R1 packet, it MUST NOT terminate 3830 the wait. It MAY continue as if it had not received the ICMP 3831 message, and send a few more I1 packets. Alternatively, it MAY take 3832 the ICMP message as a hint that the peer most probably does not 3833 support HIP, and return to state UNASSOCIATED earlier than otherwise. 3834 However, at minimum, it MUST continue waiting for an R1 packet for a 3835 reasonable time before returning to UNASSOCIATED. 3837 6.7. Processing Incoming I1 Packets 3839 An implementation SHOULD reply to an I1 with an R1 packet, unless the 3840 implementation is unable or unwilling to set up a HIP association. 3841 If the implementation is unable to set up a HIP association, the host 3842 SHOULD send an ICMP Destination Protocol Unreachable, 3843 Administratively Prohibited, message to the I1 packet source IP 3844 address. If the implementation is unwilling to set up a HIP 3845 association, the host MAY ignore the I1 packet. This latter case may 3846 occur during a DoS attack such as an I1 packet flood. 3848 The implementation SHOULD be able to handle a storm of received I1 3849 packets, discarding those with common content that arrive within a 3850 small time delta. 3852 A spoofed I1 packet can result in an R1 attack on a system. An R1 3853 packet sender MUST have a mechanism to rate-limit R1 packets sent to 3854 an address. 3856 It is RECOMMENDED that the HIP state machine does not transition upon 3857 sending an R1 packet. 3859 The following steps define the conceptual processing rules for 3860 responding to an I1 packet: 3862 1. The Responder MUST check that the Responder's HIT in the received 3863 I1 packet is either one of its own HITs or NULL. Otherwise it 3864 must drop the packet. 3866 2. If the Responder is in ESTABLISHED state, the Responder MAY 3867 respond to this with an R1 packet, prepare to drop existing SAs, 3868 and stay at ESTABLISHED state. 3870 3. If the Responder is in I1-SENT state, it must make a comparison 3871 between the sender's HIT and its own (i.e., the receiver's) HIT. 3872 If the sender's HIT is greater than its own HIT, it should drop 3873 the I1 packet and stay at I1-SENT. If the sender's HIT is 3874 smaller than its own HIT, it should send the R1 packet and stay 3875 at I1-SENT. The HIT comparison is performed as defined in 3876 Section 6.5. 3878 4. If the implementation chooses to respond to the I1 packet with an 3879 R1 packet, it creates a new R1 or selects a precomputed R1 3880 according to the format described in Section 5.3.2. It creates 3881 or chooses an R1 that contains its most preferred DH public value 3882 that is also contained in the DH_GROUP_LIST in the I1 packet. If 3883 no suitable DH Group ID was contained in the DH_GROUP_LIST in the 3884 I1 packet, it sends an R1 with any suitable DH public key. 3886 5. If the received Responder's HIT in the I1 is NULL, the Responder 3887 a HIT with a the same HIT Suite as the Initiator's HIT. If this 3888 HIT Suite is not supported by the Responder, it SHOULD select a 3889 REQUIRED HIT Suite from Section 5.2.9, which is currently RSA/ 3890 DSA/SHA-1. Other than that, selecting the HIT is a local policy 3891 matter. 3893 6. The Responder sends the R1 packet to the source IP address of the 3894 I1 packet. 3896 6.7.1. R1 Management 3898 All compliant implementations MUST produce R1 packets. An R1 packet 3899 MAY be precomputed. An R1 packet MAY be reused for time Delta T, 3900 which is implementation dependent, and SHOULD be deprecated and not 3901 used once a valid response I2 packet has been received from an 3902 Initiator. During an I1 message storm, an R1 packet may be re-used 3903 beyond this limit. R1 information MUST NOT be discarded until Delta 3904 S after T. Time S is the delay needed for the last I2 packet to 3905 arrive back to the Responder. 3907 Implementations that support multiple DH groups MAY pre-compute R1 3908 packets for each supported group so that incoming I1 packets with 3909 different DH Group IDs in the DH_GROUP_LIST can be served quickly. 3911 An implementation MAY keep state about received I1 packets and match 3912 the received I2 packets against the state, as discussed in 3913 Section 4.1.1. 3915 6.7.2. Handling Malformed Messages 3917 If an implementation receives a malformed I1 packet, it SHOULD NOT 3918 respond with a NOTIFY message, as such practice could open up a 3919 potential denial-of-service danger. Instead, it MAY respond with an 3920 ICMP packet, as defined in Section 5.4. 3922 6.8. Processing Incoming R1 Packets 3924 A system receiving an R1 packet MUST first check to see if it has 3925 sent an I1 packet to the originator of the R1 packet (i.e., it is in 3926 state I1-SENT). If so, it SHOULD process the R1 as described below, 3927 send an I2 packet, and transition to state I2-SENT, setting a timer 3928 to protect the I2 packet. If the system is in state I2-SENT, it MAY 3929 respond to the R1 packet if the R1 packet has a larger R1 generation 3930 counter; if so, it should drop its state due to processing the 3931 previous R1 packet and start over from state I1-SENT. If the system 3932 is in any other state with respect to that host, the system SHOULD 3933 silently drop the R1 packet. 3935 When sending multiple I1 packets, an Initiator SHOULD wait for a 3936 small amount of time after the first R1 reception to allow possibly 3937 multiple R1 packets to arrive, and it SHOULD respond to an R1 packet 3938 among the set with the largest R1 generation counter. 3940 The following steps define the conceptual processing rules for 3941 responding to an R1 packet: 3943 1. A system receiving an R1 MUST first check to see if it has sent 3944 an I1 packet to the originator of the R1 packet (i.e., it has a 3945 HIP association that is in state I1-SENT and that is associated 3946 with the HITs in the R1). Unless the I1 packet was sent in 3947 opportunistic mode (see Section 4.1.8), the IP addresses in the 3948 received R1 packet SHOULD be ignored and, when looking up the 3949 right HIP association, the received R1 packet SHOULD be matched 3950 against the associations using only the HITs. If a match 3951 exists, the system should process the R1 packet as described 3952 below. 3954 2. Otherwise, if the system is in any other state than I1-SENT or 3955 I2-SENT with respect to the HITs included in the R1 packet, it 3956 SHOULD silently drop the R1 packet and remain in the current 3957 state. 3959 3. If the HIP association state is I1-SENT or I2-SENT, the received 3960 Initiator's HIT MUST correspond to the HIT used in the original 3961 I1. Also, the Responder's HIT MUST correspond to the one used 3962 in the I1, unless the I1 packet contained a NULL HIT. 3964 4. The system SHOULD validate the R1 signature before applying 3965 further packet processing, according to Section 5.2.14. 3967 5. If the HIP association state is I1-SENT, and multiple valid R1 3968 packets are present, the system MUST select from among the R1 3969 packets with the largest R1 generation counter. 3971 6. The system MUST check that the Initiator HIT Suite is contained 3972 in the HIT_SUITE_LIST parameter in the R1 packet (i.e., the 3973 Initiator's HIT Suite is supported by the Responder). If the 3974 HIT Suite is supported by the Responder, the system proceeds 3975 normally. Otherwise, the system MAY stay in state I1-sent and 3976 restart the BEX by sending a new I1 packet with a Initiator HIT 3977 that is supported by the Responder and hence is contained in the 3978 HIT_SUITE_LIST in the R1 packet. The system MAY abort the BEX 3979 if no suitable source HIT is available. The system SHOULD wait 3980 for an acceptable time span to allow further R1 packets with 3981 higher R1 generation counters or different HIT and HIT Suites to 3982 arrive before restarting or aborting the BEX. 3984 7. The system MUST check that the DH Group ID in the DH parameter 3985 in the R1 matches the first DH Suite ID in the Responder's 3986 DH_GROUP_LIST in the R1 packet that was also contained in the 3987 Initiator's DH_GROUP_LIST in the I1 packet. If the DH Group ID 3988 of the DH parameter does not express the Responder's best 3989 choice, the Initiator can conclude that the DH_GROUP_LIST in the 3990 I1 packet was adversely modified. In such case, the Initiator 3991 MAY send a new I1 packet, however, it SHOULD not change its 3992 preference in the DH_GROUP_LIST in the new I1 packet. 3993 Alternatively, the Initiator MAY abort the HIP exchange. 3995 8. If the HIP association state is I2-SENT, the system MAY re-enter 3996 state I1-SENT and process the received R1 packet if it has a 3997 larger R1 generation counter than the R1 packet responded to 3998 previously. 4000 9. The R1 packet may have the A bit set -- in this case, the system 4001 MAY choose to refuse it by dropping the R1 packet and returning 4002 to state UNASSOCIATED. The system SHOULD consider dropping the 4003 R1 packet only if it used a NULL HIT in I1 packet. If the A bit 4004 is set, the Responder's HIT is anonymous and should not be 4005 stored permanently. 4007 10. The system SHOULD attempt to validate the HIT against the 4008 received Host Identity by using the received Host Identity to 4009 construct a HIT and verify that it matches the Sender's HIT. 4011 11. The system MUST store the received R1 generation counter for 4012 future reference. 4014 12. The system attempts to solve the puzzle in the R1 packet. The 4015 system MUST terminate the search after exceeding the remaining 4016 lifetime of the puzzle. If the puzzle is not successfully 4017 solved, the implementation may either resend the I1 packet 4018 within the retry bounds or abandon the HIP exchange. 4020 13. The system computes standard Diffie-Hellman keying material 4021 according to the public value and Group ID provided in the 4022 DIFFIE_HELLMAN parameter. The Diffie-Hellman keying material 4023 Kij is used for key extraction as specified in Section 6.5. 4025 14. The system selects the HIP_CIPHER ID from the choices presented 4026 in the R1 packet and uses the selected values subsequently when 4027 generating and using encryption keys, and when sending the I2 4028 packet. If the proposed alternatives are not acceptable to the 4029 system, it may either resend an I1 within the retry bounds or 4030 abandon the HIP exchange. 4032 15. The system initializes the remaining variables in the associated 4033 state, including Update ID counters. 4035 16. The system prepares and sends an I2 packet, as described in 4036 Section 5.3.3. 4038 17. The system SHOULD start a timer whose timeout value should be 4039 larger than the worst-case anticipated RTT, and MUST increment a 4040 timeout counter associated with the I2 packet. The sender 4041 SHOULD retransmit the I2 packet upon a timeout and restart the 4042 timer, up to a maximum of I2_RETRIES_MAX tries. 4044 18. If the system is in state I1-SENT, it shall transition to state 4045 I2-SENT. If the system is in any other state, it remains in the 4046 current state. 4048 6.8.1. Handling of Malformed Messages 4050 If an implementation receives a malformed R1 message, it MUST 4051 silently drop the packet. Sending a NOTIFY or ICMP would not help, 4052 as the sender of the R1 packet typically doesn't have any state. An 4053 implementation SHOULD wait for some more time for a possibly well- 4054 formed R1, after which it MAY try again by sending a new I1 packet. 4056 6.9. Processing Incoming I2 Packets 4058 Upon receipt of an I2 packet, the system MAY perform initial checks 4059 to determine whether the I2 packet corresponds to a recent R1 packet 4060 that has been sent out, if the Responder keeps such state. For 4061 example, the sender could check whether the I2 packet is from an 4062 address or HIT for which the Responder has recently received an I1. 4063 The R1 packet may have had Opaque data included that was echoed back 4064 in the I2 packet. If the I2 packet is considered to be suspect, it 4065 MAY be silently discarded by the system. 4067 Otherwise, the HIP implementation SHOULD process the I2 packet. This 4068 includes validation of the puzzle solution, generating the Diffie- 4069 Hellman key, decrypting the Initiator's Host Identity, verifying the 4070 signature, creating state, and finally sending an R2 packet. 4072 The following steps define the conceptual processing rules for 4073 responding to an I2 packet: 4075 1. The system MAY perform checks to verify that the I2 packet 4076 corresponds to a recently sent R1 packet. Such checks are 4077 implementation dependent. See Appendix A for a description of 4078 an example implementation. 4080 2. The system MUST check that the Responder's HIT corresponds to 4081 one of its own HITs and MUST drop the packet otherwise. 4083 3. The system MUST further check that the Initiator's HIT Suite is 4084 supported. The Responder SHOULD silently drop I2 packets with 4085 unsupported Initiator HITs. 4087 4. If the system's state machine is in the R2-SENT state, the 4088 system MAY check if the newly received I2 packet is similar to 4089 the one that triggered moving to R2-SENT. If so, it MAY 4090 retransmit a previously sent R2 packet, reset the R2-SENT timer, 4091 and the state machine stays in R2-SENT. 4093 5. If the system's state machine is in the I2-SENT state, the 4094 system makes a comparison between its local and sender's HITs 4095 (similarly as in Section 6.5). If the local HIT is smaller than 4096 the sender's HIT, it should drop the I2 packet, use the peer 4097 Diffie-Hellman key and nonce I from the R1 packet received 4098 earlier, and get the local Diffie-Hellman key and nonce J from 4099 the I2 packet sent to the peer earlier. Otherwise, the system 4100 should process the received I2 packet and drop any previously 4101 derived Diffie-Hellman keying material Kij it might have formed 4102 upon sending the I2 packet previously. The peer Diffie-Hellman 4103 key and the nonce J are taken from the just arrived I2 packet. 4104 The local Diffie-Hellman key and the nonce I are the ones that 4105 were sent earlier in the R1 packet. 4107 6. If the system's state machine is in the I1-SENT state, and the 4108 HITs in the I2 packet match those used in the previously sent I1 4109 packet, the system uses this received I2 packet as the basis for 4110 the HIP association it was trying to form, and stops 4111 retransmitting I1 packets (provided that the I2 packet passes 4112 the below additional checks). 4114 7. If the system's state machine is in any other state than R2- 4115 SENT, the system SHOULD check that the echoed R1 generation 4116 counter in the I2 packet is within the acceptable range. 4117 Implementations MUST accept puzzles from the current generation 4118 and MAY accept puzzles from earlier generations. If the 4119 generation counter in the newly received I2 packet is outside 4120 the accepted range, the I2 packet is stale (and perhaps 4121 replayed) and SHOULD be dropped. 4123 8. The system MUST validate the solution to the puzzle by computing 4124 the hash described in Section 5.3.3 using the same RHASH 4125 algorithm. 4127 9. The I2 packet MUST have a single value in the HIP_CIPHER 4128 parameter, which MUST match one of the values offered to the 4129 Initiator in the R1 packet. 4131 10. The system must derive Diffie-Hellman keying material Kij based 4132 on the public value and Group ID in the DIFFIE_HELLMAN 4133 parameter. This key is used to derive the HIP association keys, 4134 as described in Section 6.5. If the Diffie-Hellman Group ID is 4135 unsupported, the I2 packet is silently dropped. 4137 11. The encrypted HOST_ID is decrypted by the Initiator's encryption 4138 key defined in Section 6.5. If the decrypted data is not a 4139 HOST_ID parameter, the I2 packet is silently dropped. 4141 12. The implementation SHOULD also verify that the Initiator's HIT 4142 in the I2 packet corresponds to the Host Identity sent in the 4143 packet I2. (Note: some middleboxes may not able to make this 4144 verification.) 4146 13. The system MUST verify the HMAC according to the procedures in 4147 Section 5.2.11. 4149 14. The system MUST verify the HIP_SIGNATURE according to 4150 Section 5.2.13 and Section 5.3.3. 4152 15. If the checks above are valid, then the system proceeds with 4153 further I2 processing; otherwise, it discards the I2 and its 4154 state machine remains in the same state. 4156 16. The I2 packet may have the A bit set -- in this case, the system 4157 MAY choose to refuse it by dropping the I2 and the state machine 4158 returns to state UNASSOCIATED. If the A bit is set, the 4159 Initiator's HIT is anonymous and should not be stored 4160 permanently. 4162 17. The system initializes the remaining variables in the associated 4163 state, including Update ID counters. 4165 18. Upon successful processing of an I2 message when the system's 4166 state machine is in state UNASSOCIATED, I1-SENT, I2-SENT, or R2- 4167 SENT, an R2 packet is sent and the system's state machine 4168 transitions to state R2-SENT. 4170 19. Upon successful processing of an I2 packet when the system's 4171 state machine is in state ESTABLISHED, the old HIP association 4172 is dropped and a new one is installed, an R2 packet is sent, and 4173 the system's state machine transitions to R2-SENT. 4175 20. Upon the system's state machine transitioning to R2-SENT, the 4176 system starts a timer. The state machine transitions to 4177 ESTABLISHED if some data has been received on the incoming HIP 4178 association, or an UPDATE packet has been received (or some 4179 other packet that indicates that the peer system's state machine 4180 has moved to ESTABLISHED). If the timer expires (allowing for 4181 maximal retransmissions of I2 packets), the state machine 4182 transitions to ESTABLISHED. 4184 6.9.1. Handling of Malformed Messages 4186 If an implementation receives a malformed I2 message, the behavior 4187 SHOULD depend on how many checks the message has already passed. If 4188 the puzzle solution in the message has already been checked, the 4189 implementation SHOULD report the error by responding with a NOTIFY 4190 packet. Otherwise, the implementation MAY respond with an ICMP 4191 message as defined in Section 5.4. 4193 6.10. Processing of Incoming R2 Packets 4195 An R2 packet received in states UNASSOCIATED, I1-SENT, or ESTABLISHED 4196 results in the R2 packet being dropped and the state machine staying 4197 in the same state. If an R2 packet is received in state I2-SENT, it 4198 SHOULD be processed. 4200 The following steps define the conceptual processing rules for an 4201 incoming R2 packet: 4203 1. If the system is in any other state than I2-SENT, the R2 packet 4204 is silently dropped. 4206 2. The system MUST verify that the HITs in use correspond to the 4207 HITs that were received in the R1 packet. 4209 3. The system MUST verify the HIP_MAC_2 according to the procedures 4210 in Section 5.2.12. 4212 4. The system MUST verify the HIP signature according to the 4213 procedures in Section 5.2.13. 4215 5. If any of the checks above fail, there is a high probability of 4216 an ongoing man-in-the-middle or other security attack. The 4217 system SHOULD act accordingly, based on its local policy. 4219 6. Upon successful processing of the R2 packet, the state machine 4220 transitions to state ESTABLISHED. 4222 6.11. Sending UPDATE Packets 4224 A host sends an UPDATE packet when it intends to update some 4225 information related to a HIP association. There are a number of 4226 possible scenarios when this can occur, e.g., mobility management and 4227 rekeying of an existing ESP Security Association. The following 4228 paragraphs define the conceptual rules for sending an UPDATE packet 4229 to the peer. Additional steps can be defined in other documents 4230 where the UPDATE packet is used. 4232 The sequence of UPDATE messages is indicated by their SEQ parameter. 4233 Before sending an UPDATE message, the system first determines whether 4234 there are any outstanding UPDATE messages that may conflict with the 4235 new UPDATE message under consideration. When multiple UPDATEs are 4236 outstanding (not yet acknowledged), the sender must assume that such 4237 UPDATEs may be processed in an arbitrary order by the receiver. 4238 Therefore, any new UPDATEs that depend on a previous outstanding 4239 UPDATE being successfully received and acknowledged MUST be postponed 4240 until reception of the necessary ACK(s) occurs. One way to prevent 4241 any conflicts is to only allow one outstanding UPDATE at a time. 4242 However, allowing multiple UPDATEs may improve the performance of 4243 mobility and multihoming protocols. 4245 The following steps define the conceptual processing rules for 4246 sending UPDATE packets. 4248 1. The first UPDATE packet is sent with Update ID of zero. 4249 Otherwise, the system increments its own Update ID value by one 4250 before continuing the steps below . 4252 2. The system creates an UPDATE packet that contains a SEQ parameter 4253 with the current value of Update ID. The UPDATE packet MAY also 4254 include an ACK of the peer's Update ID found in a received UPDATE 4255 SEQ parameter, if any. 4257 3. The system sends the created UPDATE packet and starts an UPDATE 4258 timer. The default value for the timer is 2 * RTT estimate. If 4259 multiple UPDATEs are outstanding, multiple timers are in effect. 4261 4. If the UPDATE timer expires, the UPDATE is resent. The UPDATE 4262 can be resent UPDATE_RETRY_MAX times. The UPDATE timer SHOULD be 4263 exponentially backed off for subsequent retransmissions. If no 4264 acknowledgment is received from the peer after UPDATE_RETRY_MAX 4265 times, the HIP association is considered to be broken and the 4266 state machine should move from state ESTABLISHED to state CLOSING 4267 as depicted in Section 4.4.4. The UPDATE timer is cancelled upon 4268 receiving an ACK from the peer that acknowledges receipt of the 4269 UPDATE. 4271 6.12. Receiving UPDATE Packets 4273 When a system receives an UPDATE packet, its processing depends on 4274 the state of the HIP association and the presence and values of the 4275 SEQ and ACK parameters. Typically, an UPDATE message also carries 4276 optional parameters whose handling is defined in separate documents. 4278 For each association, a host stores the peer's next expected in- 4279 sequence Update ID ("peer Update ID"). Initially, this value is 4280 zero. Update ID comparisons of "less than" and "greater than" are 4281 performed with respect to a circular sequence number space. Hence, a 4282 wrap around after 2^32 updates has to be expected and must be handled 4283 accordingly. 4285 The sender may send multiple outstanding UPDATE messages. These 4286 messages are processed in the order in which they are received at the 4287 receiver (i.e., no re-sequencing is performed). When processing 4288 UPDATEs out-of-order, the receiver MUST keep track of which UPDATEs 4289 were previously processed, so that duplicates or retransmissions are 4290 ACKed and not reprocessed. A receiver MAY choose to define a receive 4291 window of Update IDs that it is willing to process at any given time, 4292 and discard received UPDATEs falling outside of that window. 4294 The following steps define the conceptual processing rules for 4295 receiving UPDATE packets. 4297 1. If there is no corresponding HIP association, the implementation 4298 MAY reply with an ICMP Parameter Problem, as specified in 4299 Section 5.4.4. 4301 2. If the association is in the ESTABLISHED state and the SEQ (but 4302 not ACK) parameter is present, the UPDATE is processed and 4303 replied to as described in Section 6.12.1. 4305 3. If the association is in the ESTABLISHED state and the ACK (but 4306 not SEQ) parameter is present, the UPDATE is processed as 4307 described in Section 6.12.2. 4309 4. If the association is in the ESTABLISHED state and there is both 4310 an ACK and SEQ in the UPDATE, the ACK is first processed as 4311 described in Section 6.12.2, and then the rest of the UPDATE is 4312 processed as described in Section 6.12.1. 4314 6.12.1. Handling a SEQ Parameter in a Received UPDATE Message 4316 The following steps define the conceptual processing rules for 4317 handling a SEQ parameter in a received UPDATE packet. 4319 1. If the Update ID in the received SEQ is not the next in the 4320 sequence of Update IDs and is greater than the receiver's window 4321 for new UPDATEs, the packet MUST be dropped. 4323 2. If the Update ID in the received SEQ corresponds to an UPDATE 4324 that has recently been processed, the packet is treated as a 4325 retransmission. The HIP_MAC verification (next step) MUST NOT be 4326 skipped. (A byte-by-byte comparison of the received and a stored 4327 packet would be acceptable, though.) It is recommended that a 4328 host caches UPDATE packets sent with ACKs to avoid the cost of 4329 generating a new ACK packet to respond to a replayed UPDATE. The 4330 system MUST acknowledge, again, such (apparent) UPDATE message 4331 retransmissions but SHOULD also consider rate-limiting such 4332 retransmission responses to guard against replay attacks. 4334 3. The system MUST verify the HIP_MAC in the UPDATE packet. If the 4335 verification fails, the packet MUST be dropped. 4337 4. The system MAY verify the SIGNATURE in the UPDATE packet. If the 4338 verification fails, the packet SHOULD be dropped and an error 4339 message logged. 4341 5. If a new SEQ parameter is being processed, the parameters in the 4342 UPDATE are then processed. The system MUST record the Update ID 4343 in the received SEQ parameter, for replay protection. 4345 6. An UPDATE acknowledgment packet with ACK parameter is prepared 4346 and sent to the peer. This ACK parameter may be included in a 4347 separate UPDATE or piggybacked in an UPDATE with SEQ parameter, 4348 as described in Section 5.3.5. The ACK parameter MAY acknowledge 4349 more than one of the peer's Update IDs. 4351 6.12.2. Handling an ACK Parameter in a Received UPDATE Packet 4353 The following steps define the conceptual processing rules for 4354 handling an ACK parameter in a received UPDATE packet. 4356 1. The sequence number reported in the ACK must match with an UPDATE 4357 packet sent earlier that has not already been acknowledged. If 4358 no match is found or if the ACK does not acknowledge a new 4359 UPDATE, the packet MUST either be dropped if no SEQ parameter is 4360 present, or the processing steps in Section 6.12.1 are followed. 4362 2. The system MUST verify the HIP_MAC in the UPDATE packet. If the 4363 verification fails, the packet MUST be dropped. 4365 3. The system MAY verify the SIGNATURE in the UPDATE packet. If the 4366 verification fails, the packet SHOULD be dropped and an error 4367 message logged. 4369 4. The corresponding UPDATE timer is stopped (see Section 6.11) so 4370 that the now acknowledged UPDATE is no longer retransmitted. If 4371 multiple UPDATEs are newly acknowledged, multiple timers are 4372 stopped. 4374 6.13. Processing of NOTIFY Packets 4376 Processing of NOTIFY packets is OPTIONAL. If processed, any errors 4377 in a received NOTIFICATION parameter SHOULD be logged. Received 4378 errors MUST be considered only as informational, and the receiver 4379 SHOULD NOT change its HIP state (see Section 4.4.2) purely based on 4380 the received NOTIFY message. 4382 6.14. Processing CLOSE Packets 4384 When the host receives a CLOSE message, it responds with a CLOSE_ACK 4385 message and moves to CLOSED state. (The authenticity of the CLOSE 4386 message is verified using both HIP_MAC and SIGNATURE). This 4387 processing applies whether or not the HIP association state is 4388 CLOSING in order to handle simultaneous CLOSE messages from both ends 4389 that cross in flight. 4391 The HIP association is not discarded before the host moves from the 4392 UNASSOCIATED state. 4394 Once the closing process has started, any new need to send data 4395 packets triggers creating and establishing of a new HIP association, 4396 starting with sending of an I1 packet. 4398 If there is no corresponding HIP association, the CLOSE packet is 4399 dropped. 4401 6.15. Processing CLOSE_ACK Packets 4403 When a host receives a CLOSE_ACK message, it verifies that it is in 4404 CLOSING or CLOSED state and that the CLOSE_ACK was in response to the 4405 CLOSE. A host can map CLOSE messages to CLOSE_ACK messages by using 4406 the included ECHO_RESPONSE_SIGNED in response to the sent 4407 ECHO_REQUEST_SIGNED in the CLOSE_ACK. 4409 The CLOSE_ACK contains the HIP_MAC and the SIGNATURE for 4410 verification. The state is discarded when the state changes to 4411 UNASSOCIATED and, after that, the host MAY respond with an ICMP 4412 Parameter Problem to an incoming CLOSE message (see Section 5.4.4). 4414 6.16. Handling State Loss 4416 In the case of a system crash and unanticipated state loss, the 4417 system SHOULD delete the corresponding HIP state, including the 4418 keying material. That is, the state SHOULD NOT be stored on long- 4419 term storage. If the implementation does drop the state (as 4420 RECOMMENDED), it MUST also drop the peer's R1 generation counter 4421 value, unless a local policy explicitly defines that the value of 4422 that particular host is stored. An implementation MUST NOT store a 4423 peer's R1 generation counters by default, but storing R1 generation 4424 counter values, if done, MUST be configured by explicit HITs. 4426 7. HIP Policies 4428 There are a number of variables that will influence the HIP exchanges 4429 that each host must support. All HIP implementations MUST support 4430 more than one simultaneous HI, at least one of which SHOULD be 4431 reserved for anonymous usage. Although anonymous HIs will be rarely 4432 used as Responders' HIs, they will be common for Initiators. Support 4433 for more than two HIs is RECOMMENDED. 4435 Initiators may use a different HI for different Responders to provide 4436 basic privacy. Such implementations SHOULD keep state for mapping 4437 Initiator's HIT to Responder's HIT. This ACL SHOULD also include 4438 preferred transform and local lifetimes. 4440 The value of K used in the HIP R1 packet can also vary by policy. K 4441 should never be greater than 20, but for trusted partners it could be 4442 as low as 0. 4444 Responders that only respond to selected Initiators require an ACL, 4445 representing which hosts they accept HIP exchanges, and the preferred 4446 transform and local lifetimes. Wildcarding SHOULD be supported for 4447 such ACL also for Responders that offer public or anonymous services. 4449 8. Changes from RFC 5201 4451 This section summarizes the changes made from [RFC5201]. 4453 8.1. Changes from draft-ietf-hip-rfc5201-bis-03 4455 o Editorial changes to improve clarity and readability. 4457 o Removed obsoleted (not applicable) attack from security 4458 consideration section. 4460 o Added a requirement that hosts MUST support processing of ACK 4461 parameters with several SEQ numbers even when they do not support 4462 sending such parameters. 4464 o Removed note on memory bound puzzles. The use of memory bound 4465 puzzles was reconsidered but no convincing arguments for inclusion 4466 in this document have been made on the list. 4468 o Changed references to reference the new bis documents. 4470 o Specified the ECC curves and the hashes used for these. 4472 o Specified representation of ECC curves in the HI. 4474 o Added text on the dependency between RHASH and HMAC. 4476 o Rephrased part of the security considerations to make them 4477 clearer. 4479 o Clarified the use of HITs in opportunistic mode. 4481 o Clarified the difference between HIP_MAC and HIP_MAC_2 as well as 4482 between SIGNATURE and SIGNATURE_2. 4484 o Changed NOTIFY name for value 44 from SERVER_BUSY_PLEASE_RETRY to 4485 RESPONDER_BUSY_PLEASE_RETRY. 4487 o Mentioned that there are multiple valid puzzle solutions. 4489 8.2. Changes from draft-ietf-hip-rfc5201-bis-02 4491 o Added recommendation to not use puzzle I twice for the same host 4492 to avoid identical key material. 4494 o Revised state machine and added missing event handling. 4496 o Added UNSUPPORTED_HIT_SUITE to NOTIFY to indicate unsupported HIT 4497 suites. 4499 o Revised parameter type numbers (corresponding to IANA allocations) 4500 and added missing "free for experimentation" range to the 4501 description. 4503 o Clarifying note on the use of the C bit in the parameter type 4504 numbers. 4506 8.3. Changes from draft-ietf-hip-rfc5201-bis-01 4508 o Changed RHASH-len to RHASH_len to avoid confusion in calculations 4509 (- could be minus) 4511 o Added RHASH_len to list of abbreviations 4513 o Fixed length of puzzle I and J to be 1*RHASH_len 4515 o Changed RHASH-len to RHASH_len to avoid confusion in calculations 4516 (- could be minus) 4518 o Added RHASH_len to list of abbreviations 4520 o Fixed length of puzzle I and J to be 1*RHASH_len 4522 o Included HIT_SUITEs. 4524 o Added DH negotiation to I1 and R1. 4526 o Added DH_LIST parameter. 4528 o Added text for DH Group negotiation. 4530 o Removed second DH public value from DH parameter. 4532 o Added ECC to HI generation. 4534 o Added Responder HIT selection to opportunistic mode. 4536 o Added ECDSA HI text and references (not complete yet). 4538 o Added separate section on aborting BEX. 4540 o Added separate section on downgrade attack prevention. 4542 o Added text about DH Group selection for use cases without I1. 4544 o Removed type range allocation for parameters related to HIP 4545 transform types. 4547 o New type range allocation for parameters that are only covered by 4548 a signature if a signature is present (Applies to DH_GROUP_LIST). 4550 o Renamed HIP_TRANSFORM to HIP_CIPHER and removed hashes from it - 4551 hashes are determined by RHASH. 4553 o The length of I and J for the puzzle now depends on RHASH. 4555 o New keymat generation. 4557 o Puzzle seed and solution now use RHASH and have variable length. 4559 o Moved timing definitions closer to state machine. 4561 o Simplified text regarding puzzle lifetime. 4563 o Clarified the description of the use of I in the puzzle 4565 o Removed "Opportunistic mode" description from general definitions. 4567 o More consistency across the old RFC5201 text. Aligned 4568 capitalization and abbreviations. 4570 o Extended protocol overview to include restart option. 4572 o Extended state machine to include restart option because of 4573 unsupported Algorithms. 4575 o Replaced SHA-1 with SHA-256 for required implementation. 4577 o Added OGA list parameter (715) for detecting the Responder's set 4578 of OGAs. 4580 o Added Appendix on ORCHID use in HITs. 4582 o Added truncated SHA-256 option for HITs. 4584 o Added truncated SHA-1 option for HITs. 4586 o Added text about new ORCHID structure to HIT overview. 4588 o Moved Editor role to Robert Moskowitz. 4590 o Added SHA-256 to puzzle parameter. 4592 o Generalized LTRUNC to be hash-function agnostic. 4594 o Added text about RHASH depending on OGA. 4596 8.4. Changes from draft-ietf-hip-rfc5201-bis-00 4598 o Added reasoning why BIS document is needed. 4600 8.5. Contents of draft-ietf-hip-rfc5201-bis-00 4602 o RFC5201 was submitted as draft-RFC. 4604 9. Security Considerations 4606 HIP is designed to provide secure authentication of hosts. HIP also 4607 attempts to limit the exposure of the host to various denial-of- 4608 service and man-in-the-middle (MitM) attacks. In doing so, HIP 4609 itself is subject to its own DoS and MitM attacks that potentially 4610 could be more damaging to a host's ability to conduct business as 4611 usual. 4613 Denial-of-service attacks often take advantage of asymmetries in the 4614 cost of an starting an association. One example of such asymmetry is 4615 the need of a Responder to store local state while a malicious 4616 Initiator can stay stateless. HIP makes no attempt to increase the 4617 cost of the start of state at the Initiator, but makes an effort to 4618 reduce the cost for the Responder. This is accomplished by having 4619 the Responder start the 3-way exchange instead of the Initiator, 4620 making the HIP protocol 4 packets long. In doing this, the first 4621 packet from the Responder, R1, becomes a 'stock' packet that the 4622 Responder MAY use many times, until some Initiator has provided a 4623 valid response to such an R1 packet. During an I1 packet storm, the 4624 host may reuse the same DH value also even if some Initiator has 4625 provided a valid response using that particular DH value. However, 4626 such behavior is discouraged and should be avoided. Using the same 4627 Diffie-Hellman values and random puzzle #I value has some risks. 4628 This risk needs to be balanced against a potential storm of HIP I1 4629 packets. 4631 This shifting of the start of state cost to the Initiator in creating 4632 the I2 HIP packet presents another DoS attack. The attacker can 4633 spoof the I1 packet and the Responder sends out the R1 HIP packet. 4634 This could conceivably tie up the 'Initiator' with evaluating the R1 4635 HIP packet, and creating the I2 packet. The defense against this 4636 attack is to simply ignore any R1 packet where a corresponding I1 4637 packet was not sent (as defined in Section 6.8 step 1). 4639 A second form of DoS attack arrives in the I2 HIP packet. Once the 4640 attacking Initiator has solved the puzzle, it can send packets with 4641 spoofed IP source addresses with either an invalid encrypted HIP 4642 payload component or a bad HIP signature. This would take resources 4643 in the Responder's part to reach the point to discover that the I2 4644 packet cannot be completely processed. The defense against this 4645 attack is after N bad I2 packets, the Responder would discard any I2 4646 packets that contain the given Initiator HIT. This will shut down 4647 the attack. The attacker would have to request another R1 packet and 4648 use that to launch a new attack. The Responder could up the value of 4649 K while under attack. On the downside, valid I2 packets might get 4650 dropped too. 4652 A third form of DoS attack is emulating the restart of state after a 4653 reboot of one of the partners. A restarting host would send an I1 4654 packet to a peer, which would respond with an R1 packet even if it 4655 were in the ESTABLISHED state. If the I1 packet were spoofed, the 4656 resulting R1 packet would be received unexpectedly by the spoofed 4657 host and would be dropped, as in the first case above. 4659 A fourth form of DoS attack is emulating the end of state. HIP 4660 relies on timers plus a CLOSE/CLOSE_ACK handshake to explicitly 4661 signal the end of a HIP association. Because both CLOSE and 4662 CLOSE_ACK messages contain an HIP_MAC, an outsider cannot close a 4663 connection. The presence of an additional SIGNATURE allows 4664 middleboxes to inspect these messages and discard the associated 4665 state (for e.g., firewalling, SPI-based NATing, etc.). However, the 4666 optional behavior of replying to CLOSE with an ICMP Parameter Problem 4667 packet (as described in Section 5.4.4) might allow an IP spoofer 4668 sending CLOSE messages to launch reflection attacks. 4670 A fifth form of DoS attack is replaying R1s to cause the Initiator to 4671 solve stale puzzles and become out of synchronization with the 4672 Responder. The R1 generation counter is a monotonically increasing 4673 counter designed to protect against this attack, as described in 4674 Section 4.1.4. 4676 Man-in-the-middle attacks are difficult to defend against, without 4677 third-party authentication. A skillful MitM could easily handle all 4678 parts of HIP, but HIP indirectly provides the following protection 4679 from a MitM attack. If the Responder's HI is retrieved from a signed 4680 DNS zone, a certificate, or through some other secure means, the 4681 Initiator can use this to validate the R1 HIP packet. 4683 Likewise, if the Initiator's HI is in a secure DNS zone, a trusted 4684 certificate, or otherwise securely available, the Responder can 4685 retrieve the HI (after having got the I2 HIP packet) and verify that 4686 the HI indeed can be trusted. 4688 The HIP Opportunistic Mode concept has been introduced in this 4689 document, but this document does not specify what the semantics of 4690 such a connection setup are for applications. There are certain 4691 concerns with opportunistic mode, as discussed in Section 4.1.8. 4693 NOTIFY messages are used only for informational purposes and they are 4694 unacknowledged. A HIP implementation cannot rely solely on the 4695 information received in a NOTIFY message because the packet may have 4696 been replayed. It SHOULD NOT change any state information purely 4697 based on a received NOTIFY message. 4699 Since not all hosts will ever support HIP, ICMP 'Destination Protocol 4700 Unreachable' messages are to be expected and may be used for a DoS 4701 attack. Against an Initiator, the attack would look like the 4702 Responder does not support HIP, but shortly after receiving the ICMP 4703 message, the Initiator would receive a valid R1 HIP packet. Thus, to 4704 protect from this attack, an Initiator should not react to an ICMP 4705 message until a reasonable delta time to get the real Responder's R1 4706 HIP packet. A similar attack against the Responder is more involved. 4707 Normally, if an I1 message received by a Responder was a bogus one 4708 sent by an attacker, the Responder may receive an ICMP message from 4709 the IP address the R1 message was sent to. However, a sophisticated 4710 attacker can try to take advantage of such a behavior and try to 4711 break up the HIP exchange by sending such an ICMP message to the 4712 Responder before the Initiator has a chance to send a valid I2 4713 message. Hence, the Responder SHOULD NOT act on such an ICMP 4714 message. Especially, it SHOULD NOT remove any minimal state created 4715 when it sent the R1 HIP packet (if it did create one), but wait for 4716 either a valid I2 HIP packet or the natural timeout (that is, if R1 4717 packets are tracked at all). Likewise, the Initiator should ignore 4718 any ICMP message while waiting for an R2 HIP packet, and should 4719 delete any pending state only after a natural timeout. 4721 10. IANA Considerations 4723 IANA has reserved protocol number 139 for the Host Identity Protocol. 4725 This document defines a new 128-bit value under the CGA Message Type 4726 namespace [RFC3972], 0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA, to be 4727 used for HIT generation as specified in ORCHID 4728 [I-D.ietf-hip-rfc4843-bis]. 4730 This document also creates a set of new namespaces. These are 4731 described below. 4733 Packet Type 4735 The 7-bit Packet Type field in a HIP protocol packet describes the 4736 type of a HIP protocol message. It is defined in Section 5.1. 4737 The current values are defined in Sections 5.3.1 through 5.3.8. 4739 New values are assigned through IETF Consensus [RFC2434]. 4741 HIP Version 4743 The four-bit Version field in a HIP protocol packet describes the 4744 version of the HIP protocol. It is defined in Section 5.1. The 4745 currently defined values are 1 and 2. The version of this 4746 document is 2. New values are assigned through IETF Consensus. 4748 HIT Suite 4750 The four-bit HIT Suite ID uses the OGA field in the ORCHID to 4751 express the type of the HIT. This document defines two HIT 4752 Suites. 4754 The HIT Suite ID is also carried in the four higher-order bits of 4755 the ID field in the HIT_SUITE_LIST parameter. The four lower- 4756 order bits are reserved for future extensions of the HIT Suite ID 4757 space beyond 16 values. 4759 At the time being, the HIT Suite uses only four bits because these 4760 bits have to be carried in the HIT. Using more bits for the HIT 4761 Suite ID reduces the cryptographic strength of the HIT. HIT Suite 4762 IDs must be allocated carefully to avoid namespace exhaustion. 4763 Moreover, deprecated IDs should be reused after an appropriate 4764 time span. If 16 Suite IDs prove insufficient and more HIT Suite 4765 IDs are needed concurrently, more bits can be used for the HIT 4766 Suite ID by using one HIT Suite ID (0) to indicate that more bits 4767 should be used. The HIT_SUITE_LIST parameter already supports 4768 8-bit HIT Suite IDs, should longer IDs be needed. Possible 4769 extensions of the HIT Suite ID space to eight-bit and new HIT 4770 Suite IDs are defined through IETF consensus. 4772 Parameter Type 4774 The 16-bit Type field in a HIP parameter describes the type of the 4775 parameter. It is defined in Section 5.2.1. The current values 4776 are defined in Sections 5.2.3 through 5.2.22. 4778 With the exception of the assigned Type codes, the Type codes 0 4779 through 1023 and 61440 through 65535 are reserved for future base 4780 protocol extensions, and are assigned through IETF Consensus. 4782 The Type codes 32768 through 49151 are reserved for 4783 experimentation. Types SHOULD be selected in a random fashion 4784 from this range, thereby reducing the probability of collisions. 4785 A method employing genuine randomness (such as flipping a coin) 4786 SHOULD be used. 4788 All other Type codes are assigned through First Come First Served, 4789 with Specification Required [RFC2434]. 4791 Group ID 4793 The eight-bit Group ID values appear in the DIFFIE_HELLMAN 4794 parameter and the DH_GROUP_LIST parameter and are defined in 4795 Section 5.2.6. New values either from the reserved or unassigned 4796 space are assigned through IETF Consensus. 4798 HIP Cipher ID 4800 The 16-bit Cipher ID values in a HIP_CIPHER parameter are defined 4801 in Section 5.2.7. New values either from the reserved or 4802 unassigned space are assigned through IETF Consensus. 4804 DI-Type 4806 The four-bit DI-Type values in a HOST_ID parameter are defined in 4807 Section 5.2.8. New values are assigned through IETF Consensus. 4809 Notify Message Type 4811 The 16-bit Notify Message Type values in a NOTIFICATION parameter 4812 are defined in Section 5.2.18. 4814 Notify Message Type values 1-10 are used for informing about 4815 errors in packet structures, values 11-20 for informing about 4816 problems in parameters containing cryptographic related material, 4817 values 21-30 for informing about problems in authentication or 4818 packet integrity verification. Parameter numbers above 30 can be 4819 used for informing about other types of errors or events. Values 4820 51-8191 are error types reserved to be allocated by IANA. Values 4821 8192-16383 are error types for experimentation. Values 16385- 4822 40959 are status types to be allocated by IANA, and values 40960- 4823 65535 are status types for experimentation. New values in ranges 4824 51-8191 and 16385-40959 are assigned through First Come First 4825 Served, with Specification Required. 4827 11. Acknowledgments 4829 The drive to create HIP came to being after attending the MALLOC 4830 meeting at the 43rd IETF meeting. Baiju Patel and Hilarie Orman 4831 really gave the original author, Bob Moskowitz, the assist to get HIP 4832 beyond 5 paragraphs of ideas. It has matured considerably since the 4833 early versions thanks to extensive input from IETFers. Most 4834 importantly, its design goals are articulated and are different from 4835 other efforts in this direction. Particular mention goes to the 4836 members of the NameSpace Research Group of the IRTF. Noel Chiappa 4837 provided valuable input at early stages of discussions about 4838 identifier handling and Keith Moore the impetus to provide 4839 resolvability. Steve Deering provided encouragement to keep working, 4840 as a solid proposal can act as a proof of ideas for a research group. 4842 Many others contributed; extensive security tips were provided by 4843 Steve Bellovin. Rob Austein kept the DNS parts on track. Paul 4844 Kocher taught Bob Moskowitz how to make the puzzle exchange expensive 4845 for the Initiator to respond, but easy for the Responder to validate. 4846 Bill Sommerfeld supplied the Birthday concept, which later evolved 4847 into the R1 generation counter, to simplify reboot management. Erik 4848 Nordmark supplied the CLOSE-mechanism for closing connections. 4849 Rodney Thayer and Hugh Daniels provided extensive feedback. In the 4850 early times of this document, John Gilmore kept Bob Moskowitz 4851 challenged to provide something of value. 4853 During the later stages of this document, when the editing baton was 4854 transferred to Pekka Nikander, the input from the early implementors 4855 was invaluable. Without having actual implementations, this document 4856 would not be on the level it is now. 4858 In the usual IETF fashion, a large number of people have contributed 4859 to the actual text or ideas. The list of these people include Jeff 4860 Ahrenholz, Francis Dupont, Derek Fawcus, George Gross, Andrew 4861 McGregor, Julien Laganier, Miika Komu, Mika Kousa, Jan Melen, Henrik 4862 Petander, Michael Richardson, Rene Hummen, Tim Shepard, Jorma Wall, 4863 and Jukka Ylitalo. Our apologies to anyone whose name is missing. 4865 Once the HIP Working Group was founded in early 2004, a number of 4866 changes were introduced through the working group process. Most 4867 notably, the original document was split in two, one containing the 4868 base exchange and the other one defining how to use ESP. Some 4869 modifications to the protocol proposed by Aura, et al., [AUR03] were 4870 added at a later stage. 4872 12. References 4874 12.1. Normative References 4876 [FIPS.180-2.2002] National Institute of Standards and 4877 Technology, "Secure Hash Standard", 4878 FIPS PUB 180-2, August 2002, . 4882 [FIPS.95-1.1993] National Institute of Standards and 4883 Technology, "Codes for the 4884 Identification of Federal and Federally 4885 Assisted Organizations", FIPS PUB 95-1, 4886 January 1993. 4888 [I-D.ietf-hip-rfc4843-bis] Laganier, J. and F. Dupont, "An IPv6 4889 Prefix for Overlay Routable 4890 Cryptographic Hash Identifiers 4891 (ORCHID)", 4892 draft-ietf-hip-rfc4843-bis-00 (work in 4893 progress), August 2010. 4895 [I-D.ietf-hip-rfc5202-bis] Jokela, P., Moskowitz, R., Nikander, 4896 P., and J. Melen, "Using the 4897 Encapsulating Security Payload (ESP) 4898 Transport Format with the Host Identity 4899 Protocol (HIP)", 4900 draft-ietf-hip-rfc5202-bis-00 (work in 4901 progress), September 2010. 4903 [I-D.mcgrew-fundamental-ecc] McGrew, D., Igoe, K., and M. Salter, 4904 "Fundamental Elliptic Curve 4905 Cryptography Algorithms", 4906 draft-mcgrew-fundamental-ecc-03 (work 4907 in progress), May 2010. 4909 [RFC0768] Postel, J., "User Datagram Protocol", 4910 STD 6, RFC 768, August 1980. 4912 [RFC1035] Mockapetris, P., "Domain names - 4913 implementation and specification", 4914 STD 13, RFC 1035, November 1987. 4916 [RFC2119] Bradner, S., "Key words for use in RFCs 4917 to Indicate Requirement Levels", 4918 BCP 14, RFC 2119, March 1997. 4920 [RFC2404] Madson, C. and R. Glenn, "The Use of 4921 HMAC-SHA-1-96 within ESP and AH", 4922 RFC 2404, November 1998. 4924 [RFC2451] Pereira, R. and R. Adams, "The ESP CBC- 4925 Mode Cipher Algorithms", RFC 2451, 4926 November 1998. 4928 [RFC2460] Deering, S. and R. Hinden, "Internet 4929 Protocol, Version 6 (IPv6) 4930 Specification", RFC 2460, 4931 December 1998. 4933 [RFC2463] Conta, A. and S. Deering, "Internet 4934 Control Message Protocol (ICMPv6) for 4935 the Internet Protocol Version 6 (IPv6) 4936 Specification", RFC 2463, 4937 December 1998. 4939 [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the 4940 Domain Name System (DNS)", RFC 2536, 4941 March 1999. 4943 [RFC2898] Kaliski, B., "PKCS #5: Password-Based 4944 Cryptography Specification Version 4945 2.0", RFC 2898, September 2000. 4947 [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA 4948 KEYs in the Domain Name System (DNS)", 4949 RFC 3110, May 2001. 4951 [RFC3484] Draves, R., "Default Address Selection 4952 for Internet Protocol version 6 4953 (IPv6)", RFC 3484, February 2003. 4955 [RFC3526] Kivinen, T. and M. Kojo, "More Modular 4956 Exponential (MODP) Diffie-Hellman 4957 groups for Internet Key Exchange 4958 (IKE)", RFC 3526, May 2003. 4960 [RFC3602] Frankel, S., Glenn, R., and S. Kelly, 4961 "The AES-CBC Cipher Algorithm and Its 4962 Use with IPsec", RFC 3602, 4963 September 2003. 4965 [RFC3972] Aura, T., "Cryptographically Generated 4966 Addresses (CGA)", RFC 3972, March 2005. 4968 [RFC4034] Arends, R., Austein, R., Larson, M., 4969 Massey, D., and S. Rose, "Resource 4970 Records for the DNS Security 4971 Extensions", RFC 4034, March 2005. 4973 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and 4974 P. Eronen, "The Network Access 4975 Identifier", RFC 4282, December 2005. 4977 [RFC4753] Fu, D. and J. Solinas, "ECP Groups For 4978 IKE and IKEv2", RFC 4753, January 2007. 4980 [RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 4981 Authentication Using the Elliptic Curve 4982 Digital Signature Algorithm (ECDSA)", 4983 RFC 4754, January 2007. 4985 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC- 4986 SHA-256, HMAC-SHA-384, and HMAC-SHA-512 4987 with IPsec", RFC 4868, May 2007. 4989 [RFC5201] Moskowitz, R., Nikander, P., Jokela, 4990 P., and T. Henderson, "Host Identity 4991 Protocol", RFC 5201, April 2008. 4993 [RFC5702] Jansen, J., "Use of SHA-2 Algorithms 4994 with RSA in DNSKEY and RRSIG Resource 4995 Records for DNSSEC", RFC 5702, 4996 October 2009. 4998 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based 4999 Extract-and-Expand Key Derivation 5000 Function (HKDF)", RFC 5869, May 2010. 5002 12.2. Informative References 5004 [AUR03] Aura, T., Nagarajan, A., and A. Gurtov, 5005 "Analysis of the HIP Base Exchange 5006 Protocol", in Proceedings of 10th 5007 Australasian Conference on Information 5008 Security and Privacy, July 2003. 5010 [CRO03] Crosby, SA. and DS. Wallach, "Denial of 5011 Service via Algorithmic Complexity 5012 Attacks", in Proceedings of Usenix 5013 Security Symposium 2003, Washington, 5014 DC., August 2003. 5016 [DIF76] Diffie, W. and M. Hellman, "New 5017 Directions in Cryptography", IEEE 5018 Transactions on Information Theory vol. 5019 IT-22, number 6, pages 644-654, 5020 Nov 1976. 5022 [FIPS.197.2001] National Institute of Standards and 5023 Technology, "Advanced Encryption 5024 Standard (AES)", FIPS PUB 197, 5025 November 2001, . 5029 [I-D.ietf-btns-c-api] Richardson, M., Williams, N., Komu, M., 5030 and S. Tarkoma, "C-Bindings for IPsec 5031 Application Programming Interfaces", 5032 draft-ietf-btns-c-api-04 (work in 5033 progress), March 2009. 5035 [I-D.ietf-hip-rfc4423-bis] Moskowitz, R., "Host Identity Protocol 5036 Architecture", 5037 draft-ietf-hip-rfc4423-bis-01 (work in 5038 progress), August 2010. 5040 [I-D.ietf-hip-rfc5204-bis] Laganier, J. and L. Eggert, "Host 5041 Identity Protocol (HIP) Rendezvous 5042 Extension", 5043 draft-ietf-hip-rfc5204-bis-00 (work in 5044 progress), August 2010. 5046 [I-D.ietf-hip-rfc5205-bis] Laganier, J., "Host Identity Protocol 5047 (HIP) Domain Name System (DNS) 5048 Extension", 5049 draft-ietf-hip-rfc5205-bis-00 (work in 5050 progress), August 2010. 5052 [I-D.ietf-hip-rfc5206-bis] Nikander, P., Henderson, T., Vogt, C., 5053 and J. Arkko, "Host Mobility with the 5054 Host Identity Protocol", 5055 draft-ietf-hip-rfc5206-bis-01 (work in 5056 progress), October 2010. 5058 [KAU03] Kaufman, C., Perlman, R., and B. 5059 Sommerfeld, "DoS protection for UDP- 5060 based protocols", ACM Conference on 5061 Computer and Communications Security , 5062 Oct 2003. 5064 [KRA03] Krawczyk, H., "SIGMA: The 'SIGn-and- 5065 MAc' Approach to Authenticated Diffie- 5066 Hellman and Its Use in the IKE- 5067 Protocols", in Proceedings of CRYPTO 5068 2003, pages 400-425, August 2003. 5070 [RFC0792] Postel, J., "Internet Control Message 5071 Protocol", STD 5, RFC 792, 5072 September 1981. 5074 [RFC2434] Narten, T. and H. Alvestrand, 5075 "Guidelines for Writing an IANA 5076 Considerations Section in RFCs", 5077 BCP 26, RFC 2434, October 1998. 5079 [RFC4306] Kaufman, C., "Internet Key Exchange 5080 (IKEv2) Protocol", RFC 4306, 5081 December 2005. 5083 [RFC5338] Henderson, T., Nikander, P., and M. 5084 Komu, "Using the Host Identity Protocol 5085 with Legacy Applications", RFC 5338, 5086 September 2008. 5088 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: 5089 Level 3 Multihoming Shim Protocol for 5090 IPv6", RFC 5533, June 2009. 5092 [SECG] SECG, "Recommended Elliptic Curve 5093 Domain Parameters", SEC 2 , 2000, 5094 . 5096 Appendix A. Using Responder Puzzles 5098 As mentioned in Section 4.1.1, the Responder may delay state creation 5099 and still reject most spoofed I2 packets by using a number of pre- 5100 calculated R1 packets and a local selection function. This appendix 5101 defines one possible implementation in detail. The purpose of this 5102 appendix is to give the implementors an idea on how to implement the 5103 mechanism. If the implementation is based on this appendix, it MAY 5104 contain some local modification that makes an attacker's task harder. 5106 The Responder creates a secret value S, that it regenerates 5107 periodically. The Responder needs to remember the two latest values 5108 of S. Each time the S is regenerated, the R1 generation counter 5109 value is incremented by one. 5111 The Responder generates a pre-signed R1 packet. The signature for 5112 pre-generated R1s must be recalculated when the Diffie-Hellman key is 5113 recomputed or when the R1_COUNTER value changes due to S value 5114 regeneration. 5116 When the Initiator sends the I1 packet for initializing a connection, 5117 the Responder receives the HIT and IP address from the packet, and 5118 generates an I value for the puzzle. The I value is set to the pre- 5119 signed R1 packet. 5121 I value calculation: 5122 I = Ltrunc( RHASH ( S | HIT-I | HIT-R | IP-I | IP-R ), n) 5123 where n = RHASH_len 5125 The RHASH algorithm is the same that is used to generate the 5126 Responder's HIT value. 5128 From an incoming I2 packet, the Responder receives the required 5129 information to validate the puzzle: HITs, IP addresses, and the 5130 information of the used S value from the R1_COUNTER. Using these 5131 values, the Responder can regenerate the I, and verify it against the 5132 I received in the I2 packet. If the I values match, it can verify 5133 the solution using I, J, and difficulty K. If the I values do not 5134 match, the I2 is dropped. 5136 puzzle_check: 5137 V := Ltrunc( RHASH( I2.I | I2.hit_i | I2.hit_r | I2.J ), K ) 5138 if V != 0, drop the packet 5140 If the puzzle solution is correct, the I and J values are stored for 5141 later use. They are used as input material when keying material is 5142 generated. 5144 Keeping state about failed puzzle solutions depends on the 5145 implementation. Although it is possible for the Responder not to 5146 keep any state information, it still may do so to protect itself 5147 against certain attacks (see Section 4.1.1). 5149 Appendix B. Generating a Public Key Encoding from an HI 5151 The following pseudo-code illustrates the process to generate a 5152 public key encoding from an HI for both RSA and DSA. 5154 The symbol := denotes assignment; the symbol += denotes appending. 5155 The pseudo-function encode_in_network_byte_order takes two 5156 parameters, an integer (bignum) and a length in bytes, and returns 5157 the integer encoded into a byte string of the given length. 5159 switch ( HI.algorithm ) 5160 { 5162 case RSA: 5163 buffer := encode_in_network_byte_order ( HI.RSA.e_len, 5164 ( HI.RSA.e_len > 255 ) ? 3 : 1 ) 5165 buffer += encode_in_network_byte_order ( HI.RSA.e, HI.RSA.e_len ) 5166 buffer += encode_in_network_byte_order ( HI.RSA.n, HI.RSA.n_len ) 5167 break; 5169 case DSA: 5170 buffer := encode_in_network_byte_order ( HI.DSA.T , 1 ) 5171 buffer += encode_in_network_byte_order ( HI.DSA.Q , 20 ) 5172 buffer += encode_in_network_byte_order ( HI.DSA.P , 64 + 5173 8 * HI.DSA.T ) 5174 buffer += encode_in_network_byte_order ( HI.DSA.G , 64 + 5175 8 * HI.DSA.T ) 5176 buffer += encode_in_network_byte_order ( HI.DSA.Y , 64 + 5177 8 * HI.DSA.T ) 5178 break; 5180 } 5182 Appendix C. Example Checksums for HIP Packets 5184 The HIP checksum for HIP packets is specified in Section 5.1.1. 5185 Checksums for TCP and UDP packets running over HIP-enabled security 5186 associations are specified in Section 3.5. The examples below use IP 5187 addresses of 192.168.0.1 and 192.168.0.2 (and their respective IPv4- 5188 compatible IPv6 formats), and HITs with the prefix of 2001:10 5189 followed by zeros, followed by a decimal 1 or 2, respectively. 5191 The following example is defined only for testing the checksum 5192 calculation. The address format for the IPv4-compatible IPv6 address 5193 is not a valid one, but using these IPv6 addresses when testing an 5194 IPv6 implementation gives the same checksum output as an IPv4 5195 implementation with the corresponding IPv4 addresses. 5197 C.1. IPv6 HIP Example (I1 packet) 5199 Source Address: ::192.168.0.1 5200 Destination Address: ::192.168.0.2 5201 Upper-Layer Packet Length: 40 0x28 5202 Next Header: 139 0x8b 5203 Payload Protocol: 59 0x3b 5204 Header Length: 4 0x4 5205 Packet Type: 1 0x1 5206 Version: 1 0x1 5207 Reserved: 1 0x1 5208 Control: 0 0x0 5209 Checksum: 446 0x1be 5210 Sender's HIT : 2001:10::1 5211 Receiver's HIT: 2001:10::2 5213 C.2. IPv4 HIP Packet (I1 packet) 5215 The IPv4 checksum value for the same example I1 packet is the same as 5216 the IPv6 checksum (since the checksums due to the IPv4 and IPv6 5217 pseudo-header components are the same). 5219 C.3. TCP Segment 5221 Regardless of whether IPv6 or IPv4 is used, the TCP and UDP sockets 5222 use the IPv6 pseudo-header format [RFC2460], with the HITs used in 5223 place of the IPv6 addresses. 5225 Sender's HIT: 2001:10::1 5226 Receiver's HIT: 2001:10::2 5227 Upper-Layer Packet Length: 20 0x14 5228 Next Header: 6 0x06 5229 Source port: 65500 0xffdc 5230 Destination port: 22 0x0016 5231 Sequence number: 1 0x00000001 5232 Acknowledgment number: 0 0x00000000 5233 Header length: 20 0x14 5234 Flags: SYN 0x02 5235 Window size: 65535 0xffff 5236 Checksum: 28618 0x6fca 5237 Urgent pointer: 0 0x0000 5239 0x0000: 6000 0000 0014 0640 2001 0010 0000 0000 5240 0x0010: 0000 0000 0000 0001 2001 0010 0000 0000 5241 0x0020: 0000 0000 0000 0002 ffdc 0016 0000 0001 5242 0x0030: 0000 0000 5002 ffff 6fca 0000 5244 Appendix D. ECDH and ECDSA 160 Bit Groups 5246 The ECDH and ECDSA 160-bit group SECP160R1 is rated at 80 bits 5247 symmetric strength. Once this was considered appropriate for one 5248 year of security. Today should be used only when the host is not 5249 powerful enough (e.g., some embedded devices) and when security 5250 requirements are low (e.g., long-term confidentiality is not 5251 required). 5253 Appendix E. HIT Suites and HIT Generation 5255 The HIT as an ORCHID [I-D.ietf-hip-rfc4843-bis] consists of three 5256 parts: A 28-bit prefix, a 4-bit encoding of the ORCHID generation 5257 algorithm (OGA) and the representation of the public key. The OGA is 5258 an index pointing to the specific algorithm by which the public key 5259 and the 96-bit hashed encoding is generated. The OGA is protocol 5260 specific and is to be interpreted as defined below for all protocols 5261 that use the same context ID as HIP. HIP groups sets of valid 5262 combinations of signature and hash algorithms into HIT Suites. These 5263 HIT suites are addressed by an index, which is transmitted in the OGA 5264 field of the ORCHID. 5266 The set of used HIT Suites will be extended to counter the progress 5267 in computation capabilities and vulnerabilities in the employed 5268 algorithms. The intended use of the HIT Suites is to introduce a new 5269 HIT Suite and phase out an old one before it becomes insecure. Since 5270 the 4-bit OGA field only permits 15 HIT Suites (the HIT Suite with ID 5271 0 is reserved) to be used in parallel, phased-out HIT Suites must be 5272 reused at some point. In such a case, there will be a rollover of 5273 the HIT Suite ID and the next newly introduced HIT Suite will start 5274 with a lower HIT Suite index than the previously introduced one. The 5275 rollover effectively deprecates the reused HIT Suite. For a smooth 5276 transition, the HIT Suite should be deprecated a considerable time 5277 before the HIT Suite index is reused. 5279 Since the number of HIT Suites is tightly limited to 16, the HIT 5280 Suites must be assigned carefully. Hence, sets of suitable 5281 algorithms are grouped in a HIT Suite. 5283 The HIT Suite of the Responder's HIT determines the RHASH and the 5284 hash function to be used for the HMAC in HIP control packets as well 5285 as the signature algorithm family used for generating the HI. The 5286 list of HIT Suites is defined in Table 11. 5288 The following HIT Suites are defined for HIT generation. The input 5289 for each generation algorithm is the encoding of the HI as defined in 5290 Section 3.2. The output is 96 bits long and is directly used in the 5291 ORCHID. 5293 +-------+----------+--------------+-------------+-------------------+ 5294 | Index | Hash | HMAC | Signature | Description | 5295 | | function | | algorithm | | 5296 | | | | family | | 5297 +-------+----------+--------------+-------------+-------------------+ 5298 | 0 | | | | Reserved | 5299 | 1 | SHA-1 | HMAC-SHA-1 | RSA, DSA | RSA or DSA HI | 5300 | | | | | hashed with | 5301 | | | | | SHA-1, truncated | 5302 | | | | | to 96 bits | 5303 | 2 | SHA-384 | HMAC-SHA-384 | ECDSA | ECDSA HI hashed | 5304 | | | | | with SHA-384, | 5305 | | | | | truncated to 96 | 5306 | | | | | bits | 5307 | 3 | SHA-1 | HMAC-SHA-1 | ECDSA_LOW | ECDSA_LOW HI | 5308 | | | | | hashed with | 5309 | | | | | SHA-1, truncated | 5310 | | | | | to 96 bits | 5311 +-------+----------+--------------+-------------+-------------------+ 5313 Table 11: HIT Suites 5315 The hash of the responder as defined in the HIT Suite determines the 5316 HMAC to be used for the HMAC parameter. The HMACs currently defined 5317 here are SHA-1 [RFC2404] and HMAC-SHA-384 [RFC4868]. 5319 Authors' Addresses 5321 Robert Moskowitz (editor) 5322 ICSA labs, An Independent Division of Verizon Business 5323 1000 Bent Creek Blvd, Suite 200 5324 Mechanicsburg, PA 5325 USA 5327 EMail: robert.moskowitz@icsalabs.com 5329 Petri Jokela 5330 Ericsson Research NomadicLab 5331 JORVAS FIN-02420 5332 FINLAND 5334 Phone: +358 9 299 1 5335 EMail: petri.jokela@nomadiclab.com 5336 Thomas R. Henderson 5337 The Boeing Company 5338 P.O. Box 3707 5339 Seattle, WA 5340 USA 5342 EMail: thomas.r.henderson@boeing.com 5344 Tobias Heer 5345 RWTH Aachen University, Communication and Distributed Systems Group 5346 Ahornstrasse 55 5347 Aachen 52062 5348 Germany 5350 EMail: heer@cs.rwth-aachen.de 5351 URI: http://www.comsys.rwth-aachen.de/team/tobias-heer/