idnits 2.17.1 draft-heer-hip-middle-auth-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 684. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 695. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 702. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 708. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- The document has an RFC 3978 Section 5.2(a) Derivative Works Limitation clause. == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 64 has weird spacing: '...itiator is th...' == Line 67 has weird spacing: '...sponder is th...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Middleboxes MAY add ECHO_REQUEST_M parameters to the the R1, I2, and to any UPDATE packet. This parameter contains an opaque data block of variable size which is used by the middlebox to carry arbitrary data. Each of the afore-mentioned HIP packets may contain multiple ECHO_REQUEST_M parameters. As all middleboxes on the path may need to add ECHO_REQUEST_M parameters, the length of the data field of each parameter SHOULD not exceed a maximum of 32 bytes. The total length of the packets SHOULD not exceed 1280 bytes to avoid IPv6 fragmentation (cf. Section Section 2.4). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 11, 2007) is 6011 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'PM1' is mentioned on line 374, but not defined == Missing Reference: 'PM2' is mentioned on line 377, but not defined == Missing Reference: 'SM1' is mentioned on line 388, but not defined == Missing Reference: 'PM3' is mentioned on line 388, but not defined == Unused Reference: 'I-D.ietf-hip-mm' is defined on line 634, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 655, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-hip-nat-traversal-02 Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Host Identity Protocol T. Heer 3 Internet-Draft Distributed Systems Group, RWTH 4 Intended status: Experimental Aachen University 5 Expires: May 14, 2008 November 11, 2007 7 End-Host Authentication for HIP Middleboxes 8 draft-heer-hip-middle-auth-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 This document may not be modified, and derivative works of it may not 17 be created, except to publish it as an RFC and to translate it into 18 languages other than English. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on May 14, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 The Host Identity Protocol is a signaling protocol for secure 45 communication, mobility, and multihoming by introducing a 46 cryptographic namespace. This document specifies an extension for 47 HIP that enables middleboxes to unambiguously verify the identities 48 of hosts that communicate across them. This extension enables 49 middleboxes to verify the liveness and freshness of a HIP association 50 and, thus, enables reliable and secure access control in middleboxes. 52 Requirements Language 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in RFC 2119. 58 Notation 60 [x] indicates that x is optional. 62 {x} indicates that x is under signature. 64 Initiator is the host which initiates a HIP association 65 (cf. HIP base protocol). 67 Responder is the host which responds to the INITIATOR 68 (cf. HIP base protocol). 70 --> signifies "Initiator to Responder" communication. 72 <-- signifies "Responder to Initiator" communication. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 1.1. Authentication and Replay Attacks . . . . . . . . . . . . 5 78 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 79 2.1. Signed Middlebox Nonces . . . . . . . . . . . . . . . . . 6 80 2.2. Identity Verification by Middleboxes . . . . . . . . . . . 8 81 2.3. Failure Signaling . . . . . . . . . . . . . . . . . . . . 11 82 2.4. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 11 83 3. HIP Parameters . . . . . . . . . . . . . . . . . . . . . . . . 11 84 3.1. ECHO_REQUEST_M . . . . . . . . . . . . . . . . . . . . . . 12 85 3.2. ECHO_RESONSE_M . . . . . . . . . . . . . . . . . . . . . . 12 86 3.3. PUZZLE_M . . . . . . . . . . . . . . . . . . . . . . . . . 13 87 3.4. SOLUTION_M . . . . . . . . . . . . . . . . . . . . . . . . 14 88 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 89 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 90 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 91 7. Normative References . . . . . . . . . . . . . . . . . . . . . 15 92 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 93 Intellectual Property and Copyright Statements . . . . . . . . . . 17 95 1. Introduction 97 The Host Identity Protocol (HIP) introduces a new cryptographic 98 namespace, based on public keys, in order to secure Internet 99 communication. This namespace allows hosts to authenticate their 100 peers. HIP was designed to be middlebox-friendly and allows 101 middleboxes to inspect HIP control traffic. Such middleboxes are 102 e.g. firewalls and Network Address Translators (NATs). 104 In this context, one can distinguish HIP-aware middleboxes, which 105 were designed to process HIP packets, and other middleboxes, which 106 are not aware of the Host Identity Protocol. This document addresses 107 only on HIP-aware middleboxes while the behavior of HIP in 108 combination with non-HIP-aware middleboxes is specified elsewhere 109 [I-D.ietf-hip-nat-traversal]. Moreover, the scope of this document 110 is restricted to middleboxes that use HIP in order to enforce access 111 regulation and, thus, need to authenticate the communicating peers 112 that send traffic over the middlebox. The class of middleboxes, this 113 document focuses on, does not require explicit registration via a 114 handshake with the middlebox. HIP behavior for interacting and 115 registering to such middleboxes is specified in 116 [I-D.ietf-hip-registration]. Thus, we focus on middleboxes that 117 build their state-base from packets it forwards. 119 An example for such a middlebox is a firewall that only allows 120 traffic from certain hosts to traverse. We assume that access 121 regulation is performed based on Host Identities (HIs). Such an 122 authenticating middlebox needs to observe the HIP Base EXchange (BEX) 123 or a HIP mobility update [I-D.ietf-hip-mm]" and check the Host 124 Identifiers (HIs) in the packets. 126 Along the lines of [I-D.tschofenig-hiprg-hip-natfw-traversal], an 127 authentication solution for middleboxes must have some vital 128 properties. For one, the middlebox must be able to unambiguously 129 identify one or both of the communicating peers. For another, the 130 solution must not allow for new attacks against the middlebox. This 131 document specifies a HIP extension that allows middleboxes to 132 participate in the HIP handshake and the HIP update process in order 133 to enable these devices to reliably verify the identities of the 134 communicating peers. To this end, this HIP extension defines how 135 middleboxes can interact with end-hosts in order to verify the 136 identity of the end-hosts. 138 Verifying public-key (PK) signatures is costly in terms of CPU 139 cycles. Thus, in addition to authentication capabilities, it is also 140 necessary to provide middleboxes with a way of defending against 141 resource-exhaustion attacks that target PK signature verification. 142 This document defines how middleboxes can utilize the HIP puzzle 143 mechanism defined in [I-D.ietf-hip-base] to slow down resource- 144 exhaustion attacks. 146 1.1. Authentication and Replay Attacks 148 Middleboxes need to be able to verify the HIs in the HIP base 149 exchange messages to perform access control based on Host Identities. 150 However, passive verification of identifiers in the messages is not 151 sufficient to verify the identity of an end-host. Moreover, it is 152 necessary to also ensure the freshness and authenticity of the 153 communication to prevent replay attacks. The basic HIP protocol as 154 specified in [I-D.ietf-hip-base] does not provide adequate protection 155 against these attacks. To illustrate the need for additional 156 security features, we briefly outline a possible replay attack 157 targeted at middleboxes: 159 Assume that a middlebox M checks HIP HIs in order to restrict traffic 160 passing through the box. Further assume that the legitimate owner of 161 HIT X establishes a HIP association with the legitimate owner of HIT 162 Y at some point in time and an attacker A overhears the base exchange 163 and records it. Note that it is not required that the middlebox M is 164 on the communication path between the peers at that time. 166 At some later point in time, A collaborates with another attacker B. 167 They replay the very same BEX with the middlebox M on the 168 communication path. The middlebox has no way to distinguish X and Y 169 A and B as it can only overhear the BEX passively and does not 170 participate in the authentication process. If A and B have agreed on 171 a shared secret beforehand, they can make fake ESP traffic traverse 172 the middlebox by using the SPIs that A and B negotiated in the 173 original BEX. This is problematic in cases for which the middlebox 174 needs to know who is communicating across it. Examples for such 175 cases are access restriction, logging of activities, and accounting 176 for traffic volume or connection duration. 178 So far, this attack is not addressed by the HIP specifications. 179 Therefore, this document specifies a HIP extension that allows 180 middleboxes to defend against it. 182 2. Protocol Overview 184 The following section gives an overview of the interaction between 185 hosts and authenticating middleboxes. 187 2.1. Signed Middlebox Nonces 189 The aforementioned attack scenario clearly shows the necessity for 190 unambiguous end-host identity verification by middleboxes. Relying 191 on nonces generated by the end-hosts is not possible because 192 middleboxes can not verify the freshness of these nonces. 193 Introducing time-stamps restricts the attack to a certain time frame 194 but requires global time synchronization. 196 The following sections specify how HIP hosts can prove their identity 197 by performing a challenge-response protocol between the middlebox and 198 the end-hosts. As the challenge, the middlebox add data (e.g. 199 nonces) to HIP control packets which end-hosts must echo with applied 200 PK signatures. 202 The challenge-response mechanism is similar to the ECHO_REQUEST/ 203 ECHO_RESPONSE mechanism used by HIP end-hosts to authenticate their 204 peers. Middleboxes may add ECHO_REQUEST_M parameters to HIP control 205 packets and verify ECHO_RESPONSE_M parameters. By echoing the data 206 in the ECHO_REQUEST_M parameter as ECHO_RESPONSE_M parameter in the 207 signed part of its response, an end-host proves that it is in 208 possession of the private key that corresponds to the HI it uses. 210 2.1.1. ECHO_REQUEST_M 212 Middleboxes MAY add ECHO_REQUEST_M parameters to the the R1, I2, and 213 to any UPDATE packet. This parameter contains an opaque data block 214 of variable size which is used by the middlebox to carry arbitrary 215 data. Each of the afore-mentioned HIP packets may contain multiple 216 ECHO_REQUEST_M parameters. As all middleboxes on the path may need 217 to add ECHO_REQUEST_M parameters, the length of the data field of 218 each parameter SHOULD not exceed a maximum of 32 bytes. The total 219 length of the packets SHOULD not exceed 1280 bytes to avoid IPv6 220 fragmentation (cf. Section Section 2.4). 222 The ECHO_REQUEST_M parameter is added to the unprotected part of a 223 HIP message. Thus it does not corrupt any HMAC or public-key 224 signatures. However, it is necessary to recompute the IP- and HIP 225 header checksums. The UDP headers of UDP encapsulated HIP packets 226 MUST also be recomputed if UDP encapsulation, as defined in 227 [I-D.ietf-hip-nat-traversal], is applied. 229 An end-host that receives a HIP control packet containing one or 230 multiple ECHO_REQUEST_M parameters must copy the contents of each 231 parameter without modification to an ECHO_RESPONSE_M parameter. This 232 parameter MUST be sent within the signed part of its reply. Note 233 that middleboxes MAY also rewrite the ECHO_REQUEST_UNSIGNED parameter 234 as specified in [I-D.ietf-hip-base] when the receiver of the 235 parameter is not required to sign the contents of the ECHO_REQUEST_M. 237 Middleboxes can delay state creation by utilizing the ECHO_RESPONSE_M 238 and ECHO_REQUEST_M parameter. Encrypted or otherwise protected 239 information about previous authentication steps can be hidden in the 240 opaque blob. 242 2.1.2. ECHO_RESPONSE_M 244 When a middlebox injects an opaque blob of data via an ECHO_REQUEST_M 245 parameter, it expects to receive the same data without modification 246 as part of an ECHO_RESPONSE_M parameter in a subsequent packet. The 247 opaque data MUST be copied as it is from the corresponding 248 ECHO_REQUEST_M parameter. In case of multiple ECHO_REQUEST_M 249 parameters, their order MUST be preserved by the corresponding 250 ECHO_RESPONSE_M parameters. 252 The ECHO_REQUEST_M and ECHO_RESPONSE_M parameters MAY be used for any 253 purpose, in particular when a middlebox needs to carry state or 254 recognizable information in a HIP packet and receive it in a 255 subsequent response packet. The ECHO_RESPONSE_M MUST be covered by 256 the HIP_SIGNATURE. 258 The ECHO_RESPONSE_M parameter is non critical. Depending on its 259 local policy, a middlebox can react differently on a missing 260 ECHO_RESPONSE_M parameter. Possible actions range from degraded or 261 restricted service such as bandwidth limitation up to refusing 262 connections and reporting access violations. 264 2.1.3. Middlebox Puzzles 266 As public-key (PK) operations are costly in terms of CPU cycles, it 267 is necessary to provide some way for the middlebox to defend against 268 resource-exhaustion attacks. The HIP base protocol 269 [I-D.ietf-hip-base] specifies a puzzle mechanism to protect the 270 Responder from I2 floods that require numerous public-key operations. 271 However, middleboxes can not utilize this mechanism as there is no 272 defense against a collaborative replay attack, which involves a 273 malicious Initiator and a malicious Responder. This section 274 specifies how middleboxes can utilize the puzzle mechanism to add 275 their own puzzles to R1, I2, and any UPDATE packets. This allows 276 middleboxes to shelter against Service (DoS) attacks on PK 277 verification. 279 To defend against attacks, a middlebox adds a puzzle in a PUZZLE_M 280 parameter to I2, R2 and UPDATE packets. Depending on the packet to 281 which the puzzle was added, either the Initiator or the Responder of 282 a BEX or the receiver of an UPDATE packet must solve it. 284 A puzzle increases the delay and computational cost for establishing 285 or updating a HIP association, a middlebox SHOULD only add puzzles to 286 packets if it is under attack conditions. Moreover, middleboxes 287 SHOULD distinguish attack directions. If the majority of the CPU 288 load is caused by verifying HIP control messages that arrive from a 289 certain interface, middleboxes MAY add puzzles with higher difficulty 290 to HIP control packets that leave the interface. 292 Middleboxes MAY decide to use only the PUZZLE_M parameter instead of 293 using PUZZLE_M in combination with ECHO_REQUEST_M because the 294 PUZZLE_M parameter also contains an opaque data field that guarantees 295 the freshness of the signature. However, the opaque data field in 296 the PUZZLE_M and the corresponding SOLUTION_M parameter is restricted 297 to 6 bytes which may not be sufficient for all purposes. 299 2.2. Identity Verification by Middleboxes 301 This section describes how middleboxes can interact with the BEX and 302 the HIP update process in order to verify the identity of the HIP 303 end-hosts. 305 2.2.1. Identity Verification During BEX 307 Middleboxes MAY add ECHO_REQUEST_M and PUZZLE_M parameters to R1 and 308 I2 packets in order to verify the identities of the participating 309 parties. Middleboxes can choose to either authenticate the 310 Initiator, the Responder, or both. Middleboxes MUST NOT add 311 ECHO_REQUEST_M or PUZZLE_M parameters to I1 messages because this 312 would expose the Responder to DoS attacks. Thus, middleboxes MUST 313 let unauthenticated minimal I1 packets traverse. Minimal means that 314 the packet MUST NOT contain more than the minimal set of parameters 315 specified by HIP standards or internet drafts. In particular, the I1 316 packet MUST NOT contain any attached payload. Figure 1 illustrates 317 the authentication process during the BEX. 319 Figure 1: Middlebox authentication of a HIP base exchange. 321 Main path: 323 Initiator Middlebox Responder 324 .-----------------. 325 I1 | | I1 326 -------------------> | | ----------------------------> 327 | | 328 R1, + EQ1, [PM1] | Add EQ1, PM1 | R1 329 <------------------- | | <---------------------------- 330 | | 331 I2, {ER1, SM1} | Verify SM1, EQ1 | I2, {ER1, SM1} + EQ2, [PM2] 332 -------------------> | Add EQ2, PM2 | ---------------------------> 333 | | 334 | | 335 R2, {ER2, SM2} | Verify SM2, ER2 | R2, {ER2, SM2} 336 -------------------> | | ----------------------------> 337 '-----------------' 339 EQ: Middlebox Echo reQuest 340 ER: Middlebox Echo Response 341 PM: Puzzle of the Middlebox 342 SM: Solution of Middlebox puzzle 344 2.2.2. Identity Verification During Mobility Updates 346 Multihomed hosts may use multiple communication paths during an HIP 347 mobility update. Depending on whether the middlebox is located on 348 the communication path between the preferred locators or not, the 349 middlebox forwards different packets and, thus, needs to interact 350 differently with the updates. Figure 1 illustrates an update with 351 Middlebox 1 on the path between the Initiator's and the RECEIVER's 352 preferred locators and with Middlebox 2 on an alternative path. 354 Middlebox 1 receives the first UPDATE packet, which contains e.g. the 355 set of new locators. As the middlebox has no adequate way of 356 identifying replay attacks of U1 (first UPDATE message) and, moreover 357 cannot defend against U1 flooding attacks, the middlebox may decide 358 not to verify the signature in the U1 packet. In the case it is 359 necessary to verify the identity of the Responder and the freshness 360 of the UPDATE packets, the middlebox MAY add an ECHO_REQUEST_M (EQ1) 361 to the U1. 363 The following figure illustrates the authentication for middleboxes 364 on the path between the preferred locators (main path) and other 365 paths between two HIP peers (alternative path). 367 Figure 1: Middlebox authentication of a HIP mobility update over 368 different paths. 370 Main path: 372 Initiator Middlebox 1 Responder 373 .------. 374 U1 | | U1 + EQ1, [PM1] 375 -----------------------------> | | ----------------------------> 376 | | 377 U2, {ER1, [SM1]} + EQ2, [PM2] | | U2, {ER1, [SM1]} 378 <----------------------------- |OK | <---------------------------- 379 | | 380 U3, {ER2, SM2} | | U3, {ER2, SM2} 381 -----------------------------> | OK| ----------------------------> 382 '------' 384 Alternative path: 386 Initiator Middlebox 2 Responder 387 .------. 388 U2, {ER1, [SM1]} + P3, [PM3] | | U2, {ER1, [SM1]} 389 <----------------------------- | wrong| <---------------------------- 390 | | 391 U3', {ER3, SM3} | | U3', {ER3, SM3} + EQ4, PM4 392 -----------------------------> |OK | -----------------------------> 393 | | 394 U4, {ER4, [SM4]} | | U4, {ER1, [SM1]} 395 <----------------------------- | OK| <---------------------------- 396 '------' 397 EQ: Middlebox Echo reQuest 398 ER: Middlebox Echo Response 399 PM: Puzzle of the Middlebox 400 SM: Solution of Middlebox puzzle 402 Middlebox 1 can verify the identity of the Responder by checking its 403 PK signature and the presence of the ECHO_RESPONSE_M in the U2 404 packet. If necessary, the middlebox MAY add an ECHO_REQUEST_M for 405 the Initiator of the update. The middlebox can verify the 406 Initiator's identity by verifying its signature and the 407 ECHO_RESPONSE_M in the U3 packet. 409 A middlebox that is not located on the path between preferred 410 locators of the HIP end-hosts does not receive the U1 message. 412 Therefore, it will not recognize any ER1 or SM1 in the second UPDATE 413 packet. Thus, if a middlebox encounters non-matching or missing 414 ECHO_RESPONSE_M parameters, the middlebox SHOULD ignore these. 416 When receiving an UPDATE message with an ECHO_REQUEST_M, a HIP host 417 SHOULD send an UPDATE message containing the corresponding 418 ECHO_RESPONSE_M covered by a HIP_SIGNATURE parameter. Otherwise the 419 middlebox may refuse to make the communication path available to the 420 HIP host. 422 2.2.3. UPDATE Verification 424 As middleboxes need to be able to rapidly verify and forward HIP 425 packets, these devices need to be supplied with all information 426 necessary to do so. If, due to host mobility, a new communication 427 path is used, middleboxes need to be able to learn the Host 428 Identifiers (HIs) from the UPDATE packets. Therefore, HIP hosts MUST 429 include the HOST_ID parameter in all UPDATE packets that use 430 combinations of locators that have not been used before. Thus, 431 UPDATE packets that contain ECHO_REQUEST or ECHO_RESPONSE parameters 432 MUST contain the HOST_ID parameter. Moreover, all packets that 433 contain an ECHO_RESPONSE_M parameter MUST contain the HOST_ID 434 parameter. 436 2.3. Failure Signaling 438 Middleboxes SHOULD inform the sender of a BEX or update message if it 439 does not satisfy the requirements of the middlebox. Reasons for non- 440 satisfactory packets are missing HOST_ID, ECHO_RESPONSE_M, and 441 SOLUTION_M parameters. Options for expressing such shortcomings are 442 ICMP or HIP_NOTIFY packets. Defining this signaling mechanism is 443 future work. 445 2.4. Fragmentation 447 Analogously to the specification in [I-D.ietf-hip-base], HIP aware 448 middleboxes SHOULD support IP-level fragmentation and reassembly for 449 IPv6 and MUST support IP-level fragmentation and reassembly for IPv4. 450 However, when adding ECHO_REQUEST_M and PUZZLE_M parameters, a 451 middlebox SHOULD keep the total packet size below 1280 bytes to avoid 452 packet fragmentation in IPv6. 454 3. HIP Parameters 456 This HIP extension specifies four new HIP parameters that allow 457 middleboxes to authenticate HIP end-hosts and to protect against DoS 458 attacks. 460 3.1. ECHO_REQUEST_M 462 The ECHO_REQUEST_M parameter MAY be added to R1, I2, and UPDATE 463 packets by HIP-aware middleboxes. The structure of the 464 ECHO_REQUEST_M parameter is depicted below: 466 0 1 2 3 467 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 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | Type | Length | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | Opaque data (variable length) | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 Type 65332 475 Length Variable 476 Opaque data Opaque data, supposed to be meaningful only to the 477 middlebox that adds ECHO_REQUEST_M and receives a 478 corresponding ECHO_RESPONSE_M. 480 3.2. ECHO_RESONSE_M 482 The ECHO_RESPONSE_M is the reply to the ECHO_REQUEST_M parameter. 483 The receiver of an ECHO_RESPONSE_M parameter SHOULD reply with n 484 ECHO_RESPONSE_M. If not, the middlebox that added the parameter MAY 485 decide to degrade or deny its service. The contents of the 486 ECHO_REQUEST_M parameter must be copied to the ECHO_RESPONSE_M 487 parameter without any modification. The ECHO_RESPONSE_M parameter is 488 non-critical and covered by the SIGNATURE. The structure of the 489 ECHO_RESPONSE_M parameter is depicted below: 491 0 1 2 3 492 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 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Type | Length | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | Opaque data (variable length) | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 Type 962 500 Length Variable 501 Opaque data Opaque data, supposed to be meaningful only to the 502 middlebox that adds adds ECHO_REQUEST_M and receives a 503 corresponding ECHO_RESPONSE_M. 505 3.3. PUZZLE_M 507 A middlebox MAY add a PUZZLE_M parameter to R1, I2, and UPDATE 508 packets. A HIP packet may contain multiple PUZZLE_M parameters as 509 multiple middleboxes may be located on a communication path. These 510 puzzles serve as defense against DoS attacks. Hosts that receive a 511 PUZZLE_M parameter SHOULD reply with a SOLUTION_M parameter in the 512 subsequent I2, R2, or UPDATE packet. With the exception of an 513 extended opaque field, the format and meaning of the puzzle are 514 defined in [I-D.ietf-hip-base]. The reader is advised to refer to 515 that document for a detailed specification of the puzzle mechanism. 516 The extended opaque data field helps middleboxes to recognize their 517 puzzles and solutions, respectively, if a packet contains more than 518 one puzzle. 520 A middlebox MUST preserve the order of PUZZLE_M parameters in a 521 packet and attach its own PUZZLE_M parameter after all other PUZZLE_M 522 parameters. Preserving the order of PUZZLE_M parameters may help 523 middleboxes to recognize the puzzles and solutions relevant to a 524 middlebox. 526 0 1 2 3 527 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 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | Type | Length | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | K, 1 byte | Lifetime | Opaque, 6 bytes / 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 / | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | Random # I, 8 bytes | 536 | | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 Type 65334 540 Length 16 541 K K is the number of verified bits 542 Lifetime Puzzle lifetime 2^(value-32) seconds 543 Opaque Data set by the middlebox, indexing the middlebox 544 Random #I Random number 546 3.4. SOLUTION_M 548 The SOLUTION_M parameter contains the solution for the corresponding 549 PUZZLE_M parameter. End-hosts that receive a PUZZLE_M parameter 550 SHOULD solve the puzzle according to the specification in 551 [I-D.ietf-hip-base] and send the resulting solution in the SOLUTION_M 552 parameter. Exclusion of a solution MAY result in degraded or denied 553 service by the middlebox that added the PUZZLE_M parameter. The 554 format and meaning of the fields in the SOLUTION_M parameter resemble 555 the specifications of the SOLUTION parameter in [I-D.ietf-hip-base]. 556 The reader is advised to refer to that document for further details. 557 The extended opaque data field helps middleboxes to recognize their 558 puzzles and the resulting solutions, respectively, when a packet 559 contains multiple puzzles. 561 The relative order of SOLUTION_M parameters in a HIP control packet 562 MUST match the order of the PUZZLE_M parameters in the previously 563 received packet. Preserving the order of PUZZLE_M for the 564 corresponding SOLUTION_M parameters may help middleboxes to recognize 565 the puzzles and solutions relevant to them. 567 0 1 2 3 568 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 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | Type | Length | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | K, 1 byte | Reserved | Opaque, 6 bytes / 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 / | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | Random # I, 8 bytes | 577 | | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | Puzzle solution #J, 8 bytes | 580 | | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 Type 322 584 Length 20 585 K K is the number of verified bits 586 Reserved Zero when sent, ignored when received 587 Opaque Copied unmodified from the received PUZZLE 588 parameter 589 Random #I Random number 590 Puzzle solution Random number 592 4. Security Considerations 594 This HIP extension specifies how HIP-aware middleboxes interact with 595 the handshake and mobility-signaling of the Host Identity Protocol. 596 Its scope is restricted to the authentication of end-hosts and does 597 not include the issue of authenticating ESP traffic on the middlebox. 599 Providing middleboxes with a way of adding puzzles to the HIP control 600 packets may cause both HIP peers, including the Responder, to spend 601 CPU time on solving these puzzles. Thus, it is advised that HIP 602 implementations for servers employ mechanisms to prevent middlebox 603 puzzles from being used as DoS attacks. Under high CPU load, servers 604 can e.g. prioritize packets that do not contain difficult middlebox 605 puzzles. 607 If multiple middleboxes add ECHO_REQUEST_M parameters to a HIP 608 control packet, the remaining space in the packet might not be 609 sufficient for further parameters to be added. Moreover, as the 610 ECHO_REQUEST_M must be echoed within an ECHO_RESPONSE_M, the space in 611 the subsequent packet may not be sufficient to add all ECHO_RESONSE_M 612 parameters. Thus, middleboxes SHOULD keep the size of the nonces 613 small. 615 5. IANA Considerations 617 This document specifies four new HIP parameter types. The 618 preliminary parameter type numbers are 322, 962, 65332, and 65334. 620 6. Acknowledgments 622 Thanks to Shaohui Li, Miika Komu, and Janne Lindqvist for the 623 fruitful discussions on this topic. Many thanks to Stefan Goetz and 624 Rene Hummen commenting and helping to improve the quality of this 625 document. 627 7. Normative References 629 [I-D.ietf-hip-base] 630 Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 631 "Host Identity Protocol", draft-ietf-hip-base-10 (work in 632 progress), October 2007. 634 [I-D.ietf-hip-mm] 635 Henderson, T., "End-Host Mobility and Multihoming with the 636 Host Identity Protocol", draft-ietf-hip-mm-05 (work in 637 progress), March 2007. 639 [I-D.ietf-hip-nat-traversal] 640 Schmitt, V., "HIP Extensions for the Traversal of Network 641 Address Translators", draft-ietf-hip-nat-traversal-02 642 (work in progress), July 2007. 644 [I-D.ietf-hip-registration] 645 Laganier, J., "Host Identity Protocol (HIP) Registration 646 Extension", draft-ietf-hip-registration-02 (work in 647 progress), June 2006. 649 [I-D.tschofenig-hiprg-hip-natfw-traversal] 650 Tschofenig, H. and M. Shanmugam, "Traversing HIP-aware 651 NATs and Firewalls: Problem Statement and Requirements", 652 draft-tschofenig-hiprg-hip-natfw-traversal-06 (work in 653 progress), July 2007. 655 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 656 Requirement Levels", BCP 14, RFC 2119, March 1997. 658 Author's Address 660 Tobias Heer 661 Distributed Systems Group, RWTH Aachen University 662 Ahornstrasse 55 663 Aachen 52062 664 Germany 666 Phone: +49 241 80 214 36 667 Email: heer@cs.rwth-aachen.de 668 URI: http://ds.cs.rwth-aachen.de/members/heer 670 Full Copyright Statement 672 Copyright (C) The IETF Trust (2007). 674 This document is subject to the rights, licenses and restrictions 675 contained in BCP 78, and except as set forth therein, the authors 676 retain all their rights. 678 This document and the information contained herein are provided on an 679 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 680 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 681 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 682 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 683 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 684 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 686 Intellectual Property 688 The IETF takes no position regarding the validity or scope of any 689 Intellectual Property Rights or other rights that might be claimed to 690 pertain to the implementation or use of the technology described in 691 this document or the extent to which any license under such rights 692 might or might not be available; nor does it represent that it has 693 made any independent effort to identify any such rights. Information 694 on the procedures with respect to rights in RFC documents can be 695 found in BCP 78 and BCP 79. 697 Copies of IPR disclosures made to the IETF Secretariat and any 698 assurances of licenses to be made available, or the result of an 699 attempt made to obtain a general license or permission for the use of 700 such proprietary rights by implementers or users of this 701 specification can be obtained from the IETF on-line IPR repository at 702 http://www.ietf.org/ipr. 704 The IETF invites any interested party to bring to its attention any 705 copyrights, patents or patent applications, or other proprietary 706 rights that may cover technology that may be required to implement 707 this standard. Please address the information to the IETF at 708 ietf-ipr@ietf.org. 710 Acknowledgment 712 Funding for the RFC Editor function is provided by the IETF 713 Administrative Support Activity (IASA).