idnits 2.17.1 draft-ietf-hip-rvs-01.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.a on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 890. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 867. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 874. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 880. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 21 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 10 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 727 has weird spacing: '...s Types by...' -- 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 (February 18, 2005) is 7000 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: '8' is defined on line 813, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 817, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 821, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-ietf-hip-arch-00 ** 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-01 ** 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-00 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-mm (ref. '5') -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. '7') (Obsoleted by RFC 5226) == Outdated reference: A later version (-05) exists of draft-ietf-hip-rvs-00 Summary: 9 errors (**), 0 flaws (~~), 12 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 HIP Working Group J. Laganier 2 Internet-Draft LIP / Sun Microsystems 3 Expires: August 19, 2005 L. Eggert 4 NEC 5 February 18, 2005 7 Host Identity Protocol (HIP) Rendezvous Extension 8 draft-ietf-hip-rvs-01 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of section 3 of RFC 3667. By submitting this Internet-Draft, each 14 author represents that any applicable patent or other IPR claims of 15 which he or she is aware have been or will be disclosed, and any of 16 which he or she become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 19, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 This document discusses a Rendezvous extension for the Host Identity 44 Protocol (HIP). The Rendezvous extension extend HIP and the HIP 45 registration extension for initiating communication between HIP nodes 46 via HIP Rendezvous Servers. Rendezvous Servers improve operation 47 when HIP nodes are multi-homed or mobile. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Overview of Rendezvous Server Operation . . . . . . . . . . . 4 54 3.1 Diagram Notation . . . . . . . . . . . . . . . . . . . . . 6 55 3.2 Rendezvous Client Registering with a Rendezvous Server . . 6 56 3.3 Establishing HIP Associations via Rendezvous Servers . . . 7 57 3.3.1 Encapsulating I1 into a Tunnel . . . . . . . . . . . . 7 58 3.3.2 Rewriting I1 IP Header . . . . . . . . . . . . . . . . 7 59 3.3.3 Bidirectional Forwarding of HIP packets . . . . . . . 8 60 3.3.4 Implication on the HIP integrity checks . . . . . . . 9 61 4. RVS Extensions Definition . . . . . . . . . . . . . . . . . . 10 62 4.1 Usage and Processing of Existing Parameters . . . . . . . 11 63 4.1.1 ECHO_REQUEST and ECHO_REPLY Parameters . . . . . . . . 11 64 4.1.2 REA Parameter . . . . . . . . . . . . . . . . . . . . 11 65 4.2 New Registration Type . . . . . . . . . . . . . . . . . . 11 66 4.3 New Parameter Formats and Processing . . . . . . . . . . . 11 67 4.3.1 RVR_TYPE Parameter . . . . . . . . . . . . . . . . . . 12 68 4.3.2 RVR_HMAC Parameter . . . . . . . . . . . . . . . . . . 13 69 4.3.3 FROM Parameter . . . . . . . . . . . . . . . . . . . . 14 70 4.3.4 TO Parameter . . . . . . . . . . . . . . . . . . . . . 15 71 4.3.5 VIA_RVS Parameter . . . . . . . . . . . . . . . . . . 16 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 74 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 76 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 19 77 8.2 Informative References . . . . . . . . . . . . . . . . . . . 19 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 79 A. Document Revision History . . . . . . . . . . . . . . . . . . 20 80 Intellectual Property and Copyright Statements . . . . . . . . 21 82 1. Introduction 84 The current Internet has a dual use of IP addresses. First, they are 85 topological locators for network attachment points. Second, they act 86 as names for the attached network interfaces. Saltzer [6] discusses 87 these naming concepts in detail. Routing and other network-layer 88 mechanisms are based on the locator aspects of IP addresses. 89 Transport-layer protocols and mechanisms typically use IP addresses 90 in their role as names for communication endpoints. This dual use of 91 IP addresses limits the flexibility of the Internet architecture. 92 The need to avoid readdressing in order to maintain existing 93 transport-layer connections complicates advanced functionality, such 94 as mobility, multi-homing, or network composition. 96 The Host Identity Protocol (HIP) architecture [1] defines a new third 97 namespace. The Host Identity namespace decouples the name and 98 locator roles currently filled by IP addresses. Transport-layer 99 mechanisms operate on Host Identities instead of using IP addresses 100 as endpoint names. Network-layer mechanisms continue to use IP 101 addresses as pure locators. Because of this decoupling the HIP layer 102 needs to map Host Identities into IP addresses. 104 Without HIP, a node needs to know its peer IP address to make an 105 initial contact. The Host Identity Protocol architecture [1] 106 introduces an additional piece of infrastructure, the Rendezvous 107 Server (RVS), which serves as an initial contact point (rendezvous) 108 for nodes trying to reach the RVS clients. A RVS offers to a peer it 109 serves to relay to its IP address the first packet of a HIP exchange 110 incoming at the RVS IP address and with the peer receiver HIT. A 111 peer uses the HIP Registration Protocol [2] to register its HIT->IP 112 address mapping with its RVS. Then an initiator and responder can 113 have rendezvous together at the RVS IP address. The initiator would 114 send a I1 packet to the RVS IP address, which would then relay the I1 115 to the responder IP address. Then, further communications would 116 typically occurs directly without further assistance from the RVS. 118 After the Base Exchange, HIP nodes use Host Identities instead of IP 119 addresses to name transport-layer endpoints. The HIP layer in the 120 network stack internally translates Host Identities (HI) into 121 network-layer IP addresses. 123 2. Terminology 125 This section defines terms used throughout the remainder of this 126 specification. 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in RFC 2119 [3]. 132 Rendezvous Service : A HIP Service provided by a HIP Rendezvous 133 Server to its Rendezvous Clients. The Rendezvous Server offers to 134 relay some of the incoming HIP packets exchanged during a HIP 135 exchange to the owner of their receiver HIT (i.e. the Rendezvous 136 Client or one of its correspondent nodes). 138 Rendezvous Server (RVS): A HIP Registrar providing the Rendezvous 139 Service. 141 Rendezvous Client (RVC): A HIP Requester which has registered for the 142 Rendezvous Service at a Rendezvous Server. 144 Rendezvous Registration (RVR): A HIP Registration for the Rendezvous 145 Service, established between a Rendezvous Server and a Rendezvous 146 Client. 148 3. Overview of Rendezvous Server Operation 150 HIP decouples domain names from IP addresses. Because transport 151 protocols bind to Host Identities, they remain unaware if the set of 152 IP addresses associated with a Host Identity changes. This change 153 can have various reasons, including, but not limited to, mobility and 154 multi-homing. 156 +-----+ +-----+ 157 | |-------I1------>| | 158 | I |<------R1-------| R | 159 | |-------I2------>| | 160 | |<------R2-------| | 161 +-----+ +-----+ 163 Figure 1: HIP Base Exchange without Rendezvous Server 165 Figure 2 shows a simple HIP Base Exchange (without Rendezvous Server) 166 in which the initiator initiates the exchange directly with the 167 responder by sending an I1 packet to the responder IP address, as per 168 the HIP base specification [4]. 170 Proposed extensions for mobility and multi-homing [5] allow a HIP 171 node to notify its peers about changes in its set of IP addresses. 172 These extensions require an established HIP association between two 173 nodes, i.e., a completed HIP Base Exchange. 175 However, such a HIP node might also want to be still reachable by 176 potential future correspondent peers unaware of its location change. 177 The HIP architecture [1] introduces Rendezvous Servers at which a HIP 178 node register its current HIT and IP addresses. The RVS basically 179 relays HIP packet incoming at this HIT to the node IP address. Thus, 180 a peer publishing its RVS IP address instead of its own is reachable 181 by means of rendezvous at its RVS IP address. 183 +-----+ 184 +--I1--->| RVS |---I1--+ 185 | +-----+ | 186 | v 187 +-----+ +-----+ 188 | |<------R1-------| | 189 | I |-------I2------>| R | 190 | |<------R2-------| | 191 +-----+ +-----+ 193 Figure 2: HIP Base Exchange with Rendezvous Server 195 Figure 2 shows a HIP Base Exchange involving a Rendezvous Server RVS. 196 It is assumed that HIP node R precedently used the HIP registration 197 protocol [2] to register with the RVS its HIT and IP address. When 198 the initiator I tries to establish contact with the responder, it 199 does not need to know the current IP address of R. Instead, I is 200 aware of the RVS IP address of R, at which it sends an I1 packet. 201 The RVS, noticing that the receiver HIT is not its own, but the HIT 202 of a HIP node registered for the rendezvous Service, would relay the 203 I1 to the responder IP address. Typically the responder would then 204 complete the exchange without further assistance from the RVS by 205 sending an R1 directly to the initiator IP address. 207 3.1 Diagram Notation 209 Notation Significance 210 -------- ------------ 212 I, R I and R are the respective source and destination IP 213 addresses of the IP header 215 HIT-I,HIT-R HIT-I and HIT-R are respectively the Initiator and the 216 Responder HIT of the packet 218 REA:I A REA parameter containing the IP address i is 219 present in the HIP header 221 FROM:I A FROM parameter containing the IP address I is present 222 in the HIP header 224 TO:I A TO parameter containing the IP address I is present 225 in the HIP header 227 VIA:RVS A VIA_RVS parameter containing IP addresses RVS 228 is present in the HIP header 230 EREQ An ECHO_REQUEST parameter is present in the HIP header 232 EREP An ECHO_REPLY parameter is present in the HIP header 234 RREQ A REG_REQUEST parameter is present in the HIP header 236 RRES A REG_RESPONSE parameter is present in the HIP header 238 RVR:t1,t2 A RVR_TYPE parameter with Type value t1 and t2 is present 239 in the HIP header. 241 3.2 Rendezvous Client Registering with a Rendezvous Server 243 Before the Rendezvous Server starts to relay HIP packets to their 244 receiver HIT owner (i.e. a Rendezvous Client or one of its 245 correspondent node), the Rendezvous Client needs to register with its 246 Server for the Rendezvous Service, as shown in the following schema: 248 +-----+ +-----+ 249 | | I1 | | 250 | |--------------------------->| | 251 | |<---------------------------| | 252 | RVC | R1(REG_INFO,RVR:1,2) | RVS | 253 | | I2(REG_REQ,RVR:2) | | 254 | |--------------------------->| | 255 | |<---------------------------| | 256 | | R2(REG_RES,RVR:2) | | 257 +-----+ +-----+ 259 3.3 Establishing HIP Associations via Rendezvous Servers 261 3.3.1 Encapsulating I1 into a Tunnel 263 If a HIP node and one of its Rendezvous Servers have a Rendezvous 264 Registration of type TUNNEL_I1, the Rendezvous Server tunnels up to 265 this node I1s incoming to this node's HIT using the appropriate 266 encapsulation technique. The technique to be used is determined 267 based on the kind of association established between the RVS and its 268 client, and differs only by the type of header prepended to the HIP 269 packet (e.g. HIP, ESP or UDP). 271 ENCAP(RVS, R)[ I1(I, RVS, ] 272 [ HIT-I, HIT-R, ] 273 I1(I, RVS, HIT-I, HIT-R) +---------+ [ FROM:I) ] 274 +----------------------->| |--------------------+ 275 | | RVS | | 276 | | | | 277 | +---------+ | 278 | V 279 +-----+ R1(R, I, HIT-R, HIT-I, REA:R, VIA:RVS) +-----+ 280 | |<---------------------------------------------| | 281 | | | | 282 | I | I2(I, R, HIT-I, HIT-R) | R | 283 | |--------------------------------------------->| | 284 | |<---------------------------------------------| | 285 +-----+ R2(R, I, HIT-R, HIT-I) +-----+ 287 Figure 5: I1_TUNNEL: Rendezvous Server Encapsulating I1 into a Tunnel 289 3.3.2 Rewriting I1 IP Header 291 If a HIP node and one of its Rendezvous Servers have a Rendezvous 292 Registration of type REWRITE_I1, the Rendezvous Server relays up to 293 this node I1s incoming to this node's HIT by merely rewrite the IP 294 header. The destination IP address of the I1 is replaced by the IP 295 address of the receiver HIT owner (i.e. the Rendezvous Client). 297 However, because of egress filtering, a HIP Rendezvous Server might 298 also need to replace the original source IP address of an I1 by its 299 own IP address, thus concealing the Initiator's IP address to the 300 Responder. Hence, such a node MUST append I1 packets with a FROM 301 parameter containing the original source IP address of the packet. 302 This FROM parameter MUST be integrity protected by a RVR_HMAC keyed 303 with the corresponding rendezvous registration integrity key [2]. 305 I1(I, RVS, HIT-I, 306 I1(I, RVS, HIT-I, HIT-R) +---------+ HIT-R, FROM:I, VIA:RVS) 307 +----------------------->| |--------------------+ 308 | | RVS | | 309 | | | | 310 | +---------+ | 311 | V 312 +-----+ R1(R, I, HIT-R, HIT-I, REA:R, VIA:RVS) +-----+ 313 | |<---------------------------------------------| | 314 | | | | 315 | I | I2(I, R, HIT-I, HIT-R) | R | 316 | |--------------------------------------------->| | 317 | |<---------------------------------------------| | 318 +-----+ R2(R, I, HIT-R, HIT-I) +-----+ 320 Figure 6: I1_REWRITE: Rendezvous Server Rewriting I1 Source and 321 Destination IP Addresses 323 3.3.3 Bidirectional Forwarding of HIP packets 325 In some cases it is useful to have a RVS which relay further HIP 326 packets in a bidirectional manner, i.e. from the initiator to the 327 responder but also from the responder to the initiator. These 328 further packets would typically be either an R1 or an UPDATE. A RVS 329 behaves accordingly when the Rendezvous Registration Type is 330 BIDIRECTIONAL. 332 However, because such packets are larger than I1 (they contain a 333 signature), their relaying create an opportunity for denial of 334 service attacks. To defend against these attacks, the Rendezvous 335 Server needs to differentiate between legitimate HIP packets (i.e., 336 I1 and subsequent HIP packets triggered by an I1) and illegitimate 337 ones. 339 For the sake of reducing the load incurred on the RVS, an RVS is not 340 required to keep track of IP addresses and other pieces of state 341 associated with ongoing HIP exchanges. Such behavior is OPTIONAL. 342 Instead, the relaying facility SHOULD make use of ECHO_REQUEST and 343 ECHO_RESPONSE parameters. 345 Each time a packet is being relayed and will possibly trigger an 346 answer, the RVS MUST augment it with an ECHO_REQUEST parameter 347 containing a chunk of opaque data. The receiver of such a packet 348 MUST augment any packet answering to this packet with an ECHO_REPLY 349 parameter containing the same chunk of opaque data. This opaque data 350 allows an RVS to find and validate the answered packet IP addresses 351 and HITs. When successfully validated, ECHO_REPLY parameters MUST be 352 removed from the packet before relaying. 354 I1(I, RVS, I1(RVS, R, HIT-I, HIT-0 355 HIT-I, HIT-0) +---------+ FROM:I, EREQ) 356 +-------------------->| |----------------------+ 357 |+--------------------| |<--------------------+| 358 || R1(RVS, I, HIT-R, | RVS | R1(R, RVS, HIT-R, || 359 || HIT-I, REA:R, | | HIT-I, REA:R, || 360 || VIA:RVS) | | TO:I, EREP) || 361 || | | || 362 || +---------+ || 363 |V |V 364 +-----+ I2(R, I, HIT-R, HIT-I) +-----+ 365 | |-------------------------------------------->| | 366 | I |<--------------------------------------------| R | 367 | | R2(I, R, HIT-I, HIT-R) | | 368 +-----+ +-----+ 370 Figure 7: BIDIRECTIONAL: Responder replying via the RVS to Initiator 372 3.3.4 Implication on the HIP integrity checks 374 The establishment of HIP associations via one or more Rendezvous 375 Servers causes HIP packets flowing between the HIP nodes to be 376 modified during transmission. Several kinds of modifications to both 377 the IP and HIP headers are possible. The HIP protocol uses two kinds 378 of packet integrity checks: hop-by-hop and end-to-end. The HIP 379 checksum is a hop-by-hop check and SHOULD be verified and recomputed 380 by each of the on-path HIP middle-boxes (e.g., Rendezvous Servers). 381 The HMAC and SIGNATURE are end-to-end checks and MUST be computed by 382 the sender and verified by the receiver. 384 3.3.4.1 Checksum 386 The checksum field of a HIP header to be modified MUST be verified 387 before applying the modification and recomputed accordingly after. 389 3.3.4.2 HMAC and SIGNATURE 391 The HMAC and SIGNATURE field of a HIP header MUST be computed and 392 verified based on a "sender view" or "receiver view" of the HIP 393 header. In particular, this implies that SIGNATURE and HMAC MUST NOT 394 cover FROM and TO parameters added or removed by Rendezvous Servers 395 and that the HIP pseudo-header used to compute and verify them MUST 396 contain the IP addresses as seen by the remote HIP peer. In case of 397 IP address concealment by the RVS, this means that the IP address of 398 this RVS MUST be used in the pseudo-header in place of the IP address 399 of the end host it conceals. 401 3.3.4.3 Example 403 Here is an example showing how to compute the different integrity 404 checks (end-to-end and hop-by-hop) when two Rendezvous Servers are 405 cascaded and conceals the Responder IP address (packet flowing along 406 the path I -> RVS1 -> RVS2 -> R) 408 End-to-end integrity checks: HMAC and SIGNATURE are computed with a 409 pseudo-header containing RVS1 as a place holder for the destination 410 IP address, the rationale being that RVS1 is concealing the Responder 411 IP address. Therefore, R will verify the signature using RVS1 as the 412 destination IP address in the pseudo-header. 414 Hop-by-hop integrity checks: Checksum is computed hop-by-hop; first 415 with I and RVS1, then with RVS1 and RVS2, and finally with RVS2 and 416 R. 418 4. RVS Extensions Definition 420 The following sections describe extensions to: 422 o The HIP registration protocol [2], allowing a HIP node to register 423 with its Rendezvous Server for the Rendezvous Service and maintain 424 the RVS aware of its current location. 426 o The HIP protocol [4] itself, allowing to establish an HIP 427 association via one or more HIP Rendezvous Server(s). 429 4.1 Usage and Processing of Existing Parameters 431 4.1.1 ECHO_REQUEST and ECHO_REPLY Parameters 433 A FROM parameter MAY be augmented by including an ECHO_REQUEST 434 parameter to the carrying packet. The contents of the ECHO_REQUEST 435 MUST then be echoed back in ECHO_RESPONSE. 437 A TO parameter MUST be augmented and authenticated by including an 438 ECHO_REPLY parameter to the carrying packet. The contents of the 439 ECHO_REPLY MUST be copied from a previously received ECHO_RESPONSE. 441 All the HIP packets requiring RVS relaying facility to carry an 442 answer packet MUST be augmented by the RVS with an ECHO_REQUEST 443 parameter. 445 A possible packet answered via the RVS, thus requiring relaying 446 facility, MUST be authenticated by an ECHO_REPLY parameter. The 447 contents of the ECHO_REPLY MUST be copied from a previously received 448 ECHO_RESPONSE. 450 On the receiving side, when a HIP node validates an ECHO_REPLY 451 located after the signatures, it MUST remove it from the packet and 452 recompute packet length and checksum accordingly. 454 4.1.2 REA Parameter 456 A HIP node associated via an RVS MAY use a REA parameter to make its 457 correspondent aware of its veritable current IP address. If used, 458 the REA parameter MUST be used in conformance with the guidelines 459 specified in [5]. 461 4.2 New Registration Type 463 This specification defines an additional Registration Type to use 464 within the HIP Registration protocol [2] while registering with a 465 Rendezvous Server for the Rendezvous Service. 467 Number Registration Type 468 ------ ----------------- 469 1 RENDEZVOUS 471 4.3 New Parameter Formats and Processing 472 4.3.1 RVR_TYPE Parameter 474 The RVR_RYPE is an OPTIONAL parameter allowing a Rendezvous Server 475 and its Requesters to negotiate the type of Rendezvous Service 476 provided by a Rendezvous Registration. 478 0 1 2 3 479 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 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Type | Length | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | RVR Type #1 | RVR Type #2 | | 484 +-+-+-+-+-+-+-+-+---------------+ Padding | 485 | | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 Type [ TBD by IANA {110) ] 489 Length 8 490 RVR Type An 8 bit number indicating the specific type of the 491 Rendezvous Server/Service. 493 Number RVR Type Definition 495 ------ ------------- ----------------------- 497 1 TUNNEL_I1 Tunneling I1 - Section 3.3.1 499 2 REWRITE_I1 Rewriting I1 - Section 3.3.2 501 3 BIDIRECTIONAL Rewriting I1 and followers - Section 3.3.3 503 3-200 Reserved by IANA 505 201-255 Reserved by IANA for private use 507 A Requester of a Rendezvous Registration SHOULD include the RVR_RYPE 508 parameter along with any REG_REQUEST for the Rendezvous Service. 509 This parameter specifies the desired RVS Type (i.e. TUNNEL_I1, 510 REWRITE_I1 or BIDIRECTIONAL). It SHOULD NOT include the parameter 511 unless there is a REG_REQUEST parameter included along. 513 A Rendezvous Server SHOULD include a RVR_TYPE parameter along with 514 any REG_INFO announcing support for the Rendezvous Service. This 515 parameter SHOULD specify all the RVR Types supported by the 516 Rendezvous Server, in preference order. 518 A Rendezvous Server MUST include a RVR_RYPE parameter along with any 519 REG_RESPONSE establishing a Rendezvous Registration. This parameter 520 MUST specify a single RVR Type for the established Registration. 522 A Rendezvous Server SHOULD NOT include the parameter unless there is 523 a REG_INFO or REG_REQUEST parameter included along. 525 4.3.2 RVR_HMAC Parameter 527 The RVR_HMAC is an OPTIONAL parameter whose only difference with the 528 HMAC parameter defined in [4] is the Type code, making it situated 529 after the TO and FROM parameters (as opposed to HMAC): 531 Type [ TBD by IANA {65320) ] 532 Length 20 533 HMAC 160 low order bits of a HMAC keyed with the appropriate 534 HIP integrity keys (HIP_lg or HIP_gl) of the corresponding 535 HIP Association. This HMAC is computed over the HIP packet 536 excluding RVR_HMAC and any other following parameter. 537 The checksum field MUST be set to zero and the HIP header 538 length in the HIP common header MUST be calculated not to 539 cover any excluded parameter when the Authenticator field 540 is calculated. 542 To allow a Rendezvous Client and its RVS to verify the integrity of 543 packets flowing between them, both use an RVR_HMAC parameter keyed 544 with a HMAC of HIP_lg and HIP_gl integrity keys. One RVR_HMAC SHOULD 545 be present on every packets flowing between a client and a server and 546 MUST be present when FROM and TO parameters are processed. 548 On the receiving side, when an RVR_HMAC is validated, it SHOULD be 549 removed from the packet and if so, packet length and checksum MUST be 550 recomputed accordingly. 552 4.3.3 FROM Parameter 554 0 1 2 3 555 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 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | Type | Length | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | | 560 | Address | 561 | | 562 | | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 Type [ TBD by IANA {65100 under signature, 65300 after) ] 566 Length 16 567 Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address 569 A Rendezvous Server MAY add a FROM parameter containing the original 570 source IP address of a HIP packet whose source IP address has been 571 rewritten. If one or more FROM parameters are already present, the 572 new FROM parameter MUST be appended after the existing ones. 574 Each time an RVS inserts a FROM parameter, it MUST also insert an 575 RVR_HMAC protecting the packet integrity that the Rendezvous Client 576 will use to validate this packet. 578 If the type of the RVR allows the Rendezvous Client to answer to a 579 relayed packet via the RVS, an ECHO_REQUEST MUST be included along 580 with the FROM parameter. It contains a chunk of opaque data allowing 581 to validate TO parameters included in a subsequent answer. These TO 582 parameters MUST be protected by an ECHO_RESPONSE containing the same 583 opaque data. 585 When a HIP node validates a FROM parameter, it is removed from the 586 packet and recorded for later use (i.e., for building the 587 corresponding TO parameter to be piggy-backed onto a subsequent 588 answer). The packet's source IP address is also replaced by the 589 address included in the first occurrence of FROM parameter. 591 For each FROM parameter, a HIP node MAY add to its replies a TO 592 parameter containing the IP address included in the FROM. These 593 replies will be sent via the RVS, which MUST remove the outer TO 594 parameter from the packet and replace its destination address with 595 the address contained in the TO parameter before relaying it. 597 4.3.4 TO Parameter 599 0 1 2 3 600 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 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | Type | Length | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | | 605 | Address | 606 | | 607 | | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 Type [ TBD by IANA {65102 under signature, 65302 after) ] 611 Length 16 612 Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address 614 A HIP node MAY add one or more TO parameter containing the final 615 destination IP address of a HIP packet whose destination IP address 616 needs to be rewritten by an RVS. This is essentially equivalent to 617 loose source-routing. If one or more TO parameters are already 618 present, the new TO parameter MUST be appended after the existing 619 ones. Each time a node inserts a TO parameter, it MUST also insert 620 additional parameters that will be used by the RVS for validation. 621 These parameters are: 623 o An ECHO_RESPONSE, containing a chunk of opaque data allowing the 624 RVS to validate the address contained in the TO parameter. 626 o A valid RVR_HMAC, protecting the packet integrity. 628 When the RVS validates a TO parameter, SHALL remove it from the 629 packet, and SHALL replace the packet destination IP address with the 630 address included in the TO parameter. Packet length and checksum 631 MUST then be recomputed accordingly. 633 For each FROM parameter, a HIP node MAY add to its replies a TO 634 parameter containing the IP address included in the FROM. These 635 replies will be sent via the RVS, which MUST remove the outer TO 636 parameter from the packet and replace its destination address field 637 with the address contained in the TO parameter before relaying it. 639 4.3.5 VIA_RVS Parameter 641 0 1 2 3 642 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 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 | Type | Length | 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 | | 647 | Address | 648 | | 649 | | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 . . . 652 . . . 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 | | 655 | Address | 656 | | 657 | | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 Type [ TBD by IANA {65500) ] 661 Length Variable 662 Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address 664 At some point a, HIP endpoint might be in position to begin to send 665 HIP packets directly towards the remote HIP endpoint's IP address, 666 without further assistance from one or more of its RVS(s). In that 667 case, it MAY include in these packets a subset of the IP address(es) 668 of its RVSs for debugging purposes. 670 Similarly, a RVS relaying an I1 to the Responder or an R1 to the 671 Initiator MAY include in these packets its IP address for debugging 672 as well. 674 When the IP address of a RVS need to be included in a packet, by 675 either an end-node or the RVS itself, one of these two methods is 676 used: 678 o Add RVS IP address into an existing VIA_RVS parameter situated at 679 the end of the HIP packet, while modifying accordingly the size of 680 the parameter. 682 o Append a newly created VIA_RVS parameter at the end of the HIP 683 packet if it does not already contain a VIA_RVS parameter. 685 Note that the main goal of using the VIA_RVS parameter is to allow 686 operators to diagnose possible issues encountered while establishing 687 a HIP association via a RVS. 689 5. Security Considerations 691 The security aspects of different HIP rendezvous mechanisms are 692 currently being investigated. This section describes the known 693 threats introduced by these HIP extensions, and implications on the 694 overall security of HIP and IP. In particular, the following tries 695 to show that the extensions described in this document do not 696 introduce additional threats in the Internet infrastructure. 698 It is difficult to encompass the whole scope of threats introduced by 699 Rendezvous Servers because their presence have implications both at 700 the IP and HIP layer. In particular, the extensions hereby described 701 might allow for redirection, amplification and reflection attacks at 702 the IP layer, as well as attacks on the HIP layer itself, for example 703 Man-in-the-Middle attacks against the cryptographic core-protocol 704 SIGMA used by HIP. 706 If an Initiator has an a priori knowledge of the Responder's HI when 707 it first contacts it via the RVS, it has a means to verify the 708 signatures in the HIP exchange, thus conforming to the SIGMA protocol 709 which is resilient to Man-in-the-Middle attacks. 711 If an Initiator has not an a priori knowledge of the Responder's HI 712 (so called Opportunistic Initiators), it is almost impossible to 713 defend the HIP exchange against MitM attacks (cannot authenticate 714 public keys exchanged). The only solution is to mitigate hijacking 715 threats on the HIP state by requiring an R1 answering an 716 Opportunistic I1 to come from the IP address where the I1 was 717 initially sent. That way we retain a level of security which is 718 equivalent to what exists today in the Internet: By sending an IP 719 packet to an IP address, and receiving an answered IP packet from 720 this same IP address, I know that the routing fabric trusts my 721 correspondent to be represented by this IP address. While it is true 722 that such security is weak, it is better than none, and avoids to 723 introduce additional threats at the IP layer. 725 6. IANA Considerations 727 This document updates the IANA Registry for HIP Parameters Types by 728 assigning new HIP Parameter Types values for the new HIP Parameters 729 defined in Section 4.3: 731 o RVR_TYPE (defined in Section 4.3.1) 733 o RVR_HMAC (defined in Section 4.3.2) 734 o FROM (defined in Section 4.3.3) 736 o TO (defined in Section 4.3.4) 738 o VIA_RVS (defined in Section 4.3.5) 740 IANA needs to open a new registry specific to the HIP Rendezvous 741 Extensions, for the Rendezvous Registration (RVR) Types values 742 defined in Section 4.3.1: 744 Type number RVR Type 746 ----------- -------- 748 0 Reserved by IANA 750 1 TUNNEL_I1 752 2 REWRITE_I1 754 3 BIDIRECTIONAL 756 3-200 Reserved by IANA 758 201-255 Reserved by IANA for private use 760 Adding new reservations requires IETF consensus RFC2434 [7]. 762 7. Acknowledgments 764 The following people have provided thoughtful and helpful discussions 765 and/or suggestions that have improved this document: Marcus Brunner, 766 Tom Henderson, Miika Komu, Mika Kousa, Pekka Nikander, Simon Schuetz, 767 Tim Shepard, Kristian Slavov, Martin Stiemerling, and Juergen 768 Quittek. 770 Part of this work is a product of the Ambient Networks project, 771 partially supported by the European Commission under its Sixth 772 Framework Programme. It is provided "as is" and without any express 773 or implied warranties, including, without limitation, the implied 774 warranties of fitness for a particular purpose. The views and 775 conclusions contained herein are those of the authors and should not 776 be interpreted as necessarily representing the official policies or 777 endorsements, either expressed or implied, of the Ambient Networks 778 project or the European Commission. 780 8. References 782 8.1 Normative References 784 [1] Moskowitz, R. and P. Nikander, "Host Identity Protocol 785 Architecture", draft-ietf-hip-arch-00 (work in progress), 786 October 2004. 788 [2] Laganier, J., Koponen, T. and L. Eggert, "Host Identity Protocol 789 (HIP) Registration Extensions", 790 draft-koponen-hip-registration-00 (work in progress), January 791 2005. 793 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 794 Levels", BCP 14, RFC 2119, March 1997. 796 [4] Moskowitz, R., Nikander, P. and P. Jokela, "Host Identity 797 Protocol", draft-ietf-hip-base-01 (work in progress), October 798 2004. 800 [5] Nikander, P., "End-Host Mobility and Multi-Homing with Host 801 Identity Protocol", draft-ietf-hip-mm-00 (work in progress), 802 October 2004. 804 8.2 Informative References 806 [6] Saltzer, J., "On the Naming and Binding of Network 807 Destinations", RFC 1498, August 1993. 809 [7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 810 Considerations Section in RFCs", BCP 26, RFC 2434, October 811 1998. 813 [8] Nikander, P. and J. Laganier, "Host Identity Protocol (HIP) 814 Domain Name System (DNS) Extensions", draft-ietf-hip-rvs-00 815 (work in progress), October 2004. 817 [9] Ferguson, P. and D. Senie, "Network Ingress Filtering: 818 Defeating Denial of Service Attacks which employ IP Source 819 Address Spoofing", BCP 38, RFC 2827, May 2000. 821 [10] Killalea, T., "Recommended Internet Service Provider Security 822 Services and Procedures", BCP 46, RFC 3013, November 2000. 824 Authors' Addresses 826 Julien Laganier 827 Sun Labs (Sun Microsystems) & LIP (CNRS/INRIA/ENSL/UCBL) 828 180, Avenue de l'Europe 829 Saint Ismier CEDEX 38334 830 FR 832 Phone: +33 476 188 815 833 EMail: ju@sun.com 834 URI: http://research.sun.com/ 836 Lars Eggert 837 NEC Network Laboratories 838 Kurfuersten-Anlage 36 839 Heidelberg 69115 840 DE 842 Phone: +49 6221 90511 43 843 Fax: +49 6221 90511 55 844 EMail: lars.eggert@netlab.nec.de 845 URI: http://www.netlab.nec.de/ 847 Appendix A. Document Revision History 849 +-----------+-------------------------------------------------------+ 850 | Revision | Comments | 851 +-----------+-------------------------------------------------------+ 852 | 01 | Splitted out the registration sub-protocol. Simplify | 853 | | typology of relaying techniques (keep only TUNNEL, | 854 | | REWRITE, BIDIRECTIONAL). Rewrote IANA Considerations. | 855 | 00 | Initial version as a HIP WG item. | 856 +-----------+-------------------------------------------------------+ 858 Intellectual Property Statement 860 The IETF takes no position regarding the validity or scope of any 861 Intellectual Property Rights or other rights that might be claimed to 862 pertain to the implementation or use of the technology described in 863 this document or the extent to which any license under such rights 864 might or might not be available; nor does it represent that it has 865 made any independent effort to identify any such rights. Information 866 on the procedures with respect to rights in RFC documents can be 867 found in BCP 78 and BCP 79. 869 Copies of IPR disclosures made to the IETF Secretariat and any 870 assurances of licenses to be made available, or the result of an 871 attempt made to obtain a general license or permission for the use of 872 such proprietary rights by implementers or users of this 873 specification can be obtained from the IETF on-line IPR repository at 874 http://www.ietf.org/ipr. 876 The IETF invites any interested party to bring to its attention any 877 copyrights, patents or patent applications, or other proprietary 878 rights that may cover technology that may be required to implement 879 this standard. Please address the information to the IETF at 880 ietf-ipr@ietf.org. 882 Disclaimer of Validity 884 This document and the information contained herein are provided on an 885 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 886 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 887 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 888 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 889 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 890 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 892 Copyright Statement 894 Copyright (C) The Internet Society (2005). This document is subject 895 to the rights, licenses and restrictions contained in BCP 78, and 896 except as set forth therein, the authors retain all their rights. 898 Acknowledgment 900 Funding for the RFC Editor function is currently provided by the 901 Internet Society.