idnits 2.17.1 draft-ietf-hip-rfc5201-bis-15.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 3 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 2191 has weird spacing: '...c Value leng...' == Line 2193 has weird spacing: '...c Value the ...' == Line 2721 has weird spacing: '...ication info...' == Line 2859 has weird spacing: '...ue data opaqu...' == Line 2889 has weird spacing: '...ue data opaqu...' == (2 more instances...) -- The document date (July 23, 2014) is 3558 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-08) exists of draft-ietf-hip-rfc4843-bis-04 == Outdated reference: A later version (-07) exists of draft-ietf-hip-rfc5202-bis-05 ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542) == Outdated reference: A later version (-20) exists of draft-ietf-hip-rfc4423-bis-05 == Outdated reference: A later version (-08) exists of draft-ietf-hip-rfc5204-bis-02 == Outdated reference: A later version (-10) exists of draft-ietf-hip-rfc5205-bis-02 == Outdated reference: A later version (-14) exists of draft-ietf-hip-rfc5206-bis-06 -- Obsolete informational reference (is this intentional?): RFC 2898 (Obsoleted by RFC 8018) -- Obsolete informational reference (is this intentional?): RFC 3447 (Obsoleted by RFC 8017) -- Obsolete informational reference (is this intentional?): RFC 5201 (Obsoleted by RFC 7401) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) -- Obsolete informational reference (is this intentional?): RFC 6253 (Obsoleted by RFC 8002) Summary: 3 errors (**), 0 flaws (~~), 14 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Moskowitz, Ed. 3 Internet-Draft Verizon 4 Obsoletes: 5201 (if approved) T. Heer 5 Intended status: Standards Track Hirschmann Automation and Control 6 Expires: January 24, 2015 P. Jokela 7 Ericsson Research NomadicLab 8 T. Henderson 9 University of Washington 10 July 23, 2014 12 Host Identity Protocol Version 2 (HIPv2) 13 draft-ietf-hip-rfc5201-bis-15 15 Abstract 17 This document specifies the details of the Host Identity Protocol 18 (HIP). HIP allows consenting hosts to securely establish and 19 maintain shared IP-layer state, allowing separation of the identifier 20 and locator roles of IP addresses, thereby enabling continuity of 21 communications across IP address changes. HIP is based on a Diffie- 22 Hellman key exchange, using public key identifiers from a new Host 23 Identity namespace for mutual peer authentication. The protocol is 24 designed to be resistant to denial-of-service (DoS) and man-in-the- 25 middle (MitM) attacks. When used together with another suitable 26 security protocol, such as the Encapsulated Security Payload (ESP), 27 it provides integrity protection and optional encryption for upper- 28 layer protocols, such as TCP and UDP. 30 This document obsoletes RFC 5201 and addresses the concerns raised by 31 the IESG, particularly that of crypto agility. It also incorporates 32 lessons learned from the implementations of RFC 5201. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 24, 2015. 50 Copyright Notice 52 Copyright (c) 2014 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 68 1.1. A New Namespace and Identifiers . . . . . . . . . . . . . 6 69 1.2. The HIP Base Exchange (BEX) . . . . . . . . . . . . . . . 6 70 1.3. Memo Structure . . . . . . . . . . . . . . . . . . . . . 7 71 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 8 72 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 8 73 2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 8 74 2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 8 75 3. Host Identity (HI) and its Structure . . . . . . . . . . . . 9 76 3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 10 77 3.2. Generating a HIT from an HI . . . . . . . . . . . . . . . 11 78 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 12 79 4.1. Creating a HIP Association . . . . . . . . . . . . . . . 12 80 4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . 14 81 4.1.2. Puzzle Exchange . . . . . . . . . . . . . . . . . . . 15 82 4.1.3. Authenticated Diffie-Hellman Protocol with DH Group 83 Negotiation . . . . . . . . . . . . . . . . . . . . . 16 84 4.1.4. HIP Replay Protection . . . . . . . . . . . . . . . . 18 85 4.1.5. Refusing a HIP base exchange . . . . . . . . . . . . 19 86 4.1.6. Aborting a HIP base exchange . . . . . . . . . . . . 19 87 4.1.7. HIP Downgrade Protection . . . . . . . . . . . . . . 20 88 4.1.8. HIP Opportunistic Mode . . . . . . . . . . . . . . . 21 89 4.2. Updating a HIP Association . . . . . . . . . . . . . . . 23 90 4.3. Error Processing . . . . . . . . . . . . . . . . . . . . 24 91 4.4. HIP State Machine . . . . . . . . . . . . . . . . . . . . 25 92 4.4.1. State Machine Terminology . . . . . . . . . . . . . . 26 93 4.4.2. HIP States . . . . . . . . . . . . . . . . . . . . . 26 94 4.4.3. HIP State Processes . . . . . . . . . . . . . . . . . 27 95 4.4.4. Simplified HIP State Diagram . . . . . . . . . . . . 35 97 4.5. User Data Considerations . . . . . . . . . . . . . . . . 37 98 4.5.1. TCP and UDP Pseudo-Header Computation for User Data . 37 99 4.5.2. Sending Data on HIP Packets . . . . . . . . . . . . . 37 100 4.5.3. Transport Formats . . . . . . . . . . . . . . . . . . 37 101 4.5.4. Reboot, Timeout, and Restart of HIP . . . . . . . . . 37 102 4.6. Certificate Distribution . . . . . . . . . . . . . . . . 38 103 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 38 104 5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 38 105 5.1.1. Checksum . . . . . . . . . . . . . . . . . . . . . . 40 106 5.1.2. HIP Controls . . . . . . . . . . . . . . . . . . . . 40 107 5.1.3. HIP Fragmentation Support . . . . . . . . . . . . . . 40 108 5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 41 109 5.2.1. TLV Format . . . . . . . . . . . . . . . . . . . . . 44 110 5.2.2. Defining New Parameters . . . . . . . . . . . . . . . 46 111 5.2.3. R1_COUNTER . . . . . . . . . . . . . . . . . . . . . 46 112 5.2.4. PUZZLE . . . . . . . . . . . . . . . . . . . . . . . 47 113 5.2.5. SOLUTION . . . . . . . . . . . . . . . . . . . . . . 48 114 5.2.6. DH_GROUP_LIST . . . . . . . . . . . . . . . . . . . . 49 115 5.2.7. DIFFIE_HELLMAN . . . . . . . . . . . . . . . . . . . 51 116 5.2.8. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . 52 117 5.2.9. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 53 118 5.2.10. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 55 119 5.2.11. TRANSPORT_FORMAT_LIST . . . . . . . . . . . . . . . . 56 120 5.2.12. HIP_MAC . . . . . . . . . . . . . . . . . . . . . . . 57 121 5.2.13. HIP_MAC_2 . . . . . . . . . . . . . . . . . . . . . . 57 122 5.2.14. HIP_SIGNATURE . . . . . . . . . . . . . . . . . . . . 58 123 5.2.15. HIP_SIGNATURE_2 . . . . . . . . . . . . . . . . . . . 59 124 5.2.16. SEQ . . . . . . . . . . . . . . . . . . . . . . . . . 59 125 5.2.17. ACK . . . . . . . . . . . . . . . . . . . . . . . . . 60 126 5.2.18. ENCRYPTED . . . . . . . . . . . . . . . . . . . . . . 60 127 5.2.19. NOTIFICATION . . . . . . . . . . . . . . . . . . . . 62 128 5.2.20. ECHO_REQUEST_SIGNED . . . . . . . . . . . . . . . . . 65 129 5.2.21. ECHO_REQUEST_UNSIGNED . . . . . . . . . . . . . . . . 66 130 5.2.22. ECHO_RESPONSE_SIGNED . . . . . . . . . . . . . . . . 66 131 5.2.23. ECHO_RESPONSE_UNSIGNED . . . . . . . . . . . . . . . 67 132 5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 68 133 5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 69 134 5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 69 135 5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 72 136 5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 74 137 5.3.5. UPDATE - the HIP Update Packet . . . . . . . . . . . 74 138 5.3.6. NOTIFY - the HIP Notify Packet . . . . . . . . . . . 75 139 5.3.7. CLOSE - the HIP Association Closing Packet . . . . . 76 140 5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet . . 76 141 5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 77 142 5.4.1. Invalid Version . . . . . . . . . . . . . . . . . . . 77 143 5.4.2. Other Problems with the HIP Header and Packet 144 Structure . . . . . . . . . . . . . . . . . . . . . . 77 146 5.4.3. Invalid Puzzle Solution . . . . . . . . . . . . . . . 77 147 5.4.4. Non-Existing HIP Association . . . . . . . . . . . . 78 148 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 78 149 6.1. Processing Outgoing Application Data . . . . . . . . . . 78 150 6.2. Processing Incoming Application Data . . . . . . . . . . 79 151 6.3. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 80 152 6.4. HIP_MAC and SIGNATURE Calculation and Verification . . . 82 153 6.4.1. HMAC Calculation . . . . . . . . . . . . . . . . . . 82 154 6.4.2. Signature Calculation . . . . . . . . . . . . . . . . 84 155 6.5. HIP KEYMAT Generation . . . . . . . . . . . . . . . . . . 86 156 6.6. Initiation of a HIP Base Exchange . . . . . . . . . . . . 88 157 6.6.1. Sending Multiple I1 Packets in Parallel . . . . . . . 89 158 6.6.2. Processing Incoming ICMP Protocol Unreachable 159 Messages . . . . . . . . . . . . . . . . . . . . . . 89 160 6.7. Processing Incoming I1 Packets . . . . . . . . . . . . . 90 161 6.7.1. R1 Management . . . . . . . . . . . . . . . . . . . . 91 162 6.7.2. Handling Malformed Messages . . . . . . . . . . . . . 91 163 6.8. Processing Incoming R1 Packets . . . . . . . . . . . . . 92 164 6.8.1. Handling of Malformed Messages . . . . . . . . . . . 94 165 6.9. Processing Incoming I2 Packets . . . . . . . . . . . . . 94 166 6.9.1. Handling of Malformed Messages . . . . . . . . . . . 97 167 6.10. Processing of Incoming R2 Packets . . . . . . . . . . . . 98 168 6.11. Sending UPDATE Packets . . . . . . . . . . . . . . . . . 98 169 6.12. Receiving UPDATE Packets . . . . . . . . . . . . . . . . 99 170 6.12.1. Handling a SEQ Parameter in a Received UPDATE 171 Message . . . . . . . . . . . . . . . . . . . . . . 100 172 6.12.2. Handling an ACK Parameter in a Received UPDATE 173 Packet . . . . . . . . . . . . . . . . . . . . . . . 101 174 6.13. Processing of NOTIFY Packets . . . . . . . . . . . . . . 101 175 6.14. Processing CLOSE Packets . . . . . . . . . . . . . . . . 102 176 6.15. Processing CLOSE_ACK Packets . . . . . . . . . . . . . . 102 177 6.16. Handling State Loss . . . . . . . . . . . . . . . . . . . 102 178 7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 103 179 8. Security Considerations . . . . . . . . . . . . . . . . . . . 103 180 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 106 181 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 110 182 11. Changes from RFC 5201 . . . . . . . . . . . . . . . . . . . . 111 183 11.1. Changes from draft-ietf-hip-rfc5201-bis-14 . . . . . . . 111 184 11.2. Changes from draft-ietf-hip-rfc5201-bis-13 . . . . . . . 111 185 11.3. Changes from draft-ietf-hip-rfc5201-bis-12 . . . . . . . 111 186 11.4. Changes from draft-ietf-hip-rfc5201-bis-11 . . . . . . . 111 187 11.5. Changes from draft-ietf-hip-rfc5201-bis-10 . . . . . . . 111 188 11.6. Changes from draft-ietf-hip-rfc5201-bis-09 . . . . . . . 111 189 11.7. Changes from draft-ietf-hip-rfc5201-bis-08 . . . . . . . 111 190 11.8. Changes from draft-ietf-hip-rfc5201-bis-07 . . . . . . . 112 191 11.9. Changes from draft-ietf-hip-rfc5201-bis-06 . . . . . . . 112 192 11.10. Changes from draft-ietf-hip-rfc5201-bis-05 . . . . . . . 112 193 11.11. Changes from draft-ietf-hip-rfc5201-bis-04 . . . . . . . 113 194 11.12. Changes from draft-ietf-hip-rfc5201-bis-03 . . . . . . . 114 195 11.13. Changes from draft-ietf-hip-rfc5201-bis-02 . . . . . . . 115 196 11.14. Changes from draft-ietf-hip-rfc5201-bis-01 . . . . . . . 115 197 11.15. Changes from draft-ietf-hip-rfc5201-bis-00 . . . . . . . 117 198 11.16. Contents of draft-ietf-hip-rfc5201-bis-00 . . . . . . . 117 199 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 117 200 12.1. Normative References . . . . . . . . . . . . . . . . . . 117 201 12.2. Informative References . . . . . . . . . . . . . . . . . 119 202 Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 122 203 Appendix B. Generating a Public Key Encoding from an HI . . 123 204 Appendix C. Example Checksums for HIP Packets . . . . . . . . . 123 205 C.1. IPv6 HIP Example (I1 packet) . . . . . . . . . . . . . . 124 206 C.2. IPv4 HIP Packet (I1 packet) . . . . . . . . . . . . . . . 124 207 C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . . 125 208 Appendix D. ECDH and ECDSA 160 Bit Groups . . . . . . . . . . . 125 209 Appendix E. HIT Suites and HIT Generation . . . . . . . . . . . 125 211 1. Introduction 213 This document specifies the details of the Host Identity Protocol 214 (HIP). A high-level description of the protocol and the underlying 215 architectural thinking is available in the separate HIP architecture 216 description [I-D.ietf-hip-rfc4423-bis]. Briefly, the HIP 217 architecture proposes an alternative to the dual use of IP addresses 218 as "locators" (routing labels) and "identifiers" (endpoint, or host, 219 identifiers). In HIP, public cryptographic keys, of a public/private 220 key pair, are used as Host Identifiers, to which higher layer 221 protocols are bound instead of an IP address. By using public keys 222 (and their representations) as host identifiers, dynamic changes to 223 IP address sets can be directly authenticated between hosts, and if 224 desired, strong authentication between hosts at the TCP/IP stack 225 level can be obtained. 227 This memo specifies the base HIP protocol ("base exchange") used 228 between hosts to establish an IP-layer communications context, called 229 a HIP association, prior to communications. It also defines a packet 230 format and procedures for updating and terminating an active HIP 231 association. Other elements of the HIP architecture are specified in 232 other documents, such as: 234 o "Using the Encapsulating Security Payload (ESP) transport format 235 with the Host Identity Protocol (HIP)" [I-D.ietf-hip-rfc5202-bis]: 236 how to use the Encapsulating Security Payload (ESP) for integrity 237 protection and optional encryption 239 o "Host Mobility with the Host Identity Protocol" 240 [I-D.ietf-hip-rfc5206-bis]: how to support host mobility in HIP 242 o "Host Identity Protocol (HIP) Domain Name System (DNS) Extensions" 243 [I-D.ietf-hip-rfc5205-bis]: how to extend DNS to contain Host 244 Identity information 246 o "Host Identity Protocol (HIP) Rendezvous Extension" 247 [I-D.ietf-hip-rfc5204-bis]: using a rendezvous mechanism to 248 contact mobile HIP hosts 250 Since the HIP base exchange was first developed, there have been a 251 few advances in cryptography and attacks against cryptographic 252 systems. As a result, all cryptographic protocols need to be agile. 253 That is, it should be a part of the protocol to be able to switch 254 from one cryptographic primitive to another. It is important to 255 support a reasonable set of mainstream algorithms to cater for 256 different use cases and allow moving away from algorithms that are 257 later discovered to be vulnerable. This update to the base exchange 258 includes this needed cryptographic agility while addressing the 259 downgrade attacks that such flexibility introduces. In particular, 260 Elliptic Curve support by Elliptic Curve DSA (ECDSA) and Elliptic 261 Curve Diffie-Hellman (ECDH) and alternative hash functions have been 262 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 Identity (HI) and the Host Identity Tag (HIT). The HI is a 273 public key and directly represents the Identity of a host. Since 274 there are different public key algorithms that can be used with 275 different key lengths, the HI, as such, is unsuitable for use as a 276 packet identifier, or as an index into the various state-related 277 implementation structures needed to support HIP. Consequently, a 278 hash of the HI, the Host Identity Tag (HIT), is used as the 279 operational representation. The HIT is 128 bits long and is used in 280 the HIP headers and to index the corresponding state in the end 281 hosts. The HIT has an important security property in that it is 282 self-certifying (see Section 3). 284 1.2. The HIP Base Exchange (BEX) 286 The HIP base exchange is a two-party cryptographic protocol used to 287 establish communications context between hosts. The base exchange is 288 a SIGMA-compliant [KRA03] four-packet exchange. The first party is 289 called the Initiator and the second party the Responder. The 290 protocol exchanges Diffie-Hellman [DIF76] keys in the 2nd and 3rd 291 packets, and authenticates the parties in the 3rd and 4th packets. 292 The four-packet design helps to make HIP DoS resilient. It allows 293 the Responder to stay stateless until the IP address and the 294 cryptographic puzzle is verified. The Responder starts the puzzle 295 exchange in the 2nd packet, with the Initiator completing it in the 296 3rd packet before the Responder stores any state from the exchange. 298 The exchange can use the Diffie-Hellman output to encrypt the Host 299 Identity of the Initiator in the 3rd packet (although Aura, et al., 300 [AUR03] notes that such operation may interfere with packet- 301 inspecting middleboxes), or the Host Identity may instead be sent 302 unencrypted. The Responder's Host Identity is not protected. It 303 should be noted, however, that both the Initiator's and the 304 Responder's HITs are transported as such (in cleartext) in the 305 packets, allowing an eavesdropper with a priori knowledge about the 306 parties to identify them by their HITs. Hence, encrypting the HI of 307 any party does not provide privacy against such attacker. 309 Data packets start to flow after the 4th packet. The 3rd and 4th HIP 310 packets may carry a data payload in the future. However, the details 311 of this may be defined later. 313 An existing HIP association can be updated using the update mechanism 314 defined in this document, and when the association is no longer 315 needed, it can be closed using the defined closing mechanism. 317 Finally, HIP is designed as an end-to-end authentication and key 318 establishment protocol, to be used with Encapsulated Security Payload 319 (ESP) [I-D.ietf-hip-rfc5202-bis] and other end-to-end security 320 protocols. The base protocol does not cover all the fine-grained 321 policy control found in Internet Key Exchange (IKE) [RFC5996] that 322 allows IKE to support complex gateway policies. Thus, HIP is not a 323 complete replacement for IKE. 325 1.3. Memo Structure 327 The rest of this memo is structured as follows. Section 2 defines 328 the central keywords, notation, and terms used throughout the rest of 329 the document. Section 3 defines the structure of the Host Identity 330 and its various representations. Section 4 gives an overview of the 331 HIP base exchange protocol. Sections 5 and 6 define the detailed 332 packet formats and rules for packet processing. Finally, Sections 7, 333 8, and 9 discuss policy, security, and IANA considerations, 334 respectively. 336 2. Terms and Definitions 338 2.1. Requirements Terminology 340 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 341 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 342 document are to be interpreted as described in RFC 2119 [RFC2119]. 344 2.2. Notation 346 [x] indicates that x is optional. 348 {x} indicates that x is encrypted. 350 X(y) indicates that y is a parameter of X. 352 i indicates that x exists i times. 354 --> signifies "Initiator to Responder" communication (requests). 356 <-- signifies "Responder to Initiator" communication (replies). 358 | signifies concatenation of information (e.g., X | Y is the 359 concatenation of X with Y). 361 Ltrunc (H(x), K) denotes the lowest order #K bits of the result of 362 the hash function H on the input x. 364 2.3. Definitions 366 HIP base exchange (BEX): the handshake for establishing a new HIP 367 association. 369 Host Identity (HI): The public key of the signature algorithm that 370 represents the identity of the host. In HIP, a host proves its 371 identity by creating a signature with the private key belonging to 372 its HI (c.f. Section 3). 374 Host Identity Tag (HIT): A shorthand for the HI in IPv6 format. It 375 is generated by hashing the HI (c.f. Section 3.1). 377 HIT Suite: A HIT Suite groups all cryptographic algorithms that are 378 required to generate and use an HI and its HIT. In particular, 379 these algorithms are: 1) the public key signature algorithm and 2) 380 the hash function, 3) the truncation (c.f. Appendix E). 382 HIP association: The shared state between two peers after 383 completion of the BEX. 385 HIP packet: A control packet carrying a HIP packet header relating 386 to the establishment, maintenance, or termination of the HIP 387 association. 389 Initiator: The host that initiates the BEX. This role is typically 390 forgotten once the BEX is completed. 392 Responder: The host that responds to the Initiator in the BEX. 393 This role is typically forgotten once the BEX is completed. 395 Responder's HIT Hash Algorithm (RHASH): The Hash algorithm used for 396 various hash calculations in this document. The algorithm is the 397 same as is used to generate the Responder's HIT. The RHASH is the 398 hash function defined by the HIT Suite of the Responder's HIT 399 (c.f. Appendix E). 401 Length of the Responder's HIT Hash Algorithm (RHASH_len): The 402 natural output length of RHASH in bits. 404 Signed data: Data that is signed is protected by a digital 405 signature that was created by the sender of the data by using the 406 private key of its HI. 408 KDF: The Key Derivation Function (KDF) is used for deriving the 409 symmetric keys from the Diffie-Hellman key exchange. 411 KEYMAT: The keying material derived from the Diffie-Hellman key 412 exchange by using the KDF. Symmetric keys for encryption and 413 integrity protection of HIP packets and encrypted user data 414 packets are drawn from this keying material. 416 3. Host Identity (HI) and its Structure 418 In this section, the properties of the Host Identity and Host 419 Identity Tag are discussed, and the exact format for them is defined. 420 In HIP, the public key of an asymmetric key pair is used as the Host 421 Identity (HI). Correspondingly, the host itself is defined as the 422 entity that holds the private key of the key pair. See the HIP 423 architecture specification [I-D.ietf-hip-rfc4423-bis] for more 424 details on the difference between an identity and the corresponding 425 identifier. 427 HIP implementations MUST support the Rivest Shamir Adelman (RSA) 428 [RFC3110] public key algorithm and the Elliptic Curve Digital 429 Signature Algorithm (ECDSA) for generating the HI as defined in 430 Section 5.2.9. Additional algorithms MAY be supported. 432 A hashed encoding of the HI, the Host Identity Tag (HIT), is used in 433 protocols to represent the Host Identity. The HIT is 128 bits long 434 and has the following three key properties: i) it is the same length 435 as an IPv6 address and can be used in fixed address-sized fields in 436 APIs and protocols, ii) it is self-certifying (i.e., given a HIT, it 437 is computationally hard to find a Host Identity key that matches the 438 HIT), and iii) the probability of a HIT collision between two hosts 439 is very low, hence, it is infeasible for an attacker to find a 440 collision with a HIT that is in use. For details on the security 441 properties of the HIT see [I-D.ietf-hip-rfc4423-bis]. 443 The structure of the HIT is defined in [I-D.ietf-hip-rfc4843-bis]. 444 The HIT is an Overlay Routable Cryptographic Hash Identifier (ORCHID) 445 and consists of three parts: first, an IANA assigned prefix to 446 distinguish it from other IPv6 addresses. Second, a four-bit 447 encoding of the algorithms that were used for generating the HI and 448 the hashed representation of HI. Third, a 96-bit hashed 449 representation of the Host Identity. The encoding of the ORCHID 450 generation algorithm and the exact algorithm for generating the 451 hashed representation is specified in Appendix E. 453 Carrying HIs and HITs in the header of user data packets would 454 increase the overhead of packets. Thus, it is not expected that they 455 are carried in every packet, but other methods are used to map the 456 data packets to the corresponding HIs. In some cases, this makes it 457 possible to use HIP without any additional headers in the user data 458 packets. For example, if ESP is used to protect data traffic, the 459 Security Parameter Index (SPI) carried in the ESP header can be used 460 to map the encrypted data packet to the correct HIP association. 462 3.1. Host Identity Tag (HIT) 464 The Host Identity Tag is a 128-bit value -- a hashed encoding of the 465 Host Identifier. There are two advantages of using a hashed encoding 466 over the actual variable-sized Host Identity public key in protocols. 467 First, the fixed length of the HIT keeps packet sizes manageable and 468 eases protocol coding. Second, it presents a consistent format for 469 the protocol, independent of the underlying identity technology in 470 use. 472 RFC 4843-bis [I-D.ietf-hip-rfc4843-bis] specifies 128-bit hash-based 473 identifiers, called Overlay Routable Cryptographic Hash Identifiers, 474 ORCHIDs. Their prefix, allocated from the IPv6 address block, is 475 defined in [I-D.ietf-hip-rfc4843-bis]. The Host Identity Tag is one 476 type of an ORCHID. 478 This document extends the original, experimental HIP specification 479 [RFC5201] with measures to support crypto agility. One of these 480 measures is to allow different hash functions for creating a HIT. 481 HIT Suites group the sets of algorithms that are required to generate 482 and use a particular HIT. The Suites are encoded in HIT Suite IDs. 483 These HIT Suite IDs are transmitted in the ORCHID Generation 484 Algorithm (OGA) field in the ORCHID. With the HIT Suite ID in the 485 OGA field, a host can tell from another host's HIT, whether it 486 supports the necessary hash and signature algorithms to establish a 487 HIP association with that host. 489 3.2. Generating a HIT from an HI 491 The HIT MUST be generated according to the ORCHID generation method 492 described in [I-D.ietf-hip-rfc4843-bis] using a context ID value of 493 0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA (this tag value has been 494 generated randomly by the editor of this specification), and an input 495 that encodes the Host Identity field (see Section 5.2.9) present in a 496 HIP payload packet. The set of hash function, signature algorithm, 497 and the algorithm used for generating the HIT from the HI depends on 498 the HIT Suite (see Appendix E) and is indicated by the four bits of 499 the ORCHID Generation Algorithm (OGA) field in the ORCHID. 500 Currently, truncated SHA-1, truncated SHA-384, and truncated SHA-256 501 [FIPS.180-2.2002] are defined as hashes for generating a HIT. 503 For identities that are either RSA, Digital Signature Algorithm (DSA) 504 [FIPS186-3], or Elliptic Curve DSA (ECDSA) public keys, the ORCHID 505 input consists of the public key encoding as specified for the Host 506 Identity field of the HOST_ID parameter (see Section 5.2.9). This 507 document defines four algorithm profiles: RSA, DSA, ECDSA, and 508 ECDSA_LOW. The ECDSA_LOW profile is meant for devices with low 509 computational capabilities. Hence, one of the following applies: 511 The RSA public key is encoded as defined in [RFC3110] Section 2, 512 taking the exponent length (e_len), exponent (e), and modulus (n) 513 fields concatenated. The length (n_len) of the modulus (n) can be 514 determined from the total HI Length and the preceding HI fields 515 including the exponent (e). Thus, the data that serves as input 516 for the HIT generation has the same length as the HI. The fields 517 MUST be encoded in network byte order, as defined in [RFC3110]. 519 The DSA public key is encoded as defined in [RFC2536] Section 2, 520 taking the fields T, Q, P, G, and Y, concatenated as input. Thus, 521 the data to be hashed is 1 + 20 + 3 * 64 + 3 * 8 * T octets long, 522 where T is the size parameter as defined in [RFC2536]. The size 523 parameter T, affecting the field lengths, MUST be selected as the 524 minimum value that is long enough to accommodate P, G, and Y. The 525 fields MUST be encoded in network byte order, as defined in 526 [RFC2536]. 528 The ECDSA public keys are encoded as defined in [RFC6090] 529 Section 4.2 and 6. 531 In Appendix B, the public key encoding process is illustrated using 532 pseudo-code. 534 4. Protocol Overview 536 This section is a simplified overview of the HIP protocol operation, 537 and does not contain all the details of the packet formats or the 538 packet processing steps. Sections 5 and 6 describe in more detail 539 the packet formats and packet processing steps, respectively, and are 540 normative in case of any conflicts with this section. 542 The protocol number 139 has been assigned by IANA to the Host 543 Identity Protocol. 545 The HIP payload (Section 5.1) header could be carried in every IP 546 datagram. However, since HIP headers are relatively large (40 547 bytes), it is desirable to 'compress' the HIP header so that the HIP 548 header only occurs in control packets used to establish or change HIP 549 association state. The actual method for header 'compression' and 550 for matching data packets with existing HIP associations (if any) is 551 defined in separate documents, describing transport formats and 552 methods. All HIP implementations MUST implement, at minimum, the ESP 553 transport format for HIP [I-D.ietf-hip-rfc5202-bis]. 555 4.1. Creating a HIP Association 557 By definition, the system initiating a HIP base exchange is the 558 Initiator, and the peer is the Responder. This distinction is 559 typically forgotten once the base exchange completes, and either 560 party can become the Initiator in future communications. 562 The HIP base exchange serves to manage the establishment of state 563 between an Initiator and a Responder. The first packet, I1, 564 initiates the exchange, and the last three packets, R1, I2, and R2, 565 constitute an authenticated Diffie-Hellman [DIF76] key exchange for 566 session-key generation. In the first two packets, the hosts agree on 567 a set of cryptographic identifiers and algorithms that are then used 568 in and after the exchange. During the Diffie-Hellman key exchange, a 569 piece of keying material is generated. The HIP association keys are 570 drawn from this keying material by using a Key Derivation Function 571 (KDF). If other cryptographic keys are needed, e.g., to be used with 572 ESP, they are expected to be drawn from the same keying material by 573 using the KDF. 575 The Initiator first sends a trigger packet, I1, to the Responder. 576 The packet contains the HIT of the Initiator and possibly the HIT of 577 the Responder, if it is known. Moreover, the I1 packet initializes 578 the negotiation of the Diffie-Hellman group that is used for 579 generating the keying material. Therefore, the I1 packet contains a 580 list of Diffie Hellman Group IDs supported by the Initiator. Note 581 that in some cases it may be possible to replace this trigger packet 582 by some other form of a trigger, in which case the protocol starts 583 with the Responder sending the R1 packet. In such cases, another 584 mechanism to convey the Initiator's supported DH Groups (e.g., by 585 using a default group) must be specified. 587 The second packet, R1, starts the actual authenticated Diffie-Hellman 588 exchange. It contains a puzzle -- a cryptographic challenge that the 589 Initiator must solve before continuing the exchange. The level of 590 difficulty of the puzzle can be adjusted based on level of trust with 591 the Initiator, current load, or other factors. In addition, the R1 592 contains the Responder's Diffie-Hellman parameter and lists of 593 cryptographic algorithms supported by the Responder. Based on these 594 lists, the Initiator can continue, abort, or restart the base 595 exchange with a different selection of cryptographic algorithms. 596 Also, the R1 packet contains a signature that covers selected parts 597 of the message. Some fields are left outside the signature to 598 support pre-created R1s. 600 In the I2 packet, the Initiator MUST display the solution to the 601 received puzzle. Without a correct solution, the I2 message is 602 discarded. The I2 packet also contains a Diffie-Hellman parameter 603 that carries needed information for the Responder. The I2 packet is 604 signed by the Initiator. 606 The R2 packet acknowledges the receipt of the I2 packet and completes 607 the base exchange. The packet is signed by the Responder. 609 The base exchange is illustrated below in Figure 1. The term "key" 610 refers to the Host Identity public key, and "sig" represents a 611 signature using such a key. The packets contain other parameters not 612 shown in this figure. 614 Initiator Responder 616 I1: DH list 617 --------------------------> 618 select precomputed R1 619 R1: puzzle, DH, key, sig 620 <------------------------- 621 check sig remain stateless 622 solve puzzle 623 I2: solution, DH, {key}, sig 624 --------------------------> 625 compute DH check puzzle 626 check sig 627 R2: sig 628 <-------------------------- 629 check sig compute DH 631 Figure 1 633 4.1.1. HIP Puzzle Mechanism 635 The purpose of the HIP puzzle mechanism is to protect the Responder 636 from a number of denial-of-service threats. It allows the Responder 637 to delay state creation until receiving the I2 packet. Furthermore, 638 the puzzle allows the Responder to use a fairly cheap calculation to 639 check that the Initiator is "sincere" in the sense that it has 640 churned enough CPU cycles in solving the puzzle. 642 The puzzle allows a Responder implementation to completely delay 643 association-specific state creation until a valid I2 packet is 644 received. An I2 packet without valid puzzle solution can be rejected 645 immediately once the Responder has checked the solution by computing 646 only one hash function before state is created and CPU-intensive 647 public-key signature verification and Diffie-Hellman key generation 648 are performed. By varying the difficulty of the puzzle, the 649 Responder can frustrate CPU or memory targeted DoS attacks. 651 The Responder can remain stateless and drop most spoofed I2 packets 652 because puzzle calculation is based on the Initiator's Host Identity 653 Tag. The idea is that the Responder has a (perhaps varying) number of 654 pre-calculated R1 packets, and it selects one of these based on the 655 information carried in the I1 packet. When the Responder then later 656 receives the I2 packet, it can verify that the puzzle has been solved 657 using the Initiator's HIT. This makes it impractical for the 658 attacker to first exchange one I1/R1 packet, and then generate a 659 large number of spoofed I2 packets that seemingly come from different 660 HITs. This method does not protect the Responder from an attacker 661 that uses fixed HITs, though. Against such an attacker, a viable 662 approach may be to create a piece of local state, and remember that 663 the puzzle check has previously failed. See Appendix A for one 664 possible implementation. Responder implementations SHOULD include 665 sufficient randomness in the puzzle values so that algorithmic 666 complexity attacks become impossible [CRO03]. 668 The Responder can set the puzzle difficulty for the Initiator, based 669 on its level of trust of the Initiator. Because the puzzle is not 670 included in the signature calculation, the Responder can use pre- 671 calculated R1 packets and include the puzzle just before sending the 672 R1 to the Initiator. The Responder SHOULD use heuristics to 673 determine when it is under a denial-of-service attack, and set the 674 puzzle difficulty value #K appropriately as explained later. 676 4.1.2. Puzzle Exchange 678 The Responder starts the puzzle exchange when it receives an I1 679 packet. The Responder supplies a random number #I, and requires the 680 Initiator to find a number J. To select a proper #J, the Initiator 681 must create the concatenation of #I, the HITs of the parties, and #J, 682 and calculate a hash over this concatenation using the RHASH 683 algorithm. The lowest order #K bits of the result MUST be zeros. 684 The value #K sets the difficulty of the puzzle. 686 To generate a proper number #J, the Initiator will have to generate a 687 number of Js until one produces the hash target of zeros. The 688 Initiator SHOULD give up after exceeding the puzzle Lifetime in the 689 PUZZLE parameter (as described in Section 5.2.4). The Responder 690 needs to re-create the concatenation of #I, the HITs, and the 691 provided #J, and compute the hash once to prove that the Initiator 692 completed its assigned task. 694 To prevent precomputation attacks, the Responder MUST select the 695 number #I in such a way that the Initiator cannot guess it. 696 Furthermore, the construction MUST allow the Responder to verify that 697 the value #I was indeed selected by it and not by the Initiator. See 698 Appendix A for an example on how to implement this. 700 Using the Opaque data field in the PUZZLE (see Section 5.2.4), in an 701 ECHO_REQUEST_SIGNED (see Section 5.2.20) or in an 702 ECHO_REQUEST_UNSIGNED parameter (see Section 5.2.21), the Responder 703 can include some data in R1 that the Initiator MUST copy unmodified 704 in the corresponding I2 packet. The Responder can use the opaque 705 data to transfer a piece of local state information to the Initiator 706 and back, for example to recognize that the I2 is a response to a 707 previously sent R1. The Responder can generate the Opaque data in 708 various ways; e.g., using encryption or hashing with some secret, the 709 sent #I, and possibly using other related data. With the same 710 secret, the received #I (from the I2 packet), and the other related 711 data (if any), the Responder can verify that it has itself sent the 712 #I to the Initiator. The Responder MUST periodically change such a 713 secret. 715 It is RECOMMENDED that the Responder generates new secrets for the 716 puzzle and new R1s once every few minutes. Furthermore, it is 717 RECOMMENDED that the Responder is able to verify valid puzzle 718 solution at least Lifetime seconds after the puzzle secret has been 719 deprecated. This time value guarantees that the puzzle is valid for 720 at least Lifetime and at most 2 * Lifetime seconds. This limits the 721 usability that an old, solved puzzle has to an attacker. Moreover, 722 it avoids problems with the validity of puzzles if the lifetime is 723 relatively short compared to the network delay and the time for 724 solving the puzzle. 726 The puzzle value #I and the solution #J are inputs for deriving the 727 keying material from the Diffie-Hellman key exchange (see 728 Section 6.5). Therefore, a Responder SHOULD NOT use the same puzzle 729 #I with the same DH keys for the same Initiator twice to ensure that 730 the derived keying material differs. Such uniqueness can be 731 achieved, for example, by using a counter as an additional input for 732 generating #I. This counter can be increased for each processed I1 733 packet. The state of the counter can be transmitted in the Opaque 734 data field in the PUZZLE (see Section 5.2.4), in an 735 ECHO_REQUEST_SIGNED (see Section 5.2.20) or in an 736 ECHO_REQUEST_UNSIGNED parameter (see Section 5.2.21) without the need 737 to establish state. 739 NOTE: The protocol developers explicitly considered whether R1 should 740 include a timestamp in order to protect the Initiator from replay 741 attacks. The decision was to NOT include a timestamp to avoid 742 problems with global time synchronization. 744 NOTE: The protocol developers explicitly considered whether a memory 745 bound function should be used for the puzzle instead of a CPU-bound 746 function. The decision was not to use memory-bound functions. 748 4.1.3. Authenticated Diffie-Hellman Protocol with DH Group Negotiation 750 The packets R1, I2, and R2 implement a standard authenticated Diffie- 751 Hellman exchange. The Responder sends one of its public Diffie- 752 Hellman keys and its public authentication key, i.e., its Host 753 Identity, in R1. The signature in the R1 packet allows the Initiator 754 to verify that the R1 has been once generated by the Responder. 755 However, since the R1 is precomputed and therefore does not cover 756 association-specific information in the I1 packet, it does not 757 protect from replay attacks. 759 Before the actual authenticated Diffie-Hellman exchange, the 760 Initiator expresses its preference regarding its choice of the DH 761 groups in the I1 packet. The preference is expressed as a sorted 762 list of DH Group IDs. The I1 packet is not protected by a signature. 763 Therefore, this list is sent in an unauthenticated way to avoid 764 costly computations for processing the I1 packet at the Responder 765 side. Based on the preferences of the Initiator, the Responder sends 766 an R1 packet containing its most suitable public DH value. The 767 Responder also attaches a list of its own preferences to the R1 to 768 convey the basis for the DH group selection to the Initiator. This 769 list is carried in the signed part of the R1 packet. If the choice 770 of the DH group value in the R1 does not match the preferences of the 771 Initiator and the Responder, the Initiator can detect that the list 772 of DH Group IDs in the I1 was manipulated (see below for details). 774 If none of the DH Group IDs in the I1 packet is supported by the 775 Responder, the Responder selects the DH Group most suitable for it 776 regardless of the Initiator's preference. It then sends the R1 777 containing this DH Group and its list of supported DH Group IDs to 778 the Initiator. 780 When the Initiator receives an R1, it receives one of the Responder's 781 public Diffie-Hellman values and the list of DH Group IDs supported 782 by the Responder. This list is covered by the signature in the R1 783 packet to avoid forgery. The Initiator compares the Group ID of the 784 public DH value in the R1 packet to the list of supported DH Group 785 IDs in the R1 packets and to its own preferences expressed in the 786 list of supported DH Group IDs. The Initiator continues the BEX only 787 if the Group ID of the public DH value of the Responder is the most 788 preferred of the IDs supported by both the Initiator and Responder. 789 Otherwise, the communication is subject of a downgrade attack and the 790 Initiator MUST either restart the base exchange with a new I1 packet 791 or abort the base exchange. If the Responder's choice of the DH 792 Group is not supported by the Initiator, the Initiator MAY abort the 793 handshake or send a new I1 packet with a different list of supported 794 DH Groups. However, the Initiator MUST verify the signature of the 795 R1 packet before restarting or aborting the handshake. It MUST 796 silently ignore the R1 packet if the signature is not valid. 798 If the preferences regarding the DH Group ID match, the Initiator 799 computes the Diffie-Hellman session key (Kij). The Initiator creates 800 a HIP association using keying material from the session key (see 801 Section 6.5), and may use the HIP association to encrypt its public 802 authentication key, i.e., the Host Identity. The resulting I2 packet 803 contains the Initiator's Diffie-Hellman key and its (optionally 804 encrypted) public authentication key. The signature of the I2 805 message covers all parameters of the signed parameter ranges (see 806 Section 5.2) in the packet without exceptions as in the R1. 808 The Responder extracts the Initiator's Diffie-Hellman public key from 809 the I2 packet, computes the Diffie-Hellman session key, creates a 810 corresponding HIP association, and decrypts the Initiator's public 811 authentication key. It can then verify the signature using the 812 authentication key. 814 The final message, R2, completes the BEX and protects the Initiator 815 against replay attacks because the Responder uses the shared key from 816 the Diffie-Hellman exchange to create an HMAC as well as uses the 817 private key of its Host Identity to sign the packet contents. 819 4.1.4. HIP Replay Protection 821 The HIP protocol includes the following mechanisms to protect against 822 malicious packet replays. Responders are protected against replays 823 of I1 packets by virtue of the stateless response to I1 packets with 824 pre-signed R1 messages. Initiators are protected against R1 replays 825 by a monotonically increasing "R1 generation counter" included in the 826 R1. Responders are protected against replays of forged I2 packets by 827 the puzzle mechanism (see Section 4.1.1 above), and optional use of 828 opaque data. Hosts are protected against replays of R2 packets and 829 UPDATEs by use of a less expensive HMAC verification preceding the 830 HIP signature verification. 832 The R1 generation counter is a monotonically increasing 64-bit 833 counter that may be initialized to any value. The scope of the 834 counter MAY be system-wide but there SHOULD be a separate counter for 835 each Host Identity, if there is more than one local host identity. 836 The value of this counter SHOULD be preserved across system reboots 837 and invocations of the HIP base exchange. This counter indicates the 838 current generation of puzzles. Implementations MUST accept puzzles 839 from the current generation and MAY accept puzzles from earlier 840 generations. A system's local counter MUST be incremented at least 841 as often as every time old R1s cease to be valid. The local counter 842 SHOULD never be decremented, otherwise the host exposes its peers to 843 the replay of previously generated, higher numbered R1s. 845 A host may receive more than one R1, either due to sending multiple 846 I1 packets (see Section 6.6.1) or due to a replay of an old R1. When 847 sending multiple I1 packets to the same host, an Initiator SHOULD 848 wait for a small amount of time (a reasonable time may be 2 * 849 expected RTT) after the first R1 reception to allow possibly multiple 850 R1s to arrive, and it SHOULD respond to an R1 among the set with the 851 largest R1 generation counter. If an Initiator is processing an R1 852 or has already sent an I2 packet (still waiting for the R2 packet) 853 and it receives another R1 with a larger R1 generation counter, it 854 MAY elect to restart R1 processing with the fresher R1, as if it were 855 the first R1 to arrive. 857 The R1 generation counter may roll over or may become reset. It is 858 important for an Initiator to be robust to the loss of state about 859 the R1 generation counter of a peer, or to a reset of the peer's 860 counter. It is recommended that, when choosing between multiple R1s, 861 the Initiator prefer to use the R1 that corresponds to the current R1 862 generation counter, but that if it is unable to make progress with 863 that R1, the Initiator may try the other R1s beginning with the R1 864 packet with the highest counter. 866 4.1.5. Refusing a HIP base exchange 868 A HIP-aware host may choose not to accept a HIP base exchange. If 869 the host's policy is to only be an Initiator, and policy allows the 870 establishment of a HIP association with the original Initiator, it 871 should begin its own HIP base exchange. A host MAY choose to have 872 such a policy since only the privacy of the Initiator's HI is 873 protected in the exchange. It should be noted that such behavior can 874 introduce the risk of a race condition if each host's policy is to 875 only be an Initiator, at which point the HIP base exchange will fail. 877 If the host's policy does not permit it to enter into a HIP exchange 878 with the Initiator, it should send an ICMP 'Destination Unreachable, 879 Administratively Prohibited' message. A more complex HIP packet is 880 not used here as it actually opens up more potential DoS attacks than 881 a simple ICMP message. A HIP NOTIFY message is not used because no 882 HIP association exists between the two hosts at that time. 884 4.1.6. Aborting a HIP base exchange 886 Two HIP hosts may encounter situations in which they cannot complete 887 a HIP base exchange because of insufficient support for cryptographic 888 algorithms, in particular the HIT Suites and DH Groups. After 889 receiving the R1 packet, the Initiator can determine whether the 890 Responder supports the required cryptographic operations to 891 successfully establish a HIP association. The Initiator can abort 892 the BEX silently after receiving an R1 packet that indicates an 893 unsupported set of algorithms. The specific conditions are described 894 below. 896 The R1 packet contains a signed list of HIT Suite IDs as supported by 897 the Responder. Therefore, the Initiator can determine whether its 898 source HIT is supported by the Responder. If the HIT Suite ID of the 899 Initiator's HIT is not contained in the list of HIT Suites in the R1, 900 the Initiator MAY abort the handshake silently or MAY restart the 901 handshake with a new I1 packet that contains a source HIT supported 902 by the Responder. 904 During the Handshake, the Initiator and the Responder agree on a 905 single DH Group. The Responder selects the DH Group and its DH 906 public value in the R1 based on the list of DH Suite IDs in the I1 907 packet. If the responder supports none of the DH Groups requested by 908 the Initiator, the Responder selects an arbitrary DH and replies with 909 an R1 containing its list of supported DH Group IDs. In such case, 910 the Initiator receives an R1 packet containing the DH public value 911 for an unrequested DH Group and also the Responder's DH Group list in 912 the signed part of the R1 packet. At this point, the Initiator MAY 913 abort the handshake or MAY restart the handshake by sending a new I1 914 packet containing a selection of DH Group IDs that is supported by 915 the Responder. 917 4.1.7. HIP Downgrade Protection 919 In a downgrade attack, an attacker attempts to unnoticeably 920 manipulate the packets of an Initiator and/or a Responder to 921 influence the result of the cryptographic negotiations in the BEX to 922 its favor. As a result, the victims select weaker cryptographic 923 algorithms than they would otherwise have selected without the 924 attacker's interference. Downgrade attacks can only be successful if 925 they remain un-detected by the victims and the victims falsely assume 926 a secure communication channel. 928 In HIP, almost all packet parameters related to cryptographic 929 negotiations are covered by signatures. These parameters cannot be 930 directly manipulated in a downgrade attack without invalidating the 931 signature. However, signed packets can be subject to replay attacks. 932 In such a replay attack, the attacker could use an old BEX packet 933 with an outdated and weak selection of cryptographic algorithms and 934 replay it instead of a more recent packet with a collection of 935 stronger cryptographic algorithms. Signed packets that could be 936 subject to this replay attack are the R1 and I2 packet. However, 937 replayed R1 and I2 packets cannot be used to successfully establish a 938 HIP BEX because these packets also contain the public DH values of 939 the Initiator and the Responder. Old DH values from replayed packets 940 lead to invalid keying material and mismatching shared secrets 941 because the attacker is unable to derive valid keying material from 942 the DH public keys in the R1 and cannot generate a valid HMAC and 943 signature for a replayed I2. 945 In contrast to the first version of HIP [RFC5201],the version 2 of 946 HIP defined in this document begins the negotiation of the DH Groups 947 already in the first BEX packet, the I1. The I1 packet is, by 948 intention, not protected by a signature to avoid CPU-intensive 949 cryptographic operations for processing floods of I1 packets targeted 950 at the Responder. Hence, the list of DH Group IDs in the I1 packet 951 is vulnerable to forgery and manipulation. To thwart an unnoticed 952 manipulation of the I1 packet, the Responder chooses the DH Group 953 deterministically and includes its own list of DH Group IDs in the 954 signed part of the R1 packet. The Initiator can detect an attempted 955 downgrade attack by comparing the list of DH Group IDs in the R1 956 packet to its own preferences in the I1 packet. If the choice of the 957 DH Group in the R1 packet does not equal to the best match of the two 958 lists (the highest priority DH ID of the Responder that is present in 959 the Initiator's DH list), the Initiator can conclude that its list in 960 the I1 packet was altered by an attacker. In this case, the 961 Initiator can restart or abort the BEX. As mentioned before, the 962 detection of the downgrade attack is sufficient to prevent it. 964 4.1.8. HIP Opportunistic Mode 966 It is possible to initiate a HIP BEX even if the Responder's HI (and 967 HIT) is unknown. In this case, the initial I1 packet contains all 968 zeros as the destination HIT. This kind of connection setup is 969 called opportunistic mode. 971 The Responder may have multiple HITs due to multiple supported HIT 972 Suites. Since the Responder's HIT Suite in the opportunistic mode is 973 not determined by the destination HIT of the I1 packet, the Responder 974 can freely select a HIT of any HIT Suite. The complete set of HIT 975 Suites supported by the Initiator is not known to the Responder. 976 Therefore, the Responder SHOULD select its HIT from the same HIT 977 Suite as the Initiator's HIT (indicated by the HIT suite information 978 in the OGA field of the Initiator's HIT) because this HIT Suite is 979 obviously supported by the Initiator. If the Responder selects a 980 different HIT that is not supported by the Initiator, the Initiator 981 MAY restart the BEX with an I1 packet with a source HIT that is 982 contained in the list of the Responder's HIT Suites in the R1 packet. 984 Note that the Initiator cannot verify the signature of the R1 packet 985 if the Responder's HIT Suite is not supported. Therefore, the 986 Initiator MUST treat R1 packets with unsupported Responder HITs as 987 potentially forged and MUST NOT use any parameters from the 988 unverified R1 besides the HIT Suite List. Moreover, an Initiator 989 that uses an unverified HIT Suite List from an R1 packet to determine 990 a possible source HIT MUST verify that the HIT_SUITE_LIST in the 991 first unverified R1 packet matches the HIT_SUITE_LIST in the second 992 R1 packet for which the Initiator supports the signature algorithm. 993 The Initiator MUST restart the BEX with a new I1 packet for which the 994 algorithm was mentioned in the verifiable R1 if the two lists do not 995 match. This procedure is necessary to mitigate downgrade attacks. 997 There are both security and API issues involved with the 998 opportunistic mode. These issues are described in the reminder of 999 this section. 1001 Given that the Responder's HI is not known by the Initiator, there 1002 must be suitable API calls that allow the Initiator to request, 1003 directly or indirectly, that the underlying system initiates the HIP 1004 base exchange solely based on locators. The Responder's HI will be 1005 tentatively available in the R1 packet, and in an authenticated form 1006 once the R2 packet has been received and verified. Hence, the 1007 Responder's HIT could be communicated to the application via new API 1008 mechanisms. However, with a backwards-compatible API the application 1009 sees only the locators used for the initial contact. Depending on 1010 the desired semantics of the API, this can raise the following 1011 issues: 1013 o The actual locators may later change if an UPDATE message is used, 1014 even if from the API perspective the association still appears to 1015 be between two specific locators. However, the locator update is 1016 still secure and the association is still between the same nodes. 1018 o Different associations between the same two locators may result in 1019 connections to different nodes, if the implementation no longer 1020 remembers which identifier the peer had in an earlier association. 1021 This is possible when the peer's locator has changed for 1022 legitimate reasons or when an attacker pretends to be a node that 1023 has the peer's locator. Therefore, when using opportunistic mode, 1024 HIP implementations MUST NOT place any expectation that the peer's 1025 HI returned in the R1 message matches any HI previously seen from 1026 that address. 1028 If the HIP implementation and application do not have the same 1029 understanding of what constitutes an association, this may even 1030 happen within the same association. For instance, an 1031 implementation may not know when HIP state can be purged for UDP- 1032 based applications. 1034 In addition, the following security considerations apply. The 1035 generation counter mechanism will be less efficient in protecting 1036 against replays of the R1 packet, given that the Responder can choose 1037 a replay that uses an arbitrary HI, not just the one given in the I1 1038 packet. 1040 More importantly, the opportunistic exchange is vulnerable to man-in- 1041 the-middle attacks, because the Initiator does not have any public 1042 key information about the peer. To assess the impacts of this 1043 vulnerability, we compare it to vulnerabilities in current, non-HIP- 1044 capable communications. 1046 An attacker on the path between the two peers can insert itself as a 1047 man-in-the-middle by providing its own identifier to the Initiator 1048 and then initiating another HIP association towards the Responder. 1049 For this to be possible, the Initiator must employ opportunistic 1050 mode, and the Responder must be configured to accept a connection 1051 from any HIP-enabled node. 1053 An attacker outside the path will be unable to do so, given that it 1054 cannot respond to the messages in the base exchange. 1056 These security properties are characteristic also of communications 1057 in the current Internet. A client contacting a server without 1058 employing end-to-end security may find itself talking to the server 1059 via a man-in-the-middle, assuming again that the server is willing to 1060 talk to anyone. 1062 If end-to-end security is in place, then the worst that can happen in 1063 both the opportunistic HIP and non-HIP (normal IP) cases is denial- 1064 of-service; an entity on the path can disrupt communications, but 1065 will be unable to successfully insert itself as a man-in-the-middle. 1067 However, once the opportunistic exchange has successfully completed, 1068 HIP provides confidentiality and integrity protection for the 1069 communications, and can securely change the locators of the 1070 endpoints. 1072 As a result, opportunistic mode in HIP offers a "better than nothing" 1073 security model. Initially, a base exchange authenticated in the 1074 opportunistic mode involves a leap of faith subject to man-in-the- 1075 middle attacks, but subsequent datagrams related to the same HIP 1076 association cannot be compromised by a new man-in-the-middle attack, 1077 and further, if the man-in-the-middle moves away from the path of the 1078 active association, the attack would be exposed after the fact. 1079 Thus, it can be stated that opportunistic mode in HIP is at least as 1080 secure as unprotected IP-based communications. 1082 4.2. Updating a HIP Association 1084 A HIP association between two hosts may need to be updated over time. 1085 Examples include the need to rekey expiring security associations, 1086 add new security associations, or change IP addresses associated with 1087 hosts. The UPDATE packet is used for those and other similar 1088 purposes. This document only specifies the UPDATE packet format and 1089 basic processing rules, with mandatory parameters. The actual usage 1090 is defined in separate specifications. 1092 HIP provides a general purpose UPDATE packet, which can carry 1093 multiple HIP parameters, for updating the HIP state between two 1094 peers. The UPDATE mechanism has the following properties: 1096 UPDATE messages carry a monotonically increasing sequence number 1097 and are explicitly acknowledged by the peer. Lost UPDATEs or 1098 acknowledgments may be recovered via retransmission. Multiple 1099 UPDATE messages may be outstanding under certain circumstances. 1101 UPDATE is protected by both HIP_MAC and HIP_SIGNATURE parameters, 1102 since processing UPDATE signatures alone is a potential DoS attack 1103 against intermediate systems. 1105 UPDATE packets are explicitly acknowledged by the use of an 1106 acknowledgment parameter that echoes an individual sequence number 1107 received from the peer. A single UPDATE packet may contain both a 1108 sequence number and one or more acknowledgment numbers (i.e., 1109 piggybacked acknowledgment(s) for the peer's UPDATE). 1111 The UPDATE packet is defined in Section 5.3.5. 1113 4.3. Error Processing 1115 HIP error processing behavior depends on whether or not there exists 1116 an active HIP association. In general, if a HIP association exists 1117 between the sender and receiver of a packet causing an error 1118 condition, the receiver SHOULD respond with a NOTIFY packet. On the 1119 other hand, if there are no existing HIP associations between the 1120 sender and receiver, or the receiver cannot reasonably determine the 1121 identity of the sender, the receiver MAY respond with a suitable ICMP 1122 message; see Section 5.4 for more details. 1124 The HIP protocol and state machine are designed to recover from one 1125 of the parties crashing and losing its state. The following 1126 scenarios describe the main use cases covered by the design. 1128 No prior state between the two systems. 1130 The system with data to send is the Initiator. The process 1131 follows the standard four-packet base exchange, establishing 1132 the HIP association. 1134 The system with data to send has no state with the receiver, but 1135 the receiver has a residual HIP association. 1137 The system with data to send is the Initiator. The Initiator 1138 acts as in no prior state, sending an I1 packet and receiving 1139 an R1 packet. When the Responder receives a valid I2 packet, 1140 the old association is 'discovered' and deleted, and the new 1141 association is established. 1143 The system with data to send has a HIP association, but the 1144 receiver does not. 1146 The system sends data on the outbound user data security 1147 association. The receiver 'detects' the situation when it 1148 receives a user data packet that it cannot match to any HIP 1149 association. The receiving host MUST discard this packet. 1151 The receiving host SHOULD send an ICMP packet, with the type 1152 Parameter Problem, to inform the sender that the HIP 1153 association does not exist (see Section 5.4), and it MAY 1154 initiate a new HIP BEX. However, responding with these 1155 optional mechanisms is implementation or policy dependent. If 1156 the sending application doesn't expect a response, the system 1157 could possibly send a large number of packets in this state, so 1158 for this reason, the sending of one or more ICMP packets is 1159 RECOMMENDED. However, any such responses MUST be rate-limited 1160 to prevent abuse (see Section 5.4). 1162 4.4. HIP State Machine 1164 The HIP protocol itself has little state. In the HIP base exchange, 1165 there is an Initiator and a Responder. Once the security 1166 associations (SAs) are established, this distinction is lost. If the 1167 HIP state needs to be re-established, the controlling parameters are 1168 which peer still has state and which has a datagram to send to its 1169 peer. The following state machine attempts to capture these 1170 processes. 1172 The state machine is symmetric and is presented in a single system 1173 view, representing either an Initiator or a Responder. The state 1174 machine is not a full representation of the processing logic. 1175 Additional processing rules are presented in the packet definitions. 1176 Hence, both are needed to completely implement HIP. 1178 This document extends the state machine as defined in [RFC5201] and 1179 introduces a restart option to allow for the negotiation of 1180 cryptographic algorithms. The extension to the previous state 1181 machine in [RFC5201] is a transition from state I1-SENT to I1-SENT - 1182 the restart option. An Initiator is required to restart the HIP base 1183 exchange if the Responder does not support the HIT Suite of the 1184 Initiator. In this case, the Initiator restarts the HIP base 1185 exchange by sending a new I1 packet with a source HIT supported by 1186 the Responder. 1188 Implementors must understand that the state machine, as described 1189 here, is informational. Specific implementations are free to 1190 implement the actual processing logic differently. Section 6 1191 describes the packet processing rules in more detail. This state 1192 machine focuses on the HIP I1, R1, I2, and R2 packets only. New 1193 states and state transitions may be introduced by mechanisms in other 1194 specifications (such as mobility and multihoming). 1196 4.4.1. State Machine Terminology 1198 Unused Association Lifetime (UAL): Implementation-specific time for 1199 which, if no packet is sent or received for this time interval, a 1200 host MAY begin to tear down an active HIP association. 1202 Maximum Segment Lifetime (MSL): Maximum time that a HIP packet is 1203 expected to spend in the network. A default value of 2 minutes 1204 has been borrowed from [RFC0793] because it is a prevailing 1205 assumption for packet lifetimes. 1207 Exchange Complete (EC): Time that the host spends at the R2-SENT 1208 state before it moves to the ESTABLISHED state. The time is n * 1209 I2 retransmission timeout, where n is about I2_RETRIES_MAX. 1211 Receive ANYOTHER: Any received packet for which no state 1212 transitions or processing rules are defined for a given state. 1214 4.4.2. HIP States 1215 +---------------------+---------------------------------------------+ 1216 | State | Explanation | 1217 +---------------------+---------------------------------------------+ 1218 | UNASSOCIATED | State machine start | 1219 | | | 1220 | I1-SENT | Initiating base exchange | 1221 | | | 1222 | I2-SENT | Waiting to complete base exchange | 1223 | | | 1224 | R2-SENT | Waiting to complete base exchange | 1225 | | | 1226 | ESTABLISHED | HIP association established | 1227 | | | 1228 | CLOSING | HIP association closing, no data can be | 1229 | | sent | 1230 | | | 1231 | CLOSED | HIP association closed, no data can be sent | 1232 | | | 1233 | E-FAILED | HIP base exchange failed | 1234 +---------------------+---------------------------------------------+ 1236 Table 1: HIP States 1238 4.4.3. HIP State Processes 1239 System behavior in state UNASSOCIATED, Table 2. 1241 +----------------------------+--------------------------------------+ 1242 | Trigger | Action | 1243 +----------------------------+--------------------------------------+ 1244 | User data to send, | Send I1 and go to I1-SENT | 1245 | requiring a new HIP | | 1246 | association | | 1247 | | | 1248 | Receive I1 | Send R1 and stay at UNASSOCIATED | 1249 | | | 1250 | Receive I2, process | If successful, send R2 and go to | 1251 | | R2-SENT | 1252 | | | 1253 | | If fail, stay at UNASSOCIATED | 1254 | | | 1255 | Receive user data for an | Optionally send ICMP as defined in | 1256 | unknown HIP association | Section 5.4 and stay at UNASSOCIATED | 1257 | | | 1258 | Receive CLOSE | Optionally send ICMP Parameter | 1259 | | Problem and stay at UNASSOCIATED | 1260 | | | 1261 | Receive ANYOTHER | Drop and stay at UNASSOCIATED | 1262 +----------------------------+--------------------------------------+ 1264 Table 2: UNASSOCIATED - Start state 1266 System behavior in state I1-SENT, Table 3. 1268 +---------------------+---------------------------------------------+ 1269 | Trigger | Action | 1270 +---------------------+---------------------------------------------+ 1271 | Receive I1 from | If the local HIT is smaller than the peer | 1272 | Responder | HIT, drop I1 and stay at I1-SENT (see | 1273 | | Section 6.5 for HIT comparison) | 1274 | | | 1275 | | If the local HIT is greater than the peer | 1276 | | HIT, send R1 and stay at I1-SENT | 1277 | | | 1278 | Receive I2, process | If successful, send R2 and go to R2-SENT | 1279 | | | 1280 | | If fail, stay at I1-SENT | 1281 | | | 1282 | Receive R1, process | If the HIT Suite of the local HIT is not | 1283 | | supported by the peer, select supported | 1284 | | local HIT, send I1 and stay at I1-SENT | 1285 | | | 1286 | | If successful, send I2 and go to I2-SENT | 1287 | | | 1288 | | If fail, stay at I1-SENT | 1289 | | | 1290 | Receive ANYOTHER | Drop and stay at I1-SENT | 1291 | | | 1292 | Timeout | Increment trial counter | 1293 | | | 1294 | | If counter is less than I1_RETRIES_MAX, | 1295 | | send I1 and stay at I1-SENT | 1296 | | | 1297 | | If counter is greater than I1_RETRIES_MAX, | 1298 | | go to E-FAILED | 1299 +---------------------+---------------------------------------------+ 1301 Table 3: I1-SENT - Initiating the HIP base exchange 1303 System behavior in state I2-SENT, Table 4. 1305 +---------------------+---------------------------------------------+ 1306 | Trigger | Action | 1307 +---------------------+---------------------------------------------+ 1308 | Receive I1 | Send R1 and stay at I2-SENT | 1309 | | | 1310 | Receive R1, process | If successful, send I2 and stay at I2-SENT | 1311 | | | 1312 | | If fail, stay at I2-SENT | 1313 | | | 1314 | Receive I2, process | If successful and local HIT is smaller than | 1315 | | the peer HIT, drop I2 and stay at I2-SENT | 1316 | | | 1317 | | If successful and local HIT is greater than | 1318 | | the peer HIT, send R2 and go to R2-SENT | 1319 | | | 1320 | | If fail, stay at I2-SENT | 1321 | | | 1322 | Receive R2, process | If successful, go to ESTABLISHED | 1323 | | | 1324 | | If fail, stay at I2-SENT | 1325 | | | 1326 | Receive CLOSE, | If successful, send CLOSE_ACK and go to | 1327 | process | CLOSED | 1328 | | | 1329 | | If fail, stay at I2-SENT | 1330 | | | 1331 | Receive ANYOTHER | Drop and stay at I2-SENT | 1332 | | | 1333 | Timeout | Increment trial counter | 1334 | | | 1335 | | If counter is less than I2_RETRIES_MAX, | 1336 | | send I2 and stay at I2-SENT | 1337 | | | 1338 | | If counter is greater than I2_RETRIES_MAX, | 1339 | | go to E-FAILED | 1340 +---------------------+---------------------------------------------+ 1342 Table 4: I2-SENT - Waiting to finish the HIP base exchange 1344 System behavior in state R2-SENT, Table 5. 1346 +------------------------+------------------------------------------+ 1347 | Trigger | Action | 1348 +------------------------+------------------------------------------+ 1349 | Receive I1 | Send R1 and stay at R2-SENT | 1350 | | | 1351 | Receive I2, process | If successful, send R2 and stay at | 1352 | | R2-SENT | 1353 | | | 1354 | | If fail, stay at R2-SENT | 1355 | | | 1356 | Receive R1 | Drop and stay at R2-SENT | 1357 | | | 1358 | Receive R2 | Drop and stay at R2-SENT | 1359 | | | 1360 | Receive data or UPDATE | Move to ESTABLISHED | 1361 | | | 1362 | Exchange Complete | Move to ESTABLISHED | 1363 | Timeout | | 1364 | | | 1365 | Receive CLOSE, process | If successful, send CLOSE_ACK and go to | 1366 | | CLOSED | 1367 | | | 1368 | | If fail, stay at ESTABLISHED | 1369 | | | 1370 | Receive CLOSE_ACK | Drop and stay at R2-SENT | 1371 | | | 1372 | Receive NOTIFY | Process and stay at R2-SENT | 1373 +------------------------+------------------------------------------+ 1375 Table 5: R2-SENT - Waiting to finish HIP 1377 System behavior in state ESTABLISHED, Table 6. 1379 +---------------------+---------------------------------------------+ 1380 | Trigger | Action | 1381 +---------------------+---------------------------------------------+ 1382 | Receive I1 | Send R1 and stay at ESTABLISHED | 1383 | | | 1384 | Receive I2 | Process with puzzle and possible Opaque | 1385 | | data verification | 1386 | | | 1387 | | If successful, send R2, drop old HIP | 1388 | | association, establish a new HIP | 1389 | | association and go to R2-SENT | 1390 | | | 1391 | | If fail, stay at ESTABLISHED | 1392 | | | 1393 | Receive R1 | Drop and stay at ESTABLISHED | 1394 | | | 1395 | Receive R2 | Drop and stay at ESTABLISHED | 1396 | | | 1397 | Receive user data | Process and stay at ESTABLISHED | 1398 | for HIP association | | 1399 | | | 1400 | No packet | Send CLOSE and go to CLOSING | 1401 | sent/received | | 1402 | during UAL minutes | | 1403 | | | 1404 | Receive UPDATE | Process and stay at ESTABLISHED | 1405 | | | 1406 | Receive CLOSE, | If successful, send CLOSE_ACK and go to | 1407 | process | CLOSED | 1408 | | | 1409 | | If fail, stay at ESTABLISHED | 1410 | | | 1411 | Receive CLOSE_ACK | Drop and stay at ESTABLISHED | 1412 | | | 1413 | Receive NOTIFY | Process and stay at ESTABLISHED | 1414 +---------------------+---------------------------------------------+ 1416 Table 6: ESTABLISHED - HIP association established 1418 System behavior in state CLOSING, Table 7. 1420 +----------------------------+--------------------------------------+ 1421 | Trigger | Action | 1422 +----------------------------+--------------------------------------+ 1423 | User data to send, | Send I1 and stay at CLOSING | 1424 | requires the creation of | | 1425 | another incarnation of the | | 1426 | HIP association | | 1427 | | | 1428 | Receive I1 | Send R1 and stay at CLOSING | 1429 | | | 1430 | Receive I2, process | If successful, send R2 and go to | 1431 | | R2-SENT | 1432 | | | 1433 | | If fail, stay at CLOSING | 1434 | | | 1435 | Receive R1, process | If successful, send I2 and go to | 1436 | | I2-SENT | 1437 | | | 1438 | | If fail, stay at CLOSING | 1439 | | | 1440 | Receive CLOSE, process | If successful, send CLOSE_ACK, | 1441 | | discard state and go to CLOSED | 1442 | | | 1443 | | If fail, stay at CLOSING | 1444 | | | 1445 | Receive CLOSE_ACK, process | If successful, discard state and go | 1446 | | to UNASSOCIATED | 1447 | | | 1448 | | If fail, stay at CLOSING | 1449 | | | 1450 | Receive ANYOTHER | Drop and stay at CLOSING | 1451 | | | 1452 | Timeout | Increment timeout sum and reset | 1453 | | timer. If timeout sum is less than | 1454 | | UAL+MSL minutes, retransmit CLOSE | 1455 | | and stay at CLOSING | 1456 | | | 1457 | | If timeout sum is greater than | 1458 | | UAL+MSL minutes, go to UNASSOCIATED | 1459 +----------------------------+--------------------------------------+ 1461 Table 7: CLOSING - HIP association has not been used for UAL minutes 1462 System behavior in state CLOSED, Table 8. 1464 +----------------------------------------+--------------------------+ 1465 | Trigger | Action | 1466 +----------------------------------------+--------------------------+ 1467 | Datagram to send, requires the | Send I1, and stay at | 1468 | creation of another incarnation of the | CLOSED | 1469 | HIP association | | 1470 | | | 1471 | Receive I1 | Send R1 and stay at | 1472 | | CLOSED | 1473 | | | 1474 | Receive I2, process | If successful, send R2 | 1475 | | and go to R2-SENT | 1476 | | | 1477 | | If fail, stay at CLOSED | 1478 | | | 1479 | Receive R1, process | If successful, send I2 | 1480 | | and go to I2-SENT | 1481 | | | 1482 | | If fail, stay at CLOSED | 1483 | | | 1484 | Receive CLOSE, process | If successful, send | 1485 | | CLOSE_ACK, stay at | 1486 | | CLOSED | 1487 | | | 1488 | | If fail, stay at CLOSED | 1489 | | | 1490 | Receive CLOSE_ACK, process | If successful, discard | 1491 | | state and go to | 1492 | | UNASSOCIATED | 1493 | | | 1494 | | If fail, stay at CLOSED | 1495 | | | 1496 | Receive ANYOTHER | Drop and stay at CLOSED | 1497 | | | 1498 | Timeout (UAL+2MSL) | Discard state, and go to | 1499 | | UNASSOCIATED | 1500 +----------------------------------------+--------------------------+ 1502 Table 8: CLOSED - CLOSE_ACK sent, resending CLOSE_ACK if necessary 1504 System behavior in state E-FAILED, Table 9. 1506 +-------------------------+-----------------------------------------+ 1507 | Trigger | Action | 1508 +-------------------------+-----------------------------------------+ 1509 | Wait for | Go to UNASSOCIATED. Re-negotiation is | 1510 | implementation-specific | possible after moving to UNASSOCIATED | 1511 | time | state. | 1512 +-------------------------+-----------------------------------------+ 1514 Table 9: E-FAILED - HIP failed to establish association with peer 1516 4.4.4. Simplified HIP State Diagram 1518 The following diagram (Figure 2) shows the major state transitions. 1519 Transitions based on received packets implicitly assume that the 1520 packets are successfully authenticated or processed. 1522 +--+ +----------------------------+ 1523 recv I1, send R1 | | | | 1524 | v v | 1525 +--------------+ recv I2, send R2 | 1526 +----------------| UNASSOCIATED |----------------+ | 1527 datagram | +--+ +--------------+ | | 1528 to send, | | | Alg. not supported, | | 1529 send I1 | | | send I1 | | 1530 . v | v | | 1531 . +---------+ recv I2, send R2 | | 1532 +---->| I1-SENT |--------------------------------------+ | | 1533 | +---------+ +----------------------+ | | | 1534 | | recv R2, | recv I2, send R2 | | | | 1535 | v send I2 | v v v | 1536 | +---------+ | +---------+ | 1537 | +--->| I2-SENT |----------+ +--------------| R2-SENT |<---+ | 1538 | | +---------+ | +---------+ | | 1539 | | | |recv R2 | data or| | | 1540 | |recv R1, | | | EC timeout| | | 1541 | |send I2 +--|-----------------+ | receive I2,| | 1542 | | | | +-------------+ | send R2| | 1543 | | | +------>| ESTABLISHED |<----------+ | | 1544 | | | +-------------+ | | 1545 | | | | | | receive I2, send R2 | | 1546 | | +------------+ | +-------------------------------+ | 1547 | | | +-----------+ | | 1548 | | | no packet sent/received| +---+ | | 1549 | | | for UAL min, send CLOSE| | |timeout | | 1550 | | | v v |(UAL+MSL) | | 1551 | | | +---------+ |retransmit | | 1552 +--|----------|------------------------| CLOSING |-+CLOSE | | 1553 | | +---------+ | | 1554 | | | | | | | | 1555 +----------|-------------------------+ | | +----------------+ | 1556 | | +-----------+ +------------------|--+ 1557 | | |recv CLOSE, recv CLOSE_ACK | | 1558 | +-------------+ |send CLOSE_ACK or timeout | | 1559 | recv CLOSE, | | (UAL+MSL) | | 1560 | send CLOSE_ACK v v | | 1561 | +--------+ receive I2, send R2 | | 1562 +---------------------| CLOSED |------------------------------+ | 1563 +--------+ | 1564 ^ | | | 1565 recv CLOSE, send CLOSE_ACK| | | timeout (UAL+2MSL) | 1566 +-+ +------------------------------------+ 1568 Figure 2 1570 4.5. User Data Considerations 1572 4.5.1. TCP and UDP Pseudo-Header Computation for User Data 1574 When computing TCP and UDP checksums on user data packets that flow 1575 through sockets bound to HITs, the IPv6 pseudo-header format 1576 [RFC2460] MUST be used, even if the actual addresses in the header of 1577 the packet are IPv4 addresses. Additionally, the HITs MUST be used 1578 in place of the IPv6 addresses in the IPv6 pseudo-header. Note that 1579 the pseudo-header for actual HIP payloads is computed differently; 1580 see Section 5.1.1. 1582 4.5.2. Sending Data on HIP Packets 1584 Other documents may define how to include user data in various HIP 1585 packets. However, currently the HIP header is a terminal header, and 1586 not followed by any other headers. 1588 4.5.3. Transport Formats 1590 The actual data transmission format, used for user data after the HIP 1591 base exchange, is not defined in this document. Such transport 1592 formats and methods are described in separate specifications. All 1593 HIP implementations MUST implement, at minimum, the ESP transport 1594 format for HIP [I-D.ietf-hip-rfc5202-bis]. The transport format to 1595 be chosen is negotiated in the base exchange. The Responder 1596 expresses its preference of the transport format in the 1597 TRANSPORT_FORMAT_LIST in the R1 packet and the Initiator selects one 1598 transport format and adds the respective HIP parameter to the I2 1599 packet. 1601 4.5.4. Reboot, Timeout, and Restart of HIP 1603 Simulating a loss of state is a potential DoS attack. The following 1604 process has been crafted to manage state recovery without presenting 1605 a DoS opportunity. 1607 If a host reboots or the HIP association times out, it has lost its 1608 HIP state. If the host that lost state has a datagram to send to the 1609 peer, it simply restarts the HIP base exchange. After the base 1610 exchange has completed, the Initiator can create a new payload 1611 association and start sending data. The peer does not reset its 1612 state until it receives a valid I2 packet. 1614 If a system receives a user data packet that cannot be matched to any 1615 existing HIP association, it is possible that it has lost the state 1616 and its peer has not. It MAY send an ICMP packet with the Parameter 1617 Problem type, and with the pointer pointing to the referred HIP- 1618 related association information. Reacting to such traffic depends on 1619 the implementation and the environment where the implementation is 1620 used. 1622 If the host, that apparently has lost its state, decides to restart 1623 the HIP base exchange, it sends an I1 packet to the peer. After the 1624 base exchange has been completed successfully, the Initiator can 1625 create a new HIP association and the peer drops its old payload 1626 associations and creates a new one. 1628 4.6. Certificate Distribution 1630 This document does not define how to use certificates or how to 1631 transfer them between hosts. These functions are expected to be 1632 defined in a future specification as for HIP Version 1 [RFC6253]. A 1633 parameter type value, meant to be used for carrying certificates, is 1634 reserved, though: CERT, Type 768; see Section 5.2. 1636 5. Packet Formats 1638 5.1. Payload Format 1640 All HIP packets start with a fixed header. 1642 0 1 2 3 1643 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 1644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1645 | Next Header | Header Length |0| Packet Type |Version| RES.|1| 1646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1647 | Checksum | Controls | 1648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1649 | Sender's Host Identity Tag (HIT) | 1650 | | 1651 | | 1652 | | 1653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1654 | Receiver's Host Identity Tag (HIT) | 1655 | | 1656 | | 1657 | | 1658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1659 | | 1660 / HIP Parameters / 1661 / / 1662 | | 1663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1664 The HIP header is logically an IPv6 extension header. However, this 1665 document does not describe processing for Next Header values other 1666 than decimal 59, IPPROTO_NONE, the IPv6 'no next header' value. 1667 Future documents MAY define behavior for also other values. However, 1668 current implementations MUST ignore trailing data if an unimplemented 1669 Next Header value is received. 1671 The Header Length field contains the combined length of the HIP 1672 Header and HIP parameters in 8-byte units, excluding the first 8 1673 bytes. Since all HIP headers MUST contain the sender's and 1674 receiver's HIT fields, the minimum value for this field is 4, and 1675 conversely, the maximum length of the HIP Parameters field is 1676 (255*8)-32 = 2008 bytes (see Section 5.1.3 regarding HIP 1677 fragmentation). Note: this sets an additional limit for sizes of 1678 parameters included in the Parameters field, independent of the 1679 individual parameter maximum lengths. 1681 The Packet Type indicates the HIP packet type. The individual packet 1682 types are defined in the relevant sections. If a HIP host receives a 1683 HIP packet that contains an unrecognized packet type, it MUST drop 1684 the packet. 1686 The HIP Version field is four bits. The version defined in this 1687 document is 2. The version number is expected to be incremented only 1688 if there are incompatible changes to the protocol. Most extensions 1689 can be handled by defining new packet types, new parameter types, or 1690 new Controls (see Section 5.1.2) . 1692 The following three bits are reserved for future use. They MUST be 1693 zero when sent, and they MUST be ignored when handling a received 1694 packet. 1696 The two fixed bits in the header are reserved for SHIM6 compatibility 1697 [RFC5533], Section 5.3. For implementations adhering (only) to this 1698 specification, they MUST be set as shown when sending and MUST be 1699 ignored when receiving. This is to ensure optimal forward 1700 compatibility. Note that for implementations that implement other 1701 compatible specifications in addition to this specification, the 1702 corresponding rules may well be different. For example, an 1703 implementation that implements both this specification and the SHIM6 1704 protocol may need to check these bits in order to determine how to 1705 handle the packet. 1707 The HIT fields are always 128 bits (16 bytes) long. 1709 5.1.1. Checksum 1711 Since the checksum covers the source and destination addresses in the 1712 IP header, it MUST be recomputed on HIP-aware NAT devices. 1714 If IPv6 is used to carry the HIP packet, the pseudo-header [RFC2460] 1715 contains the source and destination IPv6 addresses, HIP packet length 1716 in the pseudo-header length field, a zero field, and the HIP protocol 1717 number (see Section 5.1) in the Next Header field. The length field 1718 is in bytes and can be calculated from the HIP header length field: 1720 (HIP Header Length + 1) * 8. 1722 In case of using IPv4, the IPv4 UDP pseudo-header format [RFC0768] is 1723 used. In the pseudo-header, the source and destination addresses are 1724 those used in the IP header, the zero field is obviously zero, the 1725 protocol is the HIP protocol number (see Section 4), and the length 1726 is calculated as in the IPv6 case. 1728 5.1.2. HIP Controls 1730 The HIP Controls field conveys information about the structure of the 1731 packet and capabilities of the host. 1733 The following fields have been defined: 1735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1736 | | | | | | | | | | | | | | | |A| 1737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1739 A - Anonymous: If this is set, the sender's HI in this packet is 1740 anonymous, i.e., one not listed in a directory. Anonymous HIs 1741 SHOULD NOT be stored. This control is set in packets using 1742 anonymous sender HIs. The peer receiving an anonymous HI in an R1 1743 or I2 may choose to refuse it. 1745 The rest of the fields are reserved for future use and MUST be set to 1746 zero in sent packets and MUST be ignored in received packets. 1748 5.1.3. HIP Fragmentation Support 1750 A HIP implementation MUST support IP fragmentation/reassembly. 1751 Fragment reassembly MUST be implemented in both IPv4 and IPv6, but 1752 fragment generation is REQUIRED to be implemented in IPv4 (IPv4 1753 stacks and networks will usually do this by default) and RECOMMENDED 1754 to be implemented in IPv6. In IPv6 networks, the minimum MTU is 1755 larger, 1280 bytes, than in IPv4 networks. The larger MTU size is 1756 usually sufficient for most HIP packets, and therefore fragment 1757 generation may not be needed. If it is expected that a host will 1758 send HIP packets that are larger than the minimum IPv6 MTU, the 1759 implementation MUST implement fragment generation even for IPv6. 1761 In IPv4 networks, HIP packets may encounter low MTUs along their 1762 routed path. Since basic HIP, as defined in this document, does not 1763 provide a mechanism to use multiple IP datagrams for a single HIP 1764 packet, support for path MTU discovery does not bring any value to 1765 HIP in IPv4 networks. HIP-aware NAT devices SHOULD perform IPv4 1766 reassembly/fragmentation for HIP packets. 1768 All HIP implementations have to be careful while employing a 1769 reassembly algorithm so that the algorithm is sufficiently resistant 1770 to DoS attacks. 1772 Certificate chains can cause the packet to be fragmented and 1773 fragmentation can open implementations to denial-of-service attacks 1774 [KAU03]. "Hash and URL" schemes as defined in [RFC6253] for HIP 1775 version 1 may be used to avoid fragmentation and mitigate resulting 1776 DoS attacks. 1778 5.2. HIP Parameters 1780 The HIP parameters carry information that is necessary for 1781 establishing and maintaining a HIP association. For example, the 1782 peer's public keys as well as the signaling for negotiating ciphers 1783 and payload handling are encapsulated in HIP parameters. Additional 1784 information, meaningful for end-hosts or middleboxes, may also be 1785 included in HIP parameters. The specification of the HIP parameters 1786 and their mapping to HIP packets and packet types is flexible to 1787 allow HIP extensions to define new parameters and new protocol 1788 behavior. 1790 In HIP packets, HIP parameters are ordered according to their numeric 1791 type number and encoded in TLV format. 1793 The following parameter types are currently defined. 1795 +------------------------+-------+-----------+----------------------+ 1796 | TLV | Type | Length | Data | 1797 +------------------------+-------+-----------+----------------------+ 1798 | R1_COUNTER | 129 | 12 | Puzzle generation | 1799 | | | | counter | 1800 | | | | | 1801 | PUZZLE | 257 | 12 | K and Random #I | 1802 | | | | | 1803 | SOLUTION | 321 | 20 | K, Random #I and | 1804 | | | | puzzle solution J | 1805 | | | | | 1806 | SEQ | 385 | 4 | UPDATE packet ID | 1807 | | | | number | 1808 | | | | | 1809 | ACK | 449 | variable | UPDATE packet ID | 1810 | | | | number | 1811 | | | | | 1812 | DH_GROUP_LIST | 511 | variable | Ordered list of DH | 1813 | | | | Group IDs supported | 1814 | | | | by a host | 1815 | | | | | 1816 | DIFFIE_HELLMAN | 513 | variable | public key | 1817 | | | | | 1818 | HIP_CIPHER | 579 | variable | List of HIP | 1819 | | | | encryption | 1820 | | | | algorithms | 1821 | | | | | 1822 | ENCRYPTED | 641 | variable | Encrypted part of a | 1823 | | | | HIP packet | 1824 | | | | | 1825 | HOST_ID | 705 | variable | Host Identity with | 1826 | | | | Fully-Qualified | 1827 | | | | Domain FQDN (Name) | 1828 | | | | or Network Access | 1829 | | | | Identifier (NAI) | 1830 | | | | | 1831 | HIT_SUITE_LIST | 715 | variable | Ordered list of the | 1832 | | | | HIT suites supported | 1833 | | | | by the Responder | 1834 | | | | | 1835 | CERT | 768 | variable | HI Certificate; used | 1836 | | | | to transfer | 1837 | | | | certificates. | 1838 | | | | Specified in a | 1839 | | | | separate docment. | 1840 | | | | | 1841 | NOTIFICATION | 832 | variable | Informational data | 1842 | | | | | 1843 | ECHO_REQUEST_SIGNED | 897 | variable | Opaque data to be | 1844 | | | | echoed back; signed | 1845 | | | | | 1846 | ECHO_RESPONSE_SIGNED | 961 | variable | Opaque data echoed | 1847 | | | | back by request; | 1848 | | | | signed | 1849 | | | | | 1850 | TRANSPORT_FORMAT_LIST | 2049 | Ordered | variable | 1851 | | | list of | | 1852 | | | preferred | | 1853 | | | HIP | | 1854 | | | transport | | 1855 | | | type | | 1856 | | | numbers | | 1857 | | | | | 1858 | HIP_MAC | 61505 | variable | HMAC-based message | 1859 | | | | authentication code, | 1860 | | | | with key material | 1861 | | | | from KEYMAT | 1862 | | | | | 1863 | HIP_MAC_2 | 61569 | variable | HMAC based message | 1864 | | | | authentication code, | 1865 | | | | with key material | 1866 | | | | from KEYMAT. Unlike | 1867 | | | | HIP_MAC, the HOST_ID | 1868 | | | | parameter is | 1869 | | | | included in | 1870 | | | | HIP_MAC_2 | 1871 | | | | calculation. | 1872 | | | | | 1873 | HIP_SIGNATURE_2 | 61633 | variable | Signature used in R1 | 1874 | | | | packet | 1875 | | | | | 1876 | HIP_SIGNATURE | 61697 | variable | Signature of the | 1877 | | | | packet | 1878 | | | | | 1879 | ECHO_REQUEST_UNSIGNED | 63661 | variable | Opaque data to be | 1880 | | | | echoed back; after | 1881 | | | | signature | 1882 | | | | | 1883 | ECHO_RESPONSE_UNSIGNED | 63425 | variable | Opaque data echoed | 1884 | | | | back by request; | 1885 | | | | after signature | 1886 +------------------------+-------+-----------+----------------------+ 1888 As the ordering (from lowest to highest) of HIP parameters is 1889 strictly enforced (see Section 5.2.1), the parameter type values for 1890 existing parameters have been spaced to allow for future protocol 1891 extensions. 1893 The following parameter type number ranges are defined. 1895 +---------------+---------------------------------------------------+ 1896 | Type Range | Purpose | 1897 +---------------+---------------------------------------------------+ 1898 | 0 - 1023 | Handshake | 1899 | | | 1900 | 1024 - 2047 | Reserved | 1901 | | | 1902 | 2048 - 4095 | Parameters related to HIP transport formats | 1903 | | | 1904 | 4096 - 8191 | Signed parameters allocated through specification | 1905 | | documents | 1906 | | | 1907 | 8192 - 32767 | Reserved | 1908 | | | 1909 | 32768 - 49151 | Free for experimentation. Signed parameters. | 1910 | | | 1911 | 41952 - 61439 | Reserved | 1912 | | | 1913 | 61440 - 64443 | Signatures and (signed) MACs | 1914 | | | 1915 | 62464 - 63487 | Parameters that are neither signed nor MACed | 1916 | | | 1917 | 63488 - 64511 | Rendezvous and relaying | 1918 | | | 1919 | 64512 - 65023 | Parameters that are neither signed nor MACed | 1920 | | | 1921 | 65024 - 65535 | Reserved | 1922 +---------------+---------------------------------------------------+ 1924 The process for defining new parameters is described in Section 5.2.2 1925 of this document. 1927 The range between 32768 (2^15) and 49151 (2^15 + 2^14) are free for 1928 experimentation. Types from this range SHOULD be selected in a 1929 random fashion to reduce the probability of collisions. 1931 5.2.1. TLV Format 1933 The TLV-encoded parameters are described in the following 1934 subsections. The type-field value also describes the order of these 1935 fields in the packet. The parameters MUST be included in the packet 1936 so that their types form an increasing order. If multiple parameters 1937 with the same type number are in one packet, the parameters with the 1938 same type MUST be consecutive in the packet. If the order does not 1939 follow this rule, the packet is considered to be malformed and it 1940 MUST be discarded. 1942 Parameters using type values from 2048 up to 4095 are related to 1943 transport formats. Currently, one transport format is defined: the 1944 ESP transport format [I-D.ietf-hip-rfc5202-bis]. 1946 All of the encoded TLV parameters have a length (that includes the 1947 Type and Length fields), which is a multiple of 8 bytes. When 1948 needed, padding MUST be added to the end of the parameter so that the 1949 total length is a multiple of 8 bytes. This rule ensures proper 1950 alignment of data. Any added padding bytes MUST be zeroed by the 1951 sender, and their values SHOULD NOT be checked by the receiver. 1953 The Length field indicates the length of the Contents field (in 1954 bytes). Consequently, the total length of the TLV parameter 1955 (including Type, Length, Contents, and Padding) is related to the 1956 Length field according to the following formula: 1958 Total Length = 11 + Length - (Length + 3) % 8; 1960 where % is the modulo operator 1962 0 1 2 3 1963 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 1964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1965 | Type |C| Length | 1966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1967 | | 1968 / Contents / 1969 / +-+-+-+-+-+-+-+-+ 1970 | | Padding | 1971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1973 Type Type code for the parameter. 16 bits long, C-bit 1974 being part of the Type code. 1975 C Critical. One if this parameter is critical, and 1976 MUST be recognized by the recipient, zero otherwise. 1977 The C bit is considered to be a part of the Type 1978 field. Consequently, critical parameters are always 1979 odd and non-critical ones have an even value. 1980 Length Length of the Contents, in bytes excluding Type, 1981 Length, and Padding. 1982 Contents Parameter specific, defined by Type 1983 Padding Padding, 0-7 bytes, added if needed 1985 Critical parameters (indicated by the odd type number) MUST be 1986 recognized by the recipient. If a recipient encounters a critical 1987 parameter that it does not recognize, it MUST NOT process the packet 1988 any further. It MAY send an ICMP or NOTIFY, as defined in 1989 Section 4.3. 1991 Non-critical parameters MAY be safely ignored. If a recipient 1992 encounters a non-critical parameter that it does not recognize, it 1993 SHOULD proceed as if the parameter was not present in the received 1994 packet. 1996 5.2.2. Defining New Parameters 1998 Future specifications may define new parameters as needed. When 1999 defining new parameters, care must be taken to ensure that the 2000 parameter type values are appropriate and leave suitable space for 2001 other future extensions. One must remember that the parameters MUST 2002 always be arranged in numerically increasing order by Type code, 2003 thereby limiting the order of parameters (see Section 5.2.1). 2005 The following rules MUST be followed when defining new parameters. 2007 1. The low-order bit C of the Type code is used to distinguish 2008 between critical and non-critical parameters. Hence, even 2009 parameter type numbers indicate non-critical parameters while odd 2010 parameter type numbers indicate critical parameters. 2012 2. A new parameter MAY be critical only if an old implementation 2013 that ignored it would cause security problems. In general, new 2014 parameters SHOULD be defined as non-critical, and expect a reply 2015 from the recipient. 2017 3. If a system implements a new critical parameter, it MUST provide 2018 the ability to set the associated feature off, such that the 2019 critical parameter is not sent at all. The configuration option 2020 MUST be well documented. Implementations operating in a mode 2021 adhering to this specification MUST disable the sending of new 2022 critical parameters by default. In other words, the management 2023 interface MUST allow vanilla standards-only mode as a default 2024 configuration setting, and MAY allow new critical payloads to be 2025 configured on (and off). 2027 4. See Section 9 for allocation rules regarding Type codes. 2029 5.2.3. R1_COUNTER 2030 0 1 2 3 2031 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 2032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2033 | Type | Length | 2034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2035 | Reserved, 4 bytes | 2036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2037 | R1 generation counter, 8 bytes | 2038 | | 2039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2041 Type 129 2042 Length 12 2043 R1 generation 2044 counter The current generation of valid puzzles 2046 The R1_COUNTER parameter contains a 64-bit unsigned integer in 2047 network-byte order, indicating the current generation of valid 2048 puzzles. The sender SHOULD increment this counter periodically. It 2049 is RECOMMENDED that the counter value is incremented at least as 2050 often as old PUZZLE values are deprecated so that SOLUTIONs to them 2051 are no longer accepted. 2053 Support for the R1_COUNTER parameter is mandatory although its 2054 inclusion in the R1 packet is optional. It SHOULD be included in the 2055 R1 (in which case, it is covered by the signature), and if present in 2056 the R1, it MUST be echoed (including the Reserved field verbatim) by 2057 the Initiator in the I2 packet. 2059 5.2.4. PUZZLE 2060 0 1 2 3 2061 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 2062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2063 | Type | Length | 2064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2065 | #K, 1 byte | Lifetime | Opaque, 2 bytes | 2066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2067 | Random #I, RHASH_len/8 bytes | 2068 / / 2069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2071 Type 257 2072 Length 4 + RHASH_len / 8 2073 #K #K is the number of verified bits 2074 Lifetime puzzle lifetime 2^(value-32) seconds 2075 Opaque data set by the Responder, indexing the puzzle 2076 Random #I random number of size RHASH_len bits 2078 Random #I is represented as a n-bit integer (where n is RHASH_len), 2079 #K and Lifetime as 8-bit integers, all in network byte order. 2081 The PUZZLE parameter contains the puzzle difficulty #K and a n-bit 2082 random integer #I. The Puzzle Lifetime indicates the time during 2083 which the puzzle solution is valid, and sets a time limit that should 2084 not be exceeded by the Initiator while it attempts to solve the 2085 puzzle. The lifetime is indicated as a power of 2 using the formula 2086 2^(Lifetime-32) seconds. A puzzle MAY be augmented with an 2087 ECHO_REQUEST_SIGNED or an ECHO_REQUEST_UNSIGNED parameter included in 2088 the R1; the contents of the echo request are then echoed back in the 2089 ECHO_RESPONSE_SIGNED or in the ECHO_RESPONSE_UNSIGNED parameter, 2090 allowing the Responder to use the included information as a part of 2091 its puzzle processing. 2093 The Opaque and Random #I field are not covered by the HIP_SIGNATURE_2 2094 parameter. 2096 5.2.5. SOLUTION 2097 0 1 2 3 2098 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 2099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2100 | Type | Length | 2101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2102 | #K, 1 byte | Reserved | Opaque, 2 bytes | 2103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2104 | Random #I, n bytes | 2105 / / 2106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2107 | Puzzle solution #J, RHASH_len/8 bytes | 2108 / / 2109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2111 Type 321 2112 Length 4 + RHASH_len /4 2113 #K #K is the number of verified bits 2114 Reserved zero when sent, ignored when received 2115 Opaque copied unmodified from the received PUZZLE 2116 parameter 2117 Random #I random number of size RHASH_len bits 2118 Puzzle solution #J random number of size RHASH_len bits 2120 Random #I and Random #J are represented as n-bit unsigned integers 2121 (where n is RHASH_len), #K as an 8-bit unsigned integer, all in 2122 network byte order. 2124 The SOLUTION parameter contains a solution to a puzzle. It also 2125 echoes back the random difficulty #K, the Opaque field, and the 2126 puzzle integer #I. 2128 5.2.6. DH_GROUP_LIST 2129 0 1 2 3 2130 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 2131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2132 | Type | Length | 2133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2134 | DH GROUP ID #1| DH GROUP ID #2| DH GROUP ID #3| DH GROUP ID #4| 2135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2136 | DH GROUP ID #n| Padding | 2137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2139 Type 511 2140 Length number of DH Group IDs 2141 DH GROUP ID identifies a DH GROUP ID supported by the host. 2142 The list of IDs is ordered by preference of the 2143 host. The possible DH Group IDs are defined 2144 in the DIFFIE_HELLMAN parameter. Each DH Group ID 2145 is one octet long. 2147 The DH_GROUP_LIST parameter contains the list of supported DH Group 2148 IDs of a host. The Initiator sends the DH_GROUP_LIST in the I1 2149 packet, the Responder sends its own list in the signed part of the R1 2150 packet. The DH Group IDs in the DH_GROUP_LIST are listed in the 2151 order of their preference of the host sending the list. DH Group IDs 2152 that are listed first are preferred over the DH Group IDs listed 2153 later. The information in the DH_GROUP_LIST allows the Responder to 2154 select the DH group preferred by itself and supported by the 2155 Initiator. Based on the DH_GROUP_LIST in the R1 packet, the 2156 Initiator can determine if the Responder has selected the best 2157 possible choice based on the Initiator's and Responder's preferences. 2158 If the Responder's choice differs from the best choice, the Initiator 2159 can conclude that there was an attempted downgrade attack (see 2160 Section 4.1.7). 2162 When selecting the DH group for the DIFFIE_HELLMAN parameter in the 2163 R1 packet, the Responder MUST select the first DH Group ID in its 2164 DH_GROUP_LIST in the R1 packet that is compatible with one of the 2165 Suite IDs in the Initiator's DH_GROUP_LIST in the I1 packet. The 2166 Responder MUST NOT select any other DH Group ID that is contained in 2167 both lists because a downgrade attack cannot be detected then. 2169 In general, hosts SHOULD prefer stronger groups over weaker ones if 2170 the computation overhead is not prohibitively high for the intended 2171 application. 2173 5.2.7. DIFFIE_HELLMAN 2175 0 1 2 3 2176 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 2177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2178 | Type | Length | 2179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2180 | Group ID | Public Value Length | Public Value / 2181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2182 / | 2183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2184 / | Padding | 2185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2187 Type 513 2188 Length length in octets, excluding Type, Length, and 2189 Padding 2190 Group ID identifies values for p and g as well as the KDF 2191 Public Value length of the following Public Value in octets 2192 Length 2193 Public Value the sender's public Diffie-Hellman key 2195 A single DIFFIE_HELLMAN parameter may be included in selected HIP 2196 packets based on the DH Group ID selected (Section 5.2.6). The 2197 following Group IDs have been defined: 2199 Group KDF Value 2200 Reserved 0 2201 DEPRECATED 1 2202 DEPRECATED 2 2203 1536-bit MODP group [RFC3526] HKDF [RFC5869] 3 2204 3072-bit MODP group [RFC3526] HKDF [RFC5869] 4 2205 DEPRECATED 5 2206 DEPRECATED 6 2207 NIST P-256 [RFC5903] HKDF [RFC5869] 7 2208 NIST P-384 [RFC5903] HKDF [RFC5869] 8 2209 NIST P-521 [RFC5903] HKDF [RFC5869] 9 2210 SECP160R1 [SECG] HKDF [RFC5869] 10 2212 The MODP Diffie-Hellman groups are defined in [RFC3526]. The ECDH 2213 groups 7 - 9 are defined in [RFC5903] and [RFC6090]. ECDH group 10 2214 is covered in Appendix D. Any ECDH used with HIP MUST have a co- 2215 factor of 1. 2217 The Group ID also defines the key derivation function that is to be 2218 used for deriving the symmetric keys for the HMAC and symmetric 2219 encryption from the keying material from the Diffie Hellman key 2220 exchange (see Section 6.5). 2222 A HIP implementation MUST implement Group ID 3. The 160-bit 2223 SECP160R1 group can be used when lower security is enough (e.g., web 2224 surfing) and when the equipment is not powerful enough (e.g., some 2225 PDAs). Implementations SHOULD implement Group IDs 4 and 8. 2227 To avoid unnecessary failures during the base exchange, the rest of 2228 the groups SHOULD be implemented in hosts where resources are 2229 adequate. 2231 5.2.8. HIP_CIPHER 2233 0 1 2 3 2234 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 2235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2236 | Type | Length | 2237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2238 | Cipher ID #1 | Cipher ID #2 | 2239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2240 | Cipher ID #n | Padding | 2241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2243 Type 579 2244 Length length in octets, excluding Type, Length, and 2245 Padding 2246 Cipher ID identifies the cipher algorithm to be used for 2247 encrypting the contents of the ENCRYPTED parameter 2249 The following Cipher IDs are defined: 2251 Suite ID Value 2253 RESERVED 0 2254 NULL-ENCRYPT 1 ([RFC2410]) 2255 AES-128-CBC 2 ([RFC3602]) 2256 DEPRECATED 3 2257 AES-256-CBC 4 ([RFC3602]) 2259 The sender of a HIP_CIPHER parameter MUST make sure that there are no 2260 more than six (6) Cipher IDs in one HIP_CIPHER parameter. 2261 Conversely, a recipient MUST be prepared to handle received transport 2262 parameters that contain more than six Cipher IDs by accepting the 2263 first six Cipher IDs and dropping the rest. The limited number of 2264 Cipher IDs sets the maximum size of the HIP_CIPHER parameter. As the 2265 default configuration, the HIP_CIPHER parameter MUST contain at least 2266 one of the mandatory Cipher IDs. There MAY be a configuration option 2267 that allows the administrator to override this default. 2269 The Responder lists supported and desired Cipher IDs in order of 2270 preference in the R1, up to the maximum of six Cipher IDs. The 2271 Initiator MUST choose only one of the corresponding Cipher IDs. This 2272 Cipher ID will be used for generating the ENCRYPTED parameter. 2274 Mandatory implementation: AES-128-CBC. NULL-ENCRYPTION [RFC2410] is 2275 included for testing purposes. 2277 5.2.9. HOST_ID 2279 0 1 2 3 2280 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 2281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2282 | Type | Length | 2283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2284 | HI Length |DI-type| DI Length | 2285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2286 | Algorithm | Host Identity / 2287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2288 / | Domain Identifier / 2289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2290 / | Padding | 2291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2293 Type 705 2294 Length length in octets, excluding Type, Length, and 2295 Padding 2296 HI Length length of the Host Identity in octets 2297 DI-type type of the following Domain Identifier field 2298 DI Length length of the Domain Identifier field in octets 2299 Algorithm index to the employed algorithm 2300 Host Identity actual Host Identity 2301 Domain Identifier the identifier of the sender 2303 The following DI-types have been defined: 2305 Type Value 2306 none included 0 2307 FQDN 1 2308 NAI 2 2310 FQDN Fully Qualified Domain Name, in binary format. 2311 NAI Network Access Identifier 2313 The format for the FQDN is defined in RFC 1035 [RFC1035] Section 3.1. 2314 The format for the NAI is defined in [RFC4282] 2315 A host MAY optionally associate the Host Identity with a single 2316 Domain Identifier in the HOST_ID parameter. If there is no Domain 2317 Identifier, i.e., the DI-type field is zero, the DI Length field is 2318 set to zero as well. 2320 The following HI Algorithms have been defined: 2322 Algorithm 2323 profiles Values 2325 RESERVED 0 2326 DSA 3 [FIPS186-3] (RECOMMENDED) 2327 RSA 5 [RFC3447] (REQUIRED) 2328 ECDSA 7 [RFC4754] (REQUIRED) 2329 ECDSA_LOW 9 [SECG] (RECOMMENDED) 2331 For DSA, RSA, and ECDSA key types, profiles containing at least 112 2332 bits of security strength (as defined by [NIST.800-131A.2011]) should 2333 be used. For RSA signature padding, the PSS method of padding 2334 [RFC3447] MUST be used. 2336 The Host Identity is derived from the DNSKEY format for RSA and DSA. 2337 For these, the Public Key field of the RDATA part from RFC 4034 2338 [RFC4034] is used. For ECC we distinguish two different profiles: 2339 ECDSA and ECDSA_LOW. ECC contains curves approved by NIST and 2340 defined in RFC 4754 [RFC4754]. ECDSA_LOW is defined for devices with 2341 low computational capabilities and uses shorter curves from SECG 2342 [SECG]. Any ECDSA used with HIP MUST have a co-factor of 1. 2344 For ECDSA and ECDSA_LOW Host Identities are represented by the 2345 following fields: 2347 0 1 2 3 2348 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 2349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2350 | ECC Curve | / 2351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2352 / Public Key | 2353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2355 ECC Curve Curve label 2356 Public Key Represented in Octet-string format 2357 [RFC6090] 2359 For hosts that implement ECDSA as algorithm the following ECC curves 2360 are required: 2362 Algorithm Curve Values 2364 ECDSA RESERVED 0 2365 ECDSA NIST P-256 1 [RFC4754] 2366 ECDSA NIST P-384 2 [RFC4754] 2368 For hosts that implement the ECDSA_LOW algorithm profile, the 2369 following curve is required: 2371 Algorithm Curve Values 2373 ECDSA_LOW RESERVED 0 2374 ECDSA_LOW SECP160R1 1 [SECG] 2376 5.2.10. HIT_SUITE_LIST 2378 The HIT_SUITE_LIST parameter contains a list of the supported HIT 2379 Suite IDs of the Responder. The Responder sends the HIT_SUITE_LIST 2380 in the signed part of the R1 packet. Based on the HIT_SUITE_LIST, 2381 the Initiator can determine which source HIT Suite IDs are supported 2382 by the Responder. 2384 0 1 2 3 2385 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 2386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2387 | Type | Length | 2388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2389 | ID #1 | ID #2 | ID #3 | ID #4 | 2390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2391 | ID #n | Padding | 2392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2394 Type 715 2395 Length number of HIT Suite IDs 2396 ID identifies a HIT Suite ID supported by the host. 2397 The list of IDs is ordered by preference of the 2398 host. Each HIT Suite ID is one octet long. The four 2399 higher-order bits of the ID field correspond to the 2400 HIT Suite ID in the ORCHID OGA field. The four 2401 lower-order bits are reserved and set to 0 and 2402 ignored by the receiver. 2404 The HIT Suite ID indexes a HIT Suite. HIT Suites are composed of 2405 signature algorithms as defined in Section 5.2.9 and hash functions. 2407 The ID field in the HIT_SUITE_LIST is defined as eight-bit field as 2408 opposed to the four-bit HIT Suite ID and OGA field in the ORCHID. 2409 This difference is a measure to accommodate larger HIT Suite IDs if 2410 the 16 available values prove insufficient. In that case, one of the 2411 16 values, zero, will be used to indicate that four additional bits 2412 of the ORCHID will be used to encode the HIT Suite ID. Hence, the 2413 current four-bit HIT Suite-IDs only use the four higher order bits in 2414 the ID field. Future documents may define the use of the four lower- 2415 order bits in the ID field. 2417 The following HIT Suites ID are defined: 2419 HIT Suite ID 2420 RESERVED 0 2421 RSA,DSA/SHA-256 1 (REQUIRED) 2422 ECDSA/SHA-384 2 (RECOMMENDED) 2423 ECDSA_LOW/SHA-1 3 (RECOMMENDED) 2425 5.2.11. TRANSPORT_FORMAT_LIST 2427 The TRANSPORT_FORMAT_LIST parameter contains a list of the supported 2428 HIP transport formats (TFs) of the Responder. The Responder sends 2429 the TRANSPORT_FORMAT_LIST in the signed part of the R1 packet. Based 2430 on the TRANSPORT_FORMAT_LIST, the Initiator chooses one suitable 2431 transport format and includes the respective HIP transport format 2432 parameter in its response packet. 2434 0 1 2 3 2435 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 2436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2437 | Type | Length | 2438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2439 | TF type #1 | TF type #2 / 2440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2441 / TF type #n | Padding | 2442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2444 Type 2049 2445 Length 2x number of TF types 2446 TF Type identifies a transport format (TF) type supported by 2447 the host. The TF type numbers correspond to the HIP 2448 parameter type numbers of the respective transport 2449 format 2450 parameters. The list of TF types is ordered by 2451 preference of the sender 2453 The TF type numbers index the respective HIP parameters for the 2454 transport formats in the type number range between 2050 to 4095. The 2455 parameters and their use are defined in separate documents. 2456 Currently, the only transport format defined is IPsec ESP 2457 [I-D.ietf-hip-rfc5202-bis]. 2459 For each listed TF type, the sender of the TRANSPORT_FORMAT_LIST 2460 parameter MUST include the respective transport format parameter in 2461 the HIP packet. The receiver MUST ignore the TF type in the 2462 TRANSPORT_FORMAT_LIST if no matching transport format parameter is 2463 present in the packet. 2465 5.2.12. HIP_MAC 2467 0 1 2 3 2468 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 2469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2470 | Type | Length | 2471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2472 | | 2473 | HMAC | 2474 / / 2475 / +-------------------------------+ 2476 | | Padding | 2477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2479 Type 61505 2480 Length length in octets, excluding Type, Length, and 2481 Padding 2482 HMAC HMAC computed over the HIP packet, excluding the 2483 HIP_MAC parameter and any following parameters, such 2484 as HIP_SIGNATURE, HIP_SIGNATURE_2, 2485 ECHO_REQUEST_UNSIGNED, or ECHO_RESPONSE_UNSIGNED. 2486 The checksum field MUST be set to zero and the HIP 2487 header length in the HIP common header MUST be 2488 calculated not to cover any excluded parameters 2489 when the HMAC is calculated. The size of the 2490 HMAC is the natural size of the hash computation 2491 output depending on the used hash function. 2493 The HMAC uses RHASH as hash algorithm. The calculation and 2494 verification process is presented in Section 6.4.1. 2496 5.2.13. HIP_MAC_2 2498 The HIP_MAC_2 is a MAC of the packet and the HI of the sender in the 2499 form of a HOST_ID parameter when that parameter is not actually 2500 included in the packet. The parameter structure is the same as in 2501 Section 5.2.12. The fields are: 2503 Type 61569 2504 Length length in octets, excluding Type, Length, and 2505 Padding 2506 HMAC HMAC computed over the HIP packet, excluding the 2507 HIP_MAC_2 parameter and any following parameters 2508 such as HIP_SIGNATURE, HIP_SIGNATURE_2, 2509 ECHO_REQUEST_UNSIGNED, or ECHO_RESPONSE_UNSIGNED, 2510 and including an additional sender's HOST_ID 2511 parameter during the HMAC calculation. The checksum 2512 field MUST be set to zero and the HIP header length 2513 in the HIP common header MUST be calculated not to 2514 cover any excluded parameters when the HMAC is 2515 calculated. The size of the HMAC is the natural 2516 size of the hash computation output depending on the 2517 used hash function. 2519 The HMAC uses RHASH as hash algorithm. The calculation and 2520 verification process is presented in Section 6.4.1. 2522 5.2.14. HIP_SIGNATURE 2524 0 1 2 3 2525 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 2526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2527 | Type | Length | 2528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2529 | SIG alg | Signature / 2530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2531 / | Padding | 2532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2534 Type 61697 2535 Length length in octets, excluding Type, Length, and 2536 Padding 2537 SIG alg signature algorithm 2538 Signature the signature is calculated over the HIP packet, 2539 excluding the HIP_SIGNATURE parameter and any 2540 parameters that follow the HIP_SIGNATURE parameter. 2541 When the signature is calculated the checksum field 2542 MUST be set to zero, and the HIP header length in 2543 the HIP common header MUST be calculated only up to 2544 the beginning of the HIP_SIGNATURE parameter. 2546 The signature algorithms are defined in Section 5.2.9. The signature 2547 in the Signature field is encoded using the method depending on the 2548 signature algorithm (e.g., according to [RFC3110] in case of RSA/SHA- 2549 1, according to [RFC5702] in case of RSA/SHA-256, according to 2551 [RFC2536] in case of DSA, or according to [RFC6090] in case of 2552 ECDSA). 2554 The HIP_SIGNATURE calculation and verification process are presented 2555 in Section 6.4.2. 2557 5.2.15. HIP_SIGNATURE_2 2559 The HIP_SIGNATURE_2 excludes the variable parameters in the R1 packet 2560 to allow R1 pre-creation. The parameter structure is the same as in 2561 Section 5.2.14. The fields are: 2563 Type 61633 2564 Length length in octets, excluding Type, Length, and 2565 Padding 2566 SIG alg signature algorithm 2567 Signature Within the R1 packet that contains the 2568 HIP_SIGNATURE_2 parameter, the Initiator's HIT, the 2569 checksum field, and the Opaque and Random #I fields 2570 in the PUZZLE parameter MUST be set to zero while 2571 computing the HIP_SIGNATURE_2 signature. Further, 2572 the HIP packet length in the HIP header MUST be 2573 adjusted as if the HIP_SIGNATURE_2 was not in the 2574 packet during the signature calculation, i.e., the 2575 HIP packet length points to the beginning of 2576 the HIP_SIGNATURE_2 parameter during signing and 2577 verification. 2579 Zeroing the Initiator's HIT makes it possible to create R1 packets 2580 beforehand, to minimize the effects of possible DoS attacks. Zeroing 2581 the Random #I and Opaque fields within the PUZZLE parameter allows 2582 these fields to be populated dynamically on precomputed R1s. 2584 Signature calculation and verification follows the process defined in 2585 Section 6.4.2. 2587 5.2.16. SEQ 2589 0 1 2 3 2590 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 2591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2592 | Type | Length | 2593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2594 | Update ID | 2595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2596 Type 385 2597 Length 8 2598 Update ID 32-bit sequence number 2600 The Update ID is an unsigned number in network byte order, 2601 initialized by a host to zero upon moving to ESTABLISHED state. The 2602 Update ID has scope within a single HIP association, and not across 2603 multiple associations or multiple hosts. The Update ID is 2604 incremented by one before each new UPDATE that is sent by the host; 2605 the first UPDATE packet originated by a host has an Update ID of 0. 2607 5.2.17. ACK 2609 0 1 2 3 2610 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 2611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2612 | Type | Length | 2613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2614 | peer Update ID 1 | 2615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2616 / peer Update ID n | 2617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2619 Type 449 2620 Length length in octets, excluding Type and Length 2621 peer Update ID 32-bit sequence number corresponding to the 2622 Update ID being ACKed. 2624 The ACK parameter includes one or more Update IDs that have been 2625 received from the peer. The number of peer Update IDs can be 2626 inferred from the length by dividing it by 4. 2628 5.2.18. ENCRYPTED 2629 0 1 2 3 2630 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 2631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2632 | Type | Length | 2633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2634 | Reserved | 2635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2636 | IV / 2637 / / 2638 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 2640 / Encrypted data / 2641 / / 2642 / +-------------------------------+ 2643 / | Padding | 2644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2646 Type 641 2647 Length length in octets, excluding Type, Length, and 2648 Padding 2649 Reserved zero when sent, ignored when received 2650 IV Initialization vector, if needed, otherwise 2651 nonexistent. The length of the IV is inferred from 2652 the HIP_CIPHER. 2653 Encrypted The data is encrypted using the encryption algorithm 2654 data defined in the HIP_CIPHER parameter. 2656 The ENCRYPTED parameter encapsulates other parameters, the encrypted 2657 data, which holds one or more HIP parameters in block encrypted form. 2659 Consequently, the first fields in the encapsulated parameter(s) are 2660 Type and Length of the first such parameter, allowing the contents to 2661 be easily parsed after decryption. 2663 The field labeled "Encrypted data" consists of the output of one or 2664 more HIP parameters concatenated together that have been passed 2665 through an encryption algorithm. Each of these inner parameters is 2666 padded according to the rules of Section 5.2.1 for padding individual 2667 parameters. As a result, the concatenated parameters will be a block 2668 of data that is 8-byte aligned. 2670 Some encryption algorithms require that the data to be encrypted must 2671 be a multiple of the cipher algorithm block size. In this case, the 2672 above block of data MUST include additional padding, as specified by 2673 the encryption algorithm. The size of the extra padding is selected 2674 so that the length of the unencrypted data block is a multiple of the 2675 cipher block size. The encryption algorithm may specify padding 2676 bytes other than zero; for example, AES [FIPS.197.2001] uses the 2677 PKCS5 padding scheme (see section 6.1.1 of [RFC2898]) where the 2678 remaining n bytes to fill the block each have the value of n. This 2679 yields an "unencrypted data" block that is transformed to an 2680 "encrypted data" block by the cipher suite. This extra padding added 2681 to the set of parameters to satisfy the cipher block alignment rules 2682 is not counted in HIP TLV length fields, and this extra padding 2683 should be removed by the cipher suite upon decryption. 2685 Note that the length of the cipher suite output may be smaller or 2686 larger than the length of the set of parameters to be encrypted, 2687 since the encryption process may compress the data or add additional 2688 padding to the data. 2690 Once this encryption process is completed, the Encrypted data field 2691 is ready for inclusion in the parameter. If necessary, additional 2692 Padding for 8-byte alignment is then added according to the rules of 2693 Section 5.2.1. 2695 5.2.19. NOTIFICATION 2697 The NOTIFICATION parameter is used to transmit informational data, 2698 such as error conditions and state transitions, to a HIP peer. A 2699 NOTIFICATION parameter may appear in NOTIFY packets. The use of the 2700 NOTIFICATION parameter in other packet types is for further study. 2702 0 1 2 3 2703 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 2704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2705 | Type | Length | 2706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2707 | Reserved | Notify Message Type | 2708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2709 | / 2710 / Notification Data / 2711 / +---------------+ 2712 / | Padding | 2713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2715 Type 832 2716 Length length in octets, excluding Type, Length, and 2717 Padding 2718 Reserved zero when sent, ignored when received 2719 Notify Message specifies the type of notification 2720 Type 2721 Notification informational or error data transmitted in addition 2722 Data to the Notify Message Type. Values for this field 2723 are type specific (see below). 2724 multiple of 8 bytes. 2726 Notification information can be error messages specifying why an HIP 2727 Security Association could not be established. It can also be status 2728 data that a HIP implementation wishes to communicate with a peer 2729 process. The table below lists the notification messages and their 2730 Notification Message Types. HIP packets MAY contain multiple 2731 NOTIFICATION parameters if several problems exist or several 2732 independent pieces of information must be transmitted. 2734 To avoid certain types of attacks, a Responder SHOULD avoid sending a 2735 NOTIFICATION to any host with which it has not successfully verified 2736 a puzzle solution. 2738 Notify Message Types in the range 0-16383 are intended for reporting 2739 errors and in the range 16384-65535 for other status information. An 2740 implementation that receives a NOTIFY packet with a Notify Message 2741 Type that indicates an error in response to a request packet (e.g., 2742 I1, I2, UPDATE) SHOULD assume that the corresponding request has 2743 failed entirely. Unrecognized error types MUST be ignored except 2744 that they SHOULD be logged. 2746 As currently defined, Notify Message Type values 1-10 are used for 2747 informing about errors in packet structures, values 11-20 for 2748 informing about problems in parameters. 2750 Notification Data in NOTIFICATION parameters where the Notify Message 2751 Type is in the status range MUST be ignored if not recognized. 2753 Notify Message Types - Errors Value 2754 ----------------------------- ----- 2756 UNSUPPORTED_CRITICAL_PARAMETER_TYPE 1 2758 Sent if the parameter type has the "critical" bit set and the 2759 parameter type is not recognized. Notification Data contains the 2760 two-octet parameter type. 2762 INVALID_SYNTAX 7 2764 Indicates that the HIP message received was invalid because some 2765 type, length, or value was out of range or because the request 2766 was otherwise malformed. To avoid a denial-of-service 2767 attack using forged messages, this status may only be returned 2768 for packets whose HIP_MAC (if present) and SIGNATURE have been 2769 verified. This status MUST be sent in response to any error not 2770 covered by one of the other status types, and SHOULD NOT contain 2771 details to avoid leaking information to someone probing a node. 2772 To aid debugging, more detailed error information SHOULD be 2773 written to a console or log. 2775 NO_DH_PROPOSAL_CHOSEN 14 2777 None of the proposed group IDs was acceptable. 2779 INVALID_DH_CHOSEN 15 2781 The DH Group ID field does not correspond to one offered 2782 by the Responder. 2784 NO_HIP_PROPOSAL_CHOSEN 16 2786 None of the proposed HIT Suites or HIP Encryption Algorithms was 2787 acceptable. 2789 INVALID_HIP_CIPHER_CHOSEN 17 2791 The HIP_CIPHER Crypto ID does not correspond to one offered by 2792 the Responder. 2794 UNSUPPORTED_HIT_SUITE 20 2796 Sent in response to an I1 or R1 packet for which the HIT suite 2797 is not supported. 2799 AUTHENTICATION_FAILED 24 2801 Sent in response to a HIP signature failure, except when 2802 the signature verification fails in a NOTIFY message. 2804 CHECKSUM_FAILED 26 2806 Sent in response to a HIP checksum failure. 2808 HIP_MAC_FAILED 28 2810 Sent in response to a HIP HMAC failure. 2812 ENCRYPTION_FAILED 32 2814 The Responder could not successfully decrypt the 2815 ENCRYPTED parameter. 2817 INVALID_HIT 40 2819 Sent in response to a failure to validate the peer's 2820 HIT from the corresponding HI. 2822 BLOCKED_BY_POLICY 42 2823 The Responder is unwilling to set up an association 2824 for some policy reason (e.g., received HIT is NULL 2825 and policy does not allow opportunistic mode). 2827 RESPONDER_BUSY_PLEASE_RETRY 44 2829 The Responder is unwilling to set up an association as it is 2830 suffering under some kind of overload and has chosen to shed load 2831 by rejecting the Initiator's request. The Initiator may retry; 2832 however, the Initiator MUST find another (different) puzzle 2833 solution for any such retries. Note that the Initiator may need 2834 to obtain a new puzzle with a new I1/R1 exchange. 2836 Notify Message Types - Status Value 2837 ----------------------------- ----- 2839 I2_ACKNOWLEDGEMENT 16384 2841 The Responder has an I2 packet from the Initiator but had to 2842 queue the I2 packet for processing. The puzzle was correctly 2843 solved and the Responder is willing to set up an association but 2844 currently has a number of I2 packets in the processing queue. 2845 The R2 packet is sent after the I2 packet was processed. 2847 5.2.20. ECHO_REQUEST_SIGNED 2849 0 1 2 3 2850 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 2851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2852 | Type | Length | 2853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2854 | Opaque data (variable length) | 2855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2857 Type 897 2858 Length length of the opaque data in octets 2859 Opaque data opaque data, supposed to be meaningful only to the 2860 node that sends ECHO_REQUEST_SIGNED and receives a 2861 corresponding ECHO_RESPONSE_SIGNED or 2862 ECHO_RESPONSE_UNSIGNED. 2864 The ECHO_REQUEST_SIGNED parameter contains an opaque blob of data 2865 that the sender wants to get echoed back in the corresponding reply 2866 packet. 2868 The ECHO_REQUEST_SIGNED and corresponding echo response parameters 2869 MAY be used for any purpose where a node wants to carry some state in 2870 a request packet and get it back in a response packet. The 2871 ECHO_REQUEST_SIGNED is covered by the HIP_MAC and SIGNATURE. A HIP 2872 packet can contain only one ECHO_REQUEST_SIGNED parameter and MAY 2873 contain multiple ECHO_REQUEST_UNSIGNED parameters. The 2874 ECHO_REQUEST_SIGNED parameter MUST be responded to with an 2875 ECHO_RESPONSE_SIGNED. 2877 5.2.21. ECHO_REQUEST_UNSIGNED 2879 0 1 2 3 2880 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 2881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2882 | Type | Length | 2883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2884 | Opaque data (variable length) | 2885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2887 Type 63661 2888 Length length of the opaque data in octets 2889 Opaque data opaque data, supposed to be meaningful only to the 2890 node that sends ECHO_REQUEST_UNSIGNED and receives a 2891 corresponding ECHO_RESPONSE_UNSIGNED. 2893 The ECHO_REQUEST_UNSIGNED parameter contains an opaque blob of data 2894 that the sender wants to get echoed back in the corresponding reply 2895 packet. 2897 The ECHO_REQUEST_UNSIGNED and corresponding echo response parameters 2898 MAY be used for any purpose where a node wants to carry some state in 2899 a request packet and get it back in a response packet. The 2900 ECHO_REQUEST_UNSIGNED is not covered by the HIP_MAC and SIGNATURE. A 2901 HIP packet can contain one or more ECHO_REQUEST_UNSIGNED parameters. 2902 It is possible that middleboxes add ECHO_REQUEST_UNSIGNED parameters 2903 in HIP packets passing by. The creator of the ECHO_REQUEST_UNSIGNED 2904 (end-host or middlebox) has to create the Opaque field so that it can 2905 later identify and remove the corresponding ECHO_RESPONSE_UNSIGNED 2906 parameter. 2908 The ECHO_REQUEST_UNSIGNED parameter MUST be responded to with an 2909 ECHO_RESPONSE_UNSIGNED parameter. 2911 5.2.22. ECHO_RESPONSE_SIGNED 2912 0 1 2 3 2913 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 2914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2915 | Type | Length | 2916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2917 | Opaque data (variable length) | 2918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2920 Type 961 2921 Length length of the opaque data in octets 2922 Opaque data opaque data, copied unmodified from the 2923 ECHO_REQUEST_SIGNED or ECHO_REQUEST_UNSIGNED 2924 parameter that triggered this response. 2926 The ECHO_RESPONSE_SIGNED parameter contains an opaque blob of data 2927 that the sender of the ECHO_REQUEST_SIGNED wants to get echoed back. 2928 The opaque data is copied unmodified from the ECHO_REQUEST_SIGNED 2929 parameter. 2931 The ECHO_REQUEST_SIGNED and ECHO_RESPONSE_SIGNED parameters MAY be 2932 used for any purpose where a node wants to carry some state in a 2933 request packet and get it back in a response packet. The 2934 ECHO_RESPONSE_SIGNED is covered by the HIP_MAC and SIGNATURE. 2936 5.2.23. ECHO_RESPONSE_UNSIGNED 2938 0 1 2 3 2939 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 2940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2941 | Type | Length | 2942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2943 | Opaque data (variable length) | 2944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2946 Type 63425 2947 Length length of the opaque data in octets 2948 Opaque data opaque data, copied unmodified from the 2949 ECHO_REQUEST_SIGNED or ECHO_REQUEST_UNSIGNED 2950 parameter that triggered this response. 2952 The ECHO_RESPONSE_UNSIGNED parameter contains an opaque blob of data 2953 that the sender of the ECHO_REQUEST_SIGNED or ECHO_REQUEST_UNSIGNED 2954 wants to get echoed back. The opaque data is copied unmodified from 2955 the corresponding echo request parameter. 2957 The echo request and ECHO_RESPONSE_UNSIGNED parameters MAY be used 2958 for any purpose where a node wants to carry some state in a request 2959 packet and get it back in a response packet. The 2960 ECHO_RESPONSE_UNSIGNED is not covered by the HIP_MAC and SIGNATURE. 2962 5.3. HIP Packets 2964 There are eight basic HIP packets (see Table 10). Four are for the 2965 HIP base exchange, one is for updating, one is for sending 2966 notifications, and two are for closing a HIP association. Support 2967 for NOTIFY packet type is optional, but support for all other HIP 2968 packet types listed below is mandatory. 2970 +------------------+------------------------------------------------+ 2971 | Packet type | Packet name | 2972 +------------------+------------------------------------------------+ 2973 | 1 | I1 - the HIP Initiator Packet | 2974 | | | 2975 | 2 | R1 - the HIP Responder Packet | 2976 | | | 2977 | 3 | I2 - the Second HIP Initiator Packet | 2978 | | | 2979 | 4 | R2 - the Second HIP Responder Packet | 2980 | | | 2981 | 16 | UPDATE - the HIP Update Packet | 2982 | | | 2983 | 17 | NOTIFY - the HIP Notify Packet | 2984 | | | 2985 | 18 | CLOSE - the HIP Association Closing Packet | 2986 | | | 2987 | 19 | CLOSE_ACK - the HIP Closing Acknowledgment | 2988 | | Packet | 2989 +------------------+------------------------------------------------+ 2991 Table 10: HIP packets and packet type values 2993 Packets consist of the fixed header as described in Section 5.1, 2994 followed by the parameters. The parameter part, in turn, consists of 2995 zero or more TLV-coded parameters. 2997 In addition to the base packets, other packet types may be defined 2998 later in separate specifications. For example, support for mobility 2999 and multi-homing is not included in this specification. 3001 See Notation (Section 2.2) for the notation used in the operations. 3003 In the future, an optional upper-layer payload MAY follow the HIP 3004 header. The Next Header field in the header indicates if there is 3005 additional data following the HIP header. The HIP packet, however, 3006 MUST NOT be fragmented into multiple extension headers by setting the 3007 Next Header field in a HIP header to the HIP protocol number. This 3008 limits the size of the possible additional data in the packet. 3010 5.3.1. I1 - the HIP Initiator Packet 3012 The HIP header values for the I1 packet: 3014 Header: 3015 Packet Type = 1 3016 SRC HIT = Initiator's HIT 3017 DST HIT = Responder's HIT, or NULL 3019 IP ( HIP ( DH_GROUP_LIST ) ) 3021 The I1 packet contains the fixed HIP header and the Initiator's 3022 DH_GROUP_LIST. 3024 Valid control bits: none 3026 The Initiator receives the Responder's HIT either from a DNS lookup 3027 of the Responder's FQDN (see 5205-bis), from some other repository, 3028 or from a local table. If the Initiator does not know the 3029 Responder's HIT, it may attempt to use opportunistic mode by using 3030 NULL (all zeros) as the Responder's HIT. See also "HIP Opportunistic 3031 Mode" (Section 4.1.8). 3033 Since the I1 packet is so easy to spoof even if it were signed, no 3034 attempt is made to add to its generation or processing cost. 3036 The Initiator includes a DH_GROUP_LIST parameter in the I1 packet to 3037 inform the Responder of its preferred DH Group IDs. Note that the 3038 DH_GROUP_LIST in the I1 packet is not protected by a signature. 3040 Implementations MUST be able to handle a storm of received I1 3041 packets, discarding those with common content that arrive within a 3042 small time delta. 3044 5.3.2. R1 - the HIP Responder Packet 3046 The HIP header values for the R1 packet: 3048 Header: 3049 Packet Type = 2 3050 SRC HIT = Responder's HIT 3051 DST HIT = Initiator's HIT 3053 IP ( HIP ( [ R1_COUNTER, ] 3054 PUZZLE, 3055 DIFFIE_HELLMAN, 3056 HIP_CIPHER, 3057 HOST_ID, 3058 HIT_SUITE_LIST, 3059 DH_GROUP_LIST, 3060 [ ECHO_REQUEST_SIGNED, ] 3061 TRANSPORT_FORMAT_LIST, 3062 HIP_SIGNATURE_2 ) 3063 <, ECHO_REQUEST_UNSIGNED >i) 3065 Valid control bits: A 3067 If the Responder's HI is an anonymous one, the A control MUST be set. 3069 The Initiator's HIT MUST match the one received in the I1 packet if 3070 the R1 is a response to an I1. If the Responder has multiple HIs, 3071 the Responder's HIT used MUST match Initiator's request. If the 3072 Initiator used opportunistic mode, the Responder may select freely 3073 among its HIs. See also "HIP Opportunistic Mode" (Section 4.1.8). 3075 The R1 packet generation counter is used to determine the currently 3076 valid generation of puzzles. The value is increased periodically, 3077 and it is RECOMMENDED that it is increased at least as often as 3078 solutions to old puzzles are no longer accepted. 3080 The Puzzle contains a Random #I and the difficulty #K. The 3081 difficulty #K indicates the number of lower-order bits, in the puzzle 3082 hash result, that must be zeros; see Section 4.1.2. The Random #I is 3083 not covered by the signature and must be zeroed during the signature 3084 calculation, allowing the sender to select and set the #I into a 3085 precomputed R1 packet just prior sending it to the peer. 3087 The Responder selects the Diffie-Hellman public value based on the 3088 Initiator's preference expressed in the DH_GROUP_LIST parameter in 3089 the I1 packet. The Responder sends back its own preference based on 3090 which it chose the DH public value as DH_GROUP_LIST. This allows the 3091 Initiator to determine whether its own DH_GROUP_LIST in the sent I1 3092 packet was manipulated by an attacker. 3094 The Diffie-Hellman public value is ephemeral, and values SHOULD NOT 3095 be reused across different HIP associations. Once the Responder has 3096 received a valid response to an R1 packet, that Diffie-Hellman value 3097 SHOULD be deprecated. It is possible that the Responder has sent the 3098 same Diffie-Hellman value to different hosts simultaneously in 3099 corresponding R1 packets and those responses should also be accepted. 3100 However, as a defense against I1 packet storms, an implementation MAY 3101 propose, and re-use unless avoidable, the same Diffie-Hellman value 3102 for a period of time, for example, 15 minutes. By using a small 3103 number of different puzzles for a given Diffie-Hellman value, the R1 3104 packets can be precomputed and delivered as quickly as I1 packets 3105 arrive. A scavenger process should clean up unused Diffie-Hellman 3106 values and puzzles. 3108 Re-using Diffie-Hellman public values opens up the potential security 3109 risk of more than one Initiator ending up with the same keying 3110 material (due to faulty random number generators). Also, more than 3111 one Initiator using the same Responder public key half may lead to 3112 potentially easier cryptographic attacks and to imperfect forward 3113 security. 3115 However, these risks involved in re-using the same public value are 3116 statistical; that is, the authors are not aware of any mechanism that 3117 would allow manipulation of the protocol so that the risk of the re- 3118 use of any given Responder Diffie-Hellman public key would differ 3119 from the base probability. Consequently, it is RECOMMENDED that 3120 Responders avoid re-using the same DH key with multiple Initiators, 3121 but because the risk is considered statistical and not known to be 3122 manipulable, the implementations MAY re-use a key in order to ease 3123 resource-constrained implementations and to increase the probability 3124 of successful communication with legitimate clients even under an I1 3125 packet storm. In particular, when it is too expensive to generate 3126 enough precomputed R1 packets to supply each potential Initiator with 3127 a different DH key, the Responder MAY send the same DH key to several 3128 Initiators, thereby creating the possibility of multiple legitimate 3129 Initiators ending up using the same Responder-side public key. 3130 However, as soon as the Responder knows that it will use a particular 3131 DH key, it SHOULD stop offering it. This design is aimed to allow 3132 resource-constrained Responders to offer services under I1 packet 3133 storms and to simultaneously make the probability of DH key re-use 3134 both statistical and as low as possible. 3136 If the Responder uses the same DH keypair for multiple handshakes, it 3137 must take care to avoid small subgroup attacks [RFC2785]. To avoid 3138 these attacks, when receiving the I2 message, the Responder SHOULD 3139 validate the Initiators DH public key as described in [RFC2785] 3140 Section 3.1. In case the validation fails, the Responder MUST NOT 3141 generate a DH shared key and MUST silently abort the HIP BEX. 3143 The HIP_CIPHER contains the encryption algorithms supported by the 3144 Responder to encrypt the contents of the ENCRYPTED parameter, in the 3145 order of preference. All implementations MUST support AES [RFC3602]. 3147 The HIT_SUITE_LIST parameter is an ordered list of the Responder's 3148 preferred and supported HIT Suites. The list allows the Initiator to 3149 determine whether its own source HIT matches any suite supported by 3150 the Responder. 3152 The ECHO_REQUEST_SIGNED and ECHO_REQUEST_UNSIGNED parameters contain 3153 data that the sender wants to receive unmodified in the corresponding 3154 response packet in the ECHO_RESPONSE_SIGNED or ECHO_RESPONSE_UNSIGNED 3155 parameter. The R1 packet may contain zero or more 3156 ECHO_REQUEST_UNSIGNED parameters as described in 3157 Section Section 5.2.21. 3159 The TRANSPORT_FORMAT_LIST parameter is an ordered list of the 3160 Responder's preferred and supported transport format types. The list 3161 allows the Initiator and the Responder to agree on a common type for 3162 payload protection. This parameter is described in Section 5.2.11. 3164 The signature is calculated over the whole HIP packet as described in 3165 Section 5.2.15. This allows the Responder to use precomputed R1s. 3166 The Initiator SHOULD validate this signature. It MUST check that the 3167 Responder's HI matches with the one expected, if any. 3169 5.3.3. I2 - the Second HIP Initiator Packet 3171 The HIP header values for the I2 packet: 3173 Header: 3174 Type = 3 3175 SRC HIT = Initiator's HIT 3176 DST HIT = Responder's HIT 3178 IP ( HIP ( [R1_COUNTER,] 3179 SOLUTION, 3180 DIFFIE_HELLMAN, 3181 HIP_CIPHER, 3182 ENCRYPTED { HOST_ID } or HOST_ID, 3183 [ ECHO_RESPONSE_SIGNED ,] 3184 TRANSPORT_FORMAT_LIST, 3185 HIP_MAC, 3186 HIP_SIGNATURE 3187 <, ECHO_RESPONSE_UNSIGNED>i ) ) 3189 Valid control bits: A 3190 The HITs used MUST match the ones used in the R1. 3192 If the Initiator's HI is an anonymous one, the A control bit MUST be 3193 set. 3195 If present in the I1 packet, the Initiator MUST include an unmodified 3196 copy of the R1_COUNTER parameter received in the corresponding R1 3197 packet into the I2 packet. 3199 The Solution contains the Random #I from R1 and the computed #J. The 3200 low-order #K bits of the RHASH(I | ... | J) MUST be zero. 3202 The Diffie-Hellman value is ephemeral. If precomputed, a scavenger 3203 process should clean up unused Diffie-Hellman values. The Responder 3204 MAY re-use Diffie-Hellman values under some conditions as specified 3205 in Section 5.3.2. 3207 The HIP_CIPHER contains the single encryption suite selected by the 3208 Initiator, that it uses to encrypt the ENCRYPTED parameters. The 3209 chosen cipher MUST correspond to one of the ciphers offered by the 3210 Responder in the R1. All implementations MUST support AES [RFC3602]. 3212 The Initiator's HI MAY be encrypted using the HIP_CIPHER encryption 3213 algorithm. The keying material is derived from the Diffie-Hellman 3214 exchanged as defined in Section 6.5. 3216 The ECHO_RESPONSE_SIGNED and ECHO_RESPONSE_UNSIGNED contain the 3217 unmodified Opaque data copied from the corresponding echo request 3218 parameter(s). 3220 The TRANSPORT_FORMAT_LIST contains the single transport format type 3221 selected by the Initiator. The chosen type MUST correspond to one of 3222 the types offered by the Responder in the R1. Currently, the only 3223 transport format defined is the ESP transport format 3224 ([I-D.ietf-hip-rfc5202-bis]). 3226 The HMAC value in the HIP_MAC parameter is calculated over the whole 3227 HIP packet, excluding any parameters after the HIP_MAC, as described 3228 in Section 6.4.1. The Responder MUST validate the HIP_MAC. 3230 The signature is calculated over the whole HIP packet, excluding any 3231 parameters after the HIP_SIGNATURE, as described in Section 5.2.14. 3232 The Responder MUST validate this signature. The Responder uses the 3233 HI in the packet or a HI acquired by some other means for verifying 3234 the signature. 3236 5.3.4. R2 - the Second HIP Responder Packet 3238 The HIP header values for the R2 packet: 3240 Header: 3241 Packet Type = 4 3242 SRC HIT = Responder's HIT 3243 DST HIT = Initiator's HIT 3245 IP ( HIP ( HIP_MAC_2, HIP_SIGNATURE ) ) 3247 Valid control bits: none 3249 The HIP_MAC_2 is calculated over the whole HIP packet, with 3250 Responder's HOST_ID parameter concatenated with the HIP packet. The 3251 HOST_ID parameter is removed after the HMAC calculation. The 3252 procedure is described in Section 6.4.1. 3254 The signature is calculated over the whole HIP packet. 3256 The Initiator MUST validate both the HIP_MAC and the signature. 3258 5.3.5. UPDATE - the HIP Update Packet 3260 The HIP header values for the UPDATE packet: 3262 Header: 3263 Packet Type = 16 3264 SRC HIT = Sender's HIT 3265 DST HIT = Recipient's HIT 3267 IP ( HIP ( [SEQ, ACK, ] HIP_MAC, HIP_SIGNATURE ) ) 3269 Valid control bits: None 3271 The UPDATE packet contains mandatory HIP_MAC and HIP_SIGNATURE 3272 parameters, and other optional parameters. 3274 The UPDATE packet contains zero or one SEQ parameter. The presence 3275 of a SEQ parameter indicates that the receiver MUST acknowledge the 3276 the UPDATE. An UPDATE that does not contain a SEQ but only an ACK 3277 parameter is simply an acknowledgment of a previous UPDATE and itself 3278 MUST NOT be acknowledged by a separate ACK parameter. Such UPDATE 3279 packets containing only an ACK parameter do not require processing in 3280 relative order to other UPDATE packets. An UPDATE packet without 3281 either a SEQ or an ACK parameter is invalid; such unacknowledged 3282 updates MUST instead use a NOTIFY packet. 3284 An UPDATE packet contains zero or one ACK parameters. The ACK 3285 parameter echoes the SEQ sequence number of the UPDATE packet being 3286 ACKed. A host MAY choose to acknowledge more than one UPDATE packet 3287 at a time; e.g., the ACK parameter may contain the last two SEQ 3288 values received, for resilience against packet loss. ACK values are 3289 not cumulative; each received unique SEQ value requires at least one 3290 corresponding ACK value in reply. Received ACK parameters that are 3291 redundant are ignored. Hosts MUST implement the processing of ACK 3292 parameters with multiple SEQ numbers even if they do not implement 3293 sending ACK parameters with multiple SEQ numbers. 3295 The UPDATE packet may contain both a SEQ and an ACK parameter. In 3296 this case, the ACK parameter is being piggybacked on an outgoing 3297 UPDATE. In general, UPDATEs carrying SEQ SHOULD be ACKed upon 3298 completion of the processing of the UPDATE. A host MAY choose to 3299 hold the UPDATE carrying an ACK parameter for a short period of time 3300 to allow for the possibility of piggybacking the ACK parameter, in a 3301 manner similar to TCP delayed acknowledgments. 3303 A sender MAY choose to forego reliable transmission of a particular 3304 UPDATE (e.g., it becomes overcome by events). The semantics are such 3305 that the receiver MUST acknowledge the UPDATE, but the sender MAY 3306 choose to not care about receiving the ACK parameter. 3308 UPDATEs MAY be retransmitted without incrementing SEQ. If the same 3309 subset of parameters is included in multiple UPDATEs with different 3310 SEQs, the host MUST ensure that the receiver's processing of the 3311 parameters multiple times will not result in a protocol error. 3313 5.3.6. NOTIFY - the HIP Notify Packet 3315 The NOTIFY packet MAY be used to provide information to a peer. 3316 Typically, NOTIFY is used to indicate some type of protocol error or 3317 negotiation failure. NOTIFY packets are unacknowledged. The 3318 receiver can handle the packet only as informational, and SHOULD NOT 3319 change its HIP state (see Section 4.4.2) based purely on a received 3320 NOTIFY packet. 3322 The HIP header values for the NOTIFY packet: 3324 Header: 3325 Packet Type = 17 3326 SRC HIT = Sender's HIT 3327 DST HIT = Recipient's HIT, or zero if unknown 3329 IP ( HIP (i, [HOST_ID, ] HIP_SIGNATURE) ) 3331 Valid control bits: None 3332 The NOTIFY packet is used to carry one or more NOTIFICATION 3333 parameters. 3335 5.3.7. CLOSE - the HIP Association Closing Packet 3337 The HIP header values for the CLOSE packet: 3339 Header: 3340 Packet Type = 18 3341 SRC HIT = Sender's HIT 3342 DST HIT = Recipient's HIT 3344 IP ( HIP ( ECHO_REQUEST_SIGNED, HIP_MAC, HIP_SIGNATURE ) ) 3346 Valid control bits: none 3348 The sender MUST include an ECHO_REQUEST_SIGNED used to validate 3349 CLOSE_ACK received in response, and both a HIP_MAC and a signature 3350 (calculated over the whole HIP packet). 3352 The receiver peer MUST reply with a CLOSE_ACK containing an 3353 ECHO_RESPONSE_SIGNED corresponding to the received 3354 ECHO_REQUEST_SIGNED. 3356 5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet 3358 The HIP header values for the CLOSE_ACK packet: 3360 Header: 3361 Packet Type = 19 3362 SRC HIT = Sender's HIT 3363 DST HIT = Recipient's HIT 3365 IP ( HIP ( ECHO_RESPONSE_SIGNED, HIP_MAC, HIP_SIGNATURE ) ) 3367 Valid control bits: none 3369 The sender MUST include both an HMAC and signature (calculated over 3370 the whole HIP packet). 3372 The receiver peer MUST validate the ECHO_RESPONSE_SIGNED and validate 3373 both the HIP_MAC and the signature if the receiver has state for a 3374 HIP association. 3376 5.4. ICMP Messages 3378 When a HIP implementation detects a problem with an incoming packet, 3379 and it either cannot determine the identity of the sender of the 3380 packet or does not have any existing HIP association with the sender 3381 of the packet, it MAY respond with an ICMP packet. Any such replies 3382 MUST be rate-limited as described in [RFC4443]. In most cases, the 3383 ICMP packet has the Parameter Problem type (12 for ICMPv4, 4 for 3384 ICMPv6), with the Pointer field pointing to the field that caused the 3385 ICMP message to be generated. 3387 5.4.1. Invalid Version 3389 If a HIP implementation receives a HIP packet that has an 3390 unrecognized HIP version number, it SHOULD respond, rate-limited, 3391 with an ICMP packet with type Parameter Problem, with the Pointer 3392 pointing to the Version/RES. byte in the HIP header. 3394 5.4.2. Other Problems with the HIP Header and Packet Structure 3396 If a HIP implementation receives a HIP packet that has other 3397 unrecoverable problems in the header or packet format, it MAY 3398 respond, rate-limited, with an ICMP packet with type Parameter 3399 Problem, the Pointer pointing to the field that failed to pass the 3400 format checks. However, an implementation MUST NOT send an ICMP 3401 message if the checksum fails; instead, it MUST silently drop the 3402 packet. 3404 5.4.3. Invalid Puzzle Solution 3406 If a HIP implementation receives an I2 packet that has an invalid 3407 puzzle solution, the behavior depends on the underlying version of 3408 IP. If IPv6 is used, the implementation SHOULD respond with an ICMP 3409 packet with type Parameter Problem, the Pointer pointing to the 3410 beginning of the Puzzle solution #J field in the SOLUTION payload in 3411 the HIP message. 3413 If IPv4 is used, the implementation MAY respond with an ICMP packet 3414 with the type Parameter Problem, copying enough of bytes from the I2 3415 message so that the SOLUTION parameter fits into the ICMP message, 3416 the Pointer pointing to the beginning of the Puzzle solution #J 3417 field, as in the IPv6 case. Note, however, that the resulting ICMPv4 3418 message exceeds the typical ICMPv4 message size as defined in 3419 [RFC0792]. 3421 5.4.4. Non-Existing HIP Association 3423 If a HIP implementation receives a CLOSE or UPDATE packet, or any 3424 other packet whose handling requires an existing association, that 3425 has either a Receiver or Sender HIT that does not match with any 3426 existing HIP association, the implementation MAY respond, rate- 3427 limited, with an ICMP packet with the type Parameter Problem. The 3428 Pointer of the ICMP Parameter Problem packet is set pointing to the 3429 beginning of the first HIT that does not match. 3431 A host MUST NOT reply with such an ICMP if it receives any of the 3432 following messages: I1, R2, I2, R2, and NOTIFY packet. When 3433 introducing new packet types, a specification SHOULD define the 3434 appropriate rules for sending or not sending this kind of ICMP reply. 3436 6. Packet Processing 3438 Each host is assumed to have a single HIP protocol implementation 3439 that manages the host's HIP associations and handles requests for new 3440 ones. Each HIP association is governed by a conceptual state 3441 machine, with states defined above in Section 4.4. The HIP 3442 implementation can simultaneously maintain HIP associations with more 3443 than one host. Furthermore, the HIP implementation may have more 3444 than one active HIP association with another host; in this case, HIP 3445 associations are distinguished by their respective HITs. It is not 3446 possible to have more than one HIP association between any given pair 3447 of HITs. Consequently, the only way for two hosts to have more than 3448 one parallel association is to use different HITs, at least at one 3449 end. 3451 The processing of packets depends on the state of the HIP 3452 association(s) with respect to the authenticated or apparent 3453 originator of the packet. A HIP implementation determines whether it 3454 has an active association with the originator of the packet based on 3455 the HITs. In the case of user data carried in a specific transport 3456 format, the transport format document specifies how the incoming 3457 packets are matched with the active associations. 3459 6.1. Processing Outgoing Application Data 3461 In a HIP host, an application can send application-level data using 3462 an identifier specified via the underlying API. The API can be a 3463 backwards-compatible API (see [RFC5338]), using identifiers that look 3464 similar to IP addresses, or a completely new API, providing enhanced 3465 services related to Host Identities. Depending on the HIP 3466 implementation, the identifier provided to the application may be 3467 different; for example, it can be a HIT or an IP address. 3469 The exact format and method for transferring the user data from the 3470 source HIP host to the destination HIP host is defined in the 3471 corresponding transport format document. The actual data is 3472 transferred in the network using the appropriate source and 3473 destination IP addresses. 3475 In this document, conceptual processing rules are defined only for 3476 the base case where both hosts have only single usable IP addresses; 3477 the multi-address multi-homing case is specified separately. 3479 The following conceptual algorithm describes the steps that are 3480 required for handling outgoing datagrams destined to a HIT. 3482 1. If the datagram has a specified source address, it MUST be a HIT. 3483 If it is not, the implementation MAY replace the source address 3484 with a HIT. Otherwise, it MUST drop the packet. 3486 2. If the datagram has an unspecified source address, the 3487 implementation MUST choose a suitable source HIT for the 3488 datagram. Selecting the source HIT is subject to local policy. 3490 3. If there is no active HIP association with the given HIT pair, one MUST be created by running the base 3492 exchange. While waiting for the base exchange to complete, the 3493 implementation SHOULD queue at least one user data packet per HIP 3494 association to be formed, and it MAY queue more than one. 3496 4. Once there is an active HIP association for the given HIT pair, the outgoing datagram is passed to 3498 transport handling. The possible transport formats are defined 3499 in separate documents, of which the ESP transport format for HIP 3500 is mandatory for all HIP implementations. 3502 5. Before sending the packet, the HITs in the datagram are replaced 3503 with suitable IP addresses. For IPv6, the rules defined in 3504 [RFC6724] SHOULD be followed. Note that this HIT-to-IP-address 3505 conversion step MAY also be performed at some other point in the 3506 stack, e.g., before wrapping the packet into the output format. 3508 6.2. Processing Incoming Application Data 3510 The following conceptual algorithm describes the incoming datagram 3511 handling when HITs are used at the receiving host as application- 3512 level identifiers. More detailed steps for processing packets are 3513 defined in corresponding transport format documents. 3515 1. The incoming datagram is mapped to an existing HIP association, 3516 typically using some information from the packet. For example, 3517 such mapping may be based on the ESP Security Parameter Index 3518 (SPI). 3520 2. The specific transport format is unwrapped, in a way depending on 3521 the transport format, yielding a packet that looks like a 3522 standard (unencrypted) IP packet. If possible, this step SHOULD 3523 also verify that the packet was indeed (once) sent by the remote 3524 HIP host, as identified by the HIP association. 3526 Depending on the used transport mode, the verification method can 3527 vary. While the HI (as well as HIT) is used as the higher-layer 3528 identifier, the verification method has to verify that the data 3529 packet was sent by the correct node identity and that the actual 3530 identity maps to this particular HIT. When using ESP transport 3531 format [I-D.ietf-hip-rfc5202-bis], the verification is done using 3532 the SPI value in the data packet to find the corresponding SA 3533 with associated HIT and key, and decrypting the packet with that 3534 associated key. 3536 3. The IP addresses in the datagram are replaced with the HITs 3537 associated with the HIP association. Note that this IP-address- 3538 to-HIT conversion step MAY also be performed at some other point 3539 in the stack. 3541 4. The datagram is delivered to the upper layer (e.g., UDP or TCP). 3542 When demultiplexing the datagram, the right upper-layer socket is 3543 selected based on the HITs. 3545 6.3. Solving the Puzzle 3547 This subsection describes the details for solving the puzzle. 3549 In the R1 packet, the values #I and #K are sent in network byte 3550 order. Similarly, in the I2 packet, the values #I and #J are sent in 3551 network byte order. The hash is created by concatenating, in network 3552 byte order, the following data, in the following order and using the 3553 RHASH algorithm: 3555 n-bit random value #I (where n is RHASH_len), in network byte 3556 order, as appearing in the R1 and I2 packets. 3558 128-bit Initiator's HIT, in network byte order, as appearing in 3559 the HIP Payload in the R1 and I2 packets. 3561 128-bit Responder's HIT, in network byte order, as appearing in 3562 the HIP Payload in the R1 and I2 packets. 3564 n-bit random value #J (where n is RHASH_len), in network byte 3565 order, as appearing in the I2 packet. 3567 In a valid response puzzle, the #K low-order bits of the resulting 3568 RHASH digest MUST be zero. 3570 Notes: 3572 i) The length of the data to be hashed is variable depending on 3573 the output length of the Responder's hash function RHASH. 3575 ii) All the data in the hash input MUST be in network byte order. 3577 iii) The order of the Initiator's and Responder's HITs are 3578 different in the R1 and I2 packets; see Section 5.1. Care must be 3579 taken to copy the values in the right order to the hash input. 3581 iv) For a puzzle #I, there may exist multiple valid puzzle 3582 solutions #J. 3584 The following procedure describes the processing steps involved, 3585 assuming that the Responder chooses to precompute the R1 packets: 3587 Precomputation by the Responder: 3588 Sets up the puzzle difficulty #K. 3589 Creates a signed R1 and caches it. 3591 Responder: 3592 Selects a suitable cached R1. 3593 Generates a random number #I. 3594 Sends #I and #K in an R1. 3595 Saves #I and #K for a Delta time. 3597 Initiator: 3598 Generates repeated attempts to solve the puzzle until a matching 3599 #J is found: 3600 Ltrunc( RHASH( #I | HIT-I | HIT-R | #J ), #K ) == 0 3601 Sends #I and #J in an I2. 3603 Responder: 3604 Verifies that the received #I is a saved one. 3605 Finds the right #K based on #I. 3606 Computes V := Ltrunc( RHASH( #I | HIT-I | HIT-R | #J ), #K ) 3607 Rejects if V != 0 3608 Accept if V == 0 3610 6.4. HIP_MAC and SIGNATURE Calculation and Verification 3612 The following subsections define the actions for processing HIP_MAC, 3613 HIP_MAC_2, HIP_SIGNATURE and HIP_SIGNATURE_2 parameters. The 3614 HIP_MAC_2 parameter is contained in the R2 packet. The 3615 HIP_SIGNATURE_2 parameter is contained in the R1 packet. The 3616 HIP_SIGNATURE and HIP_MAC parameter are contained in other HIP 3617 packets. 3619 6.4.1. HMAC Calculation 3621 The HMAC uses RHASH as underlying hash function. The type of RHASH 3622 depends on the HIT Suite of the Responder. Hence, HMAC-SHA-256 3623 [RFC4868] is used for HIT Suite RSA/DSA/SHA-256, HMAC-SHA-1 [RFC2404] 3624 is used for HIT Suite ECDSA_LOW/SHA-1, and HMAC-SHA-384 [RFC4868] for 3625 HIT Suite ECDSA/SHA-384. 3627 The following process applies both to the HIP_MAC and HIP_MAC_2 3628 parameters. When processing HIP_MAC_2, the difference is that the 3629 HIP_MAC calculation includes a pseudo HOST_ID field containing the 3630 Responder's information as sent in the R1 packet earlier. 3632 Both the Initiator and the Responder should take some care when 3633 verifying or calculating the HIP_MAC_2. Specifically, the Initiator 3634 has to preserve the HOST_ID exactly as it was received in the R1 3635 packet until it receives the HIP_MAC_2 in the R2 packet. 3637 The scope of the calculation for HIP_MAC is: 3639 HMAC: { HIP header | [ Parameters ] } 3641 where Parameters include all HIP parameters of the packet that is 3642 being calculated with Type values ranging from 1 to (HIP_MAC's Type 3643 value - 1) and exclude parameters with Type values greater or equal 3644 to HIP_MAC's Type value. 3646 During HIP_MAC calculation, the following applies: 3648 o In the HIP header, the Checksum field is set to zero. 3650 o In the HIP header, the Header Length field value is calculated to 3651 the beginning of the HIP_MAC parameter. 3653 Parameter order is described in Section 5.2.1. 3655 The scope of the calculation for HIP_MAC_2 is: 3657 HIP_MAC_2: { HIP header | [ Parameters ] | HOST_ID } 3659 where Parameters include all HIP parameters for the packet that is 3660 being calculated with Type values from 1 to (HIP_MAC_2's Type value - 3661 1) and exclude parameters with Type values greater or equal to 3662 HIP_MAC_2's Type value. 3664 During HIP_MAC_2 calculation, the following applies: 3666 o In the HIP header, the Checksum field is set to zero. 3668 o In the HIP header, the Header Length field value is calculated to 3669 the beginning of the HIP_MAC_2 parameter and increased by the 3670 length of the concatenated HOST_ID parameter length (including 3671 type and length fields). 3673 o HOST_ID parameter is exactly in the form it was received in the R1 3674 packet from the Responder. 3676 Parameter order is described in Section 5.2.1, except that the 3677 HOST_ID parameter in this calculation is added to the end. 3679 The HIP_MAC parameter is defined in Section 5.2.12 and the HIP_MAC_2 3680 parameter in Section 5.2.13. The HMAC calculation and verification 3681 process (the process applies both to HIP_MAC and HIP_MAC_2 except 3682 where HIP_MAC_2 is mentioned separately) is as follows: 3684 Packet sender: 3686 1. Create the HIP packet, without the HIP_MAC, HIP_SIGNATURE, 3687 HIP_SIGNATURE_2, or any other parameter with greater Type value 3688 than the HIP_MAC parameter has. 3690 2. In case of HIP_MAC_2 calculation, add a HOST_ID (Responder) 3691 parameter to the end of the packet. 3693 3. Calculate the Header Length field in the HIP header including the 3694 added HOST_ID parameter in case of HIP_MAC_2. 3696 4. Compute the HMAC using either HIP-gl or HIP-lg integrity key 3697 retrieved from KEYMAT as defined in Section 6.5. 3699 5. In case of HIP_MAC_2, remove the HOST_ID parameter from the 3700 packet. 3702 6. Add the HIP_MAC parameter to the packet and any parameter with 3703 greater Type value than the HIP_MAC's (HIP_MAC_2's) that may 3704 follow, including possible HIP_SIGNATURE or HIP_SIGNATURE_2 3705 parameters 3707 7. Recalculate the Length field in the HIP header. 3709 Packet receiver: 3711 1. Verify the HIP header Length field. 3713 2. Remove the HIP_MAC or HIP_MAC_2 parameter, as well as all other 3714 parameters that follow it with greater Type value including 3715 possible HIP_SIGNATURE or HIP_SIGNATURE_2 fields, saving the 3716 contents if they are needed later. 3718 3. In case of HIP_MAC_2, build and add a HOST_ID parameter (with 3719 Responder information) to the packet. The HOST_ID parameter 3720 should be identical to the one previously received from the 3721 Responder. 3723 4. Recalculate the HIP packet length in the HIP header and clear the 3724 Checksum field (set it to all zeros). In case of HIP_MAC_2, the 3725 length is calculated with the added HOST_ID parameter. 3727 5. Compute the HMAC using either HIP-gl or HIP-lg integrity key as 3728 defined in Section 6.5 and verify it against the received HMAC. 3730 6. Set Checksum and Header Length field in the HIP header to 3731 original values. Note that the checksum and length fields 3732 contain incorrect values after this step. 3734 7. In case of HIP_MAC_2, remove the HOST_ID parameter from the 3735 packet before further processing. 3737 6.4.2. Signature Calculation 3739 The following process applies both to the HIP_SIGNATURE and 3740 HIP_SIGNATURE_2 parameters. When processing the HIP_SIGNATURE_2, the 3741 only difference is that instead of the HIP_SIGNATURE parameter, the 3742 HIP_SIGNATURE_2 parameter is used, and the Initiator's HIT and PUZZLE 3743 Opaque and Random #I fields are cleared (set to all zeros) before 3744 computing the signature. The HIP_SIGNATURE parameter is defined in 3745 Section 5.2.14 and the HIP_SIGNATURE_2 parameter in Section 5.2.15. 3747 The scope of the calculation for HIP_SIGNATURE and HIP_SIGNATURE_2 3748 is: 3750 HIP_SIGNATURE: { HIP header | [ Parameters ] } 3752 where Parameters include all HIP parameters for the packet that is 3753 being calculated with Type values from 1 to (HIP_SIGNATURE's Type 3754 value - 1). 3756 During signature calculation, the following applies: 3758 o In the HIP header, the Checksum field is set to zero. 3760 o In the HIP header, the Header Length field value is calculated to 3761 the beginning of the HIP_SIGNATURE parameter. 3763 The parameter order is described in Section 5.2.1. 3765 HIP_SIGNATURE_2: { HIP header | [ Parameters ] } 3767 where Parameters include all HIP parameters for the packet that is 3768 being calculated with Type values ranging from 1 to 3769 (HIP_SIGNATURE_2's Type value - 1). 3771 During signature calculation, the following apply: 3773 o In the HIP header, the Initiator's HIT field and Checksum fields 3774 are set to zero. 3776 o In the HIP header, the Header Length field value is calculated to 3777 the beginning of the HIP_SIGNATURE_2 parameter. 3779 o PUZZLE parameter's Opaque and Random #I fields are set to zero. 3781 Parameter order is described in Section 5.2.1. 3783 The signature calculation and verification process (the process 3784 applies both to HIP_SIGNATURE and HIP_SIGNATURE_2 except in the case 3785 where HIP_SIGNATURE_2 is separately mentioned) is as follows: 3787 Packet sender: 3789 1. Create the HIP packet without the HIP_SIGNATURE parameter or any 3790 other parameters that follow the HIP_SIGNATURE parameter. 3792 2. Calculate the Length field and zero the Checksum field in the HIP 3793 header. In case of HIP_SIGNATURE_2, set Initiator's HIT field in 3794 the HIP header as well as PUZZLE parameter's Opaque and Random #I 3795 fields to zero. 3797 3. Compute the signature using the private key corresponding to the 3798 Host Identifier (public key). 3800 4. Add the HIP_SIGNATURE parameter to the packet. 3802 5. Add any parameters that follow the HIP_SIGNATURE parameter. 3804 6. Recalculate the Length field in the HIP header, and calculate the 3805 Checksum field. 3807 Packet receiver: 3809 1. Verify the HIP header Length field and checksum. 3811 2. Save the contents of the HIP_SIGNATURE parameter and any other 3812 parameters following the HIP_SIGNATURE parameter and remove them 3813 from the packet. 3815 3. Recalculate the HIP packet Length in the HIP header and clear the 3816 Checksum field (set it to all zeros). In case of 3817 HIP_SIGNATURE_2, set Initiator's HIT field in the HIP header as 3818 well as PUZZLE parameter's Opaque and Random #I fields to zero. 3820 4. Compute the signature and verify it against the received 3821 signature using the packet sender's Host Identity (public key). 3823 5. Restore the original packet by adding removed parameters (in step 3824 2) and resetting the values that were set to zero (in step 3). 3826 The verification can use either the HI received from a HIP packet, 3827 the HI from a DNS query, if the FQDN has been received in the HOST_ID 3828 packet or one received by some other means. 3830 6.5. HIP KEYMAT Generation 3832 HIP keying material is derived from the Diffie-Hellman session key, 3833 Kij, produced during the HIP base exchange (see Section 4.1.3). The 3834 Initiator has Kij during the creation of the I2 packet, and the 3835 Responder has Kij once it receives the I2 packet. This is why I2 can 3836 already contain encrypted information. 3838 The KEYMAT is derived by feeding Kij into the key derivation function 3839 defined by the DH Group ID. Currently the only key derivation 3840 function defined in this document is the Hash-based Key Derivation 3841 Function (HKDF) [RFC5869] using the RHASH hash function. Other 3842 documents may define new DH Group IDs and corresponding key 3843 distribution functions. 3845 In the following we provide the details for deriving the keying 3846 material using HKDF. 3848 where 3850 info = sort(HIT-I | HIT-R) 3851 salt = #I | #J 3853 Sort(HIT-I | HIT-R) is defined as the network byte order 3854 concatenation of the two HITs, with the smaller HIT preceding the 3855 larger HIT, resulting from the numeric comparison of the two HITs 3856 interpreted as positive (unsigned) 128-bit integers in network byte 3857 order. The #I and #J values are from the puzzle and its solution 3858 that were exchanged in R1 and I2 messages when this HIP association 3859 was set up. Both hosts have to store #I and #J values for the HIP 3860 association for future use. 3862 The initial keys are drawn sequentially in the order that is 3863 determined by the numeric comparison of the two HITs, with comparison 3864 method described in the previous paragraph. HOST_g denotes the host 3865 with the greater HIT value, and HOST_l the host with the lower HIT 3866 value. 3868 The drawing order for the four initial keys is as follows: 3870 HIP-gl encryption key for HOST_g's ENCRYPTED parameter 3872 HIP-gl integrity (HMAC) key for HOST_g's outgoing HIP packets 3874 HIP-lg encryption key for HOST_l's ENCRYPTED parameter 3876 HIP-lg integrity (HMAC) key for HOST_l's outgoing HIP packets 3878 The number of bits drawn for a given algorithm is the "natural" size 3879 of the keys. For the mandatory algorithms, the following sizes 3880 apply: 3882 AES 128 or 256 bits 3884 SHA-1 160 bits 3886 SHA-256 256 bits 3888 SHA-384 384 bits 3890 NULL 0 bits 3891 If other key sizes are used, they MUST be treated as different 3892 encryption algorithms and defined separately. 3894 6.6. Initiation of a HIP Base Exchange 3896 An implementation may originate a HIP base exchange to another host 3897 based on a local policy decision, usually triggered by an application 3898 datagram, in much the same way that an IPsec IKE key exchange can 3899 dynamically create a Security Association. Alternatively, a system 3900 may initiate a HIP exchange if it has rebooted or timed out, or 3901 otherwise lost its HIP state, as described in Section 4.5.4. 3903 The implementation prepares an I1 packet and sends it to the IP 3904 address that corresponds to the peer host. The IP address of the 3905 peer host may be obtained via conventional mechanisms, such as DNS 3906 lookup. The I1 packet contents are specified in Section 5.3.1. The 3907 selection of which source or destination Host Identity to use, if a 3908 Initiator or Responder has more than one to choose from, is typically 3909 a policy decision. 3911 The following steps define the conceptual processing rules for 3912 initiating a HIP base exchange: 3914 1. The Initiator receives one or more of the Responder's HITs and 3915 one or more addresses either from a DNS lookup of the Responder's 3916 FQDN, from some other repository, or from a local database. If 3917 the Initiator does not know the Responder's HIT, it may attempt 3918 opportunistic mode by using NULL (all zeros) as the Responder's 3919 HIT (see also "HIP Opportunistic Mode" (Section 4.1.8)). If the 3920 Initiator can choose from multiple Responder HITs, it selects a 3921 HIT for which the Initiator supports the HIT Suite. 3923 2. The Initiator sends an I1 packet to one of the Responder's 3924 addresses. The selection of which address to use is a local 3925 policy decision. 3927 3. The Initiator includes the DH_GROUP_LIST in the I1 packet. The 3928 selection and order of DH Group IDs in the DH_GROUP_LIST MUST be 3929 stored by the Initiator because this list is needed for later R1 3930 processing. In most cases, the preferences regarding the DH 3931 Groups will be static, so no per-association storage is 3932 necessary. 3934 4. Upon sending an I1 packet, the sender transitions to state 3935 I1-SENT, starts a timer for which the timeout value SHOULD be 3936 larger than the worst-case anticipated RTT. The sender SHOULD 3937 also increment the trial counter associated with the I1. 3939 5. Upon timeout, the sender SHOULD retransmit the I1 packet and 3940 restart the timer, up to a maximum of I1_RETRIES_MAX tries. 3942 6.6.1. Sending Multiple I1 Packets in Parallel 3944 For the sake of minimizing the association establishment latency, an 3945 implementation MAY send the same I1 packet to more than one of the 3946 Responder's addresses. However, it MUST NOT send to more than three 3947 (3) Responder addresses in parallel. Furthermore, upon timeout, the 3948 implementation MUST refrain from sending the same I1 packet to 3949 multiple addresses. That is, if it retries to initialize the 3950 connection after a timeout, it MUST NOT send the I1 packet to more 3951 than one destination address. These limitations are placed in order 3952 to avoid congestion of the network, and potential DoS attacks that 3953 might occur, e.g., because someone's claim to have hundreds or 3954 thousands of addresses could generate a huge number of I1 packets 3955 from the Initiator. 3957 As the Responder is not guaranteed to distinguish the duplicate I1 3958 packets it receives at several of its addresses (because it avoids 3959 storing states when it answers back an R1 packet), the Initiator may 3960 receive several duplicate R1 packets. 3962 The Initiator SHOULD then select the initial preferred destination 3963 address using the source address of the selected received R1, and use 3964 the preferred address as a source address for the I2 packet. 3965 Processing rules for received R1s are discussed in Section 6.8. 3967 6.6.2. Processing Incoming ICMP Protocol Unreachable Messages 3969 A host may receive an ICMP 'Destination Protocol Unreachable' message 3970 as a response to sending a HIP I1 packet. Such a packet may be an 3971 indication that the peer does not support HIP, or it may be an 3972 attempt to launch an attack by making the Initiator believe that the 3973 Responder does not support HIP. 3975 When a system receives an ICMP 'Destination Protocol Unreachable' 3976 message while it is waiting for an R1 packet, it MUST NOT terminate 3977 waiting. It MAY continue as if it had not received the ICMP message, 3978 and send a few more I1 packets. Alternatively, it MAY take the ICMP 3979 message as a hint that the peer most probably does not support HIP, 3980 and return to state UNASSOCIATED earlier than otherwise. However, at 3981 minimum, it MUST continue waiting for an R1 packet for a reasonable 3982 time before returning to UNASSOCIATED. 3984 6.7. Processing Incoming I1 Packets 3986 An implementation SHOULD reply to an I1 with an R1 packet, unless the 3987 implementation is unable or unwilling to set up a HIP association. 3988 If the implementation is unable to set up a HIP association, the host 3989 SHOULD send an ICMP Destination Protocol Unreachable, 3990 Administratively Prohibited, message to the I1 packet source IP 3991 address. If the implementation is unwilling to set up a HIP 3992 association, the host MAY ignore the I1 packet. This latter case may 3993 occur during a DoS attack such as an I1 packet flood. 3995 The implementation SHOULD be able to handle a storm of received I1 3996 packets, discarding those with common content that arrive within a 3997 small time delta. 3999 A spoofed I1 packet can result in an R1 attack on a system. An R1 4000 packet sender MUST have a mechanism to rate-limit R1 packets sent to 4001 an address. 4003 It is RECOMMENDED that the HIP state machine does not transition upon 4004 sending an R1 packet. 4006 The following steps define the conceptual processing rules for 4007 responding to an I1 packet: 4009 1. The Responder MUST check that the Responder's HIT in the received 4010 I1 packet is either one of its own HITs or NULL. Otherwise it 4011 must drop the packet. 4013 2. If the Responder is in ESTABLISHED state, the Responder MAY 4014 respond to this with an R1 packet, prepare to drop an existing 4015 HIP security association with the peer, and stay at ESTABLISHED 4016 state. 4018 3. If the Responder is in I1-SENT state, it MUST make a comparison 4019 between the sender's HIT and its own (i.e., the receiver's) HIT. 4020 If the sender's HIT is greater than its own HIT, it should drop 4021 the I1 packet and stay at I1-SENT. If the sender's HIT is 4022 smaller than its own HIT, it SHOULD send the R1 packet and stay 4023 at I1-SENT. The HIT comparison is performed as defined in 4024 Section 6.5. 4026 4. If the implementation chooses to respond to the I1 packet with an 4027 R1 packet, it creates a new R1 or selects a precomputed R1 4028 according to the format described in Section 5.3.2. It creates 4029 or chooses an R1 that contains its most preferred DH public value 4030 that is also contained in the DH_GROUP_LIST in the I1 packet. If 4031 no suitable DH Group ID was contained in the DH_GROUP_LIST in the 4032 I1 packet, it sends an R1 with any suitable DH public key. 4034 5. If the received Responder's HIT in the I1 is NULL, the Responder 4035 selects a HIT with a the same HIT Suite as the Initiator's HIT. 4036 If this HIT Suite is not supported by the Responder, it SHOULD 4037 select a REQUIRED HIT Suite from Section 5.2.10, which is 4038 currently RSA/DSA/SHA-256. Other than that, selecting the HIT is 4039 a local policy matter. 4041 6. The responder expresses its supported HIP transport formats in 4042 the TRANSPORT_FORMAT_LIST as described in Section 5.2.11. The 4043 Responder MUST at least provide one payload transport format 4044 type. 4046 7. The Responder sends the R1 packet to the source IP address of the 4047 I1 packet. 4049 6.7.1. R1 Management 4051 All compliant implementations MUST be able to produce R1 packets; 4052 even if a device is configured by policy to only initiate 4053 associations, it must be able to process I1s in case of recovery from 4054 loss of state or key exhaustion. An R1 packet MAY be precomputed. 4055 An R1 packet MAY be reused for time Delta T, which is implementation 4056 dependent, and SHOULD be deprecated and not used once a valid 4057 response I2 packet has been received from an Initiator. During an I1 4058 message storm, an R1 packet MAY be re-used beyond this limit. R1 4059 information MUST NOT be discarded until Delta S after T. Time S is 4060 the delay needed for the last I2 packet to arrive back to the 4061 Responder. 4063 Implementations that support multiple DH groups MAY pre-compute R1 4064 packets for each supported group so that incoming I1 packets with 4065 different DH Group IDs in the DH_GROUP_LIST can be served quickly. 4067 An implementation MAY keep state about received I1 packets and match 4068 the received I2 packets against the state, as discussed in 4069 Section 4.1.1. 4071 6.7.2. Handling Malformed Messages 4073 If an implementation receives a malformed I1 packet, it SHOULD NOT 4074 respond with a NOTIFY message, as such practice could open up a 4075 potential denial-of-service threat. Instead, it MAY respond with an 4076 ICMP packet, as defined in Section 5.4. 4078 6.8. Processing Incoming R1 Packets 4080 A system receiving an R1 packet MUST first check to see if it has 4081 sent an I1 packet to the originator of the R1 packet (i.e., it is in 4082 state I1-SENT). If so, it SHOULD process the R1 as described below, 4083 send an I2 packet, and transition to state I2-SENT, setting a timer 4084 to protect the I2 packet. If the system is in state I2-SENT, it MAY 4085 respond to the R1 packet if the R1 packet has a larger R1 generation 4086 counter; if so, it should drop its state due to processing the 4087 previous R1 packet and start over from state I1-SENT. If the system 4088 is in any other state with respect to that host, the system SHOULD 4089 silently drop the R1 packet. 4091 When sending multiple I1 packets, an Initiator SHOULD wait for a 4092 small amount of time after the first R1 reception to allow possibly 4093 multiple R1 packets to arrive, and it SHOULD respond to an R1 packet 4094 among the set with the largest R1 generation counter. 4096 The following steps define the conceptual processing rules for 4097 responding to an R1 packet: 4099 1. A system receiving an R1 MUST first check to see if it has sent 4100 an I1 packet to the originator of the R1 packet (i.e., it has a 4101 HIP association that is in state I1-SENT and that is associated 4102 with the HITs in the R1). Unless the I1 packet was sent in 4103 opportunistic mode (see Section 4.1.8), the IP addresses in the 4104 received R1 packet SHOULD be ignored by the R1 processing and, 4105 when looking up the right HIP association, the received R1 4106 packet SHOULD be matched against the associations using only the 4107 HITs. If a match exists, the system should process the R1 4108 packet as described below. 4110 2. Otherwise, if the system is in any other state than I1-SENT or 4111 I2-SENT with respect to the HITs included in the R1 packet, it 4112 SHOULD silently drop the R1 packet and remain in the current 4113 state. 4115 3. If the HIP association state is I1-SENT or I2-SENT, the received 4116 Initiator's HIT MUST correspond to the HIT used in the original 4117 I1. Also, the Responder's HIT MUST correspond to the one used 4118 in the I1, unless the I1 packet contained a NULL HIT. 4120 4. The system SHOULD validate the R1 signature before applying 4121 further packet processing, according to Section 5.2.15. 4123 5. If the HIP association state is I1-SENT, and multiple valid R1 4124 packets are present, the system MUST select from among the R1 4125 packets with the largest R1 generation counter. 4127 6. The system MUST check that the Initiator HIT Suite is contained 4128 in the HIT_SUITE_LIST parameter in the R1 packet (i.e., the 4129 Initiator's HIT Suite is supported by the Responder). If the 4130 HIT Suite is supported by the Responder, the system proceeds 4131 normally. Otherwise, the system MAY stay in state I1-sent and 4132 restart the BEX by sending a new I1 packet with an Initiator HIT 4133 that is supported by the Responder and hence is contained in the 4134 HIT_SUITE_LIST in the R1 packet. The system MAY abort the BEX 4135 if no suitable source HIT is available. The system SHOULD wait 4136 for an acceptable time span to allow further R1 packets with 4137 higher R1 generation counters or different HIT and HIT Suites to 4138 arrive before restarting or aborting the BEX. 4140 7. The system MUST check that the DH Group ID in the DIFFIE_HELLMAN 4141 parameter in the R1 matches the first DH Suite ID in the 4142 Responder's DH_GROUP_LIST in the R1 packet that was also 4143 contained in the Initiator's DH_GROUP_LIST in the I1 packet. If 4144 the DH Group ID of the DIFFIE_HELLMAN parameter does not express 4145 the Responder's best choice, the Initiator can conclude that the 4146 DH_GROUP_LIST in the I1 packet was adversely modified. In such 4147 case, the Initiator MAY send a new I1 packet, however, it SHOULD 4148 NOT change its preference in the DH_GROUP_LIST in the new I1 4149 packet. Alternatively, the Initiator MAY abort the HIP base 4150 exchange. 4152 8. If the HIP association state is I2-SENT, the system MAY re-enter 4153 state I1-SENT and process the received R1 packet if it has a 4154 larger R1 generation counter than the R1 packet responded to 4155 previously. 4157 9. The R1 packet may have the A bit set -- in this case, the system 4158 MAY choose to refuse it by dropping the R1 packet and returning 4159 to state UNASSOCIATED. The system SHOULD consider dropping the 4160 R1 packet only if it used a NULL HIT in I1 packet. If the A bit 4161 is set, the Responder's HIT is anonymous and SHOULD NOT be 4162 stored permanently. 4164 10. The system SHOULD attempt to validate the HIT against the 4165 received Host Identity by using the received Host Identity to 4166 construct a HIT and verify that it matches the Sender's HIT. 4168 11. The system MUST store the received R1 generation counter for 4169 future reference. 4171 12. The system attempts to solve the puzzle in the R1 packet. The 4172 system MUST terminate the search after exceeding the remaining 4173 lifetime of the puzzle. If the puzzle is not successfully 4174 solved, the implementation MAY either resend the I1 packet 4175 within the retry bounds or abandon the HIP base exchange. 4177 13. The system computes standard Diffie-Hellman keying material 4178 according to the public value and Group ID provided in the 4179 DIFFIE_HELLMAN parameter. The Diffie-Hellman keying material 4180 Kij is used for key extraction as specified in Section 6.5. 4182 14. The system selects the HIP_CIPHER ID from the choices presented 4183 in the R1 packet and uses the selected values subsequently when 4184 generating and using encryption keys, and when sending the I2 4185 packet. If the proposed alternatives are not acceptable to the 4186 system, it may either resend an I1 within the retry bounds or 4187 abandon the HIP base exchange. 4189 15. The system chooses one suitable transport format from the 4190 TRANSPORT_FORMAT_LIST and includes the respective transport 4191 format parameter in the subsequent I2 packet. 4193 16. The system initializes the remaining variables in the associated 4194 state, including Update ID counters. 4196 17. The system prepares and sends an I2 packet, as described in 4197 Section 5.3.3. 4199 18. The system SHOULD start a timer whose timeout value SHOULD be 4200 larger than the worst-case anticipated RTT, and MUST increment a 4201 trial counter associated with the I2 packet. The sender SHOULD 4202 retransmit the I2 packet upon a timeout and restart the timer, 4203 up to a maximum of I2_RETRIES_MAX tries. 4205 19. If the system is in state I1-SENT, it SHALL transition to state 4206 I2-SENT. If the system is in any other state, it remains in the 4207 current state. 4209 6.8.1. Handling of Malformed Messages 4211 If an implementation receives a malformed R1 message, it MUST 4212 silently drop the packet. Sending a NOTIFY or ICMP would not help, 4213 as the sender of the R1 packet typically doesn't have any state. An 4214 implementation SHOULD wait for some more time for a possibly well- 4215 formed R1, after which it MAY try again by sending a new I1 packet. 4217 6.9. Processing Incoming I2 Packets 4219 Upon receipt of an I2 packet, the system MAY perform initial checks 4220 to determine whether the I2 packet corresponds to a recent R1 packet 4221 that has been sent out, if the Responder keeps such state. For 4222 example, the sender could check whether the I2 packet is from an 4223 address or HIT for which the Responder has recently received an I1. 4224 The R1 packet may have had Opaque data included that was echoed back 4225 in the I2 packet. If the I2 packet is considered to be suspect, it 4226 MAY be silently discarded by the system. 4228 Otherwise, the HIP implementation SHOULD process the I2 packet. This 4229 includes validation of the puzzle solution, generating the Diffie- 4230 Hellman key, possibly decrypting the Initiator's Host Identity, 4231 verifying the signature, creating state, and finally sending an R2 4232 packet. 4234 The following steps define the conceptual processing rules for 4235 responding to an I2 packet: 4237 1. The system MAY perform checks to verify that the I2 packet 4238 corresponds to a recently sent R1 packet. Such checks are 4239 implementation dependent. See Appendix A for a description of 4240 an example implementation. 4242 2. The system MUST check that the Responder's HIT corresponds to 4243 one of its own HITs and MUST drop the packet otherwise. 4245 3. The system MUST further check that the Initiator's HIT Suite is 4246 supported. The Responder SHOULD silently drop I2 packets with 4247 unsupported Initiator HITs. 4249 4. If the system's state machine is in the R2-SENT state, the 4250 system MAY check if the newly received I2 packet is similar to 4251 the one that triggered moving to R2-SENT. If so, it MAY 4252 retransmit a previously sent R2 packet, reset the R2-SENT timer, 4253 and the state machine stays in R2-SENT. 4255 5. If the system's state machine is in the I2-SENT state, the 4256 system MUST make a comparison between its local and sender's 4257 HITs (similarly as in Section 6.5). If the local HIT is smaller 4258 than the sender's HIT, it should drop the I2 packet, use the 4259 peer Diffie-Hellman key and nonce #I from the R1 packet received 4260 earlier, and get the local Diffie-Hellman key and nonce #J from 4261 the I2 packet sent to the peer earlier. Otherwise, the system 4262 should process the received I2 packet and drop any previously 4263 derived Diffie-Hellman keying material Kij it might have formed 4264 upon sending the I2 packet previously. The peer Diffie-Hellman 4265 key and the nonce #J are taken from the just arrived I2 packet. 4266 The local Diffie-Hellman key and the nonce I are the ones that 4267 were sent earlier in the R1 packet. 4269 6. If the system's state machine is in the I1-SENT state, and the 4270 HITs in the I2 packet match those used in the previously sent I1 4271 packet, the system uses this received I2 packet as the basis for 4272 the HIP association it was trying to form, and stops 4273 retransmitting I1 packets (provided that the I2 packet passes 4274 the additional checks below). 4276 7. If the system's state machine is in any other state than 4277 R2-SENT, the system SHOULD check that the echoed R1 generation 4278 counter in the I2 packet is within the acceptable range if the 4279 counter is included. Implementations MUST accept puzzles from 4280 the current generation and MAY accept puzzles from earlier 4281 generations. If the generation counter in the newly received I2 4282 packet is outside the accepted range, the I2 packet is stale 4283 (and perhaps replayed) and SHOULD be dropped. 4285 8. The system MUST validate the solution to the puzzle by computing 4286 the hash described in Section 5.3.3 using the same RHASH 4287 algorithm. 4289 9. The I2 packet MUST have a single value in the HIP_CIPHER 4290 parameter, which MUST match one of the values offered to the 4291 Initiator in the R1 packet. 4293 10. The system must derive Diffie-Hellman keying material Kij based 4294 on the public value and Group ID in the DIFFIE_HELLMAN 4295 parameter. This key is used to derive the HIP association keys, 4296 as described in Section 6.5. If the Diffie-Hellman Group ID is 4297 unsupported, the I2 packet is silently dropped. 4299 11. The encrypted HOST_ID is decrypted by the Initiator's encryption 4300 key defined in Section 6.5. If the decrypted data is not a 4301 HOST_ID parameter, the I2 packet is silently dropped. 4303 12. The implementation SHOULD also verify that the Initiator's HIT 4304 in the I2 packet corresponds to the Host Identity sent in the I2 4305 packet. (Note: some middleboxes may not able to make this 4306 verification.) 4308 13. The system MUST process the TRANSPORT_FORMAT_LIST parameter. 4309 Other documents specifying transport formats (e.g. 4310 [I-D.ietf-hip-rfc5202-bis]) contain specifications for handling 4311 any specific transport selected. 4313 14. The system MUST verify the HIP_MAC according to the procedures 4314 in Section 5.2.12. 4316 15. The system MUST verify the HIP_SIGNATURE according to 4317 Section 5.2.14 and Section 5.3.3. 4319 16. If the checks above are valid, then the system proceeds with 4320 further I2 processing; otherwise, it discards the I2 and its 4321 state machine remains in the same state. 4323 17. The I2 packet may have the A bit set -- in this case, the system 4324 MAY choose to refuse it by dropping the I2 and the state machine 4325 returns to state UNASSOCIATED. If the A bit is set, the 4326 Initiator's HIT is anonymous and should not be stored 4327 permanently. 4329 18. The system initializes the remaining variables in the associated 4330 state, including Update ID counters. 4332 19. Upon successful processing of an I2 message when the system's 4333 state machine is in state UNASSOCIATED, I1-SENT, I2-SENT, or 4334 R2-SENT, an R2 packet is sent and the system's state machine 4335 transitions to state R2-SENT. 4337 20. Upon successful processing of an I2 packet when the system's 4338 state machine is in state ESTABLISHED, the old HIP association 4339 is dropped and a new one is installed, an R2 packet is sent, and 4340 the system's state machine transitions to R2-SENT. 4342 21. Upon the system's state machine transitioning to R2-SENT, the 4343 system starts a timer. The state machine transitions to 4344 ESTABLISHED if some data has been received on the incoming HIP 4345 association, or an UPDATE packet has been received (or some 4346 other packet that indicates that the peer system's state machine 4347 has moved to ESTABLISHED). If the timer expires (allowing for 4348 maximal amount of retransmissions of I2 packets), the state 4349 machine transitions to ESTABLISHED. 4351 6.9.1. Handling of Malformed Messages 4353 If an implementation receives a malformed I2 message, the behavior 4354 SHOULD depend on how many checks the message has already passed. If 4355 the puzzle solution in the message has already been checked, the 4356 implementation SHOULD report the error by responding with a NOTIFY 4357 packet. Otherwise, the implementation MAY respond with an ICMP 4358 message as defined in Section 5.4. 4360 6.10. Processing of Incoming R2 Packets 4362 An R2 packet received in states UNASSOCIATED, I1-SENT, or ESTABLISHED 4363 results in the R2 packet being dropped and the state machine staying 4364 in the same state. If an R2 packet is received in state I2-SENT, it 4365 MUST be processed. 4367 The following steps define the conceptual processing rules for an 4368 incoming R2 packet: 4370 1. If the system is in any other state than I2-SENT, the R2 packet 4371 is silently dropped. 4373 2. The system MUST verify that the HITs in use correspond to the 4374 HITs that were received in the R1 packet that caused the 4375 transition to the I1-SENT state. 4377 3. The system MUST verify the HIP_MAC_2 according to the procedures 4378 in Section 5.2.13. 4380 4. The system MUST verify the HIP signature according to the 4381 procedures in Section 5.2.14. 4383 5. If any of the checks above fail, there is a high probability of 4384 an ongoing man-in-the-middle or other security attack. The 4385 system SHOULD act accordingly, based on its local policy. 4387 6. Upon successful processing of the R2 packet, the state machine 4388 transitions to state ESTABLISHED. 4390 6.11. Sending UPDATE Packets 4392 A host sends an UPDATE packet when it intends to update some 4393 information related to a HIP association. There are a number of 4394 possible scenarios when this can occur, e.g., mobility management and 4395 rekeying of an existing ESP Security Association. The following 4396 paragraphs define the conceptual rules for sending an UPDATE packet 4397 to the peer. Additional steps can be defined in other documents 4398 where the UPDATE packet is used. 4400 The sequence of UPDATE messages is indicated by their SEQ parameter. 4401 Before sending an UPDATE message, the system first determines whether 4402 there are any outstanding UPDATE messages that may conflict with the 4403 new UPDATE message under consideration. When multiple UPDATEs are 4404 outstanding (not yet acknowledged), the sender must assume that such 4405 UPDATEs may be processed in an arbitrary order by the receiver. 4406 Therefore, any new UPDATEs that depend on a previous outstanding 4407 UPDATE being successfully received and acknowledged MUST be postponed 4408 until reception of the necessary ACK(s) occurs. One way to prevent 4409 any conflicts is to only allow one outstanding UPDATE at a time. 4410 However, allowing multiple UPDATEs may improve the performance of 4411 mobility and multihoming protocols. 4413 The following steps define the conceptual processing rules for 4414 sending UPDATE packets. 4416 1. The first UPDATE packet is sent with Update ID of zero. 4417 Otherwise, the system increments its own Update ID value by one 4418 before continuing the steps below. 4420 2. The system creates an UPDATE packet that contains a SEQ parameter 4421 with the current value of Update ID. The UPDATE packet MAY also 4422 include zero or more ACKs of the peer's Update ID(s) from 4423 previously received UPDATE SEQ parameter(s) 4425 3. The system sends the created UPDATE packet and starts an UPDATE 4426 timer. The default value for the timer is 2 * RTT estimate. If 4427 multiple UPDATEs are outstanding, multiple timers are in effect. 4429 4. If the UPDATE timer expires, the UPDATE is resent. The UPDATE 4430 can be resent UPDATE_RETRY_MAX times. The UPDATE timer SHOULD be 4431 exponentially backed off for subsequent retransmissions. If no 4432 acknowledgment is received from the peer after UPDATE_RETRY_MAX 4433 times, the HIP association is considered to be broken and the 4434 state machine SHOULD move from state ESTABLISHED to state CLOSING 4435 as depicted in Section 4.4.4. The UPDATE timer is cancelled upon 4436 receiving an ACK from the peer that acknowledges receipt of the 4437 UPDATE. 4439 6.12. Receiving UPDATE Packets 4441 When a system receives an UPDATE packet, its processing depends on 4442 the state of the HIP association and the presence and values of the 4443 SEQ and ACK parameters. Typically, an UPDATE message also carries 4444 optional parameters whose handling is defined in separate documents. 4446 For each association, a host stores the peer's next expected in- 4447 sequence Update ID ("peer Update ID"). Initially, this value is 4448 zero. Update ID comparisons of "less than" and "greater than" are 4449 performed with respect to a circular sequence number space. Hence, a 4450 wrap around after 2^32 updates has to be expected and MUST be handled 4451 accordingly. 4453 The sender MAY send multiple outstanding UPDATE messages. These 4454 messages are processed in the order in which they are received at the 4455 receiver (i.e., no re-sequencing is performed). When processing 4456 UPDATEs out-of-order, the receiver MUST keep track of which UPDATEs 4457 were previously processed, so that duplicates or retransmissions are 4458 ACKed and not reprocessed. A receiver MAY choose to define a receive 4459 window of Update IDs that it is willing to process at any given time, 4460 and discard received UPDATEs falling outside of that window. 4462 The following steps define the conceptual processing rules for 4463 receiving UPDATE packets. 4465 1. If there is no corresponding HIP association, the implementation 4466 MAY reply with an ICMP Parameter Problem, as specified in 4467 Section 5.4.4. 4469 2. If the association is in the ESTABLISHED state and the SEQ (but 4470 not ACK) parameter is present, the UPDATE is processed and 4471 replied to as described in Section 6.12.1. 4473 3. If the association is in the ESTABLISHED state and the ACK (but 4474 not SEQ) parameter is present, the UPDATE is processed as 4475 described in Section 6.12.2. 4477 4. If the association is in the ESTABLISHED state and there is both 4478 an ACK and SEQ in the UPDATE, the ACK is first processed as 4479 described in Section 6.12.2, and then the rest of the UPDATE is 4480 processed as described in Section 6.12.1. 4482 6.12.1. Handling a SEQ Parameter in a Received UPDATE Message 4484 The following steps define the conceptual processing rules for 4485 handling a SEQ parameter in a received UPDATE packet. 4487 1. If the Update ID in the received SEQ is not the next in the 4488 sequence of Update IDs and is greater than the receiver's window 4489 for new UPDATEs, the packet MUST be dropped. 4491 2. If the Update ID in the received SEQ corresponds to an UPDATE 4492 that has recently been processed, the packet is treated as a 4493 retransmission. The HIP_MAC verification (next step) MUST NOT be 4494 skipped. (A byte-by-byte comparison of the received and a stored 4495 packet would be acceptable, though.) It is recommended that a 4496 host caches UPDATE packets sent with ACKs to avoid the cost of 4497 generating a new ACK packet to respond to a replayed UPDATE. The 4498 system MUST acknowledge, again, such (apparent) UPDATE message 4499 retransmissions but SHOULD also consider rate-limiting such 4500 retransmission responses to guard against replay attacks. 4502 3. The system MUST verify the HIP_MAC in the UPDATE packet. If the 4503 verification fails, the packet MUST be dropped. 4505 4. The system MAY verify the SIGNATURE in the UPDATE packet. If the 4506 verification fails, the packet SHOULD be dropped and an error 4507 message logged. 4509 5. If a new SEQ parameter is being processed, the parameters in the 4510 UPDATE are then processed. The system MUST record the Update ID 4511 in the received SEQ parameter, for replay protection. 4513 6. An UPDATE acknowledgment packet with ACK parameter is prepared 4514 and sent to the peer. This ACK parameter MAY be included in a 4515 separate UPDATE or piggybacked in an UPDATE with SEQ parameter, 4516 as described in Section 5.3.5. The ACK parameter MAY acknowledge 4517 more than one of the peer's Update IDs. 4519 6.12.2. Handling an ACK Parameter in a Received UPDATE Packet 4521 The following steps define the conceptual processing rules for 4522 handling an ACK parameter in a received UPDATE packet. 4524 1. The sequence number reported in the ACK must match with an UPDATE 4525 packet sent earlier that has not already been acknowledged. If 4526 no match is found or if the ACK does not acknowledge a new 4527 UPDATE, the packet MUST either be dropped if no SEQ parameter is 4528 present, or the processing steps in Section 6.12.1 are followed. 4530 2. The system MUST verify the HIP_MAC in the UPDATE packet. If the 4531 verification fails, the packet MUST be dropped. 4533 3. The system MAY verify the SIGNATURE in the UPDATE packet. If the 4534 verification fails, the packet SHOULD be dropped and an error 4535 message logged. 4537 4. The corresponding UPDATE timer is stopped (see Section 6.11) so 4538 that the now acknowledged UPDATE is no longer retransmitted. If 4539 multiple UPDATEs are acknowledged, multiple timers are stopped. 4541 6.13. Processing of NOTIFY Packets 4543 Processing of NOTIFY packets is OPTIONAL. If processed, any errors 4544 in a received NOTIFICATION parameter SHOULD be logged. Received 4545 errors MUST be considered only as informational, and the receiver 4546 SHOULD NOT change its HIP state (see Section 4.4.2) purely based on 4547 the received NOTIFY message. 4549 6.14. Processing CLOSE Packets 4551 When the host receives a CLOSE message, it responds with a CLOSE_ACK 4552 message and moves to CLOSED state. (The authenticity of the CLOSE 4553 message is verified using both HIP_MAC and SIGNATURE). This 4554 processing applies whether or not the HIP association state is 4555 CLOSING in order to handle simultaneous CLOSE messages from both ends 4556 that cross in flight. 4558 The HIP association is not discarded before the host moves to the 4559 UNASSOCIATED state. 4561 Once the closing process has started, any new need to send data 4562 packets triggers creating and establishing of a new HIP association, 4563 starting with sending of an I1 packet. 4565 If there is no corresponding HIP association, the CLOSE packet is 4566 dropped. 4568 6.15. Processing CLOSE_ACK Packets 4570 When a host receives a CLOSE_ACK message, it verifies that it is in 4571 CLOSING or CLOSED state and that the CLOSE_ACK was in response to the 4572 CLOSE. A host can map CLOSE_ACK messages to CLOSE messages by 4573 comparing the value of ECHO_REQUEST_SIGNED (in the CLOSE packet) to 4574 the value of ECHO_RESPONSE_SIGNED (in the CLOSE_ACK packet). 4576 The CLOSE_ACK contains the HIP_MAC and the SIGNATURE parameters for 4577 verification. The state is discarded when the state changes to 4578 UNASSOCIATED and, after that, the host MAY respond with an ICMP 4579 Parameter Problem to an incoming CLOSE message (see Section 5.4.4). 4581 6.16. Handling State Loss 4583 In the case of a system crash and unanticipated state loss, the 4584 system SHOULD delete the corresponding HIP state, including the 4585 keying material. That is, the state SHOULD NOT be stored in long- 4586 term storage. If the implementation does drop the state (as 4587 RECOMMENDED), it MUST also drop the peer's R1 generation counter 4588 value, unless a local policy explicitly defines that the value of 4589 that particular host is stored. An implementation MUST NOT store a 4590 peer's R1 generation counters by default, but storing R1 generation 4591 counter values, if done, MUST be configured by explicit HITs. 4593 7. HIP Policies 4595 There are a number of variables that will influence the HIP base 4596 exchanges that each host must support. All HIP implementations MUST 4597 support more than one simultaneous HI, at least one of which SHOULD 4598 be reserved for anonymous usage. Although anonymous HIs will be 4599 rarely used as Responders' HIs, they will be common for Initiators. 4600 Support for more than two HIs is RECOMMENDED. 4602 Initiators MAY use a different HI for different Responders to provide 4603 basic privacy. Whether such private HIs are used repeatedly with the 4604 same Responder and how long these HIs are used is decided by local 4605 policy and depends on the privacy requirements of the Initiator. 4607 The value of #K used in the HIP R1 must be chosen with care. Too 4608 high numbers of #K will exclude clients with weak CPUs because these 4609 devices cannot solve the puzzle within reasonable time. #K should 4610 only be raised if a Responder is under high load, i.e., it cannot 4611 process all incoming HIP handshakes any more. If a responder is not 4612 under high load, K SHOULD be 0. 4614 Responders that only respond to selected Initiators require an ACL, 4615 representing for which hosts they accept HIP base exchanges, and the 4616 preferred transport format and local lifetimes. Wildcarding SHOULD 4617 be supported for such ACLs, and also for Responders that offer public 4618 or anonymous services. 4620 8. Security Considerations 4622 HIP is designed to provide secure authentication of hosts. HIP also 4623 attempts to limit the exposure of the host to various denial-of- 4624 service and man-in-the-middle (MitM) attacks. In doing so, HIP 4625 itself is subject to its own DoS and MitM attacks that potentially 4626 could be more damaging to a host's ability to conduct business as 4627 usual. 4629 Denial-of-service attacks often take advantage of asymmetries in the 4630 cost of an starting an association. One example of such asymmetry is 4631 the need of a Responder to store local state while a malicious 4632 Initiator can stay stateless. HIP makes no attempt to increase the 4633 cost of the start of state at the Initiator, but makes an effort to 4634 reduce the cost for the Responder. This is accomplished by having 4635 the Responder start the 3-way exchange instead of the Initiator, 4636 making the HIP protocol 4 packets long. In doing this, the first 4637 packet from the Responder, R1, becomes a 'stock' packet that the 4638 Responder MAY use many times, until some Initiator has provided a 4639 valid response to such an R1 packet. During an I1 packet storm, the 4640 host may reuse the same DH value also even if some Initiator has 4641 provided a valid response using that particular DH value. However, 4642 such behavior is discouraged and should be avoided. Using the same 4643 Diffie-Hellman values and random puzzle #I value has some risks. 4644 This risk needs to be balanced against a potential storm of HIP I1 4645 packets. 4647 This shifting of the start of state cost to the Initiator in creating 4648 the I2 HIP packet presents another DoS attack. The attacker can 4649 spoof the I1 packet and the Responder sends out the R1 HIP packet. 4650 This could conceivably tie up the 'Initiator' with evaluating the R1 4651 HIP packet, and creating the I2 packet. The defense against this 4652 attack is to simply ignore any R1 packet where a corresponding I1 4653 packet was not sent (as defined in Section 6.8 step 1). 4655 The R1 packet is considerably larger than the I1 packet. This 4656 asymmetry can be exploited in an reflection attack. A malicious 4657 attacker could spoof the IP address of a victim and send a flood of 4658 I1 messages to a powerful Responder. For each small I1 packet, the 4659 Responder would send a larger R1 packet to the victim. The 4660 difference in packet sizes can further amplify a flooding attack 4661 against the victim. To avoid such reflection attacks, the Responder 4662 SHOULD rate limit the sending of R1 packets in general or SHOULD rate 4663 limit the sending of R1 packets to a specific IP address. 4665 Floods of forged I2 packets form a second kind of DoS attack. Once 4666 the attacking Initiator has solved the puzzle, it can send packets 4667 with spoofed IP source addresses with either an invalid HIP signature 4668 or invalid encrypted HIP payload (in the ENCRYPTED parameter). This 4669 would take resources in the Responder's part to reach the point to 4670 discover that the I2 packet cannot be completely processed. The 4671 defense against this attack is after N bad I2 packets with the same 4672 puzzle solution, the Responder would discard any I2 packets that 4673 contain the given solution. This will shut down the attack. The 4674 attacker would have to request another R1 packet and use that to 4675 launch a new attack. The Responder could increase the value of #K 4676 while under attack. Keeping a list of solutions from malformed 4677 packets requires that the Responder keeps state for these malformed 4678 I2 packets. This state has to be kept until the R1 counter is 4679 increased. As malformed packets are generally filtered by their 4680 checksum before signature verification, only solutions in packets 4681 that are forged to pass the checksum and puzzle are put to the 4682 blacklist. In addition, a valid puzzle is required before a new list 4683 entry is created. Hence, attackers that intend to flood the 4684 blacklist must solve puzzles first. 4686 A third form of DoS attack is emulating the restart of state after a 4687 reboot of one of the peers. A restarting host would send an I1 4688 packet to the peers, which would respond with an R1 packet even if it 4689 were in the ESTABLISHED state. If the I1 packet were spoofed, the 4690 resulting R1 packet would be received unexpectedly by the spoofed 4691 host and would be dropped, as in the first case above. 4693 A fourth form of DoS attack is emulating closing of the HIP 4694 association. HIP relies on timers and a CLOSE/CLOSE_ACK handshake to 4695 explicitly signal the end of a HIP association. Because both CLOSE 4696 and CLOSE_ACK messages contain a HIP_MAC, an outsider cannot close a 4697 connection. The presence of an additional SIGNATURE allows 4698 middleboxes to inspect these messages and discard the associated 4699 state (for e.g., firewalling, SPI-based NATing, etc.). However, the 4700 optional behavior of replying to CLOSE with an ICMP Parameter Problem 4701 packet (as described in Section 5.4.4) might allow an attacker 4702 spoofing the source IP address to send CLOSE messages to launch 4703 reflection attacks. 4705 A fifth form of DoS attack is replaying R1s to cause the Initiator to 4706 solve stale puzzles and become out of synchronization with the 4707 Responder. The R1 generation counter is a monotonically increasing 4708 counter designed to protect against this attack, as described in 4709 Section 4.1.4. 4711 Man-in-the-middle attacks are difficult to defend against, without 4712 third-party authentication. A skillful MitM could easily handle all 4713 parts of HIP, but HIP indirectly provides the following protection 4714 from a MitM attack. If the Responder's HI is retrieved from a signed 4715 DNS zone, a certificate, or through some other secure means, the 4716 Initiator can use this to validate the R1 HIP packet. 4718 Likewise, if the Initiator's HI is in a secure DNS zone, a trusted 4719 certificate, or otherwise securely available, the Responder can 4720 retrieve the HI (after having got the I2 HIP packet) and verify that 4721 the HI indeed can be trusted. 4723 The HIP Opportunistic Mode concept has been introduced in this 4724 document, but this document does not specify what the semantics of 4725 such a connection setup are for applications. There are certain 4726 concerns with opportunistic mode, as discussed in Section 4.1.8. 4728 NOTIFY messages are used only for informational purposes and they are 4729 unacknowledged. A HIP implementation cannot rely solely on the 4730 information received in a NOTIFY message because the packet may have 4731 been replayed. An implementation SHOULD NOT change any state 4732 information purely based on a received NOTIFY message. 4734 Since not all hosts will ever support HIP, ICMP 'Destination Protocol 4735 Unreachable' messages are to be expected and may be used for a DoS 4736 attack. Against an Initiator, the attack would look like the 4737 Responder does not support HIP, but shortly after receiving the ICMP 4738 message, the Initiator would receive a valid R1 HIP packet. Thus, to 4739 protect from this attack, an Initiator SHOULD NOT react to an ICMP 4740 message until a reasonable delta time to get the real Responder's R1 4741 HIP packet. A similar attack against the Responder is more involved. 4742 Normally, if an I1 message received by a Responder was a bogus one 4743 sent by an attacker, the Responder may receive an ICMP message from 4744 the IP address the R1 message was sent to. However, a sophisticated 4745 attacker can try to take advantage of such a behavior and try to 4746 break up the HIP base exchange by sending such an ICMP message to the 4747 Responder before the Initiator has a chance to send a valid I2 4748 message. Hence, the Responder SHOULD NOT act on such an ICMP 4749 message. Especially, it SHOULD NOT remove any minimal state created 4750 when it sent the R1 HIP packet (if it did create one), but wait for 4751 either a valid I2 HIP packet or the natural timeout (that is, if R1 4752 packets are tracked at all). Likewise, the Initiator SHOULD ignore 4753 any ICMP message while waiting for an R2 HIP packet, and SHOULD 4754 delete any pending state only after a natural timeout. 4756 9. IANA Considerations 4758 IANA has reserved protocol number 139 for the Host Identity Protocol 4759 and included it in the "IPv6 Extension Header Types" registry 4760 [RFC7045]. No new action regarding this value is required by this 4761 specification. 4763 The reference to the 128-bit value under the CGA Message Type 4764 namespace [RFC3972] of "0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA" 4765 should be changed from [RFC5201] to this specification. 4767 The following changes to the "Host Identity Protocol (HIP) 4768 Parameters" registries are requested. In many cases, the changes 4769 required involve updating the reference from [RFC5201] to this 4770 specification, but there are some differences as outlined below. 4771 Allocation terminology is defined in [RFC5226]; any existing 4772 references to "IETF Consensus" can be replaced with "IETF Review" as 4773 per [RFC5226]. 4775 HIP Version 4777 This document adds the value "2" to the existing registry. The 4778 value of "1" should be left with a reference to [RFC5201]. 4780 Packet Type 4782 The 7-bit Packet Type field in a HIP protocol packet describes the 4783 type of a HIP protocol message. It is defined in Section 5.1. 4784 All existing values referring to [RFC5201] should be updated to 4785 refer to this specification. Other values should be left 4786 unchanged. 4788 HIT Suite ID 4790 This specification creates a new registry for "HIT Suite ID". 4791 This is different than the existing registry for "Suite ID" which 4792 can be left unmodified for version 1 of the protocol ([RFC5201]). 4794 The four-bit HIT Suite ID uses the OGA field in the ORCHID to 4795 express the type of the HIT. This document defines three HIT 4796 Suites (see Appendix E). 4798 The HIT Suite ID is also carried in the four higher-order bits of 4799 the ID field in the HIT_SUITE_LIST parameter. The four lower- 4800 order bits are reserved for future extensions of the HIT Suite ID 4801 space beyond 16 values. 4803 For the time being, the HIT Suite uses only four bits because 4804 these bits have to be carried in the HIT. Using more bits for the 4805 HIT Suite ID reduces the cryptographic strength of the HIT. HIT 4806 Suite IDs must be allocated carefully to avoid namespace 4807 exhaustion. Moreover, deprecated IDs should be reused after an 4808 appropriate time span. If 16 Suite IDs prove insufficient and 4809 more HIT Suite IDs are needed concurrently, more bits can be used 4810 for the HIT Suite ID by using one HIT Suite ID (0) to indicate 4811 that more bits should be used. The HIT_SUITE_LIST parameter 4812 already supports 8-bit HIT Suite IDs, should longer IDs be needed. 4813 Possible extensions of the HIT Suite ID space to accommodate eight 4814 bits and new HIT Suite IDs are defined through IETF Review. 4816 Parameter Type 4818 The 16-bit Type field in a HIP parameter describes the type of the 4819 parameter. It is defined in Section 5.2.1. The current values 4820 are defined in Sections 5.2.3 through 5.2.23. The existing 4821 registry for "Parameter Type" should be updated as follows. 4823 A new value (129) for R1_COUNTER should be introduced, with a 4824 reference to this specification, and the existing value (128) for 4825 R1_COUNTER left in place with a reference to [RFC5201]. This 4826 documents the change in value that has occurred in version 2 of 4827 this protocol. 4829 A new value (579) for a new Parameter Type HIP_CIPHER should be 4830 added, with reference to this specification. This Parameter Type 4831 functionally replaces the HIP_TRANSFORM Parameter Type (value 577) 4832 which can be left in the table with existing reference to 4833 [RFC5201]. 4835 A new value (715) for a new Parameter Type HIT_SUITE_LIST should 4836 be added, with reference to this specification. 4838 A new value (2049) for a new Parameter Type TRANSPORT_FORMAT_LIST 4839 should be added, with reference to this specification. 4841 The name of the HMAC Parameter Type (value 61505) should be 4842 changed to HIP_MAC. The name of the HMAC_2 Parameter Type (value 4843 61569) should be changed to HIP_MAC_2. 4845 All other Parameter Types that reference [RFC5201] should be 4846 updated to refer to this specification, and Parameter Types that 4847 reference other RFCs should be unchanged. 4849 Regarding the range assignments, the Type codes 32768 through 4850 49151 (not 49141) should be Reserved for Private Use. Where the 4851 existing ranges state "First Come First Served with Specification 4852 Required", this should be changed to "Specification Required". 4854 The Type codes 32768 through 49151 are reserved for 4855 experimentation. Types SHOULD be selected in a random fashion 4856 from this range, thereby reducing the probability of collisions. 4857 A method employing genuine randomness (such as flipping a coin) 4858 SHOULD be used. 4860 Group ID 4862 The eight-bit Group ID values appear in the DIFFIE_HELLMAN 4863 parameter and the DH_GROUP_LIST parameter and are defined in 4864 Section 5.2.7. This registry should be updated based on the new 4865 values specified in Section 5.2.7; values noted as being 4866 DEPRECATED can be left in the table with reference to [RFC5201]. 4867 New values are assigned through IETF Review. 4869 HIP Cipher ID 4871 The 16-bit Cipher ID values in a HIP_CIPHER parameter are defined 4872 in Section 5.2.8. This is a new registry. New values either from 4873 the reserved or unassigned space are assigned through IETF Review. 4875 DI-Type 4877 The four-bit DI-Type values in a HOST_ID parameter are defined in 4878 Section 5.2.9. New values are assigned through IETF Review. All 4879 existing values referring to [RFC5201] should be updated to refer 4880 to this specification. 4882 HI Algorithm 4884 The 16-bit Algorithm values in a HOST_ID parameter are defined in 4885 Section 5.2.9. This is a new registry. New values either from 4886 the reserved or unassigned space are assigned through IETF Review. 4888 ECC Curve Label 4890 When the HI Algorithm values in a HOST_ID parameter is defined to 4891 the values of either "ECDSA" or "ECDSA_LOW", a new registry is 4892 needed to maintain the values for the ECC Curve Label as defined 4893 in Section 5.2.9. This might be handled by specifying two 4894 algorithm-specific sub-registries named "ECDSA Curve Label" and 4895 "ECDSA_LOW Curve Label". New values are to be assigned through 4896 IETF Review. 4898 Notify Message Type 4900 The 16-bit Notify Message Type values in a NOTIFICATION parameter 4901 are defined in Section 5.2.19. 4903 Notify Message Type values 1-10 are used for informing about 4904 errors in packet structures, values 11-20 for informing about 4905 problems in parameters containing cryptographic related material, 4906 values 21-30 for informing about problems in authentication or 4907 packet integrity verification. Parameter numbers above 30 can be 4908 used for informing about other types of errors or events. 4910 The existing registration procedures should be updated as follows. 4911 The range from 1-50 can remain as "IETF Review". The range from 4912 51-8191 should be marked as "Specification Required". Values 4913 8192-16383 can remain as "Reserved for Private Use". Values 4914 16385-40959 should be marked as "Specification Required". Values 4915 40960-65535 can remain as "Reserved for Private Use". 4917 The following updates to the values should be made to the existing 4918 registry. All existing values referring to [RFC5201] should be 4919 updated to refer to this specification. 4921 INVALID_HIP_TRANSFORM_CHOSEN should be renamed to 4922 INVALID_HIP_CIPHER_CHOSEN with the same value (17). 4924 A new value of 20 for the type UNSUPPORTED_HIT_SUITE should be 4925 added. 4927 HMAC_FAILED should be renamed to HIP_MAC_FAILED with the same 4928 value (28). 4930 SERVER_BUSY_PLEASE_RETRY should be renamed to 4931 RESPONDER_BUSY_PLEASE_RETRY with the same value (44). 4933 10. Acknowledgments 4935 The drive to create HIP came to being after attending the MALLOC 4936 meeting at the 43rd IETF meeting. Baiju Patel and Hilarie Orman 4937 really gave the original author, Bob Moskowitz, the assist to get HIP 4938 beyond 5 paragraphs of ideas. It has matured considerably since the 4939 early versions thanks to extensive input from IETFers. Most 4940 importantly, its design goals are articulated and are different from 4941 other efforts in this direction. Particular mention goes to the 4942 members of the NameSpace Research Group of the IRTF. Noel Chiappa 4943 provided valuable input at early stages of discussions about 4944 identifier handling and Keith Moore the impetus to provide 4945 resolvability. Steve Deering provided encouragement to keep working, 4946 as a solid proposal can act as a proof of ideas for a research group. 4948 Many others contributed; extensive security tips were provided by 4949 Steve Bellovin. Rob Austein kept the DNS parts on track. Paul 4950 Kocher taught Bob Moskowitz how to make the puzzle exchange expensive 4951 for the Initiator to respond, but easy for the Responder to validate. 4952 Bill Sommerfeld supplied the Birthday concept, which later evolved 4953 into the R1 generation counter, to simplify reboot management. Erik 4954 Nordmark supplied the CLOSE-mechanism for closing connections. 4955 Rodney Thayer and Hugh Daniels provided extensive feedback. In the 4956 early times of this document, John Gilmore kept Bob Moskowitz 4957 challenged to provide something of value. 4959 During the later stages of this document, when the editing baton was 4960 transferred to Pekka Nikander, the input from the early implementors 4961 was invaluable. Without having actual implementations, this document 4962 would not be on the level it is now. 4964 In the usual IETF fashion, a large number of people have contributed 4965 to the actual text or ideas. The list of these people include Jeff 4966 Ahrenholz, Francis Dupont, Derek Fawcus, George Gross, Andrew 4967 McGregor, Julien Laganier, Miika Komu, Mika Kousa, Jan Melen, Henrik 4968 Petander, Michael Richardson, Rene Hummen, Tim Shepard, Jorma Wall, 4969 Xin Gu, and Jukka Ylitalo. Our apologies to anyone whose name is 4970 missing. 4972 Once the HIP Working Group was founded in early 2004, a number of 4973 changes were introduced through the working group process. Most 4974 notably, the original document was split in two, one containing the 4975 base exchange and the other one defining how to use ESP. Some 4976 modifications to the protocol proposed by Aura, et al., [AUR03] were 4977 added at a later stage. 4979 11. Changes from RFC 5201 4981 This section summarizes the changes made from [RFC5201]. 4983 11.1. Changes from draft-ietf-hip-rfc5201-bis-14 4985 o Update source XML to comply with xmlrfcv2 version of the xml2rfc 4986 tool, resulting in a few table formatting changes. 4988 o Editorial and minor technical revisions based on IESG review. 4990 o Significant revisions to IANA Considerations section based on 4991 initial IANA review. 4993 11.2. Changes from draft-ietf-hip-rfc5201-bis-13 4995 o Update a few references and fix some editorial nits. 4997 11.3. Changes from draft-ietf-hip-rfc5201-bis-12 4999 o Fix I-D nits. 5001 11.4. Changes from draft-ietf-hip-rfc5201-bis-11 5003 o Specify that TRANSPORT_FORMAT_LIST is mandatory in R1 and I2; fix 5004 incorrect section reference. 5006 11.5. Changes from draft-ietf-hip-rfc5201-bis-10 5008 o Issue 39: Text clarifying R1 counter rollover and Initiator 5009 response to unexpected reset of the counter. 5011 11.6. Changes from draft-ietf-hip-rfc5201-bis-09 5013 o Editorial changes based on working group last call. 5015 11.7. Changes from draft-ietf-hip-rfc5201-bis-08 5017 o Issue 29: Use different RSA mode OEAP/PSS, elevate ECDSA to 5018 REQUIRED status 5020 o Issue 35: limiting ECC cofactor to 1 5022 o Changed text regarding issue 33 reusing DH values 5023 o Fix tracker issue 32 on Domain Identifier normative text 5025 11.8. Changes from draft-ietf-hip-rfc5201-bis-07 5027 o Removed lingering references to SHA-1 as the mandatory hash 5028 algorithm (which was changed to SHA-256 in the -02 draft version). 5030 o For parameter type number changes, changed "IETF Review" to "IETF 5031 Review or IESG Approval". 5033 o Updated Appendix C checksum examples to conform to HIPv2 packets. 5035 11.9. Changes from draft-ietf-hip-rfc5201-bis-06 5037 o Made echoing the R1_COUNTER in the I2 mandatory if the R1 contains 5038 an R1_COUNTER. This required to make the R1 counter a critical 5039 parameter. Hence, the parameter type number of the R1_COUNTER 5040 changed from 128 to 129. 5042 o Made KDF dependent on DH Group to enable negotiation of the KDF. 5044 11.10. Changes from draft-ietf-hip-rfc5201-bis-05 5046 o Changed type number of DH_GROUP_LIST from 2151 to 511 because it 5047 was in the number space that is reserved for the HIP transport 5048 mode negotiations. 5050 o Added transport form type list parameter. Transport forms are now 5051 negotiated with this list instead of by their order in the HIP 5052 packet. This allows to remove the exception of the transport 5053 format parameters that were ordered by their preference instead of 5054 by their type number. This should remove complexity from 5055 implementations. 5057 o Clarify that in HIP signature processing, the restored checksum 5058 and length fields have been rendered invalid by the previous 5059 steps. 5061 o Clarify behavior for when UPDATE does not contain SEQ or ACQ 5062 (disallow this). 5064 o For namespace changes, changed "IETF Review" to "IETF Review or 5065 IESG Approval". 5067 o Addressed IESG comment about ignoring packet IP addresses. 5069 o Permit using Anonymous HI control in packets other than R1/I2. 5071 o Fixed minor reference error (RFC2418, RFC2410). 5073 o Deleted comment that NULL-ENCRYPTION SHOULD NOT be configurable 5074 via the UI. 5076 o Editorial changes. 5078 11.11. Changes from draft-ietf-hip-rfc5201-bis-04 5080 o Clarifications of the Security Considerations section. One DoS 5081 defense mechanism was changed to be more effective and less prone 5082 to misuse. 5084 o Minor clarifications of the state machine. 5086 o Clarified text on HIP puzzle. 5088 o Added names and references for figures. 5090 o Extended the definitions section. 5092 o Added a reference to the HIP Version 1 certificate document. 5094 o Added Initiator, Responder, HIP association, and signed data to 5095 the definitions section. 5097 o Changed parameter figure for PUZZLE and SOLUTION to use 5098 RHASH_len/8 instead of n-byte. 5100 o Replaced occurrences of lowercase 'not' in SHOULD NOT. 5102 o Changed text to reflect the fact that several 5103 ECHO_REQUEST_UNSIGNED parameters may be present in an R1 and 5104 several ECHO_RESPONSE parameters may be present in an I2. 5106 o Added text on verifying the ECHO_RESPONSE_SIGNED parameter in 5107 CLOSE_ACK. 5109 o Changed wording from HMAC to HIP_MAC in Section 5.3.8. 5111 o Reflected fact that the UPDATE packet MAY include zero or more 5112 ACKs. 5114 o Added BEX to Definitions section. 5116 o Changed HIP_SIGNATURE algorithm field from 8 bit to 16 bit to 5117 achieve alignment with the HOST_ID parameters. 5119 o Fixed the wrong figures of the SEQ and ACK parameters. SEQ always 5120 contains ONE update ID. ACK may acknowledge SEVERAL update IDs. 5122 o Added wording that several NOTIFY parameters may be present in a 5123 HIP packet. 5125 o Changed wording for the ECHO_RESPONSE_SIGNED parameter. Also 5126 lifted the restriction that only one ECHO_RESPONSE_UNSIGNED 5127 parameter MUST be present in each HIP packet. This did contradict 5128 the definition of the ECHO_RESPONSE_UNSIGNED parameter. 5130 o Changed IETF Consensus to IETF Review or IESG Approval in IANA 5131 section. 5133 o Aligned use of I, J, and K. Now I is #I, J is #J and K is #K 5134 throughout the document. 5136 o Updated references. 5138 o Editorial changes. 5140 11.12. Changes from draft-ietf-hip-rfc5201-bis-03 5142 o Editorial changes to improve clarity and readability. 5144 o Removed obsoleted (not applicable) attack from security 5145 consideration section. 5147 o Added a requirement that hosts MUST support processing of ACK 5148 parameters with several SEQ numbers even when they do not support 5149 sending such parameters. 5151 o Removed note on memory bound puzzles. The use of memory bound 5152 puzzles was reconsidered but no convincing arguments for inclusion 5153 in this document have been made on the list. 5155 o Changed references to reference the new bis documents. 5157 o Specified the ECC curves and the hashes used for these. 5159 o Specified representation of ECC curves in the HI. 5161 o Added text on the dependency between RHASH and HMAC. 5163 o Rephrased part of the security considerations to make them 5164 clearer. 5166 o Clarified the use of HITs in opportunistic mode. 5168 o Clarified the difference between HIP_MAC and HIP_MAC_2 as well as 5169 between SIGNATURE and SIGNATURE_2. 5171 o Changed NOTIFY name for value 44 from SERVER_BUSY_PLEASE_RETRY to 5172 RESPONDER_BUSY_PLEASE_RETRY. 5174 o Mentioned that there are multiple valid puzzle solutions. 5176 11.13. Changes from draft-ietf-hip-rfc5201-bis-02 5178 o Added recommendation to not use puzzle #I twice for the same host 5179 to avoid identical key material. 5181 o Revised state machine and added missing event handling. 5183 o Added UNSUPPORTED_HIT_SUITE to NOTIFY to indicate unsupported HIT 5184 suites. 5186 o Revised parameter type numbers (corresponding to IANA allocations) 5187 and added missing "free for experimentation" range to the 5188 description. 5190 o Clarifying note on the use of the C bit in the parameter type 5191 numbers. 5193 11.14. Changes from draft-ietf-hip-rfc5201-bis-01 5195 o Changed RHASH-len to RHASH_len to avoid confusion in calculations 5196 (- could be minus) 5198 o Added RHASH_len to list of abbreviations 5200 o Fixed length of puzzle #I and #J to be 1*RHASH_len 5202 o Changed RHASH-len to RHASH_len to avoid confusion in calculations 5203 (- could be minus) 5205 o Added RHASH_len to list of abbreviations 5207 o Fixed length of puzzle #I and #J to be 1*RHASH_len 5209 o Included HIT_SUITEs. 5211 o Added DH negotiation to I1 and R1. 5213 o Added DH_LIST parameter. 5215 o Added text for DH Group negotiation. 5217 o Removed second DH public value from DH parameter. 5219 o Added ECC to HI generation. 5221 o Added Responder HIT selection to opportunistic mode. 5223 o Added ECDSA HI text and references (not complete yet). 5225 o Added separate section on aborting BEX. 5227 o Added separate section on downgrade attack prevention. 5229 o Added text about DH Group selection for use cases without I1. 5231 o Removed type range allocation for parameters related to HIP 5232 transform types. 5234 o New type range allocation for parameters that are only covered by 5235 a signature if a signature is present (Applies to DH_GROUP_LIST). 5237 o Renamed HIP_TRANSFORM to HIP_CIPHER and removed hashes from it - 5238 hashes are determined by RHASH. 5240 o The length of #I and #J for the puzzle now depends on RHASH. 5242 o New keymat generation. 5244 o Puzzle seed and solution now use RHASH and have variable length. 5246 o Moved timing definitions closer to state machine. 5248 o Simplified text regarding puzzle lifetime. 5250 o Clarified the description of the use of #I in the puzzle 5252 o Removed "Opportunistic mode" description from general definitions. 5254 o More consistency across the old RFC5201 text. Aligned 5255 capitalization and abbreviations. 5257 o Extended protocol overview to include restart option. 5259 o Extended state machine to include restart option because of 5260 unsupported Algorithms. 5262 o Replaced SHA-1 with SHA-256 for required implementation. 5264 o Added OGA list parameter (715) for detecting the Responder's set 5265 of OGAs. 5267 o Added Appendix on ORCHID use in HITs. 5269 o Added truncated SHA-256 option for HITs. 5271 o Added truncated SHA-1 option for HITs. 5273 o Added text about new ORCHID structure to HIT overview. 5275 o Moved Editor role to Robert Moskowitz. 5277 o Added SHA-256 to puzzle parameter. 5279 o Generalized LTRUNC to be hash-function agnostic. 5281 o Added text about RHASH depending on OGA. 5283 11.15. Changes from draft-ietf-hip-rfc5201-bis-00 5285 o Added reasoning why BIS document is needed. 5287 11.16. Contents of draft-ietf-hip-rfc5201-bis-00 5289 o RFC5201 was submitted as draft-RFC. 5291 12. References 5293 12.1. Normative References 5295 [FIPS.180-2.2002] 5296 National Institute of Standards and Technology, "Secure 5297 Hash Standard", FIPS PUB 180-2, August 2002, 5298 . 5301 [I-D.ietf-hip-rfc4843-bis] 5302 Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay 5303 Routable Cryptographic Hash Identifiers Version 2 5304 (ORCHIDv2)", draft-ietf-hip-rfc4843-bis-04 (work in 5305 progress), May 2013. 5307 [I-D.ietf-hip-rfc5202-bis] 5308 Jokela, P., Moskowitz, R., and J. Melen, "Using the 5309 Encapsulating Security Payload (ESP) Transport Format with 5310 the Host Identity Protocol (HIP)", draft-ietf-hip- 5311 rfc5202-bis-05 (work in progress), November 2013. 5313 [NIST.800-131A.2011] 5314 National Institute of Standards and Technology, 5315 "Transitions: Recommendation for Transitioning the Use of 5316 Cryptographic Algorithms and Key Lengths", NIST 800-131A, 5317 January 2011. 5319 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 5320 August 1980. 5322 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 5323 793, September 1981. 5325 [RFC1035] Mockapetris, P., "Domain names - implementation and 5326 specification", STD 13, RFC 1035, November 1987. 5328 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 5329 Requirement Levels", BCP 14, RFC 2119, March 1997. 5331 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within 5332 ESP and AH", RFC 2404, November 1998. 5334 [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and 5335 Its Use With IPsec", RFC 2410, November 1998. 5337 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 5338 (IPv6) Specification", RFC 2460, December 1998. 5340 [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System 5341 (DNS)", RFC 2536, March 1999. 5343 [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain 5344 Name System (DNS)", RFC 3110, May 2001. 5346 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 5347 Diffie-Hellman groups for Internet Key Exchange (IKE)", 5348 RFC 3526, May 2003. 5350 [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher 5351 Algorithm and Its Use with IPsec", RFC 3602, September 5352 2003. 5354 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 5355 RFC 3972, March 2005. 5357 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 5358 Rose, "Resource Records for the DNS Security Extensions", 5359 RFC 4034, March 2005. 5361 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 5362 Network Access Identifier", RFC 4282, December 2005. 5364 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 5365 Message Protocol (ICMPv6) for the Internet Protocol 5366 Version 6 (IPv6) Specification", RFC 4443, March 2006. 5368 [RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using 5369 the Elliptic Curve Digital Signature Algorithm (ECDSA)", 5370 RFC 4754, January 2007. 5372 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 5373 384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007. 5375 [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY 5376 and RRSIG Resource Records for DNSSEC", RFC 5702, October 5377 2009. 5379 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 5380 "Default Address Selection for Internet Protocol Version 6 5381 (IPv6)", RFC 6724, September 2012. 5383 12.2. Informative References 5385 [AUR03] Aura, T., Nagarajan, A., and A. Gurtov, "Analysis of the 5386 HIP Base Exchange Protocol", in Proceedings of 10th 5387 Australasian Conference on Information Security and 5388 Privacy, July 2003. 5390 [CRO03] Crosby, SA. and DS. Wallach, "Denial of Service via 5391 Algorithmic Complexity Attacks", in Proceedings of Usenix 5392 Security Symposium 2003, Washington, DC., August 2003. 5394 [DIF76] Diffie, W. and M. Hellman, "New Directions in 5395 Cryptography", IEEE Transactions on Information Theory 5396 vol. IT-22, number 6, pages 644-654, Nov 1976. 5398 [FIPS.197.2001] 5399 National Institute of Standards and Technology, "Advanced 5400 Encryption Standard (AES)", FIPS PUB 197, November 2001, 5401 . 5404 [FIPS186-3] 5405 U.S. Department of Commerce/National Institute of 5406 Standards and Technology, "FIPS PUB 186-3: Digital 5407 Signature Standard (DSS).", June 2009. 5409 [I-D.ietf-hip-rfc4423-bis] 5410 Moskowitz, R., "Host Identity Protocol Architecture", 5411 draft-ietf-hip-rfc4423-bis-05 (work in progress), 5412 September 2012. 5414 [I-D.ietf-hip-rfc5204-bis] 5415 Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 5416 Rendezvous Extension", draft-ietf-hip-rfc5204-bis-02 (work 5417 in progress), September 2012. 5419 [I-D.ietf-hip-rfc5205-bis] 5420 Laganier, J., "Host Identity Protocol (HIP) Domain Name 5421 System (DNS) Extension", draft-ietf-hip-rfc5205-bis-02 5422 (work in progress), September 2012. 5424 [I-D.ietf-hip-rfc5206-bis] 5425 Henderson, T., Vogt, C., and J. Arkko, "Host Mobility with 5426 the Host Identity Protocol", draft-ietf-hip-rfc5206-bis-06 5427 (work in progress), July 2013. 5429 [KAU03] Kaufman, C., Perlman, R., and B. Sommerfeld, "DoS 5430 protection for UDP-based protocols", ACM Conference on 5431 Computer and Communications Security , Oct 2003. 5433 [KRA03] Krawczyk, H., "SIGMA: The 'SIGn-and-MAc' Approach to 5434 Authenticated Diffie-Hellman and Its Use in the IKE- 5435 Protocols", in Proceedings of CRYPTO 2003, pages 400-425, 5436 August 2003. 5438 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 5439 RFC 792, September 1981. 5441 [RFC2785] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup" 5442 Attacks on the Diffie-Hellman Key Agreement Method for S/ 5443 MIME", RFC 2785, March 2000. 5445 [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography 5446 Specification Version 2.0", RFC 2898, September 2000. 5448 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 5449 Standards (PKCS) #1: RSA Cryptography Specifications 5450 Version 2.1", RFC 3447, February 2003. 5452 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 5453 Reserved for Documentation", RFC 3849, July 2004. 5455 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 5456 "Host Identity Protocol", RFC 5201, April 2008. 5458 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 5459 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 5460 May 2008. 5462 [RFC5338] Henderson, T., Nikander, P., and M. Komu, "Using the Host 5463 Identity Protocol with Legacy Applications", RFC 5338, 5464 September 2008. 5466 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 5467 Shim Protocol for IPv6", RFC 5533, June 2009. 5469 [RFC5747] Wu, J., Cui, Y., Li, X., Xu, M., and C. Metz, "4over6 5470 Transit Solution Using IP Encapsulation and MP-BGP 5471 Extensions", RFC 5747, March 2010. 5473 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 5474 Key Derivation Function (HKDF)", RFC 5869, May 2010. 5476 [RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a 5477 Prime (ECP Groups) for IKE and IKEv2", RFC 5903, June 5478 2010. 5480 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 5481 "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5482 5996, September 2010. 5484 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 5485 Curve Cryptography Algorithms", RFC 6090, February 2011. 5487 [RFC6253] Heer, T. and S. Varjonen, "Host Identity Protocol 5488 Certificates", RFC 6253, May 2011. 5490 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 5491 of IPv6 Extension Headers", RFC 7045, December 2013. 5493 [SECG] SECG, "Recommended Elliptic Curve Domain Parameters", SEC 5494 2 , 2000, . 5496 Appendix A. Using Responder Puzzles 5498 As mentioned in Section 4.1.1, the Responder may delay state creation 5499 and still reject most spoofed I2 packets by using a number of pre- 5500 calculated R1 packets and a local selection function. This appendix 5501 defines one possible implementation in detail. The purpose of this 5502 appendix is to give the implementors an idea on how to implement the 5503 mechanism. If the implementation is based on this appendix, it MAY 5504 contain some local modification that makes an attacker's task harder. 5506 The Responder creates a secret value S, that it regenerates 5507 periodically. The Responder needs to remember the two latest values 5508 of S. Each time the S is regenerated, the R1 generation counter 5509 value is incremented by one. 5511 The Responder generates a pre-signed R1 packet. The signature for 5512 pre-generated R1s must be recalculated when the Diffie-Hellman key is 5513 recomputed or when the R1_COUNTER value changes due to S value 5514 regeneration. 5516 When the Initiator sends the I1 packet for initializing a connection, 5517 the Responder receives the HIT and IP address from the packet, and 5518 generates an #I value for the puzzle. The #I value is set to the 5519 pre-signed R1 packet. 5521 #I value calculation: 5522 #I = Ltrunc( RHASH ( S | HIT-I | HIT-R | IP-I | IP-R ), n) 5523 where n = RHASH_len 5525 The RHASH algorithm is the same that is used to generate the 5526 Responder's HIT value. 5528 From an incoming I2 packet, the Responder receives the required 5529 information to validate the puzzle: HITs, IP addresses, and the 5530 information of the used S value from the R1_COUNTER. Using these 5531 values, the Responder can regenerate the #I, and verify it against 5532 the #I received in the I2 packet. If the #I values match, it can 5533 verify the solution using #I, #J, and difficulty #K. If the #I 5534 values do not match, the I2 is dropped. 5536 puzzle_check: 5537 V := Ltrunc( RHASH( I2.I | I2.hit_i | I2.hit_r | I2.J ), #K ) 5538 if V != 0, drop the packet 5540 If the puzzle solution is correct, the #I and #J values are stored 5541 for later use. They are used as input material when keying material 5542 is generated. 5544 Keeping state about failed puzzle solutions depends on the 5545 implementation. Although it is possible for the Responder not to 5546 keep any state information, it still may do so to protect itself 5547 against certain attacks (see Section 4.1.1). 5549 Appendix B. Generating a Public Key Encoding from an HI 5551 The following pseudo-code illustrates the process to generate a 5552 public key encoding from an HI for both RSA and DSA. 5554 The symbol ":=" denotes assignment; the symbol "+=" denotes 5555 appending. The pseudo-function "encode_in_network_byte_order" takes 5556 two parameters, an integer (bignum) and a length in bytes, and 5557 returns the integer encoded into a byte string of the given length. 5559 switch ( HI.algorithm ) 5560 { 5562 case RSA: 5563 buffer := encode_in_network_byte_order ( HI.RSA.e_len, 5564 ( HI.RSA.e_len > 255 ) ? 3 : 1 ) 5565 buffer += encode_in_network_byte_order ( HI.RSA.e, HI.RSA.e_len ) 5566 buffer += encode_in_network_byte_order ( HI.RSA.n, HI.RSA.n_len ) 5567 break; 5569 case DSA: 5570 buffer := encode_in_network_byte_order ( HI.DSA.T , 1 ) 5571 buffer += encode_in_network_byte_order ( HI.DSA.Q , 20 ) 5572 buffer += encode_in_network_byte_order ( HI.DSA.P , 64 + 5573 8 * HI.DSA.T ) 5574 buffer += encode_in_network_byte_order ( HI.DSA.G , 64 + 5575 8 * HI.DSA.T ) 5576 buffer += encode_in_network_byte_order ( HI.DSA.Y , 64 + 5577 8 * HI.DSA.T ) 5578 break; 5580 } 5582 Appendix C. Example Checksums for HIP Packets 5584 The HIP checksum for HIP packets is specified in Section 5.1.1. 5585 Checksums for TCP and UDP packets running over HIP-enabled security 5586 associations are specified in Section 3.5. The examples below use 5587 [RFC3849] and [RFC5747] addresses, and HITs with the prefix of 5588 2001:10 followed by zeros, followed by a decimal 1 or 2, 5589 respectively. 5591 The following example is defined only for testing the checksum 5592 calculation. 5594 C.1. IPv6 HIP Example (I1 packet) 5596 Source Address: 2001:D88::1 5597 Destination Address: 2001:D88::2 5598 Upper-Layer Packet Length: 48 0x30 5599 Next Header: 139 0x8b 5600 Payload Protocol: 59 0x3b 5601 Header Length: 4 0x4 5602 Packet Type: 1 0x1 5603 Version: 2 0x2 5604 Reserved: 1 0x1 5605 Control: 0 0x0 5606 Checksum: 6878 0x1ade 5607 Sender's HIT : 2001:10::1 5608 Receiver's HIT: 2001:10::2 5609 DH_GROUP_LIST type: 511 0x1ff 5610 DH_GROUP_LIST length: 3 0x3 5611 DH_GROUP_LIST group IDs: 3,4,8 5613 C.2. IPv4 HIP Packet (I1 packet) 5615 The IPv4 checksum value for the example I1 packet is shown below. 5617 Source Address: 192.0.2.1 5618 Destination Address: 192.0.2.2 5619 Upper-Layer Packet Length: 48 0x30 5620 Next Header: 139 0x8b 5621 Payload Protocol: 59 0x3b 5622 Header Length: 4 0x4 5623 Packet Type: 1 0x1 5624 Version: 2 0x2 5625 Reserved: 1 0x1 5626 Control: 0 0x0 5627 Checksum: 61934 0xf1ee 5628 Sender's HIT : 2001:10::1 5629 Receiver's HIT: 2001:10::2 5630 DH_GROUP_LIST type: 511 0x1ff 5631 DH_GROUP_LIST length: 3 0x3 5632 DH_GROUP_LIST group IDs: 3,4,8 5634 C.3. TCP Segment 5636 Regardless of whether IPv6 or IPv4 is used, the TCP and UDP sockets 5637 use the IPv6 pseudo-header format [RFC2460], with the HITs used in 5638 place of the IPv6 addresses. 5640 Sender's HIT: 2001:10::1 5641 Receiver's HIT: 2001:10::2 5642 Upper-Layer Packet Length: 20 0x14 5643 Next Header: 6 0x06 5644 Source port: 65500 0xffdc 5645 Destination port: 22 0x0016 5646 Sequence number: 1 0x00000001 5647 Acknowledgment number: 0 0x00000000 5648 Header length: 20 0x14 5649 Flags: SYN 0x02 5650 Window size: 65535 0xffff 5651 Checksum: 28618 0x6fca 5652 Urgent pointer: 0 0x0000 5654 0x0000: 6000 0000 0014 0640 2001 0010 0000 0000 5655 0x0010: 0000 0000 0000 0001 2001 0010 0000 0000 5656 0x0020: 0000 0000 0000 0002 ffdc 0016 0000 0001 5657 0x0030: 0000 0000 5002 ffff 6fca 0000 5659 Appendix D. ECDH and ECDSA 160 Bit Groups 5661 The ECDH and ECDSA 160-bit group SECP160R1 is rated at 80 bits 5662 symmetric strength. Once this was considered appropriate for one 5663 year of security. Today these groups should be used only when the 5664 host is not powerful enough (e.g., some embedded devices) and when 5665 security requirements are low (e.g., long-term confidentiality is not 5666 required). 5668 Appendix E. HIT Suites and HIT Generation 5670 The HIT as an ORCHID [I-D.ietf-hip-rfc4843-bis] consists of three 5671 parts: A 28-bit prefix, a 4-bit encoding of the ORCHID generation 5672 algorithm (OGA) and the representation of the public key. The OGA is 5673 an index pointing to the specific algorithm by which the public key 5674 and the 96-bit hashed encoding is generated. The OGA is protocol 5675 specific and is to be interpreted as defined below for all protocols 5676 that use the same context ID as HIP. HIP groups sets of valid 5677 combinations of signature and hash algorithms into HIT Suites. These 5678 HIT suites are addressed by an index, which is transmitted in the OGA 5679 field of the ORCHID. 5681 The set of used HIT Suites will be extended to counter the progress 5682 in computation capabilities and vulnerabilities in the employed 5683 algorithms. The intended use of the HIT Suites is to introduce a new 5684 HIT Suite and phase out an old one before it becomes insecure. Since 5685 the 4-bit OGA field only permits 15 HIT Suites (the HIT Suite with ID 5686 0 is reserved) to be used in parallel, phased-out HIT Suites must be 5687 reused at some point. In such a case, there will be a rollover of 5688 the HIT Suite ID and the next newly introduced HIT Suite will start 5689 with a lower HIT Suite index than the previously introduced one. The 5690 rollover effectively deprecates the reused HIT Suite. For a smooth 5691 transition, the HIT Suite should be deprecated a considerable time 5692 before the HIT Suite index is reused. 5694 Since the number of HIT Suites is tightly limited to 16, the HIT 5695 Suites must be assigned carefully. Hence, sets of suitable 5696 algorithms are grouped in a HIT Suite. 5698 The HIT Suite of the Responder's HIT determines the RHASH and the 5699 hash function to be used for the HMAC in HIP packets as well as the 5700 signature algorithm family used for generating the HI. The list of 5701 HIT Suites is defined in Table 11. 5703 The following HIT Suites are defined for HIT generation. The input 5704 for each generation algorithm is the encoding of the HI as defined in 5705 Section 3.2. The output is 96 bits long and is directly used in the 5706 ORCHID. 5708 +-------+----------+--------------+------------+--------------------+ 5709 | Index | Hash | HMAC | Signature | Description | 5710 | | function | | algorithm | | 5711 | | | | family | | 5712 +-------+----------+--------------+------------+--------------------+ 5713 | 0 | | | | Reserved | 5714 | 1 | SHA-256 | HMAC-SHA-256 | RSA, DSA | RSA or DSA HI | 5715 | | | | | hashed with | 5716 | | | | | SHA-256, truncated | 5717 | | | | | to 96 bits | 5718 | 2 | SHA-384 | HMAC-SHA-384 | ECDSA | ECDSA HI hashed | 5719 | | | | | with SHA-384, | 5720 | | | | | truncated to 96 | 5721 | | | | | bits | 5722 | 3 | SHA-1 | HMAC-SHA-1 | ECDSA_LOW | ECDSA_LOW HI | 5723 | | | | | hashed with SHA-1, | 5724 | | | | | truncated to 96 | 5725 | | | | | bits | 5726 +-------+----------+--------------+------------+--------------------+ 5728 Table 11: HIT Suites 5730 The hash of the responder as defined in the HIT Suite determines the 5731 HMAC to be used for the HMAC parameter. The HMACs currently defined 5732 here are HMAC-SHA-256 [RFC4868], HMAC-SHA-384 [RFC4868], and HMAC- 5733 SHA-1 [RFC2404]. 5735 Authors' Addresses 5737 Robert Moskowitz (editor) 5738 Verizon Telcom and Business 5739 1000 Bent Creek Blvd, Suite 200 5740 Mechanicsburg, PA 5741 USA 5743 EMail: robert.moskowitz@verizonbusiness.com 5745 Tobias Heer 5746 Hirschmann Automation and Control 5747 Stuttgarter Strasse 45-51 5748 Neckartenzlingen 72654 5749 Germany 5751 EMail: tobias.heer@belden.com 5753 Petri Jokela 5754 Ericsson Research NomadicLab 5755 JORVAS FIN-02420 5756 FINLAND 5758 Phone: +358 9 299 1 5759 EMail: petri.jokela@nomadiclab.com 5761 Thomas R. Henderson 5762 University of Washington 5763 Campus Box 352500 5764 Seattle, WA 5765 USA 5767 EMail: tomhend@u.washington.edu