idnits 2.17.1 draft-ietf-hip-rvs-02.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 670. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 647. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 654. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 660. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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: An initiator SHOULD not send an opportunistic I1 with a NULL destination HIT to an IP address which is known to be a rendezvous server address, unless it wants to establish a HIP association with the rendezvous server itself and does not know its HIT. -- 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 (June 10, 2005) is 6896 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '13' is defined on line 583, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 587, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-ietf-hip-arch-02 ** Downref: Normative reference to an Informational draft: draft-ietf-hip-arch (ref. '1') == Outdated reference: A later version (-01) exists of draft-koponen-hip-registration-00 -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-10) exists of draft-ietf-hip-base-02 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-base (ref. '4') == Outdated reference: A later version (-05) exists of draft-ietf-hip-mm-01 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-mm (ref. '5') ** Obsolete normative reference: RFC 3484 (ref. '7') (Obsoleted by RFC 6724) ** Obsolete normative reference: RFC 2434 (ref. '8') (Obsoleted by RFC 5226) == Outdated reference: A later version (-09) exists of draft-ietf-hip-dns-01 Summary: 8 errors (**), 0 flaws (~~), 10 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HIP Working Group J. Laganier 3 Internet-Draft DoCoMo Euro-Labs 4 Expires: December 12, 2005 L. Eggert 5 NEC 6 June 10, 2005 8 Host Identity Protocol (HIP) Rendezvous Extension 9 draft-ietf-hip-rvs-02 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 12, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This document discusses a rendezvous extension for the Host Identity 43 Protocol (HIP). The rendezvous extension extends HIP and the HIP 44 registration extension for initiating communication between HIP nodes 45 via HIP rendezvous servers. Rendezvous servers improve reachability 46 and operation when HIP nodes are multi-homed or mobile. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3. Overview of Rendezvous Server Operation . . . . . . . . . . . 4 53 3.1 Diagram Notation . . . . . . . . . . . . . . . . . . . . . 6 54 3.2 Rendezvous Client Registration . . . . . . . . . . . . . . 6 55 3.3 Relaying the Base Exchange . . . . . . . . . . . . . . . . 7 56 4. Rendezvous Server Extensions . . . . . . . . . . . . . . . . . 8 57 4.1 LOCATOR Parameter . . . . . . . . . . . . . . . . . . . . 8 58 4.2 RENDEZVOUS Registration Type . . . . . . . . . . . . . . . 8 59 4.3 New Parameter Formats and Processing . . . . . . . . . . . 9 60 4.3.1 RVS_HMAC Parameter . . . . . . . . . . . . . . . . . . 9 61 4.3.2 FROM Parameter . . . . . . . . . . . . . . . . . . . . 9 62 4.3.3 VIA_RVS Parameter . . . . . . . . . . . . . . . . . . 10 63 4.4 Processing Outgoing I1 Packets . . . . . . . . . . . . . . 10 64 4.5 Processing Incoming I1 packets . . . . . . . . . . . . . . 11 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 67 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 69 8.1 Normative References . . . . . . . . . . . . . . . . . . . 13 70 8.2 Informative References . . . . . . . . . . . . . . . . . . 13 71 Editorial Comments . . . . . . . . . . . . . . . . . . . . . . 14 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 73 A. Document Revision History . . . . . . . . . . . . . . . . . . 14 74 Intellectual Property and Copyright Statements . . . . . . . . 16 76 1. Introduction 78 The current Internet uses IP addresses for two purposes. First, they 79 are topological locators for network attachment points. Second, they 80 act as names for the attached network interfaces. Saltzer [9] 81 discusses these naming concepts in detail. Routing and other 82 network-layer mechanisms are based on the locator aspects of IP 83 addresses. Transport-layer protocols and mechanisms typically use IP 84 addresses in their role as names for communication endpoints. This 85 dual use of IP addresses limits the flexibility of the Internet 86 architecture. The need to avoid readdressing in order to maintain 87 existing transport-layer connections complicates advanced 88 functionality, such as mobility, multi-homing, or network 89 composition. 91 The Host Identity Protocol (HIP) architecture [1] defines a new third 92 namespace. The Host Identity namespace decouples the name and 93 locator roles currently filled by IP addresses. Transport-layer 94 mechanisms operate on Host Identities instead of using IP addresses 95 as endpoint names. Network-layer mechanisms continue to use IP 96 addresses as pure locators. Because of this decoupling the HIP layer 97 needs to map Host Identities into IP addresses. 99 Without HIP, a node needs to know its peer's IP address to make 100 initial contact. The Host Identity Protocol architecture [1] does 101 not change this basic property, but introduces an additional, 102 optional piece of infrastructure, the rendezvous server (RVS). An 103 RVS serves as an additional initial contact point ("rendezvous 104 point") for its clients. The clients of an RVS are HIP nodes that 105 use the HIP Registration Protocol [2] to register their HIT->IP 106 address mappings with the RVS. After this registration, other HIP 107 nodes can initiate a base exchange using the IP address of the RVS 108 instead of the current IP address of the node they attempt to 109 contact. Essentially, the clients of an RVS become reachable at the 110 RVS' IP addresses. Peers can initiate a HIP base exchange with the 111 IP address of the RVS, which will relay this initial communication 112 such that the base exchange may successfully complete. 114 When HIP nodes frequently change their network attachment points, 115 using a RVS can improve reachability and operation. Without an RVS, 116 a HIP node needs to update its DNS entry with its current IP address 117 before it becomes reachable to its peers. Although the DNS offers 118 mechanisms for dynamic updates to records[10][11], they may not be 119 suitable when a record changes frequently. Caching, state lifetimes 120 and deficiences in existing DNS implementations limit the rate-of- 121 change for a given record. When using an RVS - which is assumed to 122 be reachable at a static or at least infrequently changing IP address 123 - HIP nodes need not update their DNS records whenever their local IP 124 addresses change. Instead, they register the IP address of their RVS 125 in their DNS entry and then update only their RVS when their IP 126 addresses change. Because the RVS is specifically designed to 127 support high-rate updates, this indirection can improve reachability 128 of HIP nodes. 130 2. Terminology 132 This section defines terms used throughout the remainder of this 133 specification. 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in RFC 2119 [3]. 139 In addition to the terminology defined in [2], this document defines 140 and uses the following terms: 142 Rendezvous Service 143 A HIP service provided by a rendezvous server to its rendezvous 144 clients. The rendezvous server offers to relay some of the 145 arriving base exchange packets between the initiator and 146 responder. [Comment.1] 148 Rendezvous Server (RVS) 149 A HIP registrar providing rendezvous service. 151 Rendezvous Client 152 A HIP requester that has registered for rendezvous service at a 153 rendezvous server. 155 Rendezvous Registration 156 A HIP registration for rendezvous service, established between a 157 rendezvous server and a rendezvous client. 159 3. Overview of Rendezvous Server Operation 161 HIP decouples domain names from IP addresses. Because transport 162 protocols bind to host identities, they remain unaware if the set of 163 IP addresses associated with a host identity changes. This change 164 can have various reasons, including, but not limited to, mobility and 165 multi-homing. 167 +-----+ +-----+ 168 | |-------I1------>| | 169 | I |<------R1-------| R | 170 | |-------I2------>| | 171 | |<------R2-------| | 172 +-----+ +-----+ 174 Figure 1: HIP base exchange without rendezvous server. 176 Figure 2 shows a simple HIP base exchange without a rendezvous 177 server, in which the initiator initiates the exchange directly with 178 the responder by sending an I1 packet to the responder's IP address, 179 as per the HIP base specification [4]. 181 Proposed extensions for mobility and multi-homing [5] allow a HIP 182 node to notify its peers about changes in its set of IP addresses. 183 These extensions require an established HIP association between two 184 nodes, i.e., a completed HIP base exchange. 186 However, such a HIP node MAY also want to be reachable to other 187 future correspondent peers that are unaware of its location change. 188 The HIP architecture [1] introduces rendezvous servers with whom a 189 HIP node MAY register its host identity tags (HITs) and current IP 190 addresses. An RVS relays HIP packets arriving for these HITs to the 191 node's registered IP addresses. When a HIP node has registered with 192 an RVS, it SHOULD record the IP address of its RVS in its DNS record, 193 using the HIPRVS DNS record type defined in [12]. 195 +-----+ 196 +--I1--->| RVS |---I1--+ 197 | +-----+ | 198 | v 199 +-----+ +-----+ 200 | |<------R1-------| | 201 | I |-------I2------>| R | 202 | |<------R2-------| | 203 +-----+ +-----+ 205 Figure 2: HIP base exchange with a rendezvous server. 207 Figure 2 shows a HIP base exchange involving a rendezvous server. It 208 is assumed that HIP node R previously registered its HITs and current 209 IP addresses with the RVS, using the HIP registration protocol [2]. 210 When the initiator I tries to establish contact with the responder R, 211 it MAY send the I1 of the base exchange either to one of R's DNS 212 addresses or it MAY send it to the address of one of R's rendezvous 213 servers instead. Here, I obtains the IP address of R's rendezvous 214 server from R's DNS record and then sends the I1 packet of the HIP 215 base exchange to RVS. RVS, noticing that the HIT contained in the 216 arriving I1 packet is not one of its own, MUST check its current 217 registrations to determine if if needs to relay the packets. Here, 218 it determines that the HIT belongs to R and then relays the I1 packet 219 to the registered IP address. R then completes the base exchange 220 without further assistance from RVS by sending an R1 directly to the 221 I's IP address, as obtained from the I1 packet. 223 3.1 Diagram Notation 225 Notation Significance 226 -------- ------------ 228 I, R I and R are the respective source and destination IP 229 addresses in the IP header. 231 HIT-I, HIT-R HIT-I and HIT-R are the initiator's and the 232 responder's HITs in the packet, respectively. 234 LOC:I A LOCATOR parameter containing the IP address I is 235 present in the HIP header. 237 FROM:I A FROM parameter containing the IP address I is 238 present in the HIP header. 240 VIA:RVS A VIA_RVS parameter containing the IP addresses of an 241 RVS is present in the HIP header. 243 REG_REQ A REG_REQUEST parameter is present in the HIP header. 245 REG_RES A REG_RESPONSE parameter is present in the HIP header. 247 3.2 Rendezvous Client Registration 249 Before a rendezvous server starts to relay HIP packets to a 250 rendezvous client, the rendezvous client needs to register with it to 251 receive rendezvous service by using the HIP registration extension 252 [2] as illustrated in the following schema: 254 +-----+ +-----+ 255 | | I1 | | 256 | |--------------------------->| | 257 | |<---------------------------| | 258 | I | R1(REG_INFO) | RVS | 259 | | I2(REG_REQ) | | 260 | |--------------------------->| | 261 | |<---------------------------| | 262 | | R2(REG_RES) | | 263 +-----+ +-----+ 265 3.3 Relaying the Base Exchange 267 If a HIP node and one of its rendezvous servers have a rendezvous 268 registration, the rendezvous servers MUST relay inbound I1 packets 269 that contain one of the client's HITs by rewriting the IP header. 270 They replace the destination IP address of the I1 packet with one of 271 the IP addresses of the owner of the HIT, i.e., the rendezvous 272 client. They MUST also recompute the IP checksum accordingly. 274 Because of egress filtering on the path from the RVS to the client, a 275 HIP rendezvous server MAY also need to replace the source IP address, 276 i.e., the IP address of I, with one of its own IP addresses. The 277 replacement IP address SHOULD be chosen according to [6] and, when 278 IPv6 is used, to [7]. Because this replacement conceals the 279 initiator's IP address, the RVS MUST append a FROM parameter 280 containing the original source IP address of the packet. This FROM 281 parameter MUST be integrity protected by a RVS_HMAC keyed with the 282 corresponding rendezvous registration integrity key [2]. 284 I1(RVS, R, HIT-I, HIT-R 285 I1(I, RVS, HIT-I, HIT-R) +---------+ FROM:I, VIA:RVS) 286 +----------------------->| |--------------------+ 287 | | RVS | | 288 | | | | 289 | +---------+ | 290 | V 291 +-----+ R1(R, I, HIT-R, HIT-I, LOC:R, VIA:RVS) +-----+ 292 | |<---------------------------------------------| | 293 | | | | 294 | I | I2(I, R, HIT-I, HIT-R) | R | 295 | |--------------------------------------------->| | 296 | |<---------------------------------------------| | 297 +-----+ R2(R, I, HIT-R, HIT-I) +-----+ 299 Figure 5: Rendezvous server rewriting IP addresses 301 This modification of HIP packets at a rendezvous server can be 302 problematic. The HIP protocol uses two kinds of packet integrity 303 checks: hop-by-hop and end-to-end. The HIP checksum is a hop-by-hop 304 check and SHOULD be verified and recomputed by each of the on-path 305 HIP-enabled middleboxes, such as rendezvous servers. The HMAC and 306 SIGNATURE are end-to-end checks and MUST be computed by the sender 307 and verified by the receiver. 309 The RVS MUST verify the checksum field of an I1 packet doing any 310 modifications. After modification, it MUST recompute the checksum 311 field using the updated HIP header, which possibly included new FROM 312 and RVS_HMAC parameters, and a pseudo-header containing the updated 313 source and destination IP addresses. This enables the responder to 314 validate the checksum of the I1 packet "as is", without having to 315 parse any FROM parameters. 317 The SIGNATURE and HMAC verification MUST NOT cover any FROM and 318 RVS_HMAC parameters added by rendezvous servers. Hence, HMAC and 319 SIGNATURE are unaffected by the modifications performed by an RVS. 320 The computation and verification of HMAC and SIGNATURE MUST only 321 cover the original HIP header with a checksum field set to zero, MUST 322 NOT cover the pseudo header that contains modified IP addresses, and 323 mUST NOT cover any new FROM and RVS_HMAC parameters that MAY be 324 situated after the HMAC and SIGNATURE in the HIP header. 326 4. Rendezvous Server Extensions 328 The following sections describe extensions to the HIP registration 329 protocol [2], allowing a HIP node to register with a rendezvous 330 server for rendezvous service and notify the RVS aware of changes to 331 its current location. It also describes an extension to the HIP 332 protocol [4] itself, allowing establishment of HIP associations via 333 one or more HIP rendezvous server(s). 335 4.1 LOCATOR Parameter 337 A HIP responder contacted via an RVS MAY use a LOCATOR parameter in 338 the R1 packet to notify the initiator of its current IP address, in 339 conformance with the guidelines specified in [5]. 341 4.2 RENDEZVOUS Registration Type 343 This specification defines an additional registration for the HIP 344 registration protocol [2] that allows registering with a rendezvous 345 server for rendezvous service. 347 Number Registration Type 348 ------ ----------------- 349 1 RENDEZVOUS 351 4.3 New Parameter Formats and Processing 353 4.3.1 RVS_HMAC Parameter 355 The RVS_HMAC is an OPTIONAL parameter whose only difference with the 356 HMAC parameter defined in [4] is its "type" code. This change causes 357 it to be located after the FROM parameter (as opposed to the HMAC): 359 Type [ TBD by IANA (65472 = 2^16 - 2^6) ] 360 Length 20 361 HMAC 160 low order bits of a HMAC keyed with the 362 appropriate HIP integrity key (HIP_lg or HIP_gl), 363 established when rendezvous registration happened. 364 This HMAC is computed over the HIP packet, excluding 365 RVS_HMAC and any following parameters. The 366 "checksum" field MUST be set to zero and the HIP header 367 length in the HIP common header MUST be calculated 368 not to cover any excluded parameter when the 369 "authenticator" field is calculated. 371 To allow a rendezvous client and its RVS to verify the integrity of 372 packets flowing between them, both SHOULD protect packets with an 373 added RVS_HMAC parameter keyed with the HIP_lg or HIP_gl integrity 374 key. A valid RVS_HMAC SHOULD be present on every packets flowing 375 between a client and a server and MUST be present when a FROM 376 parameters is processed. 378 4.3.2 FROM Parameter 380 0 1 2 3 381 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 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Type | Length | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | | 386 | Address | 387 | | 388 | | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 Type [ TBD by IANA (65470 = 2^16 - 2^6 - 2) ] 392 Length 16 393 Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address. 395 A rendezvous server MUST add a FROM parameter containing the original 396 source IP address of a HIP packet whenever the source IP address in 397 the IP header is rewritten. If one or more FROM parameters are 398 already present, the new FROM parameter MUST be appended after the 399 existing ones. 401 Whenever an RVS inserts a FROM parameter, it MUST insert an RVS_HMAC 402 protecting the packet integrity, especially the IP address included 403 in the FROM parameter. 405 4.3.3 VIA_RVS Parameter 407 0 1 2 3 408 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 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Type | Length | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | | 413 | Address | 414 | | 415 | | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 . . . 418 . . . 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | | 421 | Address | 422 | | 423 | | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 Type [ TBD by IANA (65474 = 2^16 - 2^6 + 2) ] 427 Length Variable 428 Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address 430 After the responder receives a relayed I1 packet, it can begin to 431 send HIP packets addressed to the initiator's IP address, without 432 further assistance from an RVS. For debugging purposes, it MAY 433 include a subset of the IP addresses of its RVSs in some of these 434 packets. When a responder does so, it MUST append a newly created 435 VIA_RVS parameter at the end of the HIP packet. The main goal of 436 using the VIA_RVS parameter is to allow operators to diagnose 437 possible issues encountered while establishing a HIP association via 438 a RVS. 440 4.4 Processing Outgoing I1 Packets 442 An initiator SHOULD not send an opportunistic I1 with a NULL 443 destination HIT to an IP address which is known to be a rendezvous 444 server address, unless it wants to establish a HIP association with 445 the rendezvous server itself and does not know its HIT. 447 If an RVS needs to rewrite the source IP address of an I1 packet due 448 to egress filtering, then it MUST add a FROM parameter to the I1 that 449 contasins the initiator's source IP address. This FROM parameter 450 MUST be protected by a RVS_HMAC keyed with the integrity key 451 established at rendezvous registration. 453 4.5 Processing Incoming I1 packets 455 When a rendezvous server receives an I1 whose destination HIT is not 456 its own, it MUST consult its registration database to find a 457 registration for the rendezvous service established by the HIT owner. 458 If it finds an appropriate registration, it MUST relay the packet to 459 the registered IP address. If it does not find an appropriate 460 registration, is MUST drop the packet. 462 A rendezvous server SHOULD interpret any incoming opportunistic I1 463 (i.e., an I1 with a NULL destination HIT) as an I1 addressed to 464 itself and SHOULD NOT attempt to relay it to one of its clients. 466 When a rendezvous client receives an I1, it MUST validate any present 467 RVS_HMAC parameter. If the RVS_HMAC cannot be verified, the packet 468 SHOULD be dropped. If the RVS_HMAC cannot be verified and a FROM 469 parameter is present, the packet MUST be dropped. 471 A rendezvous client acting as responder SHOULD drop opportunistic I1s 472 that include a FROM parameter, because this indicates that the I1 has 473 been relayed. 475 5. Security Considerations 477 The security aspects of different HIP rendezvous mechanisms are 478 currently being investigated. This section describes the known 479 threats introduced by these HIP extensions and implications on the 480 overall security of HIP and IP. In particular, it argues that the 481 extensions described in this document do not introduce additional 482 threats to the Internet infrastructure. 484 It is difficult to encompass the whole scope of threats introduced by 485 rendezvous servers, because their presence has implications both at 486 the IP and HIP layers. In particular, these extensions might allow 487 for redirection, amplification and reflection attacks at the IP 488 layer, as well as attacks on the HIP layer itself, for example, man- 489 in-the-middle attacks against HIP's SIGMA protocol. 491 If an initiator has a priori knowledge of the responder's host 492 identity when it first contacts it via an RVS, it has a means to 493 verify the signatures in the HIP exchange, thus conforming to the 494 SIGMA protocol which is resilient to man-in-the-middle attacks. 496 If an initiator does not have a priori knowledge of the responder's 497 host identiy (so-called "opportunistic initiators"), it is almost 498 impossible to defend the HIP exchange against these attacks, because 499 the public keys exchanged cannot be authenticated. The only approach 500 would be to mitigate hijacking threats on HIP state by requiring an 501 R1 answering an opportunistic I1 to come from the same IP address 502 that originally sent the I1. This procedure retains a level of 503 security which is equivalent to what exists in the Internet today. 505 However, for reasons of simplicity, this specification does not allow 506 to establish a HIP association via a rendezvous server in an 507 opportunistic manner. 509 6. IANA Considerations 511 This section is to be interpreted according to [8]. 513 This document updates the IANA Registry for HIP Parameters Types by 514 assigning new HIP Parameter Types values for the new HIP Parameters 515 defined in Section 4.3: 517 o RVS_HMAC (defined in Section 4.3.1) 519 o FROM (defined in Section 4.3.2) 521 o VIA_RVS (defined in Section 4.3.3) 523 7. Acknowledgments 525 The following people have provided thoughtful and helpful discussions 526 and/or suggestions that have improved this document: Marcus Brunner, 527 Tom Henderson, Miika Komu, Mika Kousa, Pekka Nikander, Justino 528 Santos, Simon Schuetz, Tim Shepard, Kristian Slavov, Martin 529 Stiemerling and Juergen Quittek. 531 Lars Eggert is partly funded by Ambient Networks, a research project 532 supported by the European Commission under its Sixth Framework 533 Program. The views and conclusions contained herein are those of the 534 authors and should not be interpreted as necessarily representing the 535 official policies or endorsements, either expressed or implied, of 536 the Ambient Networks project or the European Commission. 538 8. References 539 8.1 Normative References 541 [1] Moskowitz, R., "Host Identity Protocol Architecture", 542 draft-ietf-hip-arch-02 (work in progress), January 2005. 544 [2] Koponen, T. and L. Eggert, "Host Identity Protocol (HIP) 545 Registration Extension", draft-koponen-hip-registration-00 (work 546 in progress), February 2005. 548 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 549 Levels", BCP 14, RFC 2119, March 1997. 551 [4] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-02 552 (work in progress), February 2005. 554 [5] Nikander, P., "End-Host Mobility and Multi-Homing with Host 555 Identity Protocol", draft-ietf-hip-mm-01 (work in progress), 556 February 2005. 558 [6] Braden, R., "Requirements for Internet Hosts - Communication 559 Layers", STD 3, RFC 1122, October 1989. 561 [7] Draves, R., "Default Address Selection for Internet Protocol 562 version 6 (IPv6)", RFC 3484, February 2003. 564 [8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 565 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 567 8.2 Informative References 569 [9] Saltzer, J., "On the Naming and Binding of Network 570 Destinations", RFC 1498, August 1993. 572 [10] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic 573 Updates in the Domain Name System (DNS UPDATE)", RFC 2136, 574 April 1997. 576 [11] Wellington, B., "Secure Domain Name System (DNS) Dynamic 577 Update", RFC 3007, November 2000. 579 [12] Nikander, P. and J. Laganier, "Host Identity Protocol (HIP) 580 Domain Name System (DNS) Extensions", draft-ietf-hip-dns-01 581 (work in progress), February 2005. 583 [13] Ferguson, P. and D. Senie, "Network Ingress Filtering: 584 Defeating Denial of Service Attacks which employ IP Source 585 Address Spoofing", BCP 38, RFC 2827, May 2000. 587 [14] Killalea, T., "Recommended Internet Service Provider Security 588 Services and Procedures", BCP 46, RFC 3013, November 2000. 590 Editorial Comments 592 [Comment.1] In this specification the client of the RVS is always 593 the responder. However, there might be reasons to allow 594 a client to initiate a base exchange through its own 595 RVS, like NAT and firewall traversal. This specification 596 does not address such scenarios which should be 597 specified in other documents. 599 Authors' Addresses 601 Julien Laganier 602 DoCoMo Communications Laboratories Europe GmbH 603 Landsberger Strasse 312 604 Munich 80687 605 Germany 607 Phone: +49 89 56824 231 608 Email: julien.ietf@laposte.net 609 URI: http://www.docomolab-euro.com/ 611 Lars Eggert 612 NEC Network Laboratories 613 Kurfuerstenanlage 36 614 Heidelberg 69115 615 Germany 617 Phone: +49 6221 90511 43 618 Fax: +49 6221 90511 55 619 Email: lars.eggert@netlab.nec.de 620 URI: http://www.netlab.nec.de/ 622 Appendix A. Document Revision History 624 +-----------+-------------------------------------------------------+ 625 | Revision | Comments | 626 +-----------+-------------------------------------------------------+ 627 | 02 | Removed multiple relaying techniques but simple I1 | 628 | | header rewriting. Updated new HIP parameters type | 629 | | numbers (consistent with new layout and assigning | 630 | | rules from draft-ietf-hip-base.) Updated IANA | 631 | | Considerations. | 632 | 01 | Splitted out the registration sub-protocol. Simplify | 633 | | typology of relaying techniques (keep only TUNNEL, | 634 | | REWRITE, BIDIRECTIONAL). Rewrote IANA Considerations. | 635 | 00 | Initial version as a HIP WG item. | 636 +-----------+-------------------------------------------------------+ 638 Intellectual Property Statement 640 The IETF takes no position regarding the validity or scope of any 641 Intellectual Property Rights or other rights that might be claimed to 642 pertain to the implementation or use of the technology described in 643 this document or the extent to which any license under such rights 644 might or might not be available; nor does it represent that it has 645 made any independent effort to identify any such rights. Information 646 on the procedures with respect to rights in RFC documents can be 647 found in BCP 78 and BCP 79. 649 Copies of IPR disclosures made to the IETF Secretariat and any 650 assurances of licenses to be made available, or the result of an 651 attempt made to obtain a general license or permission for the use of 652 such proprietary rights by implementers or users of this 653 specification can be obtained from the IETF on-line IPR repository at 654 http://www.ietf.org/ipr. 656 The IETF invites any interested party to bring to its attention any 657 copyrights, patents or patent applications, or other proprietary 658 rights that may cover technology that may be required to implement 659 this standard. Please address the information to the IETF at 660 ietf-ipr@ietf.org. 662 Disclaimer of Validity 664 This document and the information contained herein are provided on an 665 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 666 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 667 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 668 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 669 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 670 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 672 Copyright Statement 674 Copyright (C) The Internet Society (2005). This document is subject 675 to the rights, licenses and restrictions contained in BCP 78, and 676 except as set forth therein, the authors retain all their rights. 678 Acknowledgment 680 Funding for the RFC Editor function is currently provided by the 681 Internet Society.