idnits 2.17.00 (12 Aug 2021) /tmp/idnits42244/draft-eggert-hip-rendezvous-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing revision: the document name given in the document, 'draft-eggert-hip-rendezvous', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-eggert-hip-rendezvous', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-eggert-hip-rendezvous', but the file name used is 'draft-eggert-hip-rendezvous-00' == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 5, 2004) is 6679 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-06) exists of draft-moskowitz-hip-arch-05 -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-09) exists of draft-moskowitz-hip-08 -- Possible downref: Normative reference to a draft: ref. '3' == Outdated reference: A later version (-02) exists of draft-nikander-hip-mm-01 -- Possible downref: Normative reference to a draft: ref. '4' ** Downref: Normative reference to an Informational RFC: RFC 3022 (ref. '8') ** Downref: Normative reference to an Informational RFC: RFC 2993 (ref. '9') ** Downref: Normative reference to an Informational RFC: RFC 3235 (ref. '10') ** Downref: Normative reference to an Informational RFC: RFC 3053 (ref. '11') ** Obsolete normative reference: RFC 3344 (ref. '12') (Obsoleted by RFC 5944) -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. '15') (Obsoleted by RFC 4301) == Outdated reference: A later version (-09) exists of draft-nikander-esp-beet-mode-00 Summary: 8 errors (**), 1 flaw (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Eggert 3 Internet-Draft NEC 4 Expires: August 5, 2004 February 5, 2004 6 Host Identity Protocol (HIP) Rendezvous Mechanisms 7 draft-eggert-hip-rendezvous 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at http:// 24 www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on August 5, 2004. 31 Copyright Notice 33 Copyright (C) The Internet Society (2004). All Rights Reserved. 35 Abstract 37 This document discusses rendezvous mechanisms for the Host Identity 38 Protocol (HIP). Rendezvous mechanisms, such as HIP Rendezvous 39 Servers, improve operation when HIP nodes are multi-homed or mobile. 40 They can also facilitate communication between HIP and non-HIP nodes. 41 Possible rendezvous mechanisms differ in performance, compatibility, 42 and impact on the HIP and Internet architectures. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 47 2. Communication Between HIP Nodes . . . . . . . . . . . . . . 5 48 3. Communication Between Mobile or Multi-Homed HIP Nodes . . . 7 49 3.1 Mobility and Multi-Homing with DNS Updates . . . . . . . . . 7 50 3.2 Mobility and Multi-Homing with Rendezvous Servers . . . . . 8 51 4. Communication Between HIP and Non-HIP Nodes . . . . . . . . 11 52 4.1 Non-HIP Initiator to HIP Responder . . . . . . . . . . . . . 11 53 4.2 HIP Initiator to Non-HIP Responder . . . . . . . . . . . . . 12 54 4.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 13 55 4.3.1 Relaying Overhead . . . . . . . . . . . . . . . . . . . . . 14 56 4.3.2 Return Traffic . . . . . . . . . . . . . . . . . . . . . . . 14 57 4.3.3 Node Identification . . . . . . . . . . . . . . . . . . . . 14 58 4.3.4 Network Address Translation . . . . . . . . . . . . . . . . 15 59 5. Rendezvous Broker . . . . . . . . . . . . . . . . . . . . . 16 60 5.1 Comparison to Rendezvous Servers . . . . . . . . . . . . . . 17 61 5.2 Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . 18 62 5.3 Tunneling . . . . . . . . . . . . . . . . . . . . . . . . . 18 63 6. Security Considerations . . . . . . . . . . . . . . . . . . 20 64 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 21 65 Normative References . . . . . . . . . . . . . . . . . . . . 22 66 Informative References . . . . . . . . . . . . . . . . . . . 23 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . 24 68 A. Document Revision History . . . . . . . . . . . . . . . . . 25 69 Intellectual Property and Copyright Statements . . . . . . . 26 71 1. Introduction 73 The current Internet uses two global namespaces: domain names and IP 74 addresses. The Domain Name System (DNS) provides a two-way lookup 75 service between the two [1]. Domain names are symbolic identifiers 76 for sets of IP addresses. 78 IP addresses have two uses. First, they are topological locators for 79 network attachment points. Second, they act as names for the attached 80 network interfaces. Saltzer [13] discusses these naming concepts in 81 detail. 83 Routing and other network-layer mechanisms are based on the locator 84 aspects of IP addresses. Transport-layer protocols and mechanisms 85 typically use IP addresses in their role as names for communication 86 endpoints. 88 This dual use of IP addresses limits the flexibility of the Internet 89 architecture. The need to avoid readdressing in order to maintain 90 existing transport-layer connections complicates advanced 91 functionality, such as mobility, multi-homing, or network 92 composition. Sunshine summarizes the consequences of addressing on 93 advanced network functions [14]. 95 The Host Identity Protocol (HIP) architecture [2] defines a new third 96 namespace. The Host Identity namespace decouples the name and locator 97 roles currently filled by IP addresses. Instead of mapping domain 98 names directly into IP addresses, HIP maps domain names into Host 99 Identities, and Host Identities into IP addresses. Transport-layer 100 mechanisms operate on Host Identities instead of using IP addresses 101 as endpoint names. Network-layer mechanisms continue to use IP 102 addresses as pure locators. 104 Without HIP, nodes establish transport-layer connections by first 105 looking up the fully-qualified domain name (FQDN) of a peer in the 106 DNS. A successful DNS lookup returns the peer's IP addresses. A node 107 uses one of the returned IP addresses to initiate transport-layer 108 communication with a peer node. 110 HIP nodes will also look up the domain name of desired peers in the 111 DNS. When a successful lookup includes a peer's Host Identities, HIP 112 nodes perform a HIP Base Exchange before establishing transport-layer 113 connections. The HIP Base Exchange authenticates the end hosts and 114 can bootstrap encryption of the subsequent communication with IPsec 115 [15]. The HIP specification [3] discusses the details of the Base 116 Exchange and the related protocol exchanges. 118 After the Base Exchange, HIP nodes use Host Identities instead of IP 119 addresses for transport-layer connections with a peer. The HIP layer 120 in the network stack internally translates Host Identities (HI) into 121 network-layer IP addresses. This additional mapping between Host 122 Identities and IP addresses (HI->IP) is logically separate from the 123 first mapping between fully-qualified domain names and Host 124 Identities (FQDN->HI). 126 For application and transport-layer compatibility, the FQDN->HI 127 mapping must remain in the DNS. However, the HI->IP mapping is 128 internal to the HIP layer and may be performed in a number of ways. 129 Different lookup mechanism may support communication between two 130 mobile or multi-homed HIP nodes better [4]. 132 Transparent communication between HIP and non-HIP nodes places 133 additional restrictions on the lookup mechanisms. For example, 134 non-HIP nodes expect DNS lookups to return IP addresses, requiring 135 the HI->IP mapping (or a representation thereof) to remain in the 136 DNS. Section 4 discusses communication between HIP and non-HIP nodes 137 and describes different alternatives that support it. 139 2. Communication Between HIP Nodes 141 In the current Internet, the DNS provides a FQDN->IP mapping. With 142 HIP, it must continue to provide a mapping based on domain names. 143 This allows transport-layer connections to bind to Host Identities 144 instead of IP addresses transparently. 146 Instead of mapping domain names directly into IP addresses 147 (FQDN->IP), with HIP the DNS maps them to Host Identities (FQDN->HI). 148 In a second step, another lookup that is internal to the HIP-layer 149 translates the Host Identities into IP addresses for network-layer 150 delivery (HI->IP). 152 Several alternative approaches are possible for maintaining the 153 HI->IP information. The DNS can maintain this mapping along with the 154 FQDN->HI mapping. Alternatively, a database separate from the DNS can 155 manage this information. This section discusses the different 156 approaches and their implications on communication between two HIP 157 nodes. Section 4 will discuss the compatibility aspects of the 158 alternatives described here when HIP and non-HIP nodes communicate. 160 The HIP architecture and protocol specifications suggest storing Host 161 Identities along with a node's IP addresses in the DNS [2][3]. The 162 index for both tables will be domain names. Logically, the DNS will 163 thus contain two separate mappings: FQDN->HI and FQDN->IP. 165 #1 FQDN(R) +----------+ 166 +-------------------->| DNS | 167 | +-------------------| | 168 | | #2 HI(R), IP(R) | FQDN->HI | 169 | | | FQDN->IP | 170 | | +----------+ 171 | V 172 +-----+ #3 HIP Base Exchange +-----+ 173 | |-------------------------------->| | 174 | I |<--------------------------------| R | 175 | |-------------------------------->| | 176 | |<--------------------------------| | 177 +-----+ +-----+ 179 Figure 1: HIP Lookup and Base Exchange 181 Figure 1 shows the lookup steps and HIP Base Exchange when a node's 182 Host Identities are stored alongside its IP addresses. In step #1, 183 the initiator I performs a DNS lookup on R's domain name FQDN(R). The 184 DNS server responds with both R's Host Identities HI(R) and its IP 185 addresses IP(R) in step #2. 187 The initiator I uses both pieces of information to perform the HIP 188 Base Exchange with R in step #3. (The details of the Base Exchange, 189 specified in [3], are not relevant to this discussion and will thus 190 be omitted.) 192 Note that the DNS does not currently store the HI->IP mapping 193 directly. Instead, a DNS lookup on a domain name returns both its 194 FQDN->HI and FQDN->IP entries. The HIP stack then implicitly 195 constructs the HI->IP mapping based on the HI and IP information 196 returned by the DNS lookup. In the example in Figure 1, the FQDN(R) 197 lookup in step #1 returns both HI(R) and IP(R) in step #2. HIP 198 implicitly constructs the HI(R)->IP(R) mapping based on the 199 assumption that HI(R) is reachable at IP(R). 201 One disadvantage of this approach is that a node's domain name is 202 required to obtain both its Host Identities and its IP addresses. 203 Even if a HIP node already knows the Host Identity of a HIP peer 204 through other means, it cannot currently obtain the peer's IP 205 addresses through the DNS. The DNS does not maintain an explicit 206 HI->IP table, but instead indexes Host Identities only by domain 207 names. 209 A reverse HIP->FQDN DNS mapping could address this limitation. HIP 210 nodes would then look up a HIP peer's domain name through its Host 211 Identity. They would then use the returned domain name to find the 212 peer's IP addresses in a second lookup. However, the DNS may not be 213 structurally suited to maintain the reverse HIP->FQDN mapping. As the 214 main Internet-wide database, the DNS is already being overloaded with 215 functionality that might be better handled with new mechanisms [16]. 216 Finally, the additional reverse lookup would increase the latency of 217 the HIP Base Exchange. 219 3. Communication Between Mobile or Multi-Homed HIP Nodes 221 HIP decouples domain names from IP addresses. Because transport 222 protocols bind to Host Identities, they remain unaware if the set of 223 IP addresses associated with a Host Identity changes. This change can 224 have various reasons, including, but not limited to, mobility and 225 multi-homing. 227 Proposed extensions for mobility and multi-homing [4] allow a HIP 228 node to notify its peers about changes in its set of IP addresses. 229 These extensions require an established HIP association between two 230 nodes, i.e., a completed HIP Base Exchange. 232 In addition to notifying its current peers about changes in its IP 233 addresses, a HIP node must also update its HI->IP mapping in response 234 to IP address changes. Otherwise, HIP Base Exchanges from new peers 235 could fail because they try to contact the node at an IP address it 236 is no longer reachable at. 238 3.1 Mobility and Multi-Homing with DNS Updates 240 If the DNS indirectly maintains the HI->IP mapping in a FQDN->IP 241 table, nodes can dynamically update their DNS entry in a secure 242 fashion [5][6]. The DNS server maintaining the information will then 243 sign and distribute the updated zone. 245 #2 FQDN(R) +----------+ 246 +-------------------->| DNS | 247 | +-------------------| |<------+ 248 | | #3 HI(R), IP(R) | FQDN->HI | | #1 Update 249 | | | FQDN->IP | | FQDN(R)->IP(R) 250 | | +----------+ | whenever IP(R) 251 | V | changes. 252 +-----+ #4 HIP Base Exchange +-----+ 253 | |-------------------------------->| | 254 | I |<--------------------------------| R | 255 | |-------------------------------->| | 256 | |<--------------------------------| | 257 +-----+ +-----+ 259 Figure 2: HIP Lookup and Base Exchange with DNS Updates 261 Figure 2 shows an example of this scenario. In step #1, R registers 262 its FQDN(R)->IP(R) entry in the DNS. It will dynamically update the 263 DNS entry whenever its IP addresses IP(R) change. Because the DNS 264 always contains R's current IP addresses, node I can perform a HIP 265 Base Exchange with R at its new IP address (steps #2-4). 267 One drawback of using dynamic DNS updates in this way is the cost of 268 updating secure zones. Re-signing an entire zone whenever the IP 269 addresses of one entry change places a high cost on the DNS server. 270 Using dynamic DNS to update HI->IP mappings may thus not be 271 appropriate when changes of IP addresses are frequent. 273 A simple, operational change could help limit the costs of frequent 274 DNS updates. Instead of recomputing a zone after each dynamic update, 275 a DNS server could aggregate the modifications and only perform zone 276 updates periodically. The disadvantage of this approach is that HIP 277 nodes may be unreachable until the DNS server distributes the updated 278 zone. 280 Another concern with using the DNS to support HIP node mobility is 281 the propagation time of updated DNS entries. DNS servers frequently 282 cache DNS responses to reduce the load on the primary servers. During 283 the time-to-live associated with a DNS response, DNS servers may 284 answer additional requests for the same DNS entry from their local 285 caches instead of contacting the primary servers. Thus, even after a 286 HIP node updates its DNS entry, the DNS can still serve the old entry 287 until the cached responses expire. This can lead to communication 288 problems, because peers may try to contact a HIP node at an IP 289 address it is no longer reachable at. 291 3.2 Mobility and Multi-Homing with Rendezvous Servers 293 The HIP architecture tries to greatly reduce the frequency of Dynamic 294 DNS updates by introducing Rendezvous Servers [2]. Instead of 295 registering its current set of IP addresses in its HI->IP entry in 296 the DNS, a HIP node may instead register the IP addresses of its 297 Rendezvous Servers. Because the IP addresses of Rendezvous Servers 298 are assumed to change only infrequently, this approach can 299 significantly reduce the load on DNS servers. 301 Rendezvous Servers maintain a mapping between the Host Identities of 302 HIP nodes for which they provide service and the node's current IP 303 addresses. HIP nodes must notify their Rendezvous Servers about any 304 changes in their IP addresses. This approach effectively relocates 305 the HI->IP information - and the burden of keeping it current - from 306 the DNS to the Rendezvous Servers. This can reduce update costs under 307 the assumption that Rendezvous Servers provide more efficient ways of 308 maintaining HI->IP tables. 310 When a packet destined for one of its HIP nodes arrives at a 311 Rendezvous Server, it relays the packet to one of the HIP node's 312 current IP addresses. Due to the specifics of the HIP, only the first 313 packet of a HIP Base Exchange will require such relaying [2]. 314 Subsequent packet of the HIP Base Exchange and all further data 315 packets will directly flow between the HIP nodes, bypassing the 316 Rendezvous Server. 318 #3 FQDN(R) +----------+ #2 Register IP(RVS) in 319 +--------------------->| DNS | FQDN(R)->IP(RVS). 320 | +--------------------| |<------------------+ 321 | | #4 HI(R), IP(RVS) | FQDN->HI | | 322 | | | FQDN->IP | | 323 | | +----------+ | 324 | | | 325 | | #1 Update IP(R) in HI(R)->IP(R) | 326 | | +--------+ whenever IP(R) changes. | 327 | | | RVS |<------------------------------+ | 328 | | | | | | 329 | V +->| HI->IP |--+ | | 330 +-----+ | +--------+ | +-----+ 331 | |---+ +------------------------->| | 332 | I | #5 First Message of HIP Base Exchange | R | 333 | | | | 334 | |<--------------------------------------------| | 335 | |-------------------------------------------->| | 336 | |<--------------------------------------------| | 337 +-----+ #6 Remainder of HIP Base Exchange +-----+ 339 Figure 3: HIP Lookup and Base Exchange with Rendezvous Server 341 Figure 3 shows a HIP lookup and Base Exchange involving a Rendezvous 342 Server. Here, HIP node R is using Rendezvous Server RVS. In step #1, 343 it updates RVS with its current IP addresses IP(R). Then, in step #2, 344 R registers the Rendezvous Server's IP addresses IP(RVS) in its 345 FQDN(R)->IP(RVS) DNS entry. 347 In step #3, a second HIP node I issues a DNS lookup on FQDN(R) to 348 obtain R's Host Identities HI(R) and IP addresses. The lookup returns 349 R's Host Identities HI(R) in step #4. The DNS reply also includes the 350 IP addresses of the Rendezvous Server IP(RVS) (instead of IP(R), 351 because R's current addresses are unknown to the DNS.) 353 In step #5, node I initiates the HIP Base Exchange. It addresses the 354 first packet of the HIP Base Exchange to IP(RVS). Upon receipt, the 355 Rendezvous Server relays the packet to one of R's current IP 356 addresses IP(R). The remainder of the HIP Base Exchange then occurs 357 directly between I and R in step #6. 359 When Rendezvous Servers maintain the HI->IP information, they may 360 support more efficient update operations compared to dynamic DNS 361 updates (Section 3.1). Unlike the DNS, Rendezvous Servers do not 362 provide a lookup service. Instead, they use the HI->IP information to 363 actively relay traffic between HIP nodes. 365 This approach changes the role of the IP addresses stored in a DNS 366 entry. Traditionally, nodes were directly reachable at the IP 367 addresses listed in their DNS entry. HIP Rendezvous Server change 368 this basic property by replacing the IP addresses of their client 369 nodes in the DNS with their own. The IP addresses in a DNS entry 370 hence no longer directly designate interfaces of an endpoint. 371 Instead, they identify interfaces of a node that can relay packets to 372 the endpoint. 374 When two HIP nodes communicate, this change has few consequences. HIP 375 decouples higher layers from underlying IP addresses. However, when 376 HIP and non-HIP nodes communicate, this change has a significant 377 impact on the overall architecture. Section 4 will discuss the 378 implications in detail. 380 4. Communication Between HIP and Non-HIP Nodes 382 Section 2 and Section 3 have discussed communication between HIP 383 nodes. This section focuses on communication between HIP and non-HIP 384 nodes. Two different scenarios exist. First, a HIP initiator may 385 start communication with a non-HIP recipient. Second, a non-HIP 386 initiator may try to contact a HIP recipient. 388 Without Rendezvous Servers, communication between HIP and non-HIP 389 nodes remains identical to the current Internet. Transport-layer 390 protocols bind directly to IP addresses. When IP addresses change, 391 due to mobility or other reasons, transport-layer connections break. 393 Rendezvous Servers may establish some of HIP's benefits even if one 394 of the endpoints does not support it. Rendezvous Servers live at 395 static IP addresses. They can maintain ongoing transport-layer 396 connections by acting as a relays for HIP nodes whose IP addresses 397 may change. The discussion in the remainder of this section assumes 398 that HIP nodes utilize Rendezvous Servers to maintain the HI->IP 399 information as described in Section 3. 401 The HIP architecture document [2] discusses the role of Rendezvous 402 Servers in HIP communication. However, it does not currently describe 403 the details of how Rendezvous Server relay traffic between HIP and 404 non-HIP nodes. The remainder of this section presents this aspect of 405 Rendezvous Servers. 407 4.1 Non-HIP Initiator to HIP Responder 409 In the first scenario, a non-HIP initiator starts communication with 410 a HIP node. The HIP node is using Rendezvous Servers. Figure 4 shows 411 this case. 413 Steps #1-4 remain unchanged from the HIP-HIP case shown in Figure 3 414 and discussed in Section 3.2. HIP node R registers the IP addresses 415 of its Rendezvous Server RVS in the DNS. It also keeps RVS updated 416 with its current IP addresses IP(R). 418 When non-HIP node I starts communication with R, it performs a DNS 419 lookup on FQDN(R) and receives HI(R) and IP(RVS) in return. Since I 420 does not support HIP, it disregards the Host Identity HI(R) returned 421 by the DNS lookup. Instead, it sets up transport-layer connections 422 using the IP addresses IP(RVS) obtained from the DNS. The Rendezvous 423 Server RVS must then transparently relay the communication to one of 424 R's current IP addresses IP(R) in step #5. 426 #3 FQDN(R) +----------+ #2 Register IP(RVS) in 427 +----------------------->| DNS | FQDN(R)->IP(RVS). 428 | +----------------------| |<--------------------+ 429 | | #4 HI(R), IP(RVS) | FQDN->HI | | 430 | | | FQDN->IP | | 431 | | +----------+ | 432 | | | 433 | | #1 Update IP(R) in HI(R)->IP(R) | 434 | | whenever IP(R) changes. | 435 | | +---------------------------+ | 436 | | | | | 437 | V V | | 438 +---------+ +--------+ +---------+ 439 | I | | RVS | | R | 440 | | | | | | 441 | Non-HIP |<--------------->| HI->IP |<---------------->| HIP | 442 +---------+ +--------+ +---------+ 443 #5 RVS transparently relays packets 444 IP(I)<->IP(RVS) to/from IP(R). 446 Figure 4: Non-HIP initiator to HIP responder via Rendezvous Server 448 End-to-end communication between I and R is complicated by the fact 449 that R's DNS entry lists IP addresses IP(RVS). The addresses IP(RVS) 450 belong to the Rendezvous Server RVS and not R, the endpoint of the 451 communication. I's transport layer will thus bind connections to R to 452 IP addresses IP(I) and IP(RVS). Section 4.3 will discuss the 453 implications. 455 4.2 HIP Initiator to Non-HIP Responder 457 This section describes a second scenario, where a HIP node initiates 458 communication with a non-HIP node. Figure 5 shows this case. 460 As before, the HIP node I keeps its Rendezvous server RVS updated 461 about its current IP addresses IP(I) in step #2. It also registers 462 the IP addresses of the Rendezvous Server IP(RVS) in its DNS entry in 463 step #2, instead of its own. 465 In step #3, I initiates a transport-layer connection to R by 466 performing a domain name lookup on FQDN(R). The DNS reply in step #4 467 contains R's IP addresses IP(R) but no Host Identities, because R is 468 not a HIP node. 470 #2 Register IP(RVS) in 471 FQDN(I)->IP(RVS). +----------+ 472 +-------------------------->| DNS | 473 | | | 474 | #3 FQDN(R) | FQDN->HI |<--------------------+ 475 | +----------------------->| FQDN->IP | | 476 | | +----------------------| | | 477 | | | #4 IP(I) +----------+ | 478 | | | | 479 | | | #1 Update IP(I) in HI(I)->IP(I) | 480 | | | whenever IP(I) changes. | 481 | | | +-------------------------------+ | 482 | | | | | | 483 | | V | V | 484 +---------+ +--------+ +---------+ 485 | I | | RVS | | R | 486 | | | | | | 487 | HIP |<----------------------->| HI->IP |<-------->| Non-HIP | 488 +---------+ +--------+ +---------+ 489 #5 RVS translates/relays packets 490 IP(I)<->IP(R) to/from IP(RVS). 492 Figure 5: HIP initiator to Non-HIP responder via Rendezvous Server 494 If I uses IP(R) to establish a direct transport-layer connection with 495 R, the connection will break when R's IP addresses change. Instead, R 496 relays its traffic through Rendezvous Server RVS in step #5. Since 497 the IP addresses of RVS are static, the transport-layer connection 498 between I and R remains unaffected from changes to R's IP addresses. 500 4.3 Discussion 502 As illustrated by the two scenarios described in Section 4.1 and 503 Section 4.2, Rendezvous Servers can isolate non-HIP nodes from 504 changes to their HIP peers' IP addresses. Binding transport-layer 505 connections to static IP addresses of Rendezvous Servers, instead of 506 the more volatile addresses of HIP peers, allows connections between 507 HIP and non-HIP nodes to retain some of the benefits of HIP-HIP 508 connections. 510 The current HIP architecture document [2] requires HIP nodes using 511 Rendezvous Servers to register the Rendezvous Server's IP addresses 512 in the DNS. Consequently, Rendezvous Servers become explicit 513 connections endpoints. This causes several challenges for end-to-end 514 communication, as discussed in the next sections. 516 4.3.1 Relaying Overhead 518 The first issue is relaying overhead. When HIP nodes communicate, 519 Rendezvous Servers will only need to relay the first packet of a HIP 520 Base Exchange. The remaining HIP Base Exchange packets, as well as 521 all subsequent data packets, will flow directly between the HIP 522 nodes. 524 This is not the case for communication between HIP and non-HIP nodes. 525 A non-HIP node will bind its transport-layer connection to the IP 526 address obtained by looking up the HIP peer's domain name in the DNS. 527 This will be the address of the Rendezvous Server. 529 Consequently, all data from the non-HIP to the HIP node will flow 530 through the Rendezvous Server. This can cause significant relaying 531 overhead. It can also increase the communication delay between the 532 nodes, further affecting performance. 534 Relaying overhead will be difficult to eliminate. In order to provide 535 some of the benefits of HIP, non-HIP peers communicating with HIP 536 nodes must be able to bind their transport-layer connections to 537 static IP addresses. This constraint implies the presence of a 538 statically addressed relay somewhere in the system. 540 4.3.2 Return Traffic 542 A second issue is return traffic from the HIP node to the non-HIP 543 node. Because a non-HIP node binds its transport-layer connection to 544 its peer's IP address, it will not accept return traffic from a 545 different address than it is sending to. Since all traffic from the 546 non-HIP node is addressed to the Rendezvous Server, the non-HIP node 547 will expect to receive return traffic from that source address. 549 Several approaches may address this issue. First, the HIP node may 550 relay all its return traffic through the Rendezvous Server as well. 551 This causes additional relaying overhead. Second, the HIP node may 552 spoof the IP address of the Rendezvous Server when sending return 553 traffic. This may cause problems when firewalls along the path 554 perform ingress filtering [7]. Finally, the approach described in 555 Section 5 can also eliminate this issue. 557 4.3.3 Node Identification 559 A third issue is identification of the specific HIP node that a 560 Rendezvous Server must relay arriving packets to. Packets arriving 561 from non-HIP nodes are simple IP packets addressed to the Rendezvous 562 Server. They do not contain Host Identities or other information that 563 will allow the Rendezvous Server to identify the correct HIP node for 564 relaying. 566 One solution has the Rendezvous Server use multiple IP addresses. 567 Each of the HIP nodes for which it provides service receives one 568 unique IP address. The HIP node will then register this unique IP 569 address in the DNS. Hence, the Rendezvous Server can use the 570 destination IP addresses of arriving packets to identify the HIP node 571 to which they must be relayed to. The approach described in Section 5 572 uses a similar scheme. 574 A downside of registering unique IP addresses per node is a more 575 complex protocol between Rendezvous Servers and its HIP nodes. 576 Furthermore, Rendezvous Servers serving many HIP nodes may require 577 many IP addresses. 579 4.3.4 Network Address Translation 581 The HIP architecture document [2] uses the term "forwarding" to 582 describe the operation by which a Rendezvous Server enables the 583 exchange of packets between communicating nodes. This document uses 584 the term "relaying" instead, to indicate that mechanisms other than 585 IP forwarding may suit the same purpose. 587 One such approach for relaying packets between HIP and non-HIP nodes 588 is Network Address Translation [8]. When acting as a Network Address 589 Translator, a Rendezvous Server will rewrite the IP headers of 590 packets exchanged between communicating nodes. 592 The use of Network Address Translation remains problematic [9][10]. 593 Avoiding its use in the Rendezvous Server may improve protocol and 594 application compatibility. Section 5 will present a rendezvous 595 mechanism that relays using simple IP forwarding instead, avoiding 596 possible issues due to the use of Network Address Translation. 598 5. Rendezvous Broker 600 This section describes Rendezvous Brokers. Rendezvous Brokers provide 601 a modified HIP rendezvous mechanism that addresses some of the issues 602 discussed in Section 4. 604 Rendezvous Brokers are named for their similarity to tunnels brokers 605 [11]. Rendezvous Brokers also share commonalities with MobileIP's 606 Home Agents [12] as well as systems for leasing IP subnets [17]. 608 Note: Rendezvous Brokers described in this section may be similar 609 to the Packet Forwarding Agents outlined in [18]. While this 610 similarity is under discussion, this document will use the term 611 Rendezvous Broker for clarity. If the two concepts are deemed 612 identical, terminology may change. 614 Rendezvous Brokers are IP routers and manage delegations of 615 globally-routable IP subnets. Rendezvous Brokers may be located 616 anywhere in the network. HIP has no concept of home networks (unlike 617 MobileIP [12]) that would tie Rendezvous Brokers to access networks. 619 When a HIP node requests rendezvous service, the Rendezvous Broker 620 delegates a unique, globally-routable IP address (or prefix) to the 621 HIP node. HIP node and Rendezvous Broker establish a tunnel using the 622 delegated IP address as the HIP node's tunnel endpoint address. The 623 Rendezvous Broker installs a route towards the delegated IP address 624 via the tunnel. At the end of this process, the HIP node is globally 625 reachable by non-HIP nodes at the delegated IP address obtained from 626 the Rendezvous Broker. 628 Figure 6 illustrates this process. In step #1, HIP node R registers 629 its Host Identity HI(R) with the Rendezvous Broker RVB. In step #2, R 630 receives an IP address IP(T-R) from RVB. This IP address is 631 globally-routable and delegated to RVB. 633 The Rendezvous Broker and the HIP node R then establish a tunnel 634 between themselves in step #3. IP(T-R) is the IP address of R's 635 tunnel endpoint, T-RVB the endpoint address of the Rendezvous Broker. 636 The tunnel encapsulates packets with IP(RVB) and IP(R). RVB then 637 installs a route that forwards packets addressed to IP(T-R) over the 638 tunnel. 640 In step #4, R registers the IP address obtained from RVB in its DNS 641 entry. When the non-HIP initiator I performs a DNS lookup in step #6, 642 it receives IP(T-R) from the DNS (along with HI(R), which it 643 ignores). I then initiates a transport-layer connection from IP(I) to 644 IP(T-R). Packets to IP(T-R) will be routed to the RVB, because it is 645 the router for the subnet out of which IP(T-R) was allocated. The RVB 646 will then forward such packets over the tunnel to R due to the route 647 installed in step #3. 649 #5 FQDN(R) +----------+ #4 Register IP(RVB-R) in 650 +----------------------->| DNS | FQDN(R)->IP(T-R). 651 | +----------------------| |<--------------------+ 652 | | #6 HI(R), IP(T-R) | FQDN->HI | | 653 | | | FQDN->IP | | 654 | | +----------+ | 655 | V | 656 +---------+ +--------+ #1 HI(R) +---------+ 657 | | | |<--------------------------| | 658 | I | | RVB |-------------------------->| R | 659 | | | | #2 IP(T-R) | | 660 | | | | | | 661 | Non-HIP | | HI->IP |<------------------------->| HIP | 662 | | | | #3 Setup tunnel | | 663 | | | | IP(T-RVB)<->IP(T-R). | | 664 | | | | | | 665 | |<------->| |<------------------------->| | 666 +---------+ +--------+ #7 RVB forwards packets +---------+ 667 IP(I)<->IP(T-R) 668 via the tunnel. 670 Figure 6: Non-HIP initiator to HIP responder via Rendezvous Broker 672 The next sections will compare Rendezvous Brokers to Rendezvous 673 Servers and discuss several aspects of Rendezvous Brokers in more 674 detail. 676 5.1 Comparison to Rendezvous Servers 678 Rendezvous Brokers address some of the shortcomings of Rendezvous 679 Servers raised in Section 4.3. One difference is that the IP 680 addresses in a HIP node's DNS entry again identify interfaces of the 681 HIP node itself. With Rendezvous Servers, the DNS entry instead 682 identifies interfaces of the Rendezvous Server. 684 This simplifies the operation of the Rendezvous Broker. It performs 685 simple IP forwarding of packets that already carry the addresses of 686 their final source and destination endpoints. Network Address 687 Translation, or other schemes that relay by modifying packet headers, 688 are not required. This may improve application and protocol 689 compatibility. 691 Because Rendezvous Brokers are IP routers, additional mechanisms to 692 identify the correct HIP destination node for arriving packets are 693 not required. The globally-routable destination IP address already 694 acts as a unique indicator of the final destination. 696 5.2 Mobility 698 Rendezvous Brokers offer mobility support that is equivalent to 699 Rendezvous Servers. HIP nodes already notify their Rendezvous Servers 700 when their IP addresses change. Rendezvous Brokers also require such 701 notification. 703 When the IP addresses of a HIP node changes, the Rendezvous Broker 704 and the HIP node must reconfigure the tunnel between them. This 705 reconfiguration only affects the IP addresses used for tunnel 706 encapsulation. The addresses of the tunnel endpoints remain 707 unchanged. Transport-layer connections bound to a HIP node's tunnel 708 endpoint address thus remain unaffected. 710 HIP nodes may change Rendezvous Servers over time and they may use 711 multiple Rendezvous Servers at the same time. The same is true for 712 Rendezvous Brokers. Both Rendezvous Servers and Rendezvous Brokers 713 may be located anywhere in the network; unlike MobileIP [12], HIP has 714 no notion of home networks. By separating rendezvous mechanisms from 715 topological locations, HIP allows nodes to choose Rendezvous Servers 716 or Brokers based on local criteria, including network connectivity, 717 location, or mobility. 719 5.3 Tunneling 721 This document does not further define the specifics of the tunneling 722 mechanism used between a Rendezvous Broker and its HIP nodes. 723 Possible tunneling mechanisms include [19][20][21][22][23]. Different 724 tunneling mechanisms incur different overheads. Some may also offer 725 better traversal of Network Address Translators or firewalls. 727 Similarly, the tunnel setup protocol between Rendezvous Brokers and 728 HIP nodes is currently unspecified. Candidate tunnel management 729 approaches include [24][25][26]. 731 Rendezvous Brokers forward all traffic from non-HIP nodes to HIP 732 nodes over tunnels. For the return traffic from HIP nodes to non-HIP 733 nodes two options exist. First, return traffic could also flow over 734 tunnel. Second, return traffic could flow through the base network 735 over one of the HIP node's interfaces. The second alternative may 736 offer increased performance due to the avoidance of triangle routing. 737 However, firewalls that perform ingress filtering could prevent 738 communication [7]. 740 Another aspect of using tunnels to connect Rendezvous Brokers and 741 their HIP nodes is reduced Maximum Transmission Units. Implementation 742 issues in the network stacks of end systems and routers can lead to 743 communication problems in such scenarios [27]. 745 6. Security Considerations 747 The security aspects of different HIP rendezvous mechanisms are 748 currently being investigated. They will be discussed in a future 749 revision of this document. 751 7. Acknowledgments 753 The following people have provided thoughtful and helpful suggestions 754 that have improved this document: Marcus Brunner, Simon Schuetz, 755 Martin Stiemerling, and Juergen Quittek. 757 Normative References 759 [1] Mockapetris, P., "Domain names - concepts and facilities", STD 760 13, RFC 1034, November 1987. 762 [2] Moskowitz, R., "Host Identity Protocol Architecture", 763 draft-moskowitz-hip-arch-05 (work in progress), October 2003. 765 [3] Moskowitz, R., Nikander, P. and P. Jokela, "Host Identity 766 Protocol", draft-moskowitz-hip-08 (work in progress), October 767 2003. 769 [4] Nikander, P., "End-Host Mobility and Multi-Homing with Host 770 Identity Protocol", draft-nikander-hip-mm-01 (work in 771 progress), January 2004. 773 [5] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic 774 Updates in the Domain Name System (DNS UPDATE)", RFC 2136, 775 April 1997. 777 [6] Wellington, B., "Secure Domain Name System (DNS) Dynamic 778 Update", RFC 3007, November 2000. 780 [7] Ferguson, P. and D. Senie, "Network Ingress Filtering: 781 Defeating Denial of Service Attacks which employ IP Source 782 Address Spoofing", BCP 38, RFC 2827, May 2000. 784 [8] Srisuresh, P. and K. Egevang, "Traditional IP Network Address 785 Translator (Traditional NAT)", RFC 3022, January 2001. 787 [9] Hain, T., "Architectural Implications of NAT", RFC 2993, 788 November 2000. 790 [10] Senie, D., "Network Address Translator (NAT)-Friendly 791 Application Design Guidelines", RFC 3235, January 2002. 793 [11] Durand, A., Fasano, P., Guardini, I. and D. Lento, "IPv6 Tunnel 794 Broker", RFC 3053, January 2001. 796 [12] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 797 2002. 799 Informative References 801 [13] Saltzer, J., "On the Naming and Binding of Network 802 Destinations", RFC 1498, August 1993. 804 [14] Sunshine, C., "Addressing Problems in Multi-Network Systems", 805 IEN 178, April 1981. 807 [15] Kent, S. and R. Atkinson, "Security Architecture for the 808 Internet Protocol", RFC 2401, November 1998. 810 [16] Klensin, J., "Role of the Domain Name System (DNS)", RFC 3467, 811 February 2003. 813 [17] Touch, J., Eggert, L. and Y. Wang, "TetherNet Anti-NAT - Secure 814 Internet Subnet Rental System", Proc. 3rd DARPA Information 815 Survivability Conference and Exposition (DISCEX-III) 2003, 816 April 2003. 818 [18] Nikander, P., Ylitalo, J. and J. Wall, "Integrating Security, 819 Mobility, and Multi-Homing in a HIP Way", Proc. Network and 820 Distributed Systems Security Symposium (NDSS) 2003, February 821 2003. 823 [19] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 824 1996. 826 [20] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of Network 827 Address Translation (NAT) Devices", RFC 3519, May 2003. 829 [21] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina, 830 "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. 832 [22] Nikander, P., "A Bound End-to-End Tunnel (BEET) mode for ESP", 833 draft-nikander-esp-beet-mode-00 (work in progress), October 834 2003. 836 [23] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and 837 B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, 838 August 1999. 840 [24] Hamzeh, K., "Ascend Tunnel Management Protocol - ATMP", RFC 841 2107, February 1997. 843 [25] Beijnum, I., "On Demand Tunneling For Multihoming", 844 draft-van-beijnum-multi6-odt-00 (work in progress), January 845 2004. 847 [26] Touch, J., "Dynamic Internet overlay deployment and management 848 using the X-Bone", Computer Networks Vol. 36, No. 2-3, July 849 2001. 851 [27] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, 852 September 2000. 854 Author's Address 856 Lars Eggert 857 NEC Network Laboratories 858 Kurfuersten-Anlage 36 859 Heidelberg 69115 860 DE 862 Phone: +49 6221 90511 43 863 Fax: +49 6221 90511 55 864 EMail: lars.eggert@netlab.nec.de 865 URI: http://www.netlab.nec.de/ 867 Appendix A. Document Revision History 869 +-----------+-------------------------------------------------------+ 870 | Revision | Comments | 871 +-----------+-------------------------------------------------------+ 872 | 00 | Initial version. | 873 +-----------+-------------------------------------------------------+ 875 Intellectual Property Statement 877 The IETF takes no position regarding the validity or scope of any 878 intellectual property or other rights that might be claimed to 879 pertain to the implementation or use of the technology described in 880 this document or the extent to which any license under such rights 881 might or might not be available; neither does it represent that it 882 has made any effort to identify any such rights. Information on the 883 IETF's procedures with respect to rights in standards-track and 884 standards-related documentation can be found in BCP-11. Copies of 885 claims of rights made available for publication and any assurances of 886 licenses to be made available, or the result of an attempt made to 887 obtain a general license or permission for the use of such 888 proprietary rights by implementors or users of this specification can 889 be obtained from the IETF Secretariat. 891 The IETF invites any interested party to bring to its attention any 892 copyrights, patents or patent applications, or other proprietary 893 rights which may cover technology that may be required to practice 894 this standard. Please address the information to the IETF Executive 895 Director. 897 Full Copyright Statement 899 Copyright (C) The Internet Society (2004). All Rights Reserved. 901 This document and translations of it may be copied and furnished to 902 others, and derivative works that comment on or otherwise explain it 903 or assist in its implementation may be prepared, copied, published 904 and distributed, in whole or in part, without restriction of any 905 kind, provided that the above copyright notice and this paragraph are 906 included on all such copies and derivative works. However, this 907 document itself may not be modified in any way, such as by removing 908 the copyright notice or references to the Internet Society or other 909 Internet organizations, except as needed for the purpose of 910 developing Internet standards in which case the procedures for 911 copyrights defined in the Internet Standards process must be 912 followed, or as required to translate it into languages other than 913 English. 915 The limited permissions granted above are perpetual and will not be 916 revoked by the Internet Society or its successors or assignees. 918 This document and the information contained herein is provided on an 919 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 920 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 921 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 922 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 923 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 925 Acknowledgment 927 Funding for the RFC Editor function is currently provided by the 928 Internet Society.